img > Issue LIII: August 2011 > Understanding Service-Orientation - Part I: Business Goals
Raj Balasubramanian

Raj Balasubramanian


Raj Balasubramanian is an Enterprise IT Architect for IBM Software Group, delivering customer engagements around projects related to SOA, BPM and Web 2.0. Raj is the co-author of the upcoming "SOA with Java" book for the Prentice Hall Service-Oriented Computing Series for which he contributed chapters relating to portal technology and REST service design and development.

Raj has further developed a series of REST-inspired design patterns that have been contributed as candidates for the SOA Design Pattern Catalog. In addition he speaks at various industry conferences on a regular basis on the topics of SOA, Semantic Web and Web 2.0.

He just completed his Masters in Software Engineering from University of Texas at Austin and is starting his PhD.


rss  subscribe to this author

Benjamin Carlyle

Benjamin Carlyle


Benjamin has been involved with the REST community through his blog and other forums since 2004. He is credited with inspiring the popular Restlet framework for Java, he coined the term "REST Triangle", and has deep understanding of both the theory and practice of REST-style architecture.

As an architect working in the Rail industry he is experienced in bringing together REST architecture, systems architecture, systems integration, and a variety of other topics at an enterprise scale. Benjamin has recently been working with the likes of Thomas Erl on documenting the convergence between SOA and REST.


rss  subscribe to this author

Cesare Pautasso

Cesare Pautasso


Cesare Pautasso is assistant professor in the new Faculty of Informatics at the University of Lugano, Switzerland. Previously he was a researcher at the IBM Zurich Research Lab and a senior researcher at ETH Zurich. His research focuses on building experimental systems to explore the intersection of model-driven software composition techniques, business process modeling languages, and autonomic/Grid computing.

Recently he has developed an interest in Web 2.0 Mashups and Architectural Decision Modeling. He is the lead architect of JOpera, a powerful rapid service composition tool for Eclipse. His teaching and training activities both in academia and in industry cover advanced topics related to Web Development, Middleware, Service Oriented Architectures and emerging Web services technologies.

For more information, visit


rss  subscribe to this author


Understanding Service-Orientation – Part I: Business Goals

Published: Aug 11, 2011 • Service Technology Magazine Issue LIII PDF


Service-orientation is an approach to distributed computing that encompasses its own design paradigm, design principles, design pattern languages, and related technologies, concepts, and frameworks. Service-orientation builds upon past distributed computing approaches and adds new design principles, problem solving approaches, and governance challenges. This three-part article series builds upon the original SOA Principles of Service Design book [REF-1] to explore service-orientation goals, principles, and its relationship to service-oriented architecture (SOA).

History and Motivation for Service-Orientation

Information technology infrastructure is a key asset for modern businesses. Business increasingly depends on this infrastructure to remain agile in the face of rapidly changing business environments.

The traditional approach to delivering information technology solutions has been to identify the business tasks to be automated, define their business requirements, and then build the corresponding solution logic based on available technology foundations. If the business needs a new process automated, an application is built from scratch to automate that process. This is an accepted and proven approach providing a relatively predictable return on investment, but has its drawbacks as well as advantages.

Solutions built on this classical approach can be seen as “disposable applications”. They can be quickly engineered with a narrow requirements focus to achieve a particular business objective. When processes or business needs change, a new application is developed.

This approach holds up well below a particular threshold of application size and complexity. Once applications get too big, disposal becomes less viable and building a new application too expensive to contemplate. The performance of an IT department weighed down with maintaining large numbers of independent applications can slow to a crawl, and the costs of maintaining these applications can grow rapidly without offering significant new business returns.

As individual applications build their own momentum they can become silos for information and functionality that lead themselves to additional cost and complexity. Point-to-point integration activities are performed in order to access information in a given silo for use in other applications. These integration points must also be maintained and can become more and more brittle over their lifetime.

The Goals of Service-Orientation

The approach of service-orientation is to break down the monolithic application by introducing a layer of services to the architecture that encapsulates reusable functionality. A service-oriented application incorporates a set of reusable services composed together in an application-specific configuration. The application still includes disposable application-specific logic, but such logic is explicitly extracted and separated from the reusable portion of the application.

Service-orientation builds an inventory of services that provide straightforward access to reusable logic and information to any application that requires it. It seeks to break down the application silos, aims to reduce momentum associated with any particular application, aims to improve the performance of IT in delivering applications, and ultimately to improve the overall performance of the business through reduced costs and time to market for business products and services. It also seeks to reduce waste and minimize complexity.

The goals of service-orientation are ambitious and business-focused. An organization that adopts an approach based on service-orientation seeks to break away from an inventory of silo applications into a more fine-grained services model. Both services themselves and the information they collect and encapsulate can be reused from application to application, resulting in more efficient and manageable IT infrastructure. The specific goals of service-orientation include:

  • increased intrinsic interoperability
  • increased federation
  • increased vendor diversity options
  • increased business and technology domain alignment
  • increased return on investment
  • increased organizational agility
  • reduced IT burden

The following sections describe each goal from a SOA perspective.

Increased Intrinsic Interoperability

Interoperability refers to the ability to transfer information and access common functions between applications. This can be understood in terms of a number of stages of reducing cost of integration along the way to a high level of intrinsic interoperability.

  1. breaking down application silos into reusable services
  2. breaking down technology barriers to integrating services into applications
  3. breaking down semantic barriers to interoperability

The breaking down of application silos has already been discussed in this article. The implementation of applications is separated into application-specific and reusable elements, and these reusable elements are realized as services (Figure 1).

A breaking down of technology barriers can come about in a couple of alternative forms. The first is to standardize services and applications to use a common technology foundation. Services and applications built upon the same technology platform can often be connected at a low cost, however this approach can introduce vendor lock-in and conflict with the later goal of increased vendor diversity options. A second form is to focus on the technology foundations of the technical contract exposed by services. If this contract is based on a common technology that is already integrated with a number of implementation technologies, the cost of integration will be low.

The final step of breaking down semantic barriers can be taken to different levels depending on the particular objectives of a service inventory. Often this includes the application of the Canonical Schema and related patterns that ensure that different services use the same data model and format whenever they exchange the same kind of information. This can only happen if multiple groups within the organization work to produce common schemas or models for important information. This reduces the need for transformation of one data type to another, reducing the complexity of the integration and increasing the end-to-end integrity of the information.

Interoperability is fostered through the consistent application of design principles and design standards. This establishes an environment wherein services produced by different projects at different times can be repeatedly and easily assembled together into a variety of compositions to support business applications.

Figure 1 – Services are easy to incorporate into new applications

Increased Federation

Federation is the breaking down of technical and organizational boundaries within an enterprise that prevent information and functionality from being effectively shared and reused. Federation can be seen as a means to achieve consistency and standardization through the application of universal governance and has the objective of reducing redundancy and waste within an application and service inventory. To do so, federation consolidates the effort of delivering and improves business capability through better business intelligence. It also gives the ability to leverage common functions into reusable service logic (Figure 2).

Instead of inventing and reinventing the wheel in each application the reusable logic is encapsulated into a service which itself is placed under in a well-established group within the IT organization. These services, and the information they hold, are able to be used across the enterprise with reduced dependence on information silos that would otherwise prevent the free exchange of information. The information technology group is able to take advantage of economies of scale to reduce waste in supplying functions in only one place and supplying them to a high standard.

Increasing federation requires:

  • understanding and cataloging the functions of individual applications and services
  • employing a coherent design strategy to eliminate duplicate implementation
  • funding and supporting implementations of functions as services throughout their lifecycle and ongoing evolution
  • overcoming technical, organizational, administrative, and trust silos within the enterprise

Increased federation reduces redundant service logic, redundant storage of information, overall complexity, cost, and increases business capability. A federated IT environment makes information and functionality easily accessible at well-defined service endpoints, and does not include significant fragmentation or duplication of logic. Providing and cataloging a robust and relevant set of functionally-coherent services makes it easy to incorporate them into new applications while simultaneously reducing development and maintenance overhead. Required functional changes can be made in a single service and automatically flow through to applications that incorporate them with reduced need for expensive redeployments and coordination of changes.

Figure 2 – Common functionality is reused, not reinvented making relevant information available across the enterprise

Increased Vendor Diversification Options

Minimizing the set of implementation technologies in use can reduce maintenance overhead, and is a goal of many architectures. However, vendor lock-in is an undesirable architectural property that service-orientation seeks to avoid. Vendor lock-in couples an architecture to a specific technology platform provided by a single vendor or boutique set of technology providers. Once the vendor no longer supports the platform, or if the vendor goes out of business, the whole architecture depending on the vendor’s technology could become obsolete. The costs of switching an architecture between different vendors may be very high if the architecture suffers from vendor lock-in. Vendor lock-in can be reduced by:

  • selecting interoperability standards that allow services and their consumers to be developed based on different implementation technologies
  • selecting interoperability standards that allow the implementation technology underlying a given service to be changed without affecting the technical interface of the service
  • selecting mature interoperability standards that will be supported by multiple vendors into the future
  • ensuring the portability across multiple vendor-specific platforms of any artifacts that are developed
  • ensuring that parts or all of the platforms in use are supported or are able to be supported by diverse vendor organizations

Maintaining and increasing vendor diversification options through the use of standards that are agnostic to implementation technology allows an organization to pick and choose “best-of-breed” vendor products and use them together within one enterprise (Figure 3). It is not necessary to have a vendor-diverse environment, and many technology decisions will ultimately be based on whole-of-enterprise maintenance overhead considerations. However, it is beneficial to have the option to diversify or switch technologies when required. Designing vendor-neutral architectures allows businesses to absorb heterogeneous technology landscapes inherited from a history of mergers and acquisitions with a view to maintaining the enterprise over long periods of time.

Designing a service-oriented architecture in alignment with neutral to major vendor SOA platforms can avoid incorporating specific technology dependencies into service contracts. Individual services can be upgraded, and new services can be developed to incorporate alternative technology platforms without breaking compatibility with existing consumer applications.

Figure 3 – Services use vendor technologies that can be interchanged, one for another and still interoperate

Increased Business and Technology Domain Alignment

Modern enterprises include organizational structures and processes designed to meet business goals. IT infrastructure is better able to keep pace with changes to the business as they occur when it accurately models processes and designs services that reflect business processes and vocabulary (Figure 4).

Alignment can be increased by:

  • involving both business and technology experts in service analysis processes
  • describing services in terms that are meaningful to business specialists
  • building services that are aligned to specific business concepts

This concept seeks to find ways that business and information technology specialists can work most effectively together and develop a common language for framing business problems and solutions

Figure 4 – Services architecture mirrors business architecture and vocabulary

Increased ROI

A business does not need to invest in IT for technology’s own sake. Every IT investment decision is a business investment decision and must compete for investment capital with alternative investments the business may choose to make. The objective of increased ROI is to ensure that IT investments are as profitable and productive as possible.

Service-orientation seeks to increase return on investment in the following ways:

  • repeatedly reusing the same services in different applications, amortizing the cost of service development over multiple business applications
  • containing initial investment outlay by making clear and explicit decisions about which logic is application-specific, and which is genuinely valuable as reusable service logic; communicating these decisions clearly to developers can reduce excess development effort known as “gold plating”

Improving ROI requires that the total lifecycle cost of business logic is significantly less than the value generated by investing in the development of that logic. Service-orientation encourages reuse of logic across multiple applications (Figure 5). The value of the logic is multiplied across the different applications while the cost increases by only a small amount compared to logic that cannot be reused. Service-orientation advocates the identification and encapsulation of reusable solution logic into services that are agnostic to the application they are initially designed to support. This logic fully leverages the intrinsic interoperability built into services to maximize actual reuse through assembly into multiple service compositions.

It is important to acknowledge that this goal is not simply tied to the benefits traditionally associated with software reuse. Proven commercial product design techniques are incorporated and blended with existing enterprise application delivery approaches to form the basis of a distinct set of service-oriented analysis and design processes.

Figure 5 – Investment returns accumulate when a service is reused, while cost remains low and can be amortized

Increased Organizational Agility

Increased organizational agility is a goal directed at modern times. Gone are the days when an IT infrastructure could be built primarily around large unchanging systems whose cost is amortized over a decade or more. While these systems will continue to exist in some areas, IT is now predominantly required to respond to business changes in lock step with other organizational efforts to adapt to changing business conditions. The bottleneck of traditional IT has seen agile development methods gain in popularity as they provide a means of rapidly addressing immediate, tactical concerns.

Service-orientation separates the concerns of developing reusable and disposable software. When applied throughout an enterprise this results in the creation of services that are highly standardized and reusable. Services that are specific to a parent business process application are decoupled from those that are agnostic to parent processes and to specific application environments. As a service inventory grows to be comprised of more of these agnostic services, an increasing proportion of its overall solution logic belongs to not one application. Instead, because these services have been positioned as reusable IT assets they can be repeatedly composed into different configurations. The time and effort required to automate new or changed business processes is correspondingly reduced when compared to developing a new application from scratch. A high level of agility is fostered under service-orientation in the following two ways:

  • An inventory of existing services is developed that can be quickly incorporated and assembled into a new application composition.
  • Existing services are themselves well aligned to business needs and flexible when requirements change.

Service-orientation is intended to produce a fundamental shift in project delivery over time to heighten responsiveness and reduce time to market.

Easy to Change - An integration appliance allows IT to change connectivity, revise transformations and modify workflows using point-and-click functions in a visual user interface. Easy changes enable integrations to better serve the evolving needs of the business.

Reduced IT Burden

The objective of an increased ROI is to focus on the cost of developing a new application and the opportunity for amortizing cost over multiple new investments. Reduced IT burden looks at the other side of the cost equation - the cost of keeping the lights on.

Traditional, silo-based applications tend to suffer scope increases over time, resulting in potentially complex environments with costly maintenance requirements. Ever-growing non-federated integration architectures can themselves lead to increasing demands on an organization's operational budget. Every deployed silo application requires its own maintenance activities and associated ongoing cost burden. Service-orientation seeks to combat this trend by producing normalized service inventory where every function is implemented only once, and service logic is not duplicated.

This reduced redundancy has direct ramifications on the bottom line. Applications and services that are no longer required can be eliminated. Redundant functions and logic can be refactored out of the inventory to reduce the cost of maintenance.

For example, a CEO of a major airline can compare the IT performance of its established full service airline business and its low-cost business. The established full-service carrier spends 3.5% of business revenue on IT, while the newer low-cost carrier spends less than 1%. He reports that the low-cost carrier had better IT systems because they had been designed for a new start up carrier. A cost difference of 2.5% of revenue due solely to IT expenditure could make or break a business in any competitive industry. Therefore, getting the balance right between performance, agility, and cost is at the core of the paradigm of service-orientation.

Consistently applying service-orientation is intended to result in an IT enterprise with reduced waste and redundancy, reduced size and operational cost, and reduced overhead associated with its governance and evolution. Such an enterprise can benefit an organization through increases in efficiency and cost-effectiveness. Service-orientation is intended to produce a leaner, more agile IT department that is less of a burden on the organization and more of an enabling contributor to its strategic goals.


This is the first part of a three-part article series dedicated to service-orientation. The second article will focus on the service-orientation principles and how each relates to the goals covered in this article.


[REF-1] "SOA Principles of Service Design", Thomas Erl, Prentice Hall/PearsonPTR,