What is SOA?

SOA - Service Oriented Architecture ... what exactly does that mean?

Its an unfortunate fact within the IT industry that there is no single, definitive definition of 'Service Oriented Architecture'. In the early days it was often conflated with Web Services, which is not unreasonable as many resources on the web invariably include Web Services somewhere within their definition of SOA. However, today there are few who still adhere to that view, and some are even amenable to the use of REST.

I'm not going to define SOA here - there's plenty of definitions out there already. Instead, I'm going to take a different tack and consider what we're trying to achieve with SOA. Why are companies attempting to re-engineer their IT infrastructures to be coherent with this vision of 'SOA'?

System Design Principles

System Design is closely related to Systems Theory, being the application of Systems Theory to the development of systems. System Design is a complex subject; however, in its application to software-based System Design it fundamentally comes down to the following principles when defining individual components:

• High Cohesion
• Low Coupling

Incredibly, that's about it. No magic bullet. Of course, these two principles have very big implications (such as data abstraction and information hiding, impacts on interface design, contract specification, etc.). But in a nutshell, that's it.

A perfect example of a high-cohesion, low-coupling component is a lego brick. It has high-cohesion by the mere fact that it doesn't tend to spread itself around (unlike, say, air), so you won't find bits of it in places where they don't belong doing things they shouldn't be doing. It has low coupling due to the fact that it physically only has two interfaces that interact with other lego blocks - one that you can plug lego blocks into, and one that can accept lego blocks. Due to this exquisite combination of simplicity and utility, it is capable of being used to construct an infinite number of designs in conjunction with other lego blocks.

However, due to the fact that it has a well-defined set of capabilities (a result of its high-cohesion), this simplicity also imposes limits. A lego block cannot, for example, be used to construct electrical circuits. To build electrical circuits you need resistors, diodes, transistors, capacitors, conductors, and inductors - not lego blocks.

High cohesion and low coupling of components appears to be common in the construction of complex systems, whether they be software systems, computing systems, biological systems, or manufacturing systems. For example, object-oriented design heuristics have high-cohesion and low-coupling as two important properties for well-specified classes, modules and subsystems. In biological systems such as the human body, cells are specialised towards specific functions and predominantly localized to certain organs. The organs, have specialised functions and interface with the remaining body using well-defined interfaces (how else could a surgeon simply replace one heart with another?).

Are high cohesion and low coupling the only principles needed? Not quite ...

Services and Architecture

Ah yes - I remember the first time the term "services" was uttered in my presence, but without "architecture" attached. It was around 2000 or 2001 (my memory is rather sketchy on details!), and I was in a meeting with other 'architects' discussing shared components to be used across the enterprise. Someone cottoned on to the idea that we weren't really talking about components - we were talking about sharing functionality that could be invoked from anywhere; in other words, services. It was an interesting period for me, as it was intellectually challenging. However, it was also incredibly non-productive, as the architecture group seemed to be engaging in little more than intellectual masturbation. Looking back, it was probably the "forming / storming" stage for the group, so no real surprises.

Today, I wonder whether the organization still has meetings where there is lots of high-level discussion around 'Service Oriented Architectures', shared services, and governance ... with little to show for it but the obliteration of vast tracts of the Amazon.

Anyway ... what the company did have, however, was a sufficient number of 'idle' development groups such that almost all new and successful IT implementations were a series of interacting skunkwork projects (in fact, they've recently released an application to a very popular mobile platform).

I'll call this company A.

At the other end of the spectrum, I've come across organizations where they've well and truly gone past the point of discussion and have created an almost endless list of 'services'. Regrettably, there are few services consumed by more than one client as each service has essentially been designed to fit a single purpose. Not only that, but each application uses a different message format for information or services that could relatively easily be shared across applications. It works, to a degree. But without governance, the level of sharing is minimal to zero.

This is company B.

I've personally come across only one organisation where common services were developed and used by others within the organisation. They had all the hallmarks for the beginnings of a successful enterprise-wide SOA implementation - except that their cost to income ratio for IT services was approximately three times that of company A, and many more times that of company B. In addition, senior management was continuously complaining about the lack of flexibility in the provision of new products and services, and couldn't believe how much it was all costing.

This is company C.

Given that company C is, according to current approaches, IT nirvana, why is it faring so badly compared to A and B? To see why, we need to go back to first principles and take another look at why SOA is seen to be the next step for most large IT shops. We're also going to be slightly heretical and question whether SOA in its currently understood form really can deliver all that the vendors and consultants are promising.

I'll leave that for the following posts!