When to Buy, When to Build: Six Steps Toward Composite Apps

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.

Step 1: Determine Your Requirements

IT, at times, seems to be like a soccer team made up of six-year-olds. There is no strategy, but they know they must all chase the same ball. The challenges vary as enterprises are all different, as are the business requirements they must address.

Make sure you understand the business challenges first. Identify the core business problems youre trying to solve. What is the potential value that the new applications/services will bring to the business? In other words, define the ROI.

Technical requirements are important as well, including interfaces, response times, security, use and integration of existing applications, and changes or additions to the data model. All of the above can be summarized as follows:

1. A semantic-level understanding of the problem domain.

2. A services-level understanding of the problem domain.

3. A process-level understanding of the problem domain.

4. New services required.

5. New processes required.

6. Security requirements.

7. Performance requirements.

Note, that the problem domain might be a single application, a few core systems or many systems, but it's typically not the entire enterprise.

Step 2: List Candidate Services and Applications

After determining just what youre dealing with from both a business and technical perspective -- and understanding what youre looking for from new services and applications -- its time to inventory a broad range of services that have the potential to meet your needs.

Start by looking around the enterprise at existing legacy services and traditional enterprise application services (ERP, CRM and so on). Next, survey the Internet for "mashable" services that might bring value to your composite. In essence, youre creating an inventory of potentially valuable component parts for something you have yet to build. For example, say you need a logistics tracking service to monitor the movement of product. You would find very similar service(s) within ERP systems, available over the Internet using a SaaS or services marketplace, or you could build the darn thing internally. Add all available options to your inventory.

One of the critical steps in this process is validating the services that you dont own or control. This means vetting external services using the same criteria you would apply to internal services, meaning form, function, fit to purpose, security, interoperability, use of standards, etc. All of this information should be cataloged to assess the fit into a governance system (discussed next).

Step 3: Build Governance and Policy Management Layer

All of these services will have to be tracked and controlled someplace, and that place is typically going to be a governance layer. Thus, this is a good time to build a governance infrastructure that will catalog all of the services that have potential value as well as manage security and policy around those services as well.

The definition of governance varies from vendor to vendor, but youre typically looking for the following patterns:

- The ability to list and track all services that are interesting to your future composites (directory)

- The ability to manage policy around the use of services

- The ability to address security and logging

- The ability to link to design environments

Step 4: Calculate the Real Cost

This is where the rubber meets the road in the analysis. You need to define the real cost of each candidate service. Youll find that this exercise is not as easy as picking up the phone to get best-and-final pricing.

The best way to determine cost is on a monthly basis, including the cost of hardware, software and maintenance. Considering the example of the logistics traffic service, here are sample cost analyses for three options:

Scratch-Built Logistics Tracking Service

40 full-time-equivalent days to design, develop and test = $80,000

New server = $5,000

Maintenance = $3,000 per month x 60-month life cycle

Total cost = (($80K + $5K) + (3K 60 months))/60 months) or $4,416.66 per month

Enterprise-App-Delivered Logistics Tracking service

Enterprise license = $400,000, prorated to $30,000 for use with this project*

Maintenance = $100 per month (prorated)

Total cost = ((30K + ($100 60 months))/60 months) or $600 per month.

* Here we're assuming that the enterprise software has other value, and those systems are sharing the cost. If that's not the case, the cost would be prohibitive as you would not purchase an enterprise application simply to provide a few services to a few composites. Were also assuming the prorated hardware cost is almost $0.

SaaS-Delivered Logistics Tracking Service

Subscription fee = $200 per month

Total cost = $200 per month..

Step 5: Consider Your Enterprise

Based on cost alone, the SaaS-delivered service in this example would be seem to be the most compelling opition. However, there are at least four other issues at play:

Culture. This is a huge issue if the current thinking in IT is that it should build everything and that anything not invented inside the company is pure evil. Unless there is acceptance that its okay to purchase or lease services and/or applications, this analysis with get you nowhere because there are no options. In many instances, a change in culture needs to occur before you can even consider external services or applications.

Infrastructure. It's certainly an impediment if there is little or no infrastructure in place to create composites. SOAs are not just a bunch of Web services. They provide mechanisms through which services can be consumed and exposed, and those mechanisms are crucial if you hope to use services you did not build. You can leverage conventional- or SaaS-delivered applications without SOA, but youre not able to mix and match services on more granular levels.

Security. In many organizations, using services or applications that are hosted outside of the organization is a no-no, so this may not be an option. Moreover, packaged enterprise applications, and the services they may expose, have to live up to enterprise-specific security requirements.

Performance. This could be an issue considering that composites almost always run slower than conventional applications where all of the processing occurs internally. You need to determine performance requirements up front, and factor that into your buy-versus-build decision.

Step 6: Pull the Trigger

Finally, you need to weigh all the cost, culture, infrastructure, security and performance variables and justifications and make a decision whether to buy or build. If you take the composite route, you'll need to stay on top of whether expectations are being met and always have a Plan B ready if they are not. The decision will be easy if youve gone through all of the steps above and have a deep understanding of the options available and the tradeoffs of each approach.

What you're really doing is creating a set of patterns that will lead to an overall enterprise strategy. Thus, its helpful to think strategically as these decisions are being made. There are huge opportunities here. Yes, money can be saved over time, but the biggest value should be how quickly you can align your applications with the needs of the business. This is the value of SOA and of composite applications that can be easily adapted to the changing needs of your organization.