So how does SOA help with this? If you remember the SOA stack introduced in Chapter 1, these layers of abstraction insulate the enterprise so that changes do not ripple past interface boundaries. By containing the impact of these changes, service orientation keeps development and maintenance costs low and also reduces risk (another value proposition that we will discuss in the “Reducing Risk” section).

Increasing Asset Reuse

Question: What do the following things have in common?

• Disposable diapers
• Paper plates
• Air filters
• Application software

Answer: None of them have ever been designed to be reused.

While some might take exception to this, the reality is that reuse has become something of a holy grail in the information technology (IT) realm. Project managers, business divisions, and even entire enterprises have been chasing it for decades and many have concluded that it is merely a well-fabricated myth. It should come as no surprise, then, that proponents of service orientation are heralding the value of reuse as a major reason to adopt SOA. Those who are relatively new to the industry are quite excited about the prospects of service-oriented reuse. Those of us who have been around for a while, however, recognize that each new technology wave takes up the reuse mantra and espouses the virtues of its particular approach. Service orientation falls prey to this as well. In an attempt to determine the validity of SOA’s reuse claim, we will start by examining software reuse in general; then we will highlight the shortcomings of previous strategies, and finally examine the potential for SOA to actually deliver on the promise of reuse.

Copy-and-Paste as Reuse
Reuse has been tried before. We have tried reusing subroutines, functions, objects, and, eventually, components. Each time we have suffered from one fundamental weakness. No matter how clever the reuse strategy was from a software development standpoint, once we moved into production we had to deploy the software as a local module or library for each system that needs that capability. For example, one team develops a software library for data access. Another team needs the same capability, so they get a copy of that library and deploy it on their server. Then the first team upgrades to the next version. Then a third project borrows the library and modifies it for their needs for a different application. Before long, there are three or four variations running around, no central version of the truth, and no way to provide direct access to a common library at runtime (see Figure 3). Every time someone wants to “reuse” this data library, another copy is placed out onto a server and the potential for another development branch is created. So, in theory we have reuse. In practice, it is just glorified copy-and-paste.

Figure 3: Traditional reuse is more like glorified copy-and-paste

Service Oriented Reuse
Reusing services is a bit different. A service is created and hosted in one place. If another application or system needs to utilize that service, it simply needs to send an appropriately formatted message to the service address (see Figure 4). Additional copies of the service do not get distributed all over the enterprise. Certainly there still will be a need for additional versions of the service to be created, but they are centrally managed and additional uses of the service can be easily supported without losing control.

Figure 4: Service oriented reuse enables capabilities to be reused in different contexts

Increasing Agility
There was a time in the not-too-distant past when the pace of business was a bit slower than it is today. You could leave a message for someone and not expect a response for days, and deploy new products and solutions in months or years rather than days or weeks. If a company had a bad quarter, the market was forgiving and the prevailing mentality was to wait and see how the company performs the remainder of the year. Fast-forward to modern days and you are thrust into a 24/7 business cycle. Messages must be returned the same day, new products and services developed in a matter of weeks, and if a company’s stock is tanking in the morning, investors are questioning the chief executive officer’s (CEO’s) grip on business by lunchtime.

Customers and the market at large seem to value speed and responsiveness over safe, methodical business practices. Responding to opportunities in a matter of weeks or months is no longer acceptable. Previously, this was the advantage of working with smaller firms, but now even large organizations are expected to be nimble and able to adapt quickly to new opportunities. This is what is meant by the term agility. Agility is a measure of how quickly an organization can modify existing capabilities, create new products and services, or modify business processes. Service orientation raises the visibility of underlying business rules and enables rapid turnaround of new and modified business capabilities.

By breaking monolithic information systems into a collection of services, business capabilities can be more quickly and easily modified. For example, a company might have developed some customer account profile services and order-tracking services for use internally by employees. Later, there is a desire to create a customer account management portal to serve customers better and reduce the number of calls made to the customer support center. As illustrated in Figure 5, the existing services could be used to provide access to customer profile and order history and a few additional services created to add visibility into the technical support database.

All of these services could be consumed by a Web portal that is then made available to customers. In the absence of an SOA, all of these capabilities would need to be built from scratch or, at a minimum, copied from other applications and then integrated into the new application. Either way, a service-oriented solution is faster and cheaper to develop. That is how SOA enables agile business.

Figure 5: Service Orientation enables business agility