Over the past several years, a revolution has taken place in software development, fueled by new modeling tools, integrated development environments and visual code assembly.
Executive Summary
This revolution has changed the calculus of software acquisition for large, mission-critical applications.
Ten years ago, there would have been little, if any, discussion of the topic of software acquisition. Enterprise clients with mission-critical enterprise software needs almost always worked with major IT vendors such as Oracle and SAP. Today the landscape is different.
Business now has a viable choice for software acquisition and many are finding that, after careful evaluation, custom software provideds a more tailored, flexible and economical solution.
When companies evaluate factors such as suitability, scalability, flexibility, interoperability, support, time to implementation, property rights and total cost of ownership now frequently favor the custom software development option.
The radical change in custom software development has made this option more attractive than ever.
Introduction
Prepared by EPS Custom Software Group, this document addresses the criteria involved in the acquisition of mission-critical software. For the purpose of this paper, "mission-critical software" is defined as applications and system software critical to business operations. Such software must be updated or replaced periodically for businesses to remain competitive.
Changes in software development technology and techniques have altered the relative advantages of various software acquisition options, making an already difficult decision even more challenging. This paper addresses the factors that must be considered in making a sound business decision.
"Make, buy, or lease": general considerations
In the case of most tangible objects, the "make, buy, or lease" decision is fairly straightforward. In an automobile purchase decision, for example, manufacturing the car oneself is not an option. The decision becomes a simple one of "buy or lease."
The acquisition analysis is far more complex for mission-critical software, where custom "one-off" production is a viable option. There are both quantitative and qualitative differences between all software solutions. No two do things exactly the same way and, since no two application development methodologies are alike, the finished products can vary considerably, with both operational and financial ramifications over the life of the software.
In addition, no matter how the software is developed, it is never really "complete." Business requirements change and the company's software should be able to accommodate new realities. Any software acquisition analysis that does not take this into consideration is laying the groundwork for future trouble.
Acquisition decision factors
Although it is possible to do return on investment (ROI) calculations for software solutions, the reader should be cautioned against using ROI as the primary decision-making methodology. This is because the qualitative factors are likely to be even more important than the pure financials.
Factors to be considered in making the software acquisition decision include the following:
SuitabilityScalabilityFlexibilitySupportInteroperabilityTime-to-implementationImplementation risksProperty rightsCost of ownershipWhile reviewing the following sections, you may wish to use a rating system for each of the three alternatives (make, buy, or lease). We provide a place at the end of this paper to record your scores, and also offer a free download from our web site of an interactive tool for making the calculations.
1. Suitability
The single most important requirement in evaluating software is its suitability to the company's business needs. Mission-critical software should conform to how the core business process works, not vice versa. An imperfect fit can be anything from a minor annoyance to a costly burden on company operations.
Off-the-shelf software (the "buy" option) is seldom truly suited to any single corporation's mission-critical task. It comes shrink-wrapped and is generally not very customizable. To be of any use, it must come as close as possible to its intended purpose, straight "out of the box." If this happens, then it can be an attractive option. If not, its lack of flexibility (see item 3) will always be a problem for the business.
Leased software, whether acquired from one of the major vendors such as Oracle and SAP or from some second-tier vendor, suffers some of the same problems as off-the-shelf software. It is a standard package provided to the customer "as is" with all of the basic functionality programmed into the product. Leased software compensates by having customizability as a software design feature. Vendor consultants have to write the code, but it can be done.
Properly designed custom software models the company's business process better than the alternatives because it is designed and developed with only one client in mind. It is the clear winner as far as suitability is concerned. New modeling tools and techniques have made the process of simulating a company's business much easier. Any problems can be solved before the first line of code is written.
2. Scalability
Scalability is one of software's most important attributes. All software works in a test environment on a single machine with a fifty record data set. Much software becomes unusable when faced with real world situations. Software that "works" with five users may slow down and collapse as the number of users grows from five to fifty and the data set goes from a thousand records to a million. Companies sometimes find that two or three years after implementation their software restricts their ability to operate. A negative impact on the company's bottom line inevitably follows.
Off-the-shelf software is inexpensive in part because the developers target individuals and small businesses, structuring their products accordingly. This often means that the program will not scale to large volumes. There are many cases of companies making commitments to this sort of software only to discover that they have painted themselves into a corner. As the company grows, the software becomes a major bottleneck. The company does everything it can to optimize the software: it buys bigger computers, faster networks, and puts more disk cache on the server. This only allows them to go further into the corner. Business begins to overwhelm them, and there's no hiatus during which they can locate and convert to a new solution. Growth and profitability are effectively capped by the limitations of the computer system.
In contrast, leased software is scalable. As the financial arrangements for most leased software are based in part on sales volume and number of users, leased software vendors make sure their software will meet growing client needs. In most cases, this means that the platform the software is built on is "industrial" in its capability whether or not the client really needs this.
Custom software can be as scaleable as the best of the leased software. The key is to make sure the software developer understands software design and implementation at the level at which the client expects to operate. With custom-developed software, the company has the option of choosing the appropriate development platform and data store for the job rather than just accepting the software "as is" from a vendor. With custom software, the client has the option of choosing the appropriate development platform and data store for the job rather than just accepting the software "as is" from a vendor.
3. Flexibility
Once a business has found software suitable for their mission-critical application, they must ensure that the software is flexible enough to change as the business changes. A decade ago, most programming languages and application frameworks were so restricted that they were, in effect, "closed systems."
Only recently have improvements in programming languages and development platforms allowed for truly adaptable software architectures. Loosely-coupled components with non-proprietary communications protocols are elements of this change. Software adaptability has become a built-in feature. This change is fundamental, and is a critical point of difference between the past two generations of software architecture.
The flexibility of off-the-shelf software is generally very limited. Even if the software is suitable for initial installation, it is likely going to fail the flexibility test later, since it is not designed to change in any material way. It is almost always programmed as a closed system. (See 5. "Interoperability")
By design, leased software is flexible so that it can accommodate the modifications required to meet the demands of different clients. The customer pays for this flexibility, because software that must be all things to all clients is more expensive to build and maintain. (See the next section for this discussion.)
Modern custom software is totally flexible: the component architecture allows for any module to be modified as necessary and then re-integrated into the system when ready. Changes in business logic, process or presentation mean that the company must program a replacement component for a particular part of the system. It is important to note that the process is under the control of the company with the needs, and not a third party.
4. Support
Support is a serious issue with mission-critical software. The adage "You get what you pay for" applies here.
With off-the-shelf software, the vendor's support commitment is minimal for any one customer. Some vendors only provide support through a web support forum. The customer explains the problem and the company's support staff answers the question, either by pointing to a knowledgebase article that deals with a similar situation, or by providing a suggested solution.
Some vendors have telephone support and, assuming that the client communicates with a good support technician, that the instructions are clear, and that the solution fits the problem, one can have a successful experience with this solution. Unfortunately, this is often not the case. Even the best support technician cannot solve a problem caused by a defect in the software. In this case, the solution may not be a simple software setting, but rather may require a fundamental change in how the software operates. What happens then?
If the client is lucky, the problem is "elevated" and makes the list for correction in the next release of the product, which may be six months or more in the future. Until then, the client is out of luck. For mission-critical software this is not an acceptable solution.
Leased software is usually sold with a support agreement that is either factored into the annual lease fees or added as an option. It is usually sensible to purchase a support agreement, as this is the best way to get good support. Many vendors offer multiple levels of support at different price points, with service ranging from email with no guaranteed response time all the way up to dedicated 24/7 telephone support. On-site service options are sometimes available and, with some implementations, a support technician may work full-time for the company. All depends on client needs and the price they are willing to pay. The annual cost for support can easily reach twenty percent or more of the initial lease price of the software.
There is a second level of support with leased software that relates to client's custom modifications. Changes to the base product itself may also impact custom modifications and necessitate support. Vendor consultants charge for this support either in the form of "time and materials" or via a separate support contract. Either way, the client pays.
The support one can expect for custom software depends on the structure of the agreement between the development house and client. There are several issues here that need to be addressed.
First, custom-built software is, by definition, a new product. The client's initial application is therefore version 1.0 of the product. Any agreement to develop custom software should include an agreement for support during installation and acceptance trials of the software, and any reputable development house will include this in their contract. Software should perform according to the agreed-upon project specifications.
Because the client owns the code, the issue of ongoing maintenance and support is different. Modifications can be made immediately should they prove to be necessary; it is a question of "who" rather than "if." The client can even provide support for the product internally should they decide that the investment in manpower is appropriate. There will still be costs, but control is in the client's hands. Whatever the decision for "who" is, the expense tends to be lower than with support contracts for leased software. How much lower depends on the specific situation.
5. Interoperability
Software that cannot communicate with other applications presents a problem, especially if it is mission-critical software. An order processing application that does not interface with accounting, for example, is not good for business. Writing and maintaining a bridge program for data interchange can work, but it is not a particularly efficient or satisfactory solution.
Interoperability problems with off-the-shelf software are a fact of life. Quicken does not talk to ACT! to get a list of customers. Neither talks to Great Plains accounting software. Most off-the-shelf programs limit themselves to batch import and export utilities that are totally unacceptable for real time data sharing.
Leased software ensures interoperability among the modules that the vendor supplies, although even at this level there can be problems. Some vendors have recently begun to provide interfaces to allow for data sharing, but this is usually merely a more sophisticated import/export routine than a real-time shared data store. Most leased software data designs are so complex that efforts to use native data outside of the application suite are not productive. Projects have even been abandoned for this reason. Seibel, for instance, has just spent three years and used two thousand software engineers trying to address this problem.
Interoperability in custom software is a matter of how the solution is structured. Most of it is designed around a specific data store and, depending on its degree of openness, the information is accessible by other programs.
Microsoft SQL Server, for instance, has built XML publishing and consumption on a transaction basis into the latest releases. This means that real time non-proprietary access to the data is now a standard feature of the product. The company determines how current and future requirements can best be accommodated in the system design.
6. Time- to-implementation
The time to get a software package running can be critical to a business. Rarely is a software project planned and executed before the software is actually needed.
If off-the-shelf software fits a business's need, the time to implementation is short. Small businesses have managed to set up and begin using QuickBooks in less than a week. If the shoe does not fit, however, a satisfactory implementation of off-the-shelf software may never happen.
There is a general misperception that leased software is easy to implement. It is believed that because the software is already built, the modifications to make it fit a specific business should not take a significant amount of time. Actual experiences demonstrate that this is not the case.
The automation of even moderately complicated business processes using leased software can take a great deal of time and money. The requirements for data gathering and design are comparable to those for custom software but, as the data model for most leased software is already fixed, bringing the client's data into the preexisting structure can be painful, time consuming, risky, and expensive.
When a client installs a multi-million dollar, mission-critical software application, the network administrator does not simply install it and reboot: the installation requires time and knowledge. This is one of the roles of the vendor consultant.
Many large and mid-level vendors have trained vendor consultants who install, modify, test and support leased software installations. Several vendors also maintain certification programs for third parties.
Highly trained and supported, vendor consultants do not come cheap. Depending on the vendor, rates range from a low of $1,000 up to more than $3,000 per day, or $200,000 to $600,000 per year per consultant. Many projects involve more than one (and sometimes more than a dozen) vendor consultants working for protracted periods of time, making this a major investment in both time and money.
Logic dictates that the time-to-implementation for custom software should be longer than with either off-the-shelf or leased software, but the difference has been rapidly shrinking in recent years. This is due to advances in coding aids and the basic architecture of today's developer software.
Pre-built frameworks now provide a significant level of built-in functionality. And, new coding interfaces allow for code "assembly" in a highly productive fashion that shortens not only the coding phase, but also the debugging time necessary to deliver tested modules.
The architecture of modern software allows for highly modularized development, so that individual components of a system can be delivered sequentially with temporary interfaces allowing the modules to work with existing software during development and implementation. In reality, the difference in time-to-implementation for custom software is no longer a major factor in any decision.
7. Implementation risks
Any new software installation or update exposes users to implementation risks. Whether a company is contracting for new software, modifications to existing applications, or just installing a trivial patch, there are risks that the software will not work as expected.
Given the large installed base, off-the-shelf software carries the lowest implementation risk. If the software meets the client's requirements, the risks are not large. There are, however, cases in which people upgrade software to the latest version, only to discover that a feature they depend on no longer works the way they want it to because it was "fixed" or "improved."
Leased software carries its own set of implementation risks, both in the base modules and the customizations required. As with off-the-shelf software, the installed base for leased software is large, and the software's fundamental stability has been tested. Implementation issues with leased software more often center on corporate data conversions. The generic data models employed by most leased software systems are fairly complex, allowing them to accommodate the requirements of different companies. But conversion from existing systems can be slow and painful.
With leased software, the second set of implementation risks lies in the modifications the enterprise vendor consultants make to customize the software for client deployment. There are many examples of major installations that have failed because the modifications for the specific project exceeded the budget, took longer than originally anticipated, or simply did not work.
With custom software, the implementation risks can be grouped into two categories. The first is quantity and quality of development manpower. There is a natural tendency for contractors to say "yes" to projects even when the company does not have the experience or manpower to handle the work.
Choose a company with the qualifications to do the job properly. Stay away from people working from their garage and make sure that the company is competent.
The second set of risks is that the programming house's project management is not strong enough to keep the job on track and within project specifications.
While it may seem that the blame should fall on the client for demanding too many changes and additions to the project, it's the responsibility of the programming house's project manager to ensure that the work is clearly defined, specified, and kept on track during the development process.
There was a third area of implementation risk for custom software that, in the past, would have topped the list: the complexity of the programming job required. Programming in many of the older third and fourth generation languages was a challenge for all programming teams, no matter what their size and experience. The languages were complex and the tools available for programmers were rudimentary. Modern development environments, languages, frameworks, tools, and libraries have reduced this risk, while at the same time speeding up the development process significantly.
8. Property rights
Who owns the software? "Property rights" is a major issue to consider in software acquisition. Companies often invest large amounts of money on critical software without really understanding the issues of ownership rights. The term "purchase", when applied to software, is misleading. In most circumstances, a company does not buy the software. They have only a license to use the software. There is no explicit or implicit ownership, and certainly no rights to the source code.
With off-the-shelf software, the fact that there are no property rights beyond usage is usually well understood. With leased software suites, the situation is often less clear. A leased software suite contains both the base software and custom modifications made to accommodate the software to client needs. A careful reading of the license usually reveals that the company leasing the software does not have the right to the base software code; it is licensed on an "as is" basis.
The rights for the company's custom modifications done either by vendor-employed or certified consultants are different. The client pays for these modifications, and the code usually belongs to them. This is actually a moot point because, although the code may belong to the company, it only runs with software provided by the prime vendor. This means that even if the code is available, it is worthless apart from the lease agreement with the primary vendor.
Different issues arise in regards to property rights for custom software. In most cases, the client receives the source code as part of final acceptance. The company's rights to the source code are almost always non-exclusive, with the developing company retaining the right to use routines developed in the course of the engagement on other projects. This is normal practice and, as long as the purchaser's proprietary routines are identified and treated separately, there is no problem.
The client usually agrees that their software is for their use only and not for resale unless specifically agreed to in the contract.
The contractor will also retain exclusive rights to certain pieces of code, such as frameworks and previously developed utility libraries. In these cases the client receives compiled code and a single-use license, along with a support agreement for these elements.
When source code is provided, it may come with a maintenance requirement. Some custom software development houses have a policy for annual maintenance. Others may charge only time and materials or allow third parties to provide maintenance on the code.
Either way, only with custom software does the issue of property rights tilt in favor of the company. With other forms of software acquisition, it isn't possible to have any real control over the software.
9. Cost of Ownership
The final consideration for software acquisition is the cost of ownership. It should be clear by now that decisions based solely on price are far too limited. Having said this, any company that does not completely and properly consider price in making a software acquisition decision can face a rude awakening.
Defining software costs is sometimes a very complicated process, but it can be broken down into two components: the initial (acquisition) cost, and the more important total cost of ownership.
9a. Initial Investment
The cost of "buying" software is the easier to calculate, but even this is not as simple as one might think. Even with off-the-shelf software, there's: 1.) the purchase price of the appropriate number of copies of the software 2.) the computers and infrastructure necessary to run the software 3.) the cost of installing and setting up the software 4.) the training and support for end-users. 5.) the user time in learning the software. It's clear that the cost is more than simply the purchase price itself.
With leased software, the cost of acquisition is even more complicated to calculate. It does no good to get a quote for application software only to discover that the vendor did not include database seat charges, networking costs or even operating system software ? under the assumption that these were not among the listed requirements or included in the vendor's offerings. Some vendors sell only the application software, but their software must run on a specific database server. The cost of all the appropriate software, and the hardware to run it, should be part of the total acquisition estimate.
The second part of the initial investment for leased software consists of custom modifications provided by the vendor consultants. This expense can range from as little as 25% to significantly more than the total price of the base software. It is essential to estimate and include these costs in any evaluation.
The biggest expense in custom software is for development and installation. As custom software is built specifically for one customer, the up-front costs are higher due to the amount of labor that goes into the programming. These costs are not easy to estimate, so investing the appropriate resources to make the estimate as detailed as possible pays off in the end.
Whereas ten years ago custom software might have been considered an expensive luxury, the cost of building this type of application has been declining rapidly over the past few years, shrinking and in some cases even eliminating the cost gap between custom and pre-designed software. Today, it is the way to go in most all cases.
9.b Total Cost of Ownership
Software ownership costs do not end with the purchase. The client must continue to invest in support, upgrades and maintenance throughout the life of the software. These costs usually exceed the purchase price of the software!
Off-the-shelf software costs are limited to upgrade releases. The fact that there are a limited number of upgrades makes the ongoing cost of off-the-shelf software ownership low. But the other side of this coin is that the software remains relatively static while business needs continue to change. If business needs exceed the limits of the software, the economic cost can be significant.
With leased software, the ongoing cost of ownership must also be split into three pieces: the cost of maintaining the base software, the cost of maintaining the client's modifications and the annual usage fees. Although figures vary between companies, a good "average" for annual upgrade and maintenance costs is about 15% of the total cost of the software. The client must also factor in an annual expense for software support. Pricing for support services is set either on a per-incident basis or on a subscription basis.
Vendors often provide a better quality of service to subscription customers than to those who pay on a per-incident basis. Support subscriptions are usually between 5% and 10% of the value of the contract on an annual basis. Between updates and support, a company should be prepared to spend from 20% to 25% of the original purchase price of their base software annually for the life of their software.
In addition to the cost of upgrade and support subscriptions with the vendor, there are ongoing costs for vendor consultants implementing updates, handling support, making modifications and enhancements, and adding new functionality to the base software. A good rule of thumb is that a company will pay consultants as much as 25% of the value of their initial services on an annual basis. This figure, however, can be significantly higher if there is an ongoing need for their support.
Leased software may or may not have annual usage fees attached to the software usage. Most of the major vendors have these charges and they escalate annually, based on a formula that may include the number of people using the software, the number of transactions during the preceding year, or the total value of goods that flow through the system. This expense may not exist in some installations but, if it does, it can be a considerable expense to the enterprise.
With custom software, upgrades to incorporate new functionality as well as routine maintenance cost money and, since the company owns the software, they must pay someone to modify the code. The difference is that the code is usually available, and there are people either internally or externally who can work on it to fix, improve, or enhance the product.
Maintenance and support costs for custom software are a definite part of the total cost of ownership, but are not as significant as those incurred with leased software. With leased software, the vendor mandates the costs. With custom software, decisions regarding maintenance and support rest with the client, and they can prioritize both their needs and sources for the work.
A good rule of thumb is that the company should expect to spend from 10% to 15% of the initial cost of the software on maintenance and upgrades per year. The key here, once again, is that the client is in control of the process and the decisions that must be made.
Conclusion
EPS Custom Software Group is a software development house which, quite naturally, is interested in selling custom software services.
Our purpose in preparing this paper was to expose as many factors as possible in the software acquisition process, so that decision makers can more easily carry out their own analyses. The radical change in custom software development has made this option more attractive than ever. We believe that in more and more circumstances, custom software is the best choice for mission-critical applications today.
The intent of this paper has been to educate decision-makers about the qualitative as well as quantitative factors in software acquisition. If we can be of any further assistance to you in your decision making process, we would be happy to speak with you. We also urge you to visit our website, at the address below.
