How might it affect performance and licensing?As the full implications emerge with the design of Intel's (and potentially others) x64 processor (see more at the Register here) we await with interest a response from software vendors as to how the corresponding issue of licensing will be answered and resolved. Given patches are now being released (eg. AWS EC2 5th January, Azure the 10th January) the resultant performance impacts will become the subject of intense scrutiny. Why? well if, as reported, processing power diminishes anywhere from 5 to 30 percent how will customers be compensated? Processor and Core based software has been dutifully acquired on the basis of the underlying performance of the chipsets on which the products are run (consider IBM's PVUs, Microsofts Core minimums etc). Now though, if that proves to be erroneous, surely a remedy must be made available to the customer who has paid for a defined - and benchmarked - level of processing power? Take the scenario whereby a customers current 2,000 PVUs can no longer deliver the required throughput and needs a further 500 PVUs in order to deliver the same capability - you would be right to expect no additional charges to apply given there is no improvement in performance surely? And what about needing more hardware just to achieve the current level of demand, or a Cloud vendor purchasing an array of new servers in order to provision more vCPUs for their PaaS / SaaS customers just to meet the same CPU cycles ? That all costs money, so ... Who Pays?? Which then presents an intriguing conundrum for the chip makers and the software vendors. Presumably there will be a vast re-benchmarking exercise (and consider chipsets produced in the last 10 years are potentially affected) the question then being, what is to be done on the basis of the results? Compensation? Free License Grants? Reduced Annual Maintenance fees?? So we expectantly await vendor responses once the focus on getting fixes out shifts to the underlying and associated commercial dilemma confronting the industry. What can you do in the meantime? Firstly, make sure you have current performance metrics that you can measure any degradation against, and then pose these questions to your vendor Account Manager, your Sales Rep, your Software Specialist - ask how any performance issues you experience might be remediated in the immediate term, and request an open and regular communication channel to stay informed as it all progresses ... We firmly believe - if the projected performance impacts do transpire - this issue will prove to be one of the most perplexing problems to emerge in the IT industry in many years. Watch this space for further updates as more unfolds.
0 Comments
While these three little snippets might not seem particularly sensational they are worth noting precisely for that reason - they are likely lurking in the background, ready to cost you money when you least need it!
OK, so we all know that under the IBM sub-capacity rules we must produce a report from ILMT every quarter right? And we know that we must sign and date that record, and keep them all as an artefact that may be required during any audit too, right? All good, then the tip: Make sure you have configured ILMT correctly and fully for VM Management. What's so important about VM Management in ILMT? If not properly configured it will default to 120 PVUs per core, so you could be over-reporting without being aware. How can you tell if its configured? Firstly, it shows a status on the Dashboard, and secondly, if not configured servers will be displayed with a serial-like number beginning with 'TLM_VM' or similar. If you need more information on how to configure just look here.
Microsoft in many ways have led the industry in a shift to SaaS offerings backed by subscription based licensing. While this may appear to have a favourable ROI initially, there are other Time-Value commercial components to consider. Firstly, you need to be aware that your licensing is now not only visible but manageable real-time by Microsoft. So from a commercial perspective there is now no locked-in pricing for the typical 3 year term of an Enterprise Agreement, instead you will see price increases built-in year on year in your CPS. And more so, there is no 'True-Up' benefit whereby you would pay essentially half the cost in the year in which you deployed the product - you now 'reserve' the additional licenses you need to be drawn down, and you start paying from that month onwards. The tip? Make sure you consider TVM with subscription changes in your ROI / Cost Comparisons. And the last tip for 2017 ... a favourite topic here at Software Compliance ... processor to core conversion.
Wrong! ... A license pack is applied to a server, so where you have say a 12 Core server you need to assign 6 x 2 Core packs - you can't assign 12 from your 16 Core pack, and then apply the other 4 elsewhere. A nasty - and potentially expensive error - if not properly considered in determining your conversion. And so ends 2017 ... we look forward to a busy and productive 2018 for us all!
Gone are the more simplistic days of Microsoft Per Processor licensing when there was a basic assignment of a single license to a processor, unlimited use and access, all available across multiple editions of software. Indeed, Microsoft were touting per processor as a major point of difference looking back to even SQL Server 2008, going as far as to claim ‘thought leadership’ when it came to competitor licensing models aligned to multicore processors. From 2016 though (and noting the GA of SQL Server 2017 from October 2017), following their conformance and gradual demise of the processor metric, there are now primarily three Per Core licensing models:
So let’s take a look at 2 more common server products afflicted by this change, SQL Server under (1) and Windows Server under (2) – and if you are intending to use Self-Hosting or SPLA rights note that there are further considerations not covered here, the context of this blog contained to licensing acquired under Microsoft’s Volume Licensing offerings (refer: Microsoft Commercial Licensing) SQL Server 2016 With SQL Server 2016 Per Core licensing, each server running software or any of its components (such as Reporting Services or Integration Services) must be assigned an appropriate number of SQL Server 2016 core licenses. The number of core licenses needed depends on whether you are licensing the physical server or individual virtual operating system environments (OSEs), across either edition.  Unlike the Server+CAL licensing model, the Per Core model allows access for an unlimited number of users or devices to connect from either inside or outside an organisation’s firewall. With the Per Core model, you do not need to purchase client access licenses (CALs) to access the SQL Server software. When running SQL Server in a physical OSE, all physical cores on the server must be licensed, noting software partitioning does not reduce the number of core licenses required except when licensing individual virtual machines (VMs). A minimum of four core licenses are required for each physical processor on the server, with the use of hyper-threading not affecting the number of core licenses required when running in a physical OSE, only those licensed under individual virtual machines (which are still subject to the four core minimum). So with the basics understood you’ll then want to familiarise with what you gain with the addition of a Software Assurance subscription… Key SQL Server SA Benefits
And be cautious – the components of a SQL Server license cannot be separated. While management tools and other software identified as additional or supplemental software such as product documentation, client connectivity tools, software add-ins, and Software Development Kits (SDKs) can generally be distributed and run on any number of devices for use with a licensed instance of SQL Server software, other licensed components such as the SQL Server Database Engine (DB), SQL Server Services for Windows, Master Data Services (MDS), Analysis Services (AS), Integration Services (IS), Reporting Services (RS), and Data Quality Services (DQS) will require licensing if deployed to other servers. You can find more details of the components at: SQL Server Software Components And for Non-Production: Effective April 1, 2016, SQL Server Developer Edition became a free product, available for download from the Microsoft Dev Essentials program as a potential alternative to the likes of a Visual Studio subscription. SQL Server 2016 Developer Edition is a fully featured version of SQL Server software—including all of the features and capabilities of Enterprise Edition--licensed for development, test, and demonstration purposes only. Windows Server 2016 For both Standard and Datacenter editions, the number of core licenses required equals the number of physical cores on the licensed server, subject to a minimum of 8 core licenses per physical processor and a minimum of 16 core licenses per server (sold in 2-Core and 16-Core packs).  Which means being very careful when you tally your overall requirement – make sure you account for the 16-Core per server minimum across any single CPU servers you might have in your inventory where you might otherwise under-allocate (where <16). And the differences in the editions?
(and if you're looking for a definition of containers, look no further - go here) So, To Finish … Bear in mind that in both cases you will still need to account for the CAL requirements if necessary (and remember to count all direct and indirect users/devices, ie. no multiplexing), typically via the likes of a Core CAL Suite or equivalent, which as an example provides the following licenses:
Noting that the likes of SQL Server CALs and Dynamics/CRM CALs must be acquired separately. Microsoft have provided a very helpful Licensing Brief across Core Licensing that I would also recommend reading for more information.
You've been there right ... in a meeting, time for the mandatory introductions, and the chair says "now from Procurement we have ..." ... so you shake your head (not visibly) and dutifully introduce yourself, thinking "They still have no idea!" So lets get a few things straight. Sourcing isn't Procurement. Sourcing ultimately involves Procurement, but other than that, it's quite different. And while we're on the subject, what's with 'Category Management?' Really?? ... to our thinking, 'Category Management' is just an unnecessary classification - sure - we work in categories, be it IT, Marketing, Stationary, Travel ... whatever, but it's the Sourcing label that defines the function. Well then, if it is different, what is Sourcing ? Sourcing, fundamentally is a discipline (much like, and in fact premised on, Project Management) - it has methodology, it has process, it has discipline, and it has rigour (for example, CIPSA). Not that Procurement doesn't - but Procurement ultimately follows the framework that Sourcing puts in place. Rather than straight 'buying' a good Sourcing practitioner will firstly work closely with the business to ensure there is an understanding (and proper framing and presentation) of requirements, development of a Market Strategy (who to approach, and how it should be constructed - RFI, RFP, RQT ...) , all backed up by a practice of relevant and credible assessment and evaluation (and that means no less than an objective, defensible process qualified by accurate data and irrefutable artefacts), followed by the subsequent qualification of supply (being full and complete due-diligence), with expert negotiation and agreement of (favourable!) contractual terms, plus induction of this new supply (and if you're a regulated institution, don't forget your obligations here - your license could be at stake). So where is Procurement in all of this? Procurement then steps in to make sure the ongoing acquisition of contracted products or services occurs within the framework of the Sourcing arrangements that have been put in place, tracking the metrics, monitoring the costs, measuring delivery - keeping the Supplier to their commitments. But let's hear from the practitioners out there - all you Sourcing and Procurement people doing the job day in / day out - where would you classify your role, what differentiates your function, how might you describe what you do? We're keen to hear your view - share your thoughts ...
As a postscript to the May blog regarding the SAP-Diageo lawsuit that found in favour of SAP a further action has been lodged against Anheuser-Busch Companies in the courts of New York, this time a staggering claim of US$600M (which must be a very confronting scenario for a company running a $150M annual IT budget) alleging license deficiency and misuse as summed up in the Anheuser-Busch Form-20 below: On 21 February 2017, SAP America, Inc. (“SAP”) commenced an arbitration in New York against Anheuser-Busch Companies, LLC pursuant to the Commercial Arbitration Rules of the American Arbitration Association. The statement of claim asserts multiple breaches of a 30 September 2010 Software License Agreement (together with related amendments and ancillary documents, the “SLA”) based on allegations that company employees used SAP systems and data—directly and indirectly—without appropriate licenses, and that the company underpaid fees due under the SLA. The statement of claim seeks both reformation of the SLA in certain respects and also damages potentially in excess of USD 600 million. We intend to defend against SAP’s asserted claims vigorously. Given SAPs 65,000 customers globally there would appear to be a potential minefield of non-compliance that presents an unenviable opportunity – remedy via lawsuit (with resultant consequences), or go some-way to addressing customer issues. SAP have now at least started to clarify and evolve their licensing to accommodate the inherent issue of how broader access by external parties and devices should be authorised, in their words embarking: “on a journey to move away from user-based licensing to a more transparent and predictable licensing model focused on outcomes related to our customers’ use of the SAP ERP system”. The fundamental principal though – changes or otherwise – remains that you cannot ignore the simple premise that accessing a system, or the data generated by the system, undoubtedly has a cost attached to it in the form of licensing. Consider SAPs own definition of ‘Use’ which is the central tenant of the misuse claims: Use means “to activate the processing capabilities of the Software, load, execute, access, employ the Software, or display information resulting from such capabilities.” Additionally, “Use may occur by way of an interface delivered with or as a part of the Software, a Licensee or third-party interface, or another intermediary system.” Use is defined broadly to cover both direct and indirect access scenarios and any use of the SAP Software requires an appropriate license. In response SAP identified the three most common indirect access scenarios that they have defined new “transparent and predictable” policy for, being: (1) order-to-cash (meaning the number of sales & service orders processed by the Software annually), (2) procure-to-pay (meaning the number of purchase orders processed by the Software annually), and (3) indirect static read, as represented below:  While encouraging to see a major vendor respond to their customers in a progressive way there is no silver bullet – with any installation and any metric there is the potential (or more often likelihood) that changes in your environment over time will generate further exposure.
So whether your organisation runs a $5M or a $150M IT budget, any sizeable investment in software – and the reputation of your company – surely warrants a robust and regular compliance and review program. IBM first introduced sub-capacity licensing in 2005 in response to the production of the x86 dual core chipset on the premise that licensing could shift to each core on a chip, not just the chipset itself. Clearly this has merit given today's much more complex, virtualised technology platforms with chips containing up to 18 cores - the enduring problem though for customers: understanding the sub-capacity rules and staying compliant. So lets take a look at one of the most common IBM sub-capacity metrics - the Processor Value Unit or PVU for middleware. Firstly, lets be clear on IBM's terminology relevant to this discussion: Core - A functional unit within a computing device that interprets and executes software instructions. Chip – electronic circuitry, containing but not limited to at least one core, on a silicon wafer. Socket – the mount that secures a chip to a motherboard. Processor – There remains disagreement in the computer industry over the definition of a processor. IBM defines a processor as the core. For example, a dual-core chip has two processor cores on it. As an IBM customer there are certain prerequisites to employing sub-capacity licensing under your Passport Advantage (PA) Agreement:
So with that all ticked off (and make sure they are - you will need these artefacts in the event of any audit), what are the basics in determining the number of licenseable PVUs?
If counting physical cores you count Activated Processor Cores, which are processor cores that are available for use in the server (ie. don't count if deactivated). The illustration below provides an example of the counting rules applied in an x86 environment where the Virtualisation Capacity equates to the number of licenseable cores:  So with the number of cores established, how do we determine the applicable PVU count? IBM assigns a PVU per processor core rating to each processor technology collated in the PVU Table published on their website - and note just how much has changed when you compare to the original table from 2006 below (!)  You'll need the requisite system access in order to interrogate your systems to determine the relevant processor model - refer to IBM's helpful Guide if you need more information on how to do this (or, let our ComplianceWare tool do it all for you!)
Its then a matter of extrapolating the PVU counts by cores across your product installations, and tracking on a regular basis to be sure you account for the inevitable changes in your environment that alter those figures (again, easily done through system compares of our ComplianceWare output). IBM has published a list of FAQ that should assist you through any other queries you might have, or ... comment here and we'll be happy to help! As many major software vendors approach that ever ominous 4th Quarter revenues become very much front of mind, and in a climate of slow sales customer compliance can be an easy target - just consider the rather telling statistics:  Of the US$20 Billion dollars in unlicensed software attributed to the Asia-Pacific region the BSA / Software Alliance considers more than US$500 Million of that figure to be within organisations based in Australia:  Quite an attractive source of ready funds to tap into, and with the Campaign for Clear Licensing (CCL) reporting the average audit spanning 7 months and consuming some 200 hours of IT time www.clearlicensing.org/2016/11/24/audit-report-nov-2016/ it's not just potentially a costly exercise, but also an unwanted disruption to normal business - consider the more detailed timings reported by Cherwell:  So if you haven't seen a dreaded audit letter for some time (and current reported frequencies are as high as one every two years in major companies), or if you have significant arrangements coming up for renewal, you should be taking stock of your software and confirming your compliance position as a priority.
Of further interest (and perhaps concern) is the recent elevation by the BSA of their "Australian Rewards Program", (www.bsa.org) where individuals who report cases of unlicensed software can gain up to AU$20,000 on successful prosecution or out of court settlement - an attractive amount for any aggrieved employee or perhaps contractor recently let go who might have come across an oversight within your organisation. The alternative just makes sense - run a compliance report at a minimum and discover what your software landscape actually looks like. The comparative effort and nominal cost could save a lot of grief and damage if (and when) those auditors are sent in. Talk to us about a simple and quick services engagement that will deliver a comprehensive inventory report via our ComplianceWare product, and the addition of our services to then analyse and establish your compliance position. Software Compliance.
Software Certainty. Having just launched our ComplianceWare tool as a web-based application the various components of the solution stack serve as a prime example of the depth of licensing complexity and ancillary terms given the number of platforms utilised in the web-central (or cloud) model as is prevalent these days.
In the case of ComplianceWare, we decided to utilise an Opensource stack of products that, rather than requiring the likes of source disclosure (eg. GNU licences), are subject only to the typical copy-left inclusion of acknowledgements (eg. BSD-3). This, coupled with a SQL back-end issued under a similarly liberal PostgreSQL (MIT-like) license allowed us to construct an industry-grade solution entirely within the Opensource domain. When it comes to deployment though there are of course provider terms, and that's when it can pay to look around. With a scaled application like ComplianceWare many providers have a tiered model to suit start-ups like ourselves in particular. And you don't necessarily need to limit yourself to a single platform. As an example, to keep our data local we use S3 storage from the AWS Sydney hub, while the web application actually runs out of US based data centres. And across all, you only pay for what you use - from fee-free to pay-by the-hour. So if you are looking to implement a similar scalable solution, consider the stack approach - the benefits are essentially two-fold - firstly, the terms imposed by providers are generally minimal, and secondly, you gain broad access to low-cost hosting - all still to a robust industry standard. And if you'd like to see all this in action just ask for a login to our ComplianceWare demo site by sending an email to us at demo@swcompliance.com.au! It's there in the agreement, you can bet on it. Indirect Access. Whether it's disguised as 'qualified users, or 'devices', or perhaps 'multiplexing', it's prohibited. And that means you need to be sure that the access you're providing to your licensed systems is correct and compliant. The simple way to think about it is that if it's related to a proprietary system, or sourced from a proprietary system, any access must be properly authorised. And that means properly licensed. So whether it's via an API, an interface, or extracts, you need to ensure that you're compliant with the terms of your agreement - to not be can prove very problematic, and potentially very costly. Take the recent finding (Feb 2017) in favour of SAP UK over DIAGEO Great Britain which you can view at http://www.bailii.org/ew/cases/EWHC/TCC/2017/189.html in a remarkably readable form for a crown judgement. The core of the matter was the "Named User" metric by which DIAGEO licensed its SAP installation, and the development and use of functionality within Salesforce (known as Gen2 or Connect) that enabled DIAGEO customers and distributors to places orders, check stock availability and prices, see invoices and select delivery. Through various interfaces back to SAP, Connect provided the necessary data, lists, and workflow to those end customers and distributors 24x7 negating the need for a call centre to receive and process requests. Despite DIAGEO asserting that the use of Connect by customers was essentially no different to when they contacted and were processed through the call centre, the judge saw otherwise and ruled that such access constituted use of the SAP system. The implications are yet to be seen, however in summary the damages were considered by the judge as below: "In summary, usage by Gen2 sales representatives is not authorised usage under the Agreement. SAP is entitled to additional licence and maintenance fees, the level of such fees to be assessed in the quantum phase of the trial, if not agreed, by reference to the nature and extent of the usage and SAP's price list." So, should we be concerned? Absolutely. If you're unsure of the your license grants or metrics, the terms of your agreements, or the compliance of any periphery/accessing systems, you need to take stock and run a full assessment exercise across your domain.
To be unaware is to be in danger. We hear it everywhere now - "you've got to move to the Cloud" - and of course often you should, but that needs to be a fully informed, calculated, and well determined decision. Mostly migration to a provided virtual service (be it IaaS, PaaS, SaaS, ITaaS) is premised on ready access to technology at reduced cost as a result of the lower footprint in terms of in-house hardware and associated resources, but there's more to it than just that. Lets look at the advantages you (can) get first:
Which all sounds very compelling. So, wait- there's no down side? From a licensing perspective its hard not to be a little sceptical. Typically you'll find its a vendor driving the initiative by promoting just the advantages, without insight into some of those vexing, pesky issues like license conversion and longer term costs - particularly when it comes to other vendor product in the mix as well, or that list of 'excluded software' which can include the base operating system (?!) typically licensed by cores - so just how many 'per core', 'activated processor cores' or 'RVUs' might be deemed available to your programmes, and therefore chargeable?
Then there's the investment in your current licenses that can be summarily dismissed for the seemingly more cost effective subscription pricing with the cloud solution. What about terms for full or partial license conversion (both to and from), or at minimum, some form of license protection in the event that you want to re-house your platform internally? Don't forget that once you commence your subscription and let your current support and maintenance lapse, theres typically an 80% reinstatement fee should you want to activate those entitlements again, or under more fortunate circumstances, perhaps just back-payment dating to expiry (and remember this is above and beyond those Cloud subscription fees you've been paying). Predicting what the future licensing costs might be has always been a minefield, but yet another 'new world' landscape presents enormous opportunity for software vendors to engineer more licensing models that, as we well know, generally seem attractive and start favourably but have a longer term objective - and thats increased revenue. So while Cloud should be a considered option in most organisations, don't let the licensing elements be trivalised in favour of all those 'advantages'. Just as it is with on-premise software, your use of vendor software in the Cloud remains subject to compliance terms, and once all the hype settles, just as liable to strict audit and commercial remedy. You'd expect that if its documented by the vendor, its correct. Of course. Why wouldn't you? But that's not always the case. It's not just customers who can get confused by vendor licensing, it happens to be themselves as well. And the issue is, if you don't find out before you get audited, its a whole lot harder to dispute than beforehand - those audit 'partners' will go by the rulebook, and that's their employers documented facts. So what does that mean? Well, a whole lot of work for someone to keep track of announcement letters, product rights, license information, terms, conditions, limitations ... constraints .... restrictions ..... and the list goes on. Not only do you need to keep current, you need to decipher what those facts mean - how do they translate to your situation? What are the implications? A recent example we identified had the complete removal of an existing metric (yep just plain gone) as published on the vendor public website, their licensing 'source of truth' no less. Now where would that leave you, the customer? Unlicensed ... unentitled? Common sense (and commercial practicality) says of course not, but then, that happens to become your argument (with those 'partners') - a time intensive, frustrating, unnecessary and - worse - potentially a futile exercise, unless you know what went wrong,
On the plus side - you don't have to invest your organisations valuable time keeping track of this - we do it day in, and day out ... read the announcement letters, check the product rights, license information etc etc, so you don't have to. Just subscribe to our free notices at alerts@swcompliance.com.au and we'll send you updates as we uncover (and contest) them.
Well the New Year is now in-play and completing a major Year-2 True-Up for a large Microsoft Enterprise Agreement provided a prompt to refresh on the Windows Server 2016 conversion prior to those nasty renewals that come around so soon.
Much like the SQL Server 2014 migration the Windows Server 2016 shift (which started from October 2016) presents an opportunity for customers with active SA to transition their processor based licenses to core based ensuring coverage is gained across the full physical cores in their environment. Essentially, where you have a ‘server density’ of 8 cores or less per processor and 16 cores or less per server a full license grant is assumed – there is no need to record your environment as you’ll get the full complement of licenses by default. If however your server density is higher there’s some work to be done! You’ll need to ensure your entire Windows Server landscape is inventoried and formally documented ready for the expiration of your current SA, at which point you’ll only pay the additional SA, not additional licenses. But if you are not prepared and time gets away on you there’s potentially significant cost down the track as those uncounted cores come to light (the dreaded audit perhaps), so it pays to get organised and active way before your renewal date. And as a postscript - if you're using subscription licenses be aware that although you can vary down at anniversary, if you varied up at any time during the year - well that applies from the date of install. Well the December rush is now behind us although not without the usual lessons, primarily that the end of year for some organisations (US corporates perhaps!?) offers much more opportunity for negotiation than you might otherwise get at other times of the year. Keeping informed across the performance of such key (or where possible all) supplier companies provides an insight into just how much pressure there is likely to be on their sales and account teams, and it may well be timely to go beyond the usual boundaries for closing a deal. The 'last minute' can present a surprising transformation of firstly outlandish requests into what are suddenly 'our most valued partner' incentives - anything from an array of additional 'you need/must have' product to the inclusion of extensive 'our skins in the game' professional and/or project services (of course a mere placeholder without Key Personnel), to the real, last gasp, what about big '$$$' financial offsets (and think large - this year, capital 'L') real value, real money in YOUR pocket), all of which can make a borderline business case (and with unexpected funds in your budget, possibly others) pretty attractive to your executive/board. So a useful tactic can be to defer those initiatives that are unlikely to get the go ahead until the vendors end of quarter - or preferably end of the financial year for most leverage - and really test what's on the table. As that time honoured saying of Project Management goes: 'if it wasn't for the last minute, nothing would happen!'
Well it would seem the big change is the move to (physical) core based licensing for Windows Server 2016, now offered as just two major editions - Standard or Datacentre - with an 8 core license minimum per processor and 16 core license minimum per server (sold in 2-core packs), subject to the accompanying User or Device CALs of course.
What does it all mean? Well the price for 16 core licenses for Standard or Datacentre is being touted as the same as the current pricing for one 2-processor 2012 R2 Standard or Datacentre, but an additional 2-cores will increase the price of server licensing by 25%. Properly converting your processor licenses to cores is an imperative - if you don't get the numbers right (particularly with VM's running on the Standard edition) you could face some significant costs down the track due to the 2 VM maximum (ie. all physical cores must be licensed again for any VM increment above each 2 VM maximum). The good news - as with the SQL Server conversion if your SA is current the license grant will cover no less than you have now (ie. all physical cores), so get counting and make sure you have the right artefacts to validate your entitlement at renewal time! We all know that core based licensing can be expensive, but balancing that with the efficiencies of scale - being able to run up any number of instances (without impacting performance) - has its benefits. At what point though should that scale be reconsidered? Perhaps a shift to processor based licensing with a fully architected physical HA platform, or even a move to purpose built appliance infrastructure?
Oracle database is a case in point - commonly a large investment in sizeable organisations. With Oracle still not recognising the likes of VMware as a soft-partioning solution under their licensing model options are limited, basically you either adopt an authorised virtualisation alternative (ah, maybe Oracle Cloud?), or run it on dedicated physical machines. But what advantages might the Oracle Database Appliance offer? First introduced in 2011 the latest fifth generation X6-2 appliance models (www.oracle.com/goto/databaseappliance) are simplified, optimised, and more affordable making them now a serious option as an integrated database and application system. Apart from the technology and administration benefits you can now license on an on-demand processor core basis, anywhere from 2 to 40 cores to support the workload you need across both Oracle Standard or Enterprise editions, with Oracle Real Applications Clusters available on the X6-2-HA model offering an active-active or active-passive configuration for database failover. With an easy pathway for deployment to Oracle Public Cloud your software investment can be extended providing both an on-premise and off-premise platform that works particularly well for dev/test or even DR environments. So if its time to reassess your Oracle platform its worth taking a look at the Oracle Database Appliance range. An evaluation of your current investment against an integrated and scalable solution like the X6-2 might end up saving you not just money, but a lot of valuable time as well. The latest talk suggests another imminent update by Microsoft in its licensing domain, just where is yet to be seen. Of late though, the changes have been largely positive - certainly the conversion to the Product Use Terms as opposed to the Product Use Rights format (which had morphed into a near undecipherable amalgamation of the varied products and license models) was a welcome change. And the simplification across the server products - take SQLServer with its narrowed editions and rationalised licensing - may well signal a more plain, coherent licensing programme to be front of mind. With the recent release of the new Enterprise Agreement structure what else might be in store is hard to predict, but we're all for a simplified model - a gold medal to the vendor that gets there first!
So the latest incarnation of IBM's Enterprise Software and Services Offerings (ESSO) takes the form of precious stones ... hard to argue, it can offer good value when put to good use. But that means knowing how to get the most out of the ACP and CBA, and also S&S Credits where you can. If you've loaded up your MLC projections make sure you don't lose that value either, I'd recommend preparing for renewal up to 12 months before expiry - you want to establish your baseline before IBM does, as it's pretty much locked in at that point. It takes effort, but it'll be worth it.
If you (a) start with the wrong baseline (and to IBM that's your S&S at the time, whether you're going to renew it or not), or (b) just take a guess at your future MLC, you could forfeit major, not minor, MAJOR dollars. Get ahead of the curve, sort your position out early. Only then can you negotiate on your terms. |
|
Unravelling license complexity for Business
ACN 623 529 751 |
Privacy Policy | Terms of Use
|