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!