Service-oriented architecture (SOA) provoked hot debate when it burst onto the scene in 2005. Its advocates said that it would replace traditional information technology (IT) architecture. The traditionalists replied that SOA was nothing new, just a rehash of old (but good) ideas about encapsulation and loose coupling.
There is some truth in both of these positions. But in the main they are both wrong. Although SOA does include earlier architectural ideas, it is a distinct style which marks a major step forward. And, to obtain maximum benefit from SOA, an enterprise needs traditional architectural disciplines and methods.
Enterprise Architecture
Enterprise architecture is concerned with the strategic development of an enterprise's IT. It looks at the whole of the enterprise, not just a particular system, and it looks at the long-term evolution of the IT, not just at what should be installed today.
The quality of an enterprise's IT architecture can have a major impact on its business performance. Since the 1950's, commercial and government organizations have become increasingly dependant on IT for the conduct of their everyday operations, and that trend looks likely to continue. Companies that use IT effectively prosper. The best of the once-derided .com companies ("When will they ever make a profit?") became household names. Companies with poor IT fall behind their competition, or fail.
Because of its importance to the overall business, enterprise IT architecture has become a profession. No company would think of undertaking the development of a major building without engaging a buildings architect with a professional status that provides a guarantee of competency. Similarly, companies undertaking the development of major IT systems look for professional enterprise IT architects. Their status as professionals indicates that they understand, and have a track record of applying, the best IT architecture methods and techniques.
SOA
An enterprise architect looks at the overall construction of the enterprise. SOA is a particular construction technique that can be used to build enterprise IT.
A particular technique can have a major impact on the overall construction. The introduction of steel-frame techniques in the latter part of the 19th century revolutionized buildings architecture. It made possible the skyscrapers of the 1920's, and the even larger buildings that we have today.
SOA could have a similar impact on IT architecture. It does not increase the size of IT systems, but it does increase their interoperability.
With SOA, the IT systems perform services that are defined and described in the context of the enterprise's business activities. Each service is identified, and what it does is clearly set out in the form of a contract.
This principle enables use of techniques such as service composition, discovery, massage-based communication, and model-driven implementation, which give fast development of effective and flexible solutions. They are important features of SOA. Their benefits, especially that of enterprise agility, are the most frequently quoted reasons for SOA adoption.
But it is the replacement of large, monolithic applications that have tiny interoperability interfaces, grudgingly provided and not guaranteed, by smaller, modular services that have interface descriptions and contracts, that is the most fundamental effect of SOA. This is the basis for the huge increase in IT system interoperability that can SOA bring, not only within enterprises, but also between enterprises.
The architectural dimension of SOA
It takes far greater knowledge and skill to erect a skyscraper than to build a house. The buildings architect must make complex stress calculations based on an understanding of the properties of the materials involved. Training and experience are essential for success.
Knowledge and skill are also needed for success with SOA. The IT architect must specify the right tools and infrastructure, create the basis for the identification of modular services, and ensure that appropriate implementation governance is in place. Good judgment in these matters is crucial.
Also, just as steel-frame construction is not appropriate for every building, SOA is not necessarily the right approach to solving every IT problem. The IT architect must know when, as well as how, to use SOA.
SOA can be a big investment. Its tools and infrastructure cost money, but that is only one part of what is needed. Development and operation staff must have special skills to create and use SOA, and the overall organization structure and culture must be right if the full benefits of SOA are to be achieved. Staff development and organizational change is often the larger part of the investment. Such an investment can only be justified in the light of a long-term strategy for the enterprise as a whole.
Many enterprises have undertaken small-scale SOA developments as part of a learning process. This is an excellent way for them to introduce SOA, but they often find it hard to extend beyond the initial pilot. Developers complain that they cannot justify the infrastructure that they need. Of course not! Expensive infrastructure cannot be justified on the basis of small projects and, in any case, looking for business justification for technical spending is putting the cart before the horse. The business need should come before the technical solution. SOA should be used where – and only where – it is the best way to meet that need.
This is where enterprise architecture comes in. Enterprise architecture creates long-term IT strategy in the light of business possibilities and needs. Inclusion in such a strategy is the only good justification for large-scale SOA.
Mainstream SOA
SOA is no longer a new toy. It is an established style that architects understand and can use.
The architect does not start by assuming SOA, but considers service orientation and its associated techniques in the light of the business strategy. Sometimes, the technical possibilities can change that strategy, but the business needs and possibilities are still the main driving force. The architect finishes by specifying a particular combination of SOA techniques because it best realizes the possibilities and meets the needs.
This is the normal architectural approach to IT strategy. SOA and enterprise architecture may have seemed different in the beginning, but SOA is now part of the enterprise architecture mainstream.
About Dr. Chris Harding
Dr. Chris Harding is Forum Director for SOA and Semantic Interoperability at The Open Group. He has been with The Open Group for ten years and is currently responsible for managing and supporting its work on semantic interoperability and SOA.
Before joining The Open Group, he was a consultant, and a designer and development manager of communications software. With a PhD in mathematical logic, he welcomes the current upsurge of interest in semantic technology, and the opportunity to apply logical theory to practical use.
He has presented at Open Group and other conferences on a range of topics, and is a frequent contributor to electronic journals such as eBizQ, CIO Update, DM Review and SOA World. He is a certified TOGAF practitioner.
