Section 4.38. Is buy versus build a false tradeoff in ESA?

4.38. Is buy versus build a false tradeoff in ESA?

In the past, there has been a debate about the tradeoffs between committing the resources to building custom applications versus buying standard (and thus nondifferentiating) applications from vendors. Taking into account all of the short- and long-term implications, what is the total cost of each? And how does this dichotomy apply in the far more granular world of services?

In the world of ESA, organizations will do boththey'll buy some services and build othersbut what will really differentiate them from their competitors is the deployment of processes based on those services. Because of that, companies should plan to buy as many necessary services as possible, then use them to automate and improve new and existing processes unique to them. Buy, build, and compose becomes the model. Because of the nature of services, changing them and extending them is a simple matter. Instead of building services from scratch, customers will often adapt and extend services in ways that differentiate them and meet unique business needs. Over time, there will be a core of standardized services, new ones appearing on the market, and custom services created by customers and partners. But building versus buying stops being a dramatic choice because they'll do both on a regular basis.

Figure 4-11 illustrates the previous divide between packaged applications and custom code. Figure 4-12 shows how this divide is bridged by composite applications drawing upon the relevant functionality of both. Service enablement will simultaneously drive down the cost of custom development by eliminating the need to develop code from scratch each time out, while also increasing the value of commodity software by raising the possibility of innovation through creative reuse.

Figure 4-11. Build versus buy

Figure 4-12. From build versus buy to build, buy, and compose