SOA: The 1-2-3s
Perspectives on measuring the ROI and implementation progress of your enterprise SOA push
--James Kobielus
SOA’s return-on-investment (ROI) is both hard and soft, quantitative and qualitative, near-term and deferred—depending on who you ask, how you ask, and how both you and they define SOA.
SOA’s ramp-up costs
SOA’s ROI can be calculated in monetary terms if you have a crisp enough definition of the approach. Fundamentally, SOA is a development methodology that encourages sharing of remotely invocable application functions throughout networks. Another way of characterizing SOA is as the “provide once, consume everywhere” paradigm. It’s a way of doing more with less, where applications can be built more quickly and incrementally, through recomposition and orchestration of pre-existing services, and with fewer and fewer lines of original code. In other words, SOA promises that the marginal cost of building new applications will continue to drop closer to zero as the service-reuse rate climbs closer to 100 percent—in other words, new applications simply plug into existing applications rather than re-invent their functionality. This SOA nirvana of 100 percent service reuse is illustrated in Figure 4.
SOA can have a substantial payback for implementers. First, though, your organization may have to surmount a significant ramp-up curve that doesn’t come cheap. As the word “architecture” in SOA indicates, you’re going to need to rethink many of your traditional approaches to application modeling, development, integration, deployment, and management if you truly commit your careers to this new paradigm.
“No business wants to spend on architecture—they want you to produce products,” says Christopher Crowhurst, vice president and principal architect at Thomson Learning, a Stamford, Connecticut-based business unit of Thomson Corporation. “I can guarantee there’s a cheaper way to built your next product [than by taking an architectural approach], but there’s no cheaper way to build your next 20 products. That’s why IT professionals are adopting SOA [for application development].”
“The core tenets of SOA are coarse-grained service abstraction, orchestration, and interoperability through proxies.” said Crowhurst. “I only know four or five companies that are purely implementing all of these SOA approaches, because it’s a hard job. It requires a considerable amount of business process re-engineering.”
These observations are borne out by leading analyst firms. Forrester Research analyst Ken Vollmer and Mike Gilpin report that SOA-based development often costs more than—sometimes twice as much as--traditional approaches when viewed solely with respect of building a particular application component. But when that application component is reused over and over, for integration with other applications—both internal and external to the enterprise—SOA may become more than 30 percent more cost effective than traditional development approaches. These savings derive from the lower lifetime development, integration, and maintenance costs associated with SOA-based distributed applications.
SOA’s downstream cost savings from application reuse and consolidation
Many of the savings from SOA stem from its ability to consolidate silos of redundant application functionality and data throughout organizations. Fewer software licenses and servers translates into clear cost savings in enterprise capital and operating budgets. Fewer redundant software components throughout the organization translates into less need for redundant programming groups. Application consolidation onto fewer platforms reduces deployment, integration, and maintenance costs over the software lifecycle. A recent Gartner Group study found that the costs of installing, integrating, and maintaining software over its useful life can be as much as six times greater than its license cost.
You need to make an investment in SOA in order to reap the cost-reduction benefits of application consolidation, sharing, and reuse. Standard Life Group of Edinburgh, Scotland has committed considerable resources to SOA as the basis for all current and future business applications.
“We have invested in our people and processes in order to fully implement and realize the value of SOA,” says Derek Ireland, group tech solutions manager at the firm. “We have developed architecture, design and implementation patterns for delivering service-oriented applications. We have over 30 person-years of effort invested in a run-time framework that underpins the whole approach, abstracting applications from underlying transports and protocols and providing standard APIs for common application behaviors such as logging. We have a virtual team representing all development areas that identifies, exhibits, and promotes best practice for delivering reusable business services. This team manages the catalog of reusable business services and the development process required to ensure consistency of XML interfaces, ensuring interoperability of services.”
Standard Life has kept close tabs on the return from its SOA investment. “We’ve saved over 2.8 million pounds in development costs over the past three years,” says Ireland, “based on reuse of existing functionality within the service catalog.” The company currently has around 300 reusable services in its catalog. Over 50 percent of those services being reused. They are being consumed by more than 70 other services across all environments at any time. All in all, the company counts 361 instances of service reuse. Over 40 percent of its back-end transactions are initiated through its SOA-based environment. The volume of transactions that traverse Standard Life’s SOA environment has increased 900 percent since the company began its SOA implementation in 2001. The company maintains three SOA-implementing development groups with around 500 personnel among them, of whom about half are delivering SOA services and applications. Their SOA-enabling distributed-application infrastructure is managed by a staff of seven.
Other enterprises report both hard and soft monetary paybacks from SOA. “We’ve seen huge savings in Oracle [database] licenses,” says Jayson Minard, CIO of Abebooks in Victoria, British Columbia, due to the server consolidation that has accompanied their SOA push. At the same time, says Minard, “we’ve also seen savings on the team side, due to having more development staff bandwidth for new projects. Development group efficiency is going up.”
Another cost advantage of SOA is that—by stressing platform-agnostic service virtualization—it allows enterprises to choose the most cost-effective best-of-breed application components for particular functions. “With SOA, you can go the vendor’s SOA route,” says Minard. “Or you can take the approach that we did. First, we identified the features and benefits we were looking for, such as flexibility, decoupling, asynchronous communications, and service boundary partitioning. Then we identified best-of-breed products that addressed those requirements. We evaluated 14 products, including commercial offerings and open-source packages. We tested interoperability among those products, and eliminated the ones where the vendors differed from us in their philosophical approach to SOA. In that way, we’ve steered clear of vendor lock-in.”
SOA-based acceleration of application development
Speedier SOA-based application development can also contribute to a company’s financial well-being and competitive agility. “Applications that used to take two weeks to develop now take two days,” says Minard.
“We’re a fast-paced multi-channel transportation company that requires ever faster time to market for IT solutions,” says Maja Tibbling, application architect with Con-Way Transportation Services in Portland, OR. “To take advantage of new business opportunities, SOA allows for speedy delivery of new functionality as well as providing adaptability in existing functionality. This flexibility also permits us to meet the evolving demands of our customers.”
Faster development allows companies to respond more flexibly to new competitive challenges, stimulating top-line revenues. TSYS Prepaid Inc. is a hosted service provider that processes prepaid debit cards on behalf of financial institutions. Its SOA-based applications are the basis for revenue-producing services. “Accelerated development allows us to recognize revenue more quickly,” says Carl Ansley, the company’s CTO.
Difficulty of quantifying other SOA ROI metrics
SOA’s other benefits may be quantified to greater or lesser degrees. How can you put a valid number on improved business adaptability and agility? Or on improvements in application consistency due to reliance on a common set of shared services? Or on reductions in the risk to interoperability when you make changes to application code that’s been virtualized, abstracted, and loosely coupled in keeping with SOA principles? Or enhancements to application usability, scalability, and performance that come from reliance on shared services that have been built and optimized by development centers of competence within your organization?
One of the principal difficulties with quantifying SOA’s ROI in the real world is that the paradigm overlaps with so many other development, integration, and management approaches. SOA, to some degree, carries on many of the objectives and methods of component-based development, as attested by several case studies who were interviewed for these articles.
But SOA has, in industry discussions, been elevated from a mere approach to something resembling a religion. It is often portrayed as an all-pervading panacea, a golden force field that encompasses all good programming practices from Babbage to the present. If you look at almost any popular discussion of SOA, you’ll see it mentioned in the same breath as Web services, enterprise service bus (ESB), business process management (BPM), model-driven development (MDD), governance, and other hot topics. Indeed, every IT vendor with a savvy marketing group these days has hitched its entire product portfolio and roadmap on its alignment with SOA. So it’s hard to know what ROI to credit to SOA versus these other development and integration approaches.
SOA is still a fuzzy concept to many enterprise IT professionals, and it sprawls, in many people’s minds, across a wide range of loosely related technologies and approaches. According to a recent IDG Research Services Group survey, IT professionals are almost evenly split between people who claim some familiarity with SOA (52 percent) and those who admit they haven’t a clue (48 percent). Likewise, the split was almost even between those respondents who reported strong confidence in SOA’s long-term potential (55 percent) and those whose confidence in the paradigm was lacking or lackluster (45 percent).
IDG asked that same population of respondents to associate various phrases with SOA. The respondents ranked the most valid SOA descriptor—“reusable applications”—fifth among the options given. Respondents ranked such descriptors as “software as a service,” “enterprise application integration,” “Web services registries/repositories.” and “frequent use of Web services” higher, even though those phrases don’t directly articulate SOA’s core meaning.
As we can see, popular understanding of SOA concepts is fuzzy, to say the least. What’s even fuzzier is any reliable data on who exactly is implementing SOA, with what degree of commitment, and at what level in the organization. In that same IDG study, 28 percent of respondents stated that their companies are already implementing SOA, with slightly less than half of those SOA implementers merely conducting pilot projects. Of those respondents who are considering SOA but don’t currently have pilot projects, IDG found that only 22 percent are actively investigating SOA-based solutions over the coming year.
However, a recent Forrester Research survey of large North American companies reported that more than 70 percent of respondents have already implemented SOA. Forrester analysts say that by the end of 2005, 51 percent of medium-sized enterprises and 46 percent of small businesses will have adopted SOA as well.
The leading IT analyst firms present widely divergent pictures of SOA adoption rates in 2005. So, really, it’s anybody’s guess exactly how many organizations of various sizes have adopted SOA, or plan to do so over the coming several years. And there’s no telling how many of the people responding to these surveys are clear on precisely what they mean by SOA, or are using the term that’s consistent with how others are construing it. Or whether any of them is correctly using the term.
Enumerating the levels of SOA implementation
Another problem with such surveys is that they tend to use a binary definition of SOA adoption: either you’re implementing SOA or you’re not, with no gray territory between these two poles. This simplistic approach to gauging SOA adoption is at odds with the extremely complex, multifaceted nature of this methodology.
Anybody who’s spent any time studying the topic can quickly identify various steps, phases, layers, degrees, and approaches to implementing SOA. As the case studies in this article and the companion article, “SOA: The ABCs,” illustrate, there’s no single way to do SOA. By the same token, your ROI will depend considerably on the approach your organization has taken, and on how far you are along your SOA implementation roadmap.
One of the most critical elements of any enterprise SOA roadmap is the need to gain a solid commitment from senior IT and business managers, based on such business benefits as accelerated development, reduced cost, and greater business agility. Also, you should provide developers with the training, tools, guidelines, and incentives necessary to get them thinking in SOA terms, and to discourage development of one-off and non-modular applications. Your SOA roadmap would be incomplete without a thorough reorganization of IT governance processes aimed at enforcing organization-wide adherence to SOA best practices.
An enterprise SOA roadmap should incorporate the requisite philosophy, culture, practices, tools, and infrastructure. The more of these roadmap components you’ve established in your organization, the closer you are to realizing the full ROI on your commitment to SOA. Figure 5 represents the SOA roadmap components graphically.
Standard Life has implemented all of these SOA roadmap components. As we’ve noted earlier in this article, Standard Life has achieved considerable cost savings from its SOA and has embedded the paradigm deeply into its development culture and operations. Let’s look at their approach in greater detail.
As a manager responsible for application solutions at Standard Life, Derek Ireland sees his primary job as one of instilling the SOA philosophy among the firm’s development groups. “My team provides direction on the application of SOA to business problems. We help developers to identify when it is appropriate to reuse the application solutions we already have, identify when it is appropriate to use packaged solutions, identify when it is appropriate to develop new applications using our core technologies, and identify when it is appropriate to develop new applications using new technologies.”
As noted earlier, Standard Life has created an internal SOA culture that spans all development areas, identifying, exhibiting, and promoting best practices for delivering reusable business services. “Implementing SOA required a shift in our development culture. Our SOA virtual services team maintains that culture by disseminating SOA best practices across development groups.”
The company’s SOA practices continue to evolve. Standard Life defines various SOA “application design patterns” that apply to development and integration projects throughout the company. Programmers are encouraged to use these patterns as company standard practices on all projects. “An application design pattern is a set of architecture, design and implementation patterns,” he says. “Architecture patterns show concepts, such as the need for channel-independent application development. Design patterns give technology-independent design advice, such as when and how to implement reliable messaging in distributed services. And implementation patterns give technology-specific ‘how to’ advice, such as how to deliver a business service using J2EE Message-Driven Beans in IBM WebSphere.”
Standard Life’s developers use company-standard SOA tools to build these application design patterns. “We call this our runtime SOA software framework,” Ireland says. “It abstracts applications from lower-level implementation issues such as communication across tiers and logging. We have implemented our SOA software framework in IBM WebSphere Application Studio Developer for Java development, IBM IMS tools for COBOL development, and Microsoft Visual Studio .NET for C# development. The framework enables all inter-layer communication and run-time business service directory look-ups. Fundamentally, the framework enables development teams to concentrate on the business aspects of the application under development.”
As noted above, Standard Life’s SOA infrastructure includes a mixture of IBM and Microsoft platforms and middleware. The company has standardized on IBM WebSphere MQ Integrator as its principal message-oriented middleware (MOM) platform, Java as the principal programming language, and XML as the markup syntax for all interoperability interfaces. However, it has only a minimal SOAP implementation and hasn’t yet migrated to UDDI and other Web services standards. Their SOA service registry runs on IBM’s UDB database on AIX.
Layered SOA infrastructures
Enterprises committed to SOA will need to continue evolving their infrastructures to realize the ROI from service reuse. Where reuse is concerned, the principal layers of an SOA-enabling infrastructure are the service brokers, orchestration engines, message-oriented middleware environments, and service-level management tools. Many SOA case studies involve all or most of these service layers, implemented through a combination of Web services and other middleware protocols.
Brokering infrastructures encourage reuse by allowing developers to “advertise” their programs’ service interfaces in a shared online registry, repository, or catalog. Any entity that facilitates registration, discovery, and retrieval of service contracts may be regarded as a broker.
The UDDI standard defines a service-brokering environment for Web services. However, many companies have implemented service-brokering infrastructures on other platforms, such as DBMSs. As noted above, Standard Life’s non-UDDI-based SOA service registry runs on an IBM UDB DBMS. Standard Life first implemented its registry early in this decade, at a time when “UDDI was immature for a runtime registry,” says the company’s Derek Ireland, “and it didn’t contain some of the features we wanted for a runtime registry, such as quality of service attributes.”
Even when companies commit to UDDI, Web services aren’t the only type of service that companies want to register and manage in their registries. One of the next steps on Con-Way Transportation’s SOA roadmap is to “create a comprehensive repository of business component services for all types of services, including both Web services and other technology implementations,” says the company’s Maja Tibbling, “perhaps using WSDL and UDDI.”
Orchestration engines encourage reuse by allowing developers to build new services through workflow definitions that connect pre-existing services. Developers often use graphical process-definition tools that allow them to specify orchestration tasks, dependencies, and routing and processing steps with flowchart icons. This approach is also called “model-driven development” (MDD). Once defined, these visual process models may be compiled into reusable rule definitions that control the execution of multistep interaction flows, such as those that involve complex transformation and routing rules, across heterogeneous platforms.
“We are using TIBCO BusinessWorks to reliably orchestrate asynchronous business processes in near real-time,” says Con-Way Transportation’s Maja Tibbling. “TIBCO’s transformations are based on XML, Xpath, and XSLT. We can take a transaction from any source in any format within our very heterogeneous environment, transform the data into a canonical XML Schema, and then interact with the shared services.”
MOM environments encourage reuse by providing guaranteed-delivery, event-notification, and publish-and-subscribe protocols that bind heterogeneous application endpoints into an enterprise service bus.
Abebooks has deployed Sonic Software’s MOM products as the backplane for its SOA environment. “We deploy Sonic MQ everywhere in our intranet,” says Abebooks’ Jayson Minard. “Sonic MQ supports both asynchronous and synchronous calls between service endpoints and provides pub/sub, message queuing, and event notification services. At the edges of our intranet, we use Sonic ESB to wrap shared services with Web services interfaces so that they can be called by our external trading partners.”
Service-level management infrastructures encourage reuse by helping companies monitor, optimize, control, and integrate their distributed application environments. A more common term for this functionality is Web services management (WSM) tools. WSM infrastructures help companies ensure the performance, reliability, availability, operational management, lifecycle management, and security of end-to-end Web services within an SOA environment. However, a growing range of WSM tools also monitor and enforce service levels in environments that implement MOM and other middleware protocols, which is why the broader term “service-level management” is more appropriate than the middleware-specific term “WSM.”
Thomson Learning uses Actional’s SOAPstation WSM proxies to control XML-based interactions within their SOA environment, according to company VP Chris Crowhurst. “We chose XML as the basis for service abstraction in our SOA, but haven’t tied XML interfaces to Web services protocols. Much of our SOA involves interchange of XML via HTTP or file transfers, not Web services. Every SOA consumer or provider service interoperates through Actional SOAPstation proxies that sit in the middle to do performance analysis and content-aware routing among distributed services.”
Enterprises can implement SOA without service-level management, but they would be foolish to do so for long. As SOA succeeds, companies will need to ensure 24x7 availability, guaranteed delivery, and performance optimization across the service bus, spanning all service endpoints. But, just as important, your company will need to maintain an IT culture that encourages maximum service reuse, through a full slate of SOA-focused training, incentives, tools, and practices.
Without a doubt, realizing SOA’s full ROI will be impossible without the appropriate technical infrastructure and organizational commitment, operating hand in hand.
