Enterprise Architecture and SOA: Two Tribes

By Chris Harding

(Back to article)

Service-Oriented Architecture (SOA) is becoming the architectural style of choice in many enterprises. It has seen explosive growth over the last year. But some enterprise architects are still doubtful about it, and there is much confusion.

Is SOA part of enterprise architecture, or is it something separate? Is it really new, or is it just a rehash of old ideas? Does it require a radically different approach, or are the tried and trusted methods still valid?

Part of the problem is that SOA devotees and traditional enterprise architects tend to form different communities, and do not talk to each other as much as they should. David Linthicum, the well-known SOA expert and blogger, speaking at the recent Open Group conference in Austin, Texas, referred to them as “different tribes”, which do not understand each other. This is an interesting and perceptive comment. But misunderstandings can also occur within families particularly between different generations and this may be a better metaphor for the differences between architects that do and don’t use SOA.

The Two Tribes

Traditional enterprise architects see themselves as professionals. They take responsibility for delivering solutions that meet the clients’ needs and that also meet accepted professional standards. Because of this, they are wary of things that are new and untried. They follow existing best practice, because they know it works, in the same way as a surgeon follows standard procedure when performing an operation. It might be interesting to experiment with new techniques, but this would not be fair to the client.

So, does this mean that the SOA devotees are unprofessional and irresponsible? Not at all! SOA has generally been introduced carefully, starting with small pilot projects, or with architectures that use the principle of loosely-coupled services within a traditional infrastructure and omit the more advanced SOA features such as service discovery. More mature examples of the SOA style have followed from the success of these early projects.

SOA devotees are not different in kind from traditional enterprise architects. They have the same professional approach to delivering solutions. They just believe in a new technical approach.

SOA Is Different

How different is this new approach? What distinguishes SOA from traditional approaches to enterprise architecture?

The principle of service orientation can apply throughout the enterprise architecture, but is usually applied to the organization of the software that supports the enterprise's business operations. With SOA, this software is organised as a set of loosely-coupled software services. The services are supported by an infrastructure that, together with the services, enables information to flow freely within the enterprise and between the enterprise and external organizations.

The software services are used by the enterprise’s business operations. This most frequently involves a human-computer interface, often implemented as a Web interface using portals, but it may also involve other interfaces such as machine interfaces for process control.

Note that the business operations themselves may be organized on the service-oriented principle. Indeed, there are many people who believe that the greatest benefits of SOA are obtained when it is applied to the business architecture. But this is not essential to a service-oriented software architecture.

The infrastructure provides the execution environment for the software services. This includes the basic operating system and networking, and also includes specific support for software services, such as message passing and service discovery. It is used via human-computer interfaces by technical operations staff who are responsible for all aspects of managing the enterprise’s information technology, including its availability, performance, and security.A major benefit of SOA is it delivers enterprise agility, by enabling rapid development and modification of the software services. The infrastructure can support this by including facilities such as business-oriented scripting languages and model-driven implementation tools. These facilities support not only the creation of new software services, but also the modification and replacement of existing ones; in fact the whole service lifecycle. They are used via human-computer interfaces by development staff.

Again, the service-oriented principle may extend to the design of the infrastructure, and many people advocate this, but it is not essential to a service-oriented software architecture.

The infrastructure also provides for storage of enterprise information. SOA enables the free flow of information within and between enterprises. This does however bring to the forefront the need for semantic interoperability; that is, for different services to be able to interpret the same information in the same way.

The key differences between SOA and other architectural styles are that:

The modules are loosely-coupled services that can be combined dynamically, as opposed to subroutines, scripts, or other forms of program that invoke each other directly.

There is more emphasis on infrastructure support for service development and evolution. The enterprise architect has always been concerned with principles and guidelines governing the evolution of the architecture components over time. With SOA, this extends to the specification of particular development tools and methods, and their incorporation in the infrastructure to provide software service lifecycle support.

The ability to develop and modify services rapidly, the need to ensure that they support the business operations as effectively as possible, and the desire to encourage their re-use by different parts of the enterprise impacts on governance: the process by which the translation of the architect’s specifications into implemented systems, and the continuing evolution of those systems, is controlled.

Information is not locked up in specific services, as it often is in the so-called "silo" applications of earlier architecture styles, but is available when and where needed throughout the enterprise and its partners, unhindered by artificial boundaries imposed by the enterprise’s information technology. SOA can thus help to realize the ideal of Boundaryless Information Flow.

Enabling Take-up of SOA

A professional approach is not a barrier to the adoption of new techniques. For example, the medical profession has a great record of progress in improving patient care through innovation. But this does not mean that, when anyone has an idea for a new treatment, every doctor immediately starts using it. There is a period of cautious experiment to establish that it works. There is then a period of increasing take-up, whose speed may be limited by the need for training or the lack of infrastructure or equipment. Only when the treatment is proven and enough doctors can use it is it accepted as standard.

SOA is now in the second of these phases. That it works has been established. Take-up is increasing. There is really no new infrastructure needed, and product suppliers are delivering supporting tools and equipment. The main limiting factor on take-up of SOA is the ability of architects to use it.

There are architecture frameworks that encapsulate best-practice. Enterprise architects use them for guidance in achieving successful projects. They include the Zachman Framework, the architecture Framework of the U.S. Department of Defence DoDAF , and The Open Group Architectural Framework (TOGAF). They all help enterprise architects to take advantage of prior art and best practice, and to develop architectures in an organized and structured way.If SOA can be integrated into these frameworks then enterprise architects will be able to use it as an extension of their traditional methods. But how easy is it for traditional enterprise architecture frameworks to do this? Must they undergo an evolution or a revolution?

This question has been explored by The Open Group. Its conclusions, in the recently published Open Group White Paper on Service-Oriented Architecture, are that SOA is an evolution of traditional architectural styles, not a revolution, and that SOA can be integrated into traditional architecture frameworks. The paper outlines how SOA relates to TOGAF, and a project is under way in The Open Group to develop detailed practical guidance for enterprise architects on how to use TOGAF for SOA.

The Way Forward

SOA implies important changes to the way that the architecture process is applied, but does not imply a change to the process itself. The changes from traditional styles of enterprise architecture are significant, but SOA remains a style within enterprise architecture, it does not break the mould.

The value of SOA is established, but its take-up is limited by the ability of enterprise architects to deploy it in a normal and routine manner. Integration of SOA into architectural frameworks will be a major factor in removing that limitation. But this requires cooperation between the “two tribes”, the traditional architects and the proponents of SOA, who must rise above their recent history of misunderstanding.

SOA enthusiasts and traditional enterprise architects are now working together in the Open Group to develop SOA as a part of Enterprise Architecture. This is part of a wider convergence of these apparently separate worlds in standards bodies and consortia generally, and in the enterprise.

SOA is an evolution of enterprise architecture practice, but it is delivering a revolution in enterprise agility and Boundaryless Information Flow. By working together, the proponents of SOA and the traditional enterprise architecture community can smooth the evolution of the practice, and help SOA deliver its revolution, so that the organizations that use SOA can deliver better business value.

Chris Harding leads the SOA Working Group at The Open Group, an open forum of customers and suppliers of IT products and services. In addition, he is a director of UDEF Forum, and manages The Open Group’s work on semantic interoperability. He can be contacted at c.harding@opengroup.org.