• silicon.com
• Technology
• Software

By Quocirca, 23 July 2004 09:55

COMMENT Put forward as something quite revolutionary, CBM seems to be a derivative of time and motion studies from the 1950s, total quality management from the 1970s and business process re-engineering from the 1980s. This does not make it unusable in itself - it just means that it is based on a set of premises that will generally require wholesale changes to a company to make the most of the approach.

The fact that IBM tends to utilise CBM as a point tool to sort out process issues within constrained, small areas of the infrastructure does not promote feelings of confidence in this approach. As a pre-sales tool, CBM looks like it can work, enabling companies to rapidly see the issues faced in creating an SOA. But as a serious working tool, it looks like it requires an army of consultants. Unsurprisingly, CBM comes from the IBM Business Consulting Services group - the former PWC consultancy.

From Microsoft, I was given a disjointed presentation that rapidly went from a discussion of what an SOA consisted of to a pretty average demonstration of how Visual Studio can be used to create web services. Statements such as 'services must be created as if they are an island - they must be self-contained' did not match up with the general viewpoint that individual services can be dependent on other services.

As an example, a service such as a sales account component may require a call to a file service to open up a discrete account file. Surely we must be able to assume that the file service will already be there - or does Microsoft expect us to write our own file-handling routines for each service we create?

While the Microsoft presentation was aimed at technically adept programmers and so was preaching to the converted, the fact remains that the approach was complicated. It did not attempt to address the actual business process issues that real-world programmers have to deal with and it showed no higher-level tools for business analysts to address these issues.

Microsoft seems to have forgotten that it purchased such a tool some time ago in the guise of Visio - which business people can use to visually describe a process and which technical people could use as a front-end development aid to create the described web service. Such an approach would at least provide the intermediary step required for business types to engage fully with the techies.

At both the IBM and Microsoft events, the attending analysts and press found it very easy to force the presenters to climb down on key views - this was, in itself, very worrying. If the practitioners themselves are not solid in their views, then their customers run the risk of being misled and provided with a substandard level of flexibility.

Microsoft's SOA story is a key part of its future strategy, both in how it will approach the changing market out there and in how it interacts with non-Microsoft systems. If Microsoft cannot make its pitch understandable to business types, it runs the risk of perpetuating the view that Microsoft is only for pure Microsoft environments. For example, the fact that companies can now use .Net in a J2EE environment has to be better promoted. This requires more clarity from Microsoft on its own capabilities.

With Oracle still trying to persuade everyone that Oracle wall-to-wall is the only way for full grid computing, and with HP not yet gaining full credibility alongside IBM, EDS and Accenture as a trusted business advisor, the lack of a simple story on SOA is holding back a market that should be closer to achieving mainstream focus than it is.

It's true that complexity makes money for consultants - and that companies are no longer in the position to undertake long-term disruptive projects.

But simpler SOA messaging across the board would create a larger penetrable market for all the players - who can then argue the case for customers choosing them based on their own flavour of implementation.