Enterprise Architecture and SOA: Two Tribes

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.