Key Concepts of Service-Oriented Architecture 

by Dirk Slama and Robert Paluch

Service-oriented architecture is currently one of the most heatedly debated IT concepts, promising to address many of the age-old problems of large, heterogeneous legacy systems of large enterprises. However, there are many different opinions about what SOA actually is, and how it can be implemented in an IT organization. This article provides a definition of the key concepts of SOA, and a set of best practices developed by CSC for the adoption of SOA in the enterprise organization.

SOA ¹ Web Services

For many decades now, enterprise IT organizations have attempted to improve agility and efficiency by homogenizing their systems through the introduction of enterprisewide IT standards — most of the time with very limited success.

In the 1980s, with relational database systems becoming mainstream, we saw a wave of so-called Enterprise Data Model projects (EDMs). The idea of these standardization projects was to define one global data model for all the business entities in an enterprise, which was to be shared amongst all the different organizations and systems in a company. Almost all of these EDM projects failed. Today, there are usually as many different database schemas out there as there are databases in an enterprise. There are a variety of different reasons for the failure of these EDM projects: turf wars between different departments; conflicts among stakeholders, such as business representatives, application specialists, and DBMS administrators; the sheer technical complexity of the undertaking; and the fact that due to the dynamics and complexity of modern enterprises it is usually impossible to capture a snapshot of the complete state of the enterprise at a given point in time.

In the 1990s, we saw the next attempt to homogenize the enterprise application landscape, this time via enterprisewide middleware standards. The concept of the Enterprise Software Bus became popular. The idea was that by agreeing on a ubiquitous, technology-independent, enterprisewide standard for communication between software modules, the problem of application integration would be solved once and forever. However, the reality in almost all enterprises today is that in addition to application heterogeneity we are also facing the problem of middleware heterogeneity. In many cases, middleware such as CORBA was only used to solve point-to-point integration problems on a per-project basis. It wasn’t established as a global software bus, and as a result many enterprises now have nearly as many incompatible middleware systems as they have applications.

In general, it seems fair to say that enterprise standardization efforts in IT have failed to deliver on their promise of homogenization and easy application integration. Too many generations of middleware, such as DCE, CORBA, SOAP, and WSDL, have been touted as silver bullets, but failed to become established as the ubiquitous Enterprise Software Bus. The result has been a high level of cynicism amongst the people involved.

So you might now be asking yourself: “what is different this time?” Isn’t SOA yet another enterprisewide standardization effort, this time under the label of the Enterprise Service Bus? How are SOAP and WSDL – while maybe technically superior and more flexible – going to address the organizational challenges of global standards that made the Enterprise Data Model, the Enterprise Software Bus, and many other enterprise standardization efforts fail to large extends?

SOA is neither a technology nor a technology standard, but instead represents a technology-independent, high-level concept which provides architectural blueprints. These architectural blueprints focus on the slicing, dicing, and composition of the enterprise application layer in a way that allows the creation of components that are not only technically independent, but also have a direct relationship to business functionality. They allow for the structuring of application components on the local level, while also promoting the global integration of these components. An SOA does not rely on the support of particular runtime protocols, such as SOAP or IIOP.

Therefore, an SOA does not impose adherence to technical standards on the global level, and is not based on strict norms and specifications.

Applications that are structured according to the guiding SOA principles will be able to fit into any integration scenario, regardless of the runtime protocols required. Having said this, there will still be work required to bridge technology gaps, such as different communication protocols, but the efforts required to bridge these gaps will be marginal when compared to the complexity of integrating applications on the structural level.

Key Concepts of Service Oriented Architecture:

• SOA means accepting the heterogeneity of platforms and middleware, as well as the fact that things change - constantly.
• SOA is about a fundamental transformation of the enterprise IT landscape into loosely coupled building blocks.
• SOA means focusing on the structure of these building blocks.
• The building blocks (services) of an SOA have a clearly articulated value to the business.
• SOA allows for integration of services in real time, eliminating many of the problems resulting from batch architectures.
• SOA supports a clean layering on the architecture level.
• Interface standardization in an SOA is important but secondary, because adding interfaces (new functionality or additional access protocols) to a well designed SOA building block is affordable.

SOA & IT/Business Alignment

SOA is a very powerful tool for helping to align IT and business functions. By leveraging IT/business alignment frameworks, such as CSC Fusion, one can create a transparent mapping of business strategy and objectives down to the supporting IT systems. This mapping provides a clear trace of the high-level objectives to the supporting business processes, down to individual process steps, which in turn are supported by different SOA services.

Because this approach provides a very high level of transparency, it provides an invaluable governance tool for the development of a process-oriented SOA with a high level of reuse.

Leveraging SOA on the portfolio management level is very powerful, because it allows for control of the development of SOA services across multiple projects. Such control is a key requirement if an enterprise aims to achieve reuse and synergies between different projects, which would be carried out in isolation under traditional portfolio management.

SOA governance and portfolio management should also be combined with balanced scorecards to control and prioritize the investment in individual SOA services. BSC provides a good basis for deriving the key IT priorities.

Efficient SOA governance requires the creation and constant maintenance of a global process map and service repository, including lifecycle information and a general development roadmap. The process map and service repository can be used to coordinate the evolution of the SOA across the individual projects. An initial version of this information can be created, for example, by applying CSC’s Application Performance Effectiveness Review (APER) methodology.

Once the SOA governance framework is established, CIOs have a very powerful tool for controlling the future evolution of the IT landscape, and will be able to provide faster and more cost-efficient support for all critical business processes.