HMILLER.JUN UNRAVELING THE PURCHASED SOFTWARE DILEMMA by HOWARD W. MILLER The author is responsible for administrative computing at Boston University, Boston, Massachusetts and is the executive director of the Information Technology Institute. Mr. Miller has been involved in management for over 20 years. His area of expertise is information technology. Introduction The single factor that inhibits the rapid expansion of information technology is the inability to develop low cost, high quality software. As development methodologies, high level languages and similar techniques have failed, organizations have increasingly turned to purchased software as an alternative. Purchased software is a very popular solution to the requirements of mainframe computer users. It represents a large portion of the application software and virtually all of the operating and support software for mainframe computers. Purchased software is virtually the only game in town for personal computers and departmental computers. For many industries such as manufacturing, banking, insurance and education purchased software is the primary software source. Within these industries and others, it is the main source of software for major business functions such as payroll, general accounting, accounts payable and purchasing. The Purchased Software Dilemma Purchased software is not without problems. It is no less difficult for a vendor to develop software than it is for anyone else. The advantage of purchased software comes from an economy of scale; the vendor develops the software only once and then distributes the cost of development and ongoing maintenance over a large, installed base. The down- side to this is reverse economy of scale, the "Tower of Babel Effect" and obsolescence. Commercial software is typically developed using the most widely accepted and installed technology. For IBM mainframe users, this technology is typically CICS and VSAM. The selection of this technology is a marketing stratagem; use technology that reaches the largest base of potential users. The same holds true for departmental computer or personal computer users; develop software for the largest installed base of computers. In most cases, purchased software does not support such state-of-the-art concepts as unattended data center operation. Further, since it is developed for the largest installed base of computers, it may not run efficiently on any one computer or operating system. The result is that most commercial software is not using the best technology, and in many cases is using obsolete technology. There is a resistance to making major functional changes to commercial software. As the cost of development and maintenance is reduced by spreading it across a large installed base, the cost of implementing major improvements is also magnified by spreading it across that same large installed base. This is reverse economy of scale. If a large installed base reduces cost, then major changes to this large base are conversely, very costly. There are no desirable solutions to this dilemma. The supplier can maintain multiple versions of the software and lose maintenance economies of scale, or the supplier can drop support for users that do not maintain a specified level of currency and, therefore, lose ongoing revenues. Neither is attractive and the logical outcome is that purchased software becomes slow to evolve and obsolescence is accelerated. Another down-side aspect of purchased software is the "Tower of Babel Effect" or the use of multiple programming languages. The direction of data processing for the last two decades has been to standardize on a single programming language (COBOL, FORTRAN, PL/1). However, in an effort to reduce maintenance and improve flexibility, vendors are writing all or part of their software using home-grown report writers or fourth generation languages (4GLs). This works well when the first software package is purchased and installed but becomes a nightmare with future installations. What happens is that each vendor provides a language, and usually the data processing group also purchases one or more general purpose 4GL's. These languages add overhead to the operation of the system support staff; each language has a learning curve, requires cross-training and results in dependence on trained individuals. The languages do not talk to one another, hence causing the "Tower of Babel Effect." There is virtually no solution to this dilemma. Because software suppliers use the languages for the custom part of their installation, it is difficult, if not impossible, to avoid using them. Suppliers use these languages as a further enticement to purchasing more than one of their offerings, forcing organizations to sacrifice functionality to avoid the problem of incompatibility. In some cases, the languages differ from package to package, even from the same vendor. And in most cases, the vendor 4GL's do not substitute for general purpose languages, which cannot be eliminated. Lastly, the use of database software has become common. Rarely is purchased mainframe software designed specifically for a database management system (IMS, IDMS, ADABAS, TOTAL). The installed base for each database management system is only a portion of the entire database market. Therefore, if used, the database limits the potential market for the software package. The result is a choice between functionality or database compatibility. The ability to satisfy both conditions is limited. The widespread use of purchased software severely limits the likelihood of having a single image corporate database of information. Further, it severely limits the flexibility of the organization to adjust software to the changing needs of its business. The risk associated with purchased software is substantial. In addition to the above business and management problems, there are many other vendor related issues. These issues include: vendor stability, mergers, acquisitions and simple nonperformance. There are also organizational issues such as software modifications, training requirements, budgeting considerations and installation standards. The Benefits Of Purchased Software Yet with all the associated problems, the popularity of purchased software is increasing. Why is purchased software becoming more popular, and why would computer professionals complicate their lives by installing something as risky as purchased software? The answer is productivity. Purchased software provides an opportunity to deliver a complex system in a comparatively short time. The more common applications are available in many different colors and flavors. In most cases, the software has a large installed base of users and a proven track record of success. Usually, the software is extensively documented. Further, the users are able to see the actual screens, reports and forms required to operate the system. Potential clients are given the opportunity to meet other clients to share experiences and avoid installation problems. The benefits continue after the software is installed. The ongoing maintenance overhead for purchased software is far less than for in-house developed software. Staff is released to address issues that can only be satisfied with home-grown software. New releases of the software satisfy new requirements or legal requirements with little or no requirements definition. The users have an opportunity to continue to meet and share experiences and to exert influence over the future direction of the software. Establishing Requirements It is obvious that regardless of improvements in the ability to develop software, purchased software is here to stay. In order to effectively select purchased software, an organization needs to understand the functions and technical specifications that the ideal software possesses. These functions and technical specifications are the software requirements. By systematically analyzing available software and comparing the functional characteristics to the requirements, it is possible to select purchased software that maximizes the forementioned benefits while minimizing the problems. Selecting a software package is the end result of a long series of compromises. Some functions of the software are a perfect fit, other functions require compromise, and some functions are missing. Therefore, it is important to understand what is required; which functions are critical and which are not. When the time comes for compromise, it is therefore possible to select the software that best satisfies the requirements. The decision should not be influenced by superficial features. It is best to group like requirements into general classifications. The most common classifications are as follows: o Product Capabilities -- Includes functional requirements for the type of software required (computer operating system, utility, sort, banking, inventory, and so on). o Technical Support Information -- Includes such information as product documentation, communication monitor and operating system support. o Implementation Information -- Includes information about report setup, hardware requirements, software prerequisites, implementation effort and complexity to change. o Miscellaneous Information -- Includes pricing, discounts and maintenance schedules, installed base of users, vendor information and user group information. After the initial list of requirements is developed and classified, present them to a group composed of user representatives, information technology professionals and management. Make this a brainstorming session and expand the list to include as many functional requirements as possible. Remember, there is no limit to the number of items that can be added to a wish list. However, be concise and avoid duplication and overlap as much as possible. The functions of the vendor software are compared to the list of requirements and are numerically evaluated for compliance. Calculations are required. Furthermore, as the process proceeds, requirements are added while others are dropped. It is therefore suggested that the requirements list be maintained on a spreadsheet. In this way, items can be added or dropped, ratings can be calculated, and the list can be sorted with little or no manual effort. Making The Ratings Each requirement is rated by the analyst. A requirement can receive a rating of yes or no, or a rating of excellent, good, adequate, poor or very poor. These are assigned a numerical value. (See Figure 1) The ratings are the analyst's best assessment of how well the software meets the requirements. They are based on a judgement of the degree to which something exists, rather than measurable fact. This means that complete agreement on the rating is not possible. The selecting organization needs to be cognizant of halo effects and discount subjective judgements when they become evident. This halo effect includes decisions influenced by vendor promises of "future enhancements." Enhancements are rarely as extensive as promised and seldom occur when promised. Consistently skewed judgements need to be avoided and corrected when detected. Assigning Weights As each requirement is developed, the analyst determines the weight it deserves. Weight is a multiplying factor. Its value depends upon the importance of a requirement to a particular environment. Weight is a measure of importance; it is not related to the rating, which is a measure of condition. Weights may be assigned either before or after the analysis is performed. Assigning weights before the evaluation lets the analyst know what is important and could cause deeper probing on highly weighted items. This could also be undesirable. If the analyst is inclined to look for justification to improve a rating, the higher weight could influence the analyst's thinking. Furthermore, some risk exists that the lower weighted items could get superficial treatment and not the probing analysis they deserve. Assigning weights after the evaluation avoids these potential drawbacks but may create another problem; the assigned ratings may influence the assignment of the weights. The choice of approach therefore, depends upon the judgement of management. Requirements with a weight of zero should be excluded in advance so that the analyst will not waste time on evaluations that are considered to be irrelevant or unimportant. Weights should be based on the importance of the requirement to the organization. Figure 2 shows the criteria suggested for assigning weights. All weights are set at normal (1) and a judgement is required to increase or decrease it. Realistically, few items are a 2, 3 or 4. However, because the assignment of weight is a judgement, individual variations may result from oversights, differences in knowledge and experience and other factors. One task of management is to resolve such conflicts. Quantitative Scoring Five columns are positioned on the right side of the spreadsheet or evaluation document for the following entries (see Figure 3). o Rating. The analyst's evaluation of requirements based on how well the software meets the requirements. o Weight. A measure of the importance of the requirement, typically entered before the evaluation. o Actual score. A calculated value, (weight X rating). o Maximum score. A calculated value (weight X 5). o Index Value. A calculated value (actual score/maximum score). The relationship between actual and maximum score is the compliance index. This is determined by a single calculation: divide maximum score into actual score (actual/maximum) for the sum of the requirements. Index values may range from 0.00 to 1.00. In general, the meanings in Figure 4 may be given to any compliance index. It is important to recognize that the compliance index is a calculation based on a numeric value assigned to a judgement and has all the limitations of a judgement. As such, its usefulness is restricted to providing a simple indication of overall compliance for an item, classification or software package. The goal of the analysis is to select the software that best meets the requirements identified by the analyst. When the rating and scoring is complete, compare the compliance index for each software package selected, and select the two packages with the highest ratings. Schedule a site visit for each, and, if possible, select one of the two for a 30 day trial period. If the results of the site visits or trial period are not satisfactory, choose the next highest alternative. Before you schedule a site visit, secure a copy of the purchase contract and submit the contract for legal evaluation. Ensure that warranties are adequate to protect your interests during and after installation. Complete books have been written on negotiating purchase contracts for data processing hardware, software and services. Do not ignore this aspect of the selection process. Final Words of Caution Virtually all of the computer operating software, utility software, computer management and application development software (languages, methodologies) for a mainframe computer are purchased. Further, an ever increasing percentage of the application software is also purchased. As a result, good selection procedures for purchased software are becoming increasingly more important. The key to successful software selection is establishing requirements. In many cases, however, the potential purchaser does not truly understand the requirements. This results in one of two potential types of errors: o The purchaser selects a software package based on the specifications presented by a single vendor. o The purchaser looks at many different software packages without fully developing a list of the organization's requirements. In the first case the organization selects the software without having a set of requirements, without a clear idea of what is available and without a clear point of reference. Software vendors will always try to get you to focus in on their product to the exclusion of all others. In the second case, the organization looks at so many software packages that its requirements tend to be developed by availability rather than need. Further, it becomes very difficult to differentiate the importance of one requirement from another. When selecting software, look at the ratings and evaluations in trade journals like DATAPRO. Do not hesitate to ask others in your industry what experiences they have had with purchased software. However, avoid making site visits until you have limited the selection to one or two vendors. The purpose of a site visit is not to identify the functionality of the software but to gain insight into variables that are difficult to assess from a requirements evaluation. For example, it is possible for a requirement to be satisfied in more than one way. One way may be more labor-intense than another, and although it meets the requirements, it is less valuable. It is possible to ascertain this kind of information from a site visit. Never bring in a software package for a 30 day free trial unless it is your finalist. Installation of software is rarely as easy as the software supplier intimates. Installation takes longer than expected, evaluation staff is seldom available on the desired schedule and there are often technical problems. Resolution of all these issues makes it very unlikely that the software will ever be removed from your computer. Increase the likelihood of success by only installing your finalist. The benefits of purchased software are clearly seen in its increasing popularity for mainframe applications and in its virtual dominance of personal and departmental computer applications. The selection process for purchased software is a long series of compromises, and there are many risks associated with these compromises. However, with a little planning and a little structure, the chances of a successful selection are greatly increased. /* 2758