Back to SOA

OK, so high complexity is Evil (and even physicists are getting in on it - here).

In the last few posts I've identified (IMHO) the underlying principles of a well-designed system - high cohesion, low coupling, high conceptual coherence, and good layering.

These are good principles because they aid in reducing system complexity, and low complexity is good.

Today there are many enterprises with a plethora of business processes supported by a host of different systems, perhaps interfacing to one or more legacy applications, all on heterogeneous hardware. To allow information to be distributed, there are numerous point-to-point interfaces using various means such as ETL batch processes, file shares, database shares, messaging, and various styles of RPC.

Just reading that should make you cringe, and most organisations deal with it by making it worse.

Service oriented architecture is the latest attempt at fixing this mess by making a simple observation. Each system (and I'm including the business processes associated with the system) is providing a set of services, and by identifying those services and the contracts by which they are invoked we should be able to abstract the service definition and its interface from the implementation of the service.

Now, the ability to abstract the service definition and interface from its implementation means that you can decouple the systems and introduce something else - like a messaging platform or ESB - to interface the systems. The has the potential to immediately reduce the number of interfaces (there are many traps, outside the scope of this post) by adopting, say, a hub-and-spoke architecture and hence reduce the complexity.

Done badly, of course, it can also increase the complexity! But we won't go there.

Add a few heuristics to take into account the fact that you're dealing with people (such as governance), and a couple of good ideas (like discoverability and interface self-description), and voila you have SOA. Add even-driven ideas (because firing events is a good decoupling mechanism), and you have SOA + EDA.

Most SOA proponents would generally agree that all the above are incorporated into current SOA best practices. Unfortunately, even by adhering to the above principles we're still going to end up with the problems of Company C! In my next post I'll explain why.