Service-Oriented Architecture – SOA and Enterprise 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

Why does an enterprise need an SOA – or an architecture of any other kind?

The directing function of an enterprise – the board of directors of a commercial company, or the top-level management of a division or government department, for example – sets objectives for the enterprise, and decides how it should operate in order to achieve them. A clearly articulated architecture describes the desired enterprise organization and manner of operation. By doing so, it provides:

  • A definition of the changes that should be implemented to achieve this organization
  • A basis for control and governance of its ongoing operation

An enterprise architecture also provides a third benefit. Enterprises change over time. They combine and split, as in commercial mergers and spin-offs, or government department reorganizations. It is easier to combine an enterprise with another, or to split it into component parts, when it has a clearly-defined architecture. This brings significant cost savings, and can increase the value of a commercial enterprise.

Enterprise architecture in its widest sense includes much more than IT. It covers business operations, finance, people, and buildings in addition to technology, and it covers technologies other than IT, such as for manufacturing or transport. The enterprise architect must understand these areas, at least well enough to supervise architects that specialize in them. The IT architect must be able to work in teams with such specialists.

The SOA Source Book focuses on the IT component of enterprise architecture. This 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 1950s, commercial and government organizations have become increasingly dependent 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 1920s, 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, message-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 SOA can bring, not only within enterprises, but also between enterprises.

Overview of SOA

The principle of service-orientation can apply throughout the enterprise architecture, but is most commonly applied to the organization of the software that supports the enterprise's business operations. With SOA, this software is organized as a set of software services. The services are supported by an infrastructure that, together with the services, improves information flow within the enterprise and between the enterprise and external enterprises.

Overview of a Service-Oriented Architecture

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

Specific sets of business processes, services, and interfaces are created in the context of a supporting infrastructure as service-based solutions. Each solution solves a particular business problem.

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.

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. The infrastructure is managed via human-computer interfaces by technical staff who are responsible for all aspects of operating the enterprise’s IT, including its availability, performance, and security.

A major benefit of SOA is that it delivers enterprise agility, by enabling rapid development and modification of the software that supports the business processes. The infrastructure can provide for 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: the whole service lifecycle. They are used via human-computer interfaces by development staff.

The infrastructure also provides for storage of enterprise information. SOA can enable easier flow of information within and between enterprises. The 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 to all the software services that need it.

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

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 spend 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.