When to Buy, When to Build: Six Steps Toward Composite Apps
Services-oriented architecture, SOA-standard interfaces, SaaS applications and Internet-delivered services are opening up new options to mix, match and mash up internal, off-the-shelf and on-demand offerings into composite applications. The goal is to quickly respond to changing business requirements by taking advantage of ready-made components that fill gaps in applications. But how do you know when to buy and when to build? Here's a six-step approach to making the right choice.
With service-oriented architecture (SOA), Ajax, the enterprise service bus (ESB) and other new technologies maturing, application architects and business analysts have tough decisions to make about whether to buy packaged applications, build them, or more likely, do some combination of the two.
The buy-versus-build question is even more important now that we have infrastructure to support the mixing and matching of applications and services. Best practices are beginning to emerge, and sources for applications and services are rapidly multiplying, including open source, new SOA interfaces for traditional packaged enterprise applications and SaaS offerings. The SaaS vendors, in particular, are making new and innovative applications and services available at price points that were previously unheard of.
So, how do you know when to buy and when to build? There are no hard-and-fast rules, but this article presents a six-step approach to make sure youre making the right calls.
What Has Changed?
The short answer to this question is "everything, with an exclamation point now placed after the buy-versus-build question mark thanks to several big trends:
- The use of SOA gives architects the ability to mix and match services to form new and customized composite applications
- Service interfaces have been added to conventional enterprise applications, including most packaged ERP and CRM systems
- Legacy systems have been modernized with service interfaces
- SaaS (Software as a Service) technology and providers have emerged, offering complete applications as well as simple services on demand
- Ajax and other RIA (Rich Internet Application) technologies are closing the gap between enterprise-delivered applications and applications delivered over the Internet.
Web services and, to a higher level of abstraction, SOA, were created around the notion that it's easier to discover and leverage somebody else's service rather than write your own from scratch. Also, it's easy to create applications made up of many services, an approach that lets you change apps at a pace faster than achievable through conventional software development approaches.
The idea of Web services and SOA was to create a standard interface, programming model, description language and directory supporting interoperability between very different systems. Indeed, today you can leverage services across the Internet that are functionally equivalent to services you now build and host locally.
Taking this concept to the next level, we can build applications (composites) through the selection and use of these services. For instance, we have no need to write a logistics subsystem if one exists on a server someplace that you can access on demand. No need to write a risk-analytics application; instead leverage somebody else's work. You buy rather than build to save a ton of time in the application development process. In the bargain, business becomes more agile and IT more cost effective. This is the promise behind SOA.
The move to composite apps requires not only the embrace of reusable services, both remote and local, but also a great deal of research and planning to determine your requirements and flesh out the options and tradeoffs of buying versus building. This is uncharted territory for most enterprises, but outlined below are some best practices and a six-step approach that should make the process easier for the inexperienced.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.