This content is excerpted from Service Oriented Architecture Field Guide for Executives (978-0-470-26091-3) with permission from the publisher, John Wiley & Sons. You may not make any other use, or authorize any others to make any other use of this excerpt, in any print or non-print format, including electronic or multimedia.
SOA Value Story
Ronald Schmelzer, of industry think tank ZapThink, describes four key benefits to SOA.[1]
- Reducing integration expenses (both development costs and maintenance costs)
- Increasing asset reuse (no need to re-invent the wheel each time)
- Increasing business agility (the pace of business has changed, but few enterprises have)
- Reducing business risk (both operational and compliance risk).
In the following sections, we will explore and illustrate each of these value propositions.
Reducing Integration Expenses
“If I had a dollar for every time that upper management asked me to cut costs…” — A CTO who is fond of irony
Cost cutting is a common demand that is levied on technology organizations. Consequently, each new paradigm within the industry (e.g., client-server, Web/n-tier, SOA, etc.) is pitched by some as a cost-cutting strategy. The trouble is that many enterprises attempt some grand enterprise-wide deployment rather than incrementally growing their SOA over time and incorporating lessons learned along the way. The fact is that, if properly implemented, SOA actually can reduce both development and maintenance costs. Use of loosely coupled, standards-based interfaces keeps integration costs low. By leveraging standard protocols, data formats, and interfaces, a great deal of traditional integration costs can be mitigated or even entirely avoided. Additionally, SOA’s push toward loosely coupled system integration allows for a reduction in time spent writing and ultimately maintaining custom integration logic. Some enterprises even see a reduction in middleware maintenance licensing fees by moving to standard Web Services interfaces rather than paying for a large stack of licenses in order to connect systems via various proprietary connectors and adapters.
Another way that SOA helps to keep costs low is by reducing the impact of making significant system and infrastructure changes. The multiple levels of granularity within SOA (recall the SOA stack examined in Chapter 1) facilitate changes to business processes and system use cases while minimizing the impact to the software baseline.
SOA reduces system maintenance and development costs associated with the deployment of new solutions by isolating components and systems through well-defined interfaces and proper architectural layering. To understand this better, consider Figure 1. In a standard enterprise environment, integration points between systems are tightly coupled:
- Vendor, platform, and/or language-specific bindings.
- Application-specific data formats are used.
- Application-specific application provider interfaces (APIs) are directly leveraged.
Figure 1: Tightly integrated enterprise environment
Each system in Figure 1 is directly connected to the systems with which it must interact during the course of operation. In some cases, external partners are even coming in through the firewall to directly access enterprise systems. In this particular example, the enterprise resource planning (ERP) system is a key component of the enterprise (typical for manufacturing, engineering, and product-centric businesses). It is a mission-critical system that the entire supply chain hinges upon. When significant changes need to be made to such a system (either upgrading to a new system or even just moving to the next major release), the impact of such a change can ripple throughout the enterprise. Figure 2 illustrates this ripple effect, impacting other systems and even the external systems of external business partners.
Figure 2: Changes to the tightly integrated environment produce a catastrophic ripple effect
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
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