SOA: A square peg in a round hole?

It is really interesting when you look back on your blogs over the years and reflect on how your views have changed, and whether anything still remains true given what you know now. Over the past few months I’ve been researching the state of SOA today; well over a decade since .NET Web Services arrived on the scene and the term SOA first came to popular attention.

One blog I’ve referred to time and time again in talking about SOA is the one I wrote on SOA Anti-patterns back in 2005. I use these anti-patterns regularly when talking to people and had come to think that their value had never been more significant than they are today given the emergence of the so-called “cloud”. However, I had noticed that they resonated less well with those where SOA was being “successful”. It therefore came as quite a shock when I actually re-read the blog only to find that the core tenet on which these anti-patterns were based was actually proving to be itself one of the core anti-patterns of SOA and why in so many cases SOA has proved unsuccessful.

The anti-pattern was actually described in the opening section where I suggest that the decentralised nature of SOA “left unchecked” could lead to the occurrence of a number of the anti-patterns that I went on on to describe. Unwittingly, I had hit upon one of the core anti-patterns for SOA; the square-peg anti-pattern, it was just that at the time I didn’t realise it.

The square-peg anti-pattern

As I noted back in 2005, SOA is a “decentralised” pattern for integrating distributed systems, but what I didn’t realise at the time and where the true problem turns out to be, is that we insist on trying to fit SOA (the peg) into a “centralised” model of IT (the round hole). This is like holding the same poles of two magnets end to end, they repulse each other, we are simply trying to put two incompatible models of operation together as one.

From a centralised perspective of IT these anti-patterns make sense, but turn the problem on the head and they become less significant and maybe cease to exist. The reality of the problem turns out, not to be one of fitting a square peg into a round hole, but that there are simply no square holes!

For IT and let’s face it, for the really important part; the business, to really take advantage of SOA it needs to give up being the monopoly, it needs to decentralise and devolve control to the services themselves. The result is smaller IT, encapsulated within the service, focused almost entirely on delivering business value for that service, rather than having to pay a high tax to conform to the demands of a centralised IT function.

The three Cs!

So if this is the major problem, then why do it? Why not drop SOA and retain the centralised model for IT? Of course this is an option, but let’s look at it through the lens of the three Cs that Hammer and Champy raised in re-engineering the corporation:

• Customers take charge
• Competition intensifies
• Change becomes constant

IT is subject to the same pressures and has to deliver the service that is required by the business. Your customer demands the ability to be more in control, dynamic, they have choice and increasingly have the potential to ‘shop elsewhere’. The competition from others who can provide the service, faster, cheaper and to order is increasing. The rate of change required by your customer grows daily and the need for IT to move from reactive to proactive and part of driving business.

Specialised Units of Business Capability

In looking at the trends within the business itself, one can see it is differentiating into often finer units of specialism. the benefit being, to take advantage of market leading innovation quicker, cheaper and at lower risk. IT needs to power these new capabilities, but can’t do so through a rigid model of centralised command and control. These new capabilities need to move fast, grow fast and evolve quickly in response to change. The IT needs to be as close to that business innovation as possible and be part of the solution rather than a problem that slows down their time to react.

The rise of the Central IS function?

So what now for IT? Is it the end of IT department? Well may be it is, as we know it today. Decentralisation is inevitable for Business as it is for IT, as the technology layers commoditise there is less need for many of the old functions of IT, but given all these moving parts, these increasing units of specialised business capabilities, the increasing number of sourcing choices for services of all shapes and sizes, it is clear that there is a need for:

• co-ordination
• governance
• compliance
• innovation management

These, then become the watch words for the future of the centralised IT function, but it is perhaps the name that needs a change, it is less about the technology but still about the information and management and certainly needs to nurture innovation and of course it’s all about the service.

Welcome to the:

Corporate Information and Innovation Management Service.

Advertisement