Application Selection Dictates Hardware Selection
Acquisition of technology products follows the application. At the consumer level, individuals buy products for their function, not the design of the circuit board. Businesses, industry, and government select the application software first, and then the hardware that goes with it. Information technology (IT) managers are often pressed to look at "technology" as a solution to business problems; however, the real fact is that the solution to business problems is an application, not technology. It does not matter how the bits and bytes are configured or if the processor capability is less than leading edge; if the application does not support the business.
It is only after a commitment has been made to a particular application that the hardware platform and associated operating system become meaningful. The long-term useful life of the equipment is tied to the planned useful life of the application. If the application decision is in error, the associated hardware and service contracts will also gather dust.
Careful attention to the initial product selection that goes beyond the application negotiation and into the tangled support functions of hardware, application license, and operating system (OS) license will bring long-term rewards.
The selection of products and associated support is a constant tug-of-war between the buyer and the manufacturer, usually known as the original equipment manufacturer, or OEM. The buyer and the seller are not involved in a traditional purchase agreement, despite the appearance. Buyers do not own IT equipment in the same manner as they own a house or even as they own a vehicle. Nor is the license agreement for software a straightforward arrangement like a condo lease. The relationship between buyer and seller, or licensee and developer, is more like a marriage than a home purchase. Buyers should be negotiating IT purchases and license agreements just as carefully as they would a prenuptial agreement expecting divorce and conflict.
Figure 1 shows the OEM view of the sale or license agreement.1 OEMs expect the user to enter into a long-term relationship where the OEM controls the useful life of the product with no exit points for the user. Although OEMs might not set out to produce products that are unstable and require repairs and software patches, they have little incentive to do otherwise. It is beneficial for OEMs to have reasons for the user to need their support.
Figure 1. OEM cycle of dependence. (Adapted from www.continuant.com. With permission.)
Manufacturers of hardware long ago recognized that the application drove the hardware. Outside of the mainframe environment, where initially most applications were custom built, the entire middle range of product sales were built around what used to be called "Turnkey" systems. The turnkey arrangement was perfect for the business that had no computerized applicationsand thus no employeescapable of writing, customizing, or implementing the application. Most of the big names in applications today came from these roots.
Hardware manufacturers were not initially in the application software business. Nor did hardware companies sell or separately license the operating system. In order to sell to the neophyte buyer, hardware manufacturers made alliances with software developers, later called business partners or value-added resellers, to represent them to new or smaller users. Software vendors became the sales force for their own products and a free extension of the OEM sales force as an authorized partner. The software company got a healthy commission for selling the hardware. The operating system and the requisite maintenance contracts were also sold, and commissions paid, to the application partner.
It is for these historical reasons that the sales channel through which equipment is purchased usually dictates how both hardware maintenance (break-fix) and software maintenance (operating system and application support) are offered. This chapter discusses how different players in the supply chain have different offerings and how negotiations should be conducted to maximize effectiveness in support options.
Each type of acquisition method still involves navigating the natural tension between seller and buyer. The seller always wants to sell more equipment, more quickly, and drag along higher margin services at the highest possible price point. The buyer has goals of buying equipment that best supports the application requirements, at the best price, and with the least likelihood to need replacement ahead of the depreciation schedule.
Application License Acquisition
Buyers are commonly exasperated with trying to control maintenance costs for software, the price of which often exceeds the acquisition cost of the license over time. The reason is very simple: vendors have total control of the pricing of post-warranty support (maintenance). As with any other monopoly, this ability to dictate price and terms leads inevitably to taking advantage of the profit margin potential of the revenue stream. Maintenance is often the most profitable part of the license agreement. It is therefore essential that the initial negotiation for application licenses be extremely attentive to issues that might occur only in the far future.
There are only a handful of ways to control maintenance pricing, at the outset, through competitive replacement or a commitment to open systems. None of these tactics are perfect. Applications are completely protected by copyright law (which is itself consistent with both the Berne Convention and World Intellectual Property Organization [WIPO] international treaties). As "Intellectual Property (IP)," vendors are allowed to be monopolistic not only about the transfer of licenses but also about ongoing support. There is no legal (as of this writing) opportunity for competition for support unless the application vendor allows it.
Unfair terms and conditions in the "End User License Agreement (EULA)" are coming under scrutiny in general as digital rights are being considered. Copyright law, including international conventions, remains rooted in the predigital era. Even legislation passed at the end of the millennium to update the Copyright Code under the DMCA (Digital Millennium Copyright Act of 1998) seems archaic and dated. Some work has been done defining conceptual "User Rights" by the Gartner Group in 2010, none of which has been put into law.2
The ideal time to control maintenance costs in the future is to carefully negotiate the initial contract to include limits on future increases for maintenance costs. These negotiations usually focus on a percentage of the original list price, or original acquisition cost, rather than the need for maintenance in the future. The downside of this approach is that buyers are stuck with whatever percentages they negotiate, on top of which application vendors can inflict further financial burdens for upgrades to major "new" releases, requirements that all versions of the purchases be kept current, or other requirements such as linkages to hardware maintenance agreements. The concept of the responsibility of the developer to deliver bug-free code is lost in the focus on discounting. Vendors have been allowed to own the negotiation over support and limit the discussion to discounting off list price for future support contracts. This is exclusively to the advantage of the vendor and always puts the buyer in the position of begging for discounts. The framework of the negotiation can change if buyers demand performance-based post-warranty support in the initial license negotiation. Once the focus of the negotiation is put on quality and performance on the part of the vendor, the entire spectrum of costs and rights can be discussed.
Defect and performance-based support is rooted in the idea that the vendor, either hardware or software, has an obligation to deliver fully functional products that meet the specifications as advertised. Patches and fixes are indications that code is buggy. Users need to stop acquiescing to the concept that buyers should pay for corrections to code that should not need correction.
Users have been led to believe that they should pay handsomely for support (maintenance) of flawed code because the patches and fixes are delivering improvements in the product. This is unlikely to be the case, although there may be exceptions. There is more than a semantic difference between an "update" and an "upgrade." An update is likely to be double-speak for a bug fix, but sounds far more positive. An upgrade should provide a new and valuable function that did not previously exist. An upgrade should be something that the user might want to purchase, separately. Sadly, many software and hardware vendors blithely mix the wording of updates and upgrades simply to hide the weaknesses in their product stability.
The costs and rights for users to buy patches and fixes to flawed code can, and must, be separated from enhancements and customizations. Users can begin the process of accountability by evaluating the patches and fixes that are disseminated for existing licenses for applicability, impact, and separating upgrades from patches. Much of this work is already being done by support staff to discern which patches must be urgently applied. Adding the layer of intelligence to differentiate between welcomed and un-welcomed updates will enormously increase the negotiating power of the user in future contracts.
It is an underutilized but viable option to drop maintenance (support) where no meaningful changes are needed and freeze the system, both hardware and software, at a stable release. Vendors use the term "going naked" to infer the undesirable vulnerability of dropping vendor support. The key to confidence in dropping "support" is to evaluate the types of patches and fixes being issued and consider if the improvements being made are valuable. Only the user can judge if the problems being fixed are meaningful.
In many cases, application systems patching follows the pattern of hardware systems patching. The initial release is full of bugs, which require a high level of interaction on the part of the user and the developer to fully diagnose and then fix. Within a few months, or a year, most major or common bugs have been addressed and the development team is able to move forward with completing other items on the development timetable. As new features are created, the bugs in the new feature, or the interaction of the new feature and other products, are fixed. The fewer the enhancements, the slower the pace of patches, and the less likely the new patches to the new features are widely applicable.
It is crucial to keep the originally negotiated terms and conditions in mind whenever any vendor, not just an application vendor, changes the policies involving maintenance. For example, Oracle, immediately following their acquisition of Sun Microsystems in 2010, abruptly changed its policies for both hardware and OS maintenance for prior Sun products.3 Sun users were presented with a new set of rules requiring that they sign a new maintenance agreement for hardware maintenance for all Sun products within the enterprise or have no products on Sun maintenance. There were many other restrictions put forth. Those users who reminded Oracle of the terms and conditions of their original agreement were successful in forestalling the impact of the new policy.
Once the original license agreement is in place, and if the maintenance contract is not viable in the eyes of the licensor, then the only remaining options are to rip out the application or to outsource the hosting of the system to a more cost-effective host. It is not in the least surprising that the move toward open-systems products and hosted (cloud) offerings have been the salvation of the locked-in application user.
Moving the application from an in-house system to a hosted system does not remove license obligations if the licenses are not issued per serial number or per processor. The largest savings in moving to a hosted solution for specific applications is the dramatically reduced costs of the license and maintenance contract for the OS and the hardware, which are shared costs across multiple users.
Operating System Acquisition
Selection of an operating system is unusual, as the application requirements are operating system and hardware specific. The exceptions are open-systems platforms where users have choices between different versions of common OS, such as the Linux OS. Using the Linux base, several competitors have developed their own versions of Linux, which include enhancements and features not available in the base version, and offer their own support contracts for their versions. Unless the author offers an open domain version of the OS, there are no independent support options for any OS. As with application licenses, the OS license is protected by copyright and the terms and conditions of use are not mitigated by competition.
Operating systems are most often licensed either per serial number or per processor. Different fees are commonly charged for different types of processors, with a lower fee for the OS on a less powerful machine, and a much higher fee for the high-speed version of the same architecture. The explosion of large multiprocessor servers has given rise to per processor licensing as the price increase for the OS license from a single-processor version to a new version often made the new purchase unaffordable, which dampened sales for hardware. In cases where hardware manufacturers also license their OS, the platform (hardware) sale still tends to lead the sale in order to drag the associated licenses, custom services, and postwarranty support agreements. In addition to the OS, there are accessory software products known as "Systems Software" that attach directly to the OS used to perform functions not included in the OS or included in a lackluster way.4 Each of these products has its own licensing models, which do not always follow the OS license model. Before buying any new products or making major upgrades, buyers need to ascertain the price of the impact on the license costs, or required upgrades, to all products licensed with the OS, or accidently put themselves in a terrible bargaining position after the fact.
- The concept is not unique and is well understood, particularly in software circles, where users are more frequently faced with a high volume of patching leading to new releases and a continual cycle of patching and dependence. The same is the case, but less visibly, with hardware.
- Gartner Group created a Global IT Council for IT Maintenance in 2010. The results and recommendations for seven rights for software buyers are available at: http://www.gartner.com/newsroom/id/1403313.
- Oracle purchased Sun Microsystems in January 2010, and in March 2010 completely changed the terms and conditions for hardware (and Solaris) maintenance. Among the many changes was a requirement that all software (Solaris) and hardware maintenance contracts be at the same level for all equipment in the enterprise, or that no software or hardware be on Oracle maintenance contracts. Many articles were posted at the time, such as "Oracle Enacts 'All or Nothing' Hardware Support Policy" by Chris Kanaracus of CIO Magazine, regarding the "all or nothing" policy. For users accustomed to purchasing maintenance on a per serial number basis, this created havoc.
- Computer Associates (CA) is the largest of the companies providing systems software products. Among its staple offerings are "Storage Management" products that began in the late 1970s with tape library management (now CA 1®).
Read more IT Performance Improvement
Certain names and logos on this page and others may constitute trademarks, servicemarks, or tradenames of
Taylor & Francis LLC. Copyright © 20082014 Taylor & Francis LLC. All rights reserved.