The Classic Software Debate Takes a Turn

In the past, those responsible for acquiring and deploying software for important corporate functions would begin internal discussions with the tried and true question: Should we buy or should we build it? This question was quite rational and fostered extensive discussion. However, for major applications at almost any company, the debate is over.

Paul Bleicher

Few companies today would consider building their own general accounting ledger system or a customer relationship system—even if their core business was software development. High-quality, reliable, and sophisticated software exists for all major types of enterprise corporate functions and is designed to be customized and integrated with other systems while still being commercial, off-the-shelf software (COTS).

For the record, I am not trying to imply that such software is always ideal or bug and frustration free. But it is generally available in a robust and scalable form that is a good match for the needs of customers. In addition, the last few years have brought an additional question: Should we rent?

Back in the Day

Going back a few decades, corporate IT in large companies may have considered a buy vs. build decision for just about any software contemplated. At the time, COTS may have been difficult to use, prone to problems and data loss, and somewhat limited in functionality and customization. The alternative—to direct an internal team or external consultants to build a customized product with exactly the functionality needed—seemed a very attractive alternative.

Some home grown systems functioned quite well for many years in corporate environments. However, the systems would often require ongoing maintenance and expansion to meet the growing needs of the business, and eventually those systems became a source of significant corporate expense and user frustration. In a scenario that repeated itself from industry to industry, from application to application, a few COTS applications in each area would eventually emerge as being modern, robust, and fully featured.

While the COTS might not have had exactly the functionality desired or exactly fit the process being used, it was compelling enough to purchase and deploy. Often, it would take several major upgrades until the COTS application was "perfect" for the organization, and sometimes it simply required an evolution from users who were accustomed to the old, custom system to new users without any previous experience.

In the end, the elimination of internal maintenance, support, and development—as well as user frustration—typically made the migration from a custom software system to COTS a winning proposition for the company.

Evolutionary improvements

While each industry is different, the general evolution of software deployment is very similar between them, though it may drastically differ in the pace and timing. As we have already seen, software may arise from internal projects, consulting engagements or commercial offerings with limited functionality and flexibility.

Some companies will build their own solutions (occasionally more than once!) and passionately feed and care for them. Other companies will pilot one or more of the existing solutions, finding none satisfactory. If the software has a large market and/or is horizontal (i.e., applicable in many industries), vendors will invest in and continue to improve their software. And for a time, many vendors may appear with competing solutions. Eventually, a few products/vendors will emerge from the competing vendors as the choice for most of the buyers.

Over time, this lead may shift from company to company, and disruptive technologies/companies may emerge from the pack and take the lead. The major theme, however, is consolidation and concentration of the market, which creates the level of customer support necessary to sustain these companies.

The concentration that occurs is almost universal because it is driven by recurrent market forces. Buyers focus on the companies with the best combination of features and services and look for products that are used by many other companies. These companies have more money to develop and expand their product, and thus become even more attractive to the buyers.

The focus on two or three products in a market is a winning proposition for almost everyone involved. The buyers get richer products and better services, especially if there is meaningful competition. The vendors can grow their companies, always staying alert for the competition. The only ones who lose are the companies that are not one of the leaders or acquired by a leader.

Boutique software

There are many areas in which the there are fewer vendors or less mature solutions to meet emerging or important needs of companies. Also, in some areas there may be a group of vendors/COTS with no particular leader, or a series of custom built products. This often happens where there isn't a large enough market and/or enough critical mass of customers to drive any particular solution to a leadership position. These are often referred to as boutique markets or boutique software products. These markets are the primary place today where IT departments may drive a buy versus build discussion.

The argument to build a solution, whether internally or with consultants, will arise from arguments that the specific needs of a company are unique or that none of the COTS products available on the market have the right functions. This reasoning may be true in some cases, but often these types of conclusions arise from some faulty assumptions and/or political considerations.

Reluctance on the part of the organization to examine and change processes to meet those of an adequate COTS solution may lead to a custom solution that "bronzes the baby shoes"—linking poor business processes and workflow to the software for years to come. And the cost of developing and supporting a custom solution are often underestimated by orders of magnitude. In addition, the "imperfect" COTS solutions from existing vendors may be of higher quality and enforce better business processes than the planned custom software.

Why not rent?

Over the past 10 years, a dramatic change has entered the software market, enabled entirely by the emergence of the high bandwidth, universally accessible, and security enabled Internet.

The Internet enabled the development of a business/software deployment model known as Software as a Service (SaaS), whereby enterprise software can be deployed from a central server by a third party. SaaS is deployed on a central server, either as an individual instance for each customer or in one large multitenant application. The software and its installation is managed entirely by the software vendor, and companies can use the software with little more than some initial configuration and training for users.

One of the best known examples of SaaS is Salesforce.com, which provides customer relationship management (CRM) for the sales force entirely as a service. Salesforce.com has made dramatic inroads with CRM customers, from the largest to the smallest companies, taking substantial market share away from longstanding traditional CRM software.

The SaaS model dramatically disrupts the classic buy vs. build debate in several ways. First, SaaS software is typically offered as a subscription, with terms varying from one year to several years. SaaS software doesn't require a substantial upfront cost for building software or licensing, and the cost of using the software can be easily projected over several budget cycles.

Next, the deployment of SaaS software doesn't require an army of IT and database professionals to manage the software and its users. Companies whose core competence isn't information technology no longer have to find and hire experts in the particular software being deployed or mange the peaks and valleys of demand for these resources. This is especially important for small companies such as biotechs. For large companies, a long-term analysis often shows a substantial savings in total cost of ownership when using SaaS. For these reasons, the SaaS model has been very successful in a wide range of companies, from the Fortune 500 to the 10 person startup.

The SaaS model also provides the opportunity to try software before committing to it. Since the cost of buying and installing software is eliminated with SaaS, companies can pilot or choose to work with a particular solution without making a permanent commitment to that solution. This flexibility provides the opportunity to migrate to a new solution when a better one appears or another emerges with better functionality or services.

Points of friction

Given the advantages of SaaS, why do some companies continue to buy and install enterprise software in many cases? There are many answers to this question that vary from legitimate business considerations to problematic internal politics.

One of the most common points of resistance to SaaS software is a perceived need to manage software and data internally. IT organizations in companies often feel that they can do a better job at building and/or managing software than an external vendor. Although this may be true in some cases, a careful vendor selection through recent references and the use of service level agreements (SLAs) can provide assurance of quality and responsiveness.

Some software needs are, indeed, highly specific and unique for an organization. In this case, it is highly unlikely that software of any type, whether licensed or delivered by SaaS, will be available or adequately supported/updated over time. The economics of developing software of this type simply don't make sense. With eyes wide open to the total costs of ownership, companies with this issue may choose to build the software themselves or with consultants.

Any company that comes to the conclusion that they have a particular software need or process that is unique enough to require custom software should consider this conclusion very carefully. Every company thinks that their process or industry is unique, but the large majority of internal processes fit nicely into existing software and often can benefit from standardization.

Another aspect of internal resistance to SaaS (and also, more traditionally licensed software) is the "Manhattan Project" complex that sometimes drives IT organizations to build software themselves. A major project, which includes substantial staff and budget increases and corporate-wide participation, can be very attractive to an IT organization. It is essential, in evaluating the need for such a project, that the real need be weighed against the substantial costs and high historical failure rates of these types of projects.

The big question nowadays

As always, biopharmaceutical companies create value through innovation in science and medicine. Today, this type of innovation requires substantial management of data, processes, and information. Though this management is part of the core competence and even competitive advantage of the best biopharmaceutical companies, the development of the software required for this no longer needs to be. Today, the buy vs. build decision has been replaced, in the majority of circumstances, with buy vs. rent.

Paul Bleicher MD, PhD, is the founder and chairman of Phase Forward, 880 Winter Street, Waltham, MA 02451, (888) 703-1122, paul.bleicher@phaseforward.com,www.phaseforward.com.

He is also a member of the Applied Clinical Trials Editorial Advisory Board.