To buy or to build?

It's a question of Shakespearean proportions. Should you license a commercial enterprise application that will meet 75 percent of your needs, or would it be nobler to build your own application, one that will track as closely as possible to the task at hand?

Decades of trial, error, and egghead analysis have yielded a consensus conclusion: Buy when you need to automate commodity business processes; build when you're dealing with the core processes that differentiate your company.

But reality isn't quite so orderly. Creaky, complicated systems developed in-house may handle mundane tasks, but astronomical switching costs may make them impractical to replace with commercial software. And in some instances, packaged software -- even SaaS (software as a service) offerings --may fit the strategic plans of an enterprise hand in glove. "Buy to standardize, build to compete" may be terrific as an ideology, but the choices that real companies face are a lot messier and more interesting.

As enterprises from MCI to Motorola to Visa weigh the build-or-buy decision in their projects, two overarching trends emerge. First, as vendors saturate the market from general-purpose CRM to the narrowest vertical solution, the economic pressure to buy and consolidate (or subscribe and let a SaaS provider deploy and maintain) continues to mount. And when companies decide to build, they strive to ensure that the functionality created is as reusable as possible across the organization.

"Everybody knows that the more standardized you are and the more you buy off-the-shelf, the more cost effective it will be for both implementation and ongoing maintenance," says Mark Lutchen, former global CIO of PricewaterhouseCoopers, now head of the firm's IT Effectiveness practice.

On the other hand, executives such as Bob Laird, IT chief architect at MCI (now part of Verizon Business), sing the familiar refrain of in-house development: "Where we tend to invest is where we can get incremental revenue or competitive advantage," he says.

As with many modern enterprises, Laird and team have recast their in-house development efforts within an SOA, enabling them to reuse rather than build from scratch. "Part of the decision is to look at your legacy applications and analyse what legacy you have that still has business value," he says.

Build-versus-buy decision points remain the same: cost, time to market, politics, architecture, skill sets, and strategic value. Additionally, vendor consolidation has led to new pricing models and bundling options that give customers much greater leverage.And finally, open source is delivering the best of both worlds, with hybrid approaches that combine purchased and custom-built components. Pop the hood on any large IT organization, and you'll likely find a wild mix of all these approaches.

Page Break

Pulling out the checkbook

Most IT execs say they evaluate commercial software first, particularly when time-to-market and money are top priorities. The rule of thumb, PricewaterhouseCoopers' Lutchen says, is to buy applications to the maximum extent possible to cut costs -- freeing up resources for whatever really needs to be built in-house.

When evaluating whether to buy or build, it's critical to thoroughly understand total costs during the software lifecycle -- typically seven or eight years. This step is important, Lutchen says, because 70 percent of software costs occur after implementation. A rigorous lifecycle analysis that realistically estimates ongoing maintenance by in-house developers often tips the balance in favour of buying.

Even in core areas that touch an enterprise's customers, products, or services -- and even when an IT shop has a cultural bias toward inventing software in-house -- buying can still win the day. Visa, for instance, has a build-centric IT organization, partly due to security, reliability, and privacy concerns, but also because of the global financial network's enormous scale. "The sheer volume of information makes it often impractical to outsource projects effectively to smaller organizations," says David Allen, a consultant who served as Visa's CTO (through Visa's technology arm Inovant) for three years.

Nevertheless, when Visa was looking to offer greater support to its member banks and merchants with such applications as profitability-usage analysis, it streamlined its approach to data collection, dissemination, and reporting, integrating vendor-based solutions versus its more typical building approach (Visa promotes PMI certification across the board, and uses both classical methodologies and iterative styles in development). Visa purchased applications for information processing from Ab Initio and for reporting and analysis from Microstrategy because the functionality could be delivered much more quickly with lower lifecycle costs than building.

In areas such as infrastructure and tools, Allen pushed Visa to the buy side. "They work, and there is no competitive advantage to build," he says. "Those systems are built at a scale because you're leveraging the technology across many companies."

Moreover, the open source movement has been a boon for Visa in areas such as development, operations, databases, and programming languages.

"The combination of low-cost tools and having the source code available can be like getting the best of both worlds [of buying and building]," Allen says. "We have gotten as good if not better in deploying new services on open source as on commercially available software like Windows."

Page Break

Buy, don't modify

Although open source implementations invite all sorts of customization, a clear lesson learned from the ERP wars of the 90s appears to have sunk in: When it comes to commercial software, avoid hacking the system when possible or you'll end up with maintenance costs equal to or greater than those incurred by apps developed in-house.

MCI's Laird says many companies, including his, have made the mistake of rewriting third-party apps until they are essentially homegrown. "If you are going to buy something and make significant changes to fit your business, why bother?" he asks. In areas of the business that are not unique to MCI -- such as sales and financials -- he opts for adapting MCI's processes to fit off-the-shelf software. "[The software] has to be close to our business processes or we can readily adapt our business processes to it."

As an alternative to customization, Lutchen recommends turning to aftermarket products, such as the raft of plug-ins now available for the major ERP packages. "If you can avoid touching the main package, it will keep your maintenance costs down," he says.

SaaS solutions, which deliver applications through the browser, by their very nature, prevent costly modifications. Moreover, SaaS is "a better sales model and return model for the enterprise," says Toby Redshaw, corporate vice president of strategy, architecture, and e-business at Motorola, which uses SaaS offerings from Salesforce.com and Rearden Commerce. In part, Redshaw says, this is because SaaS vendors typically let customers pick and pay for functionality in modular fashion, versus licensing packaged software functionality that will never be used.

Redshaw says the SaaS model will have an enormous impact on enterprise IT. Commercial software may boast shorter time to market and lower maintenance costs than big in-house development projects, but SaaS incurs no hardware or software capital investment and drives maintenance costs lower still. Redshaw predicts a continuing drop in enterprise software prices, due to unfulfilled promises of big ROI, greater customer diligence in purchasing, and increasingly fierce vendor competition.

New, attractive buying options raise the bar to justify in-house development. They may also tip the balance toward replacing aging proprietary apps with tried-and-true commercial solutions.

Page Break

Building for success

Over the past few years, the District of Columbia city government has engaged in a district-wide standardization effort to migrate from homegrown departmental systems to standard off-the-shelf applications from Ariba, PeopleSoft, and others. Nonetheless, Dan Thomas, director of the District's DC-Stat business-intelligence group, decided to develop a BI system with functionality that commercial software alone could not deliver.

To leverage his development efforts, Thomas opted for an SOA approach and mixed commercial software with in-house development to create an array of Windows and Web-based analytical tools for executives, analysts, general staffers, and mobile workers. "We buy the core applications and build connectivity and tools to do the work," Thomas says.

First, he licensed the foundation applications: geographical information systems from Oracle and ESRI, business intelligence applications from Business Objects, an ESB (enterprise service bus) from Sonic, and a portal solution from Plumtree. Next, DC-Stat developers used Java and .Net to build services and interfaces to tie the core applications together.

The stakeholders needed four applications with different UIs, a principal reason Thomas opted to build rather than buy. "We try to move very quickly and follow agile development methodologies," Thomas explains. "I would rather give stakeholders something that is 80 percent of the way now, versus 100 percent later."

Although combining off-the-shelf and in-house development can lower risk and cost, certain core areas are so strategic and specific to the business that commercial apps never enter into the discussion. At MCI, that means anything that directly touches its telecom network, says Laird, such as network provisioning, network management, and network restoration.

In the 1980s, MCI built an automated network-restoration system, because no such commercial apps existed. The system was so successful it enabled MCI to achieve the lowest FCC-reported outages in its industry, Laird says, a record that the company says it continues to hold today.

Page Break

Commercial potential

When none of the available packaged software will do, a little creativity can lower the cost and overhead of building and maintaining proprietary apps. One method is to collaborate with competitors to build vertical software that can eventually be licensed.

"The marketplace and economies of scale are forcing competitors to work together more often," Lutchen says. As an example, he cites a client in the entertainment industry that is partnering with a competitor, venture capitalists, and a software company to develop a royalty information system. Off-the shelf royalty systems have been tough to implement, he says, because each contract is different, incurring complicated tracking and payment processes. Together, these partners are working on a system that will account for such wide variations.

The University of Pittsburgh Medical Center took things in a similar direction. In the late 1990s, UPMC was looking for a PACS (picture-archiving communications system) to convert radiology film to digital images for easier storage, viewing, and analysis. The problem was that none of the PACS vendors at the time offered a product that would display images on standard PCs.

With the help of an informatics lab on campus, UPMC developed its own PACS, still in use today. Soon after, UPMC partnered with venture capitalists to launch Stentor (a company that Philips Medical later acquired) to take ownership of product development.

Commercialization helped lower the risk in long-term support and maintenance. "We saw that the only way it could be really successful for the long-term was to get it outside of UPMC," says Duane Falk, UPMC's director of enterprise middleware. Falk also notes that having ample resources (250 developers in a total IT staff of 900), a sophisticated development culture (relying upon the Carnegie Mellon Capability Maturity Model), and an on-site lab makes major development decisions less of a gamble. "For us, it's not so much starting from scratch," he says.

Page Break

Shaking the decision tree

Other models are emerging that blur the line between build and buy. In an SOA, for example, business processes are broken down into coarse-grained application components -- which are beginning to be standardized and offered individually by independent players such as StrikeIron. The major enterprise software vendors, including Oracle, SAP, and Siebel, are also moving toward component-based models, although it remains unclear whether this will result in licensing of individual components to customers.

"I believe we're moving toward a model where the components are being commoditized and eventually I can go buy that service that I need," says DC-Stat's Thomas.

But enterprise IT can never completely escape the past.

"I always say, never start with a blank slate," advises John Pierce, vice president of global solutions for insurance at Patni Computer Systems, provider of on-site and off-site outsourcing services for midsize to large enterprises.

"You can't discount the legacy environment," Pierce says. "It runs your business from day-to-day."

Pierce says it all starts with defining business processes in the right way. "Business processes are often inward-focused versus outward-focused on the customer," he warns.

Increasingly, the asset-management approach to lining up data for decision-making is cropping up in IT environments, Lutchen says. "Spreadsheets are not enough. You need ... a systemic way to collect this data."

Tools such as IT resource planning software (which he describes as "ERP for IT") can help IT organizations assemble a complete picture of assets and requirements such as people, skills, compliance needs, budget, hardware and software, technology architecture, and so on. The best bet, Lutchen advises, is to collect and present the data, with detailed options and consequences, to business stakeholders. Then, let them make the decision.

That approach can help mitigate political battles, but inevitably, politics is the nasty beast always lurking beneath the surface of any technology decision. Do the best you can to empathize with stubborn stakeholders, Motorola's Redshaw advises, and learn to compromise on lower-priority projects. "Sometimes there are emotional battles that aren't worth it," he says. "Focus on the areas where you really feel you can make a difference in terms of saving money."

Page Break

Inside MCI's decision to build or to buy IT applications

In the past year, MCI had to make a decision about whether to buy or build a system to track third-party services inventory. The following series of questions illustrates how the company arrived at a decision to buy the application.

Should we build?

Q: Is there competitive advantage in building?

A: No competitive advantage.

Q: Is the project covering core or generic business processes?

A: Generic.

Q: Is there business expertise in-house to build something world-class?

A: Yes, but resources are tight and this is not a priority.

Q: Is there technical expertise in-house or available on the market to build something world-class?

A: Same as previous answer.

Q: What is the total cost of ownership?

A: Low to medium.

Should we buy?

Q: Do capabilities exist that meet or nearly meet our needs?

A: There are two packages that meet our needs.

Q: Can our business processes fit those imposed by the package?

A: Yes.

Q: Is the vendor going to be around for a long time? Many of the best solutions come from smaller vendors, so it is necessary to review their financials.

A: Both vendors are viable.

Q: Does the vendor fit into our cornerstone technology stack? (For MCI: Microsoft .Net on the portal side, IBM Websphere on the back-office OSS side.)

A: Yes, for both vendors.

Q: Does the vendor have a vision that is compatible with our vision of future growth needs for the package?

A: Excellent vision; better than we have in this area.

Q: Does the vendor have a demonstrated ability to deliver releases on time?

A: Yes, based on reference checks.

Q: What is the TCO (total cost of ownership)? Is it less than building and maintaining this ourselves?

A: An RFP was conducted and significant concessions were obtained. TCO is favorable.