Lustratus LiteBytes

Archive for November, 2006

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

After a month of life, Illuminatus Research is being reborn as Lustratus Research.

The name change is at the behest of a US-based company that claimed our name was similar to its own, and despite our judgement that our business-oriented focus differentiates us from this technology-focused firm, changing seems the simplest decision in order to avoid lining lawyers’ pockets.

The target is to achieve the changeover by Tuesday 7th November. This blog will become Lustratus Litebytes, and the Illuminatus Research site, www.IlluminatusResearch.com, will become www.LustratusResearch.com.

Apologies to our rapidly growing audience for the disruption – but rest assured, we will continue to provide a wide range of independent and unbiased commentary and guidance on technologies impacting business.

Steve

As Steve noted in his last…

…post, ESB vendor Fiorano has just announced a component gallery. I should start by saying that I do find the notion of a marketplace for components attractive and as a concept it has been around for a long time. However, it has never taken off in any previous guise for any but the most technical components.

In the first instance, I think that the blocker is related to the generic SOA reuse issue that has been discussed here and elsewhere: Even within an organization you need to marshal all your technology and organizational resources to achieve reasonable reuse levels. When you try to create a business level component for reuse outside of the organization the problems are much greater again.

The second reason is around the business model: it is hard to make money selling enterprise-style components for $4k off the web. There simply isn’t the volume to support the necessary development and marketing spend. Clearly in the case of Fiorano, this is leveraging an existing business model and therefore may generate some attractive incremental revenue – which brings me to my third point.

Steve already commented on the very technical nature of the components listed. I would go further and wonder why these components are not already in the Fiorano box. Paying $4,000 for something as basic as allowing a single CPU machine (and since just about any machine you will use will be at least 2 CPU this is actually $8,000) to receive HTTP requests seems very high if I am already paying for what is clearly now a basic base product.

And finally, as was previously pointed out on this blog in connection with IONA’s claim to an extensible ESB, this ‘only buy what you want’ approach to introduces a level of complexity around what the product does way beyond the normal comfort level of purchasing managers. Unfortunately to some, it could appear that this approach is primarily about making the base price look attractive and then loading on the extras to solve any real business problem.

Ronan

Fiorano just…

…announced availability of its new Component Gallery. The idea, described as similar to iTunes for music, is that

“the Fiorano Component gallery allows business analysts to assemble ready-to-deploy business solutions using standards-based coarse-grained software Components with XML interfaces”

So there is a repository of components that can be downloaded to build business solutions. The idea is quite neat, although it does depend on people donating (or selling) components in the gallery. However, my concern about these types of ’standard template’ mechanisms for packaged application assembly is that the application can never be decoupled from the business concerned. For example, a company may have strict programming guidelines making any component built outside of these procedures inappropriate. Standard transformation and interface components may be useful with well-known packages such as SAP, but with homegrown applications they are of limited use.

I shall watch developments with interest. However, my biggest concern is the way that this component gallery is portrayed as allowing business analysts to assemble these solutions from the component gallery. A quick look at the current components in the gallery reveal such components as EJBAdapter, BeanShell, JMSRequestor etc.. The business analysts I know would not feel comfortable dealing with their applications at this level. My own view is that the target audience is clearly a more IT-literate programming one.

Steve