lustratus LiteBytes

I was talking with a user the other week about SOA.

She was enthused with the SOA bug, but was frustrated because her company is notoriously conservative when it comes to ‘new developments such as SOA’, as she put it. This is not the first time I have heard the view that SOA is a recent development.

I find this quite amusing. It never fails to amaze me how we in the IT industry can fall for something which we see as shiny and new, when in reality it is at least largely based on things long past. Perhaps IT is like fashion – hemlines may go up and down, but the latest thing is always ‘new’.

As far as SOA goes, it bears a strong resemblance to old software engineering disciplines of the early 80s, when programmers were advised to encapsulate functionality in ‘black box’ fashion, with clean inputs and outputs, so that routines could be easily reused. Then we had object-oriented programming, which was really just an extension of this. I wrote my first paper on SOA (although it did not actually use that three-letter acronym) in 1996, and I am sure I was not the first.

In fact, I met an old mainframe programmer once who had a pretty good story of how the IBM mainframe transaction processing system, CICS (the original application server, if you prefer), was actually the first implementation of an SOA. This is a bit contrived, but bear with me. In the days of companies running everything on mainframes, a CICS shop would make all its applications out of CICS transactions. IBM provided mechanisms for CICS systems to interoperate with each other across geographical and corporate boundaries, and hence CICS transactions could invoke each other. Therefore, CICS transactions became building blocks representing pieces of business functionality, and the applications were then assembled from collections of these building blocks, without any problems concerning the physical location of the transaction.

Actually, I think he had a point. What is SOA, really? It is easy to spout loads of intelligent-sounding stuff, but basically it is about three things – encapsulate business functionality into reusable building blocks, provide a standards-based way to understand and invoke it, and supply mediation functions that can handle differences in formats and environments, and can orchestrate the way the blocks join up. OK – this is a simple view, but looking at the old CICS example, given that if everything is in CICS then this makes interfaces ‘standard’ (yes I know this is a bit of a cheat), the only real difference lies with the orchestration piece.

And so this touches on two important points. One is that management need not look in terror at SOA as some new-fangled development that comes laden with risks. It is an awful lot about just doing things cleanly, much as in the software engineering or OO sense. The other is that orchestration is the key to getting the most out of SOA – in the CICS case, the understanding of HOW the different transactions should link together in which situation was built into the programs, making it hard wired. With SOA, it is outside the program, and hence is more readily understood and capable of being changed without resorting to extensive reprogramming.

Steve