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 both—they'll buy some services and build others—but 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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access