img > Issue XI: October 2007 > Beyond IT: Exploring the Business Value of SOA
Richard Tews

Richard Tews


Richard Tews is a freelance writer, expert in SOA, and a well-known Agile ScrumMaster.

He is the Director of Technology Services at Asynchrony Solutions, a leading systems integration firm based in St. Louis.

He can be reached at:


rss  subscribe to this author


Beyond IT: Exploring the Business Value of SOA

Published: October 5th, 2007 • SOA Magazine Issue XI

Abstract: SOA has been a prominent topic of discussion in the IT world for years now. But what has raised eyebrows is how hot of a buzzword it has also become in the business communities. As most already know, SOA promises service-orientation, a new paradigm that will make adding new functionality to software as simple as connecting Lego® building blocks... relatively speaking of course. The increased levels of agility now in reach with SOA will clearly affect the way organizations conduct business. The key is in understanding how SOA actually contributes business value.


As with any IT trend caught in the hype cycle, there is often more flash than substance. Ask 50 people to define SOA and you will likely get 50 or more different answers, some even contradictory. Even its pronunciation is up in the air. Some people vocalize its initials: "S," "O," "A". Others take the phonetic approach and say "soh-uh."

SOA's enigmatic identity is due to two primary factors:

  1. SOA burst into the public eye as a visionary concept, rather than an implemented technology.
  2. Even the experts' understanding of SOA is still evolving. Leaders in the field are working to transform the concepts of SOA into working systems in a variety of ways. Like the old wise tale of the blind men and the elephant, it is easy to be convinced that an isolated view of SOA is the whole picture.

Separating the Sizzle from the Steak

Given the relative immaturity of the associated technology, how can organizations make good decisions about investing in SOA-related initiatives? If companies move too fast in the wrong direction they risk wasting great amounts of resources on speculative initiatives that never deliver business value. If they take a too-conservative approach they risk losing their competitive advantage to organizations that figure out how to take advantage of SOA's potential to turbo-charge agility and efficiency.

A good first step to gaining a clear and useful understanding of SOA is to set aside the exciting grand vision for a moment and start with its essential core:

SOA is an approach to delivering software capabilities
through building blocks of processes called "services."

Traditionally, software applications are created as self-sufficient islands. Every capability is hard coded and tightly integrated. The benefit of this approach is that when done well, the software is fast, efficient and conforms closely to design specifications.

The problem with the traditional approach is that changes are usually complex, time-consuming and costly. Software capabilities are often so interconnected that even a small change can ripple across the code and necessitate major rework.

SOA takes a different approach. Instead of tightly integrated application code, it builds applications through loosely-coupled modules, called "services." Each service presents a self-describing interface that application developers or system integrators can access, regardless of what programming language is used and without any need to view or understand the services' underlying code.

The most effective way to cut through the hype surrounding SOA is to consider it in the context of clear and specific cases where generalities are replaced with specific business goals.

Business Goals

SOA, approached as a business strategy process, leads to the achievement of broad and significant goals; including quicker time to market with innovative offerings, reduced integration costs associated with mergers, and greater productivity throughout the enterprise. SOA enables access, which leads to the use and distribution of information becoming more agile and receptive to changing market demands.

A study by Lorraine Cosgrove Ware [REF-1] reported that agility was specifically part of their company's core business strategy for 85 percent of the (Chief Information Officer) CIO 100 winners. The motivations for pursuing agility included:

  • increasing growth and revenue opportunities
  • reducing response times to market forces
  • reducing costs

The process of SOA provides an approach guided by agreement on standards and interoperability; the ability to blend and deliver information from a broad array of existing applications, data sources and infrastructure. This approach and process can affect the value and the long-term viability of an enterprise.

Paradigm Shift

Service-orientation is a significant paradigm shift in distributed application design. In the old paradigm, IT invested in new complex applications to address business requirements. It was usually necessary to align business processes with new applications. The service-orientation paradigm advocates building functionality from services that align with functional processes (many of which exist within current IT systems).

When I think of service-orientation, I'm reminded of my son's Lego® building blocks. Rather than buying a one-piece molded plastic helicopter (that would be the old paradigm of buying a complex computer application) he assembles blocks into the helicopter of his design. Many of the same blocks could also be used to build a car, a robot, or anything else imagined - and rapidly.

Technology investment focuses on enhancing the mission and business objectives by rapidly delivering functionality to address mission-driven goals. With an SOA it is no longer a game of chance, gambling on an IT investment in enterprise-class applications to address current or anticipated needs. Service-orientation promotes agility to rapidly respond to the dynamics of the business. This activity, aimed at achieving measurable results, drives the assembly of "services" to create a functional application riding on a supporting infrastructure.

Figure 1: A blocks of a Lego helicopter can be disassembled and used to build other things. Similarly, most services are agnostic to any one purpose, meaning that regardless of what they are initially used for, they can be continually repurposed for new things.


SOA touches information everywhere within an organization so the importance of managing the exchange cannot be overlooked. SOA governance is essential to managing many levels of SOA decisions. Those decisions are made in business, architecture, technology, standards, and services. Governance and policy models are essential. It is critical to decide early on who owns the SOA efforts to ensure success and adaptation for the benefit of the enterprise.

This is always an area of significant challenge because governance is about people, not technology. Sir Francis Bacon once said, "Knowledge is power." The owners of silos of data have long lived by that creed. With SOA comes the technology and the governance processes to break down the barriers to sharing data. Governance policies within SOA build rules and controls around access and availability of data.

While SOA technology simplifies and automates data sharing, imagine the chaos if all information were simply available to anyone, anytime, and anywhere. SOA addresses the issues of access to data through systems controlled policies and security measures. Roles, security, authorization, validation, and conformance testing are integral to the process, as are people. Agreements between departments and enterprises are made and documented in contracts or Memos of Understanding (MOU). Intense security practices and mechanisms are part of a SOA plan. The SOA process enforces practices enabling the security of data across services, when properly planned and executed.

A governance model will determine:

  • What is to be governed? (and why?)
  • Structure and processes for SOA oversight
  • Processes: roles, responsibilities and procedures for managing SOA activities
  • Policies: enforcement issues including standards, security, release, reuse
  • Access Control
  • Service Level Agreement (SLA)
  • Service Promotion to Operations
  • XSD and WSDL Validity
  • Metrics: business outcomes with specific metrics for success
  • Behavior: behavioral model, incentives, penalties and rewards for appropriate "SOA Behavior"


A requirement to successful SOA is the availability of services. That might be self-evident given the name, but the question remains: where do the services originate?

Services can be:

  • provided within enterprise applications
  • interfaces to legacy applications
  • new development
  • from external providers in private industry and in government

SOA is an organizationally introspective process. Every business has unique goals. Those goals are the place to start. Business plans document and provide guidance in mission, objectives, strategy and tactics. Within those planning areas are processes. It is critical to align the SOA strategy to the organizational strategy. Managers of the company must understand, support and drive the SOA initiative. SOA should be reflected in and reflect the business plan. SOA must also be definable in language different than that used only by IT professionals.

From this perspective, SOA is more about business and process than about IT. The technology inherent to the architecture exists purely to support, protect and add value to the business. The reach is across all departments with the potential to provide value to new users with new solutions driven by new opportunities.

  • New Users - Reach knowledge workers and management processes
  • New Solutions - Combine transactions, analytics, and collaboration
  • New Opportunities - Integrate with engineering and embedded systems

SOA Applied

The following scenario depicts a service-oriented solution in a simplified manner. An organization may want a statement generating application that cross-references personalized interests with offers from advertisers. The services assembled could include "Get Transactions," "Compare Interests," and "Advertisements."

In this scenario, the company can generate highly-focused and relevant offers to potential buyers who demonstrate a pattern of buying products like that of the advertiser. This brings value to both the targeted buyer and the advertiser. It does not require the "sharing" of personal information; preserving both personal privacy and asset value.

Figure 2: The different services of a statement generating application, represented as Lego blocks.

The primary business goal is increasing revenue. An objective is defined as creating a new advertising revenue stream of $X for fiscal year 20xx. The strategy is to leverage information from the client database to develop a new advertising service delivered with each statement. And the tactic may be defined as: "develop advertising capability linked to statement production by matching advertising offers to clients where clients show repetitive buying patterns from companies matching the SIC code to the advertising campaign target audience."

A world of services from private industry and government is expanding. Organizations are no longer bound to the limitations of existing systems. The business-centric emphasis of service-orientation is improving business results. Thoughtful approaches to employing the architecture lead to greater productivity wherever employed in the enterprise. Conversely, poorly conceived approaches simply consume resources.

How to Begin

The best way to start is to plan a pilot project that will create a success story and visibility for the initiative. The process of SOA itself begins with business process modeling followed by a plan that includes governance (planning and process modeling help management determine priority). Selecting an initiative that will demonstrate the viability and value of the initiative is critical. As in any investment, the ability to show returns keeps enthusiasm levels high.

Below are a few further suggestions to take into consideration:

  • Start By Examining Business Or Agency Processes
  • Must Have Buy-In From Management And User Community
  • Don't Focus On SOA Products without a Strategy
  • Think Big, Start Smart, Scale Fast

SOA is an organizational and cultural approach to achieving results defined in the goals, objectives, and tactics. It is important to accept that SOA is a process that evolves over time. By starting with well-understood business processes one can create a list of potential pilot projects. The service-oriented ecosystem in every organization evolves over time, as do the standards and products supporting this environment. Through a pilot project many of the required skills can be attained and refined. With the support of management and other stakeholders the business objectives will be achieved and the implication of this process is that SOA is not simply an IT-based venture.

IT initiatives, budgets and skills should match the business objectives and the architectural requirements. SOA is not a one-time product or service line item. In fact, all possible elements of an enterprise SOA are not required to conduct a pilot project. Many products and product families now exist to help an organization build the technical piece of an SOA. It seems every product marketer now touts SOA features. This is a giant leap forward when "services" were part of closed and proprietary business solutions.

To many people getting through the noise of SOA advertising is one of the greatest challenges. Good product and tool choices exist for speeding SOA implementation, and these can save time and allow for a faster path to delivery. Additionally, bundled solutions are available to incorporate essential elements like publishing and discovery of services, messaging, compliance to policies, and security. Others provide rapid development of data-layer services and still others provide governance and modeling automation and mechanisms. The product landscape is rapidly evolving and changing as technology providers are "rolled-up."

Before jumping into the product selection process I advocate developing a SOA vision for the organization and aligning the alternatives with the ultimate objectives over time. Develop the vision, then the plan, and then execute a couple of pilot projects. The learning that happens by doing so will have an impact on the potential choice of tools and products chosen to support the architecture and speed the delivery process.


The definition of service-oriented architecture is as fluid and dynamic as its purposes. Service-orientation is a process and a path to achieving diverse business goals. It is based on standards developed and implemented by governing bodies fostering a commonality across domains. A well-designed SOA strategy will lead to achievement of financially-based, process-based, and market-driven goals. Service-orientation adds value to the enterprise. In an era where productivity improvements, positive demonstrable financial results, and the ability to rapidly adapt to changes are expected and assumed, a solid IT foundation built on a service-oriented architecture creates a truly competitive advantage.


[REF-1] "The Benefits of Agile IT", Lorraine Cosgrove Ware, CIO Magazine, August 03 2004 (