Quocirca's Straight Talking: We must simplify SOA

Vendors have yet to learn how to communicate the value of a service-oriented architecture, or SOA, to business types, says Quocirca's Clive Longbottom. In keeping things so complex, they're holding back the utility computing market from going mainstream.

Utility computing has been on most companies' radar for a couple of years now and the major competitors in the market have been playing their respective cards with differing amounts of success.

Vendors such as IBM, Microsoft, Oracle and HP use terms as diverse as 'on demand', 'agile business', 'grid computing' and 'adaptive infrastructure' to describe their visions of utility computing, but the general push is similar, even if the rhetoric is different.

In short, utility computing is the practice of moving from a relatively inflexible, silo-based, application-focused environment dependent on specific hardware/software configurations, to a flexible, scalable environment based around functional services that can be provisioned across an existing infrastructure as business needs change.

For the single, underpinning software framework to support the utility vision, the market has come up with the vision of a service-oriented architecture (SOA), which should be great news. Why? Because we should be able to get the same, simple message from every vendor on the kinds of technologies we need to have in place to support business processes.

But to date SOA has failed to live up to its promise - and thus the utility computing market is still mired in complexity that runs the risk of holding back its growth.

To Quocirca's mind, SOA is relatively simple at a conceptual level - technical functionality (what a company can do with its IT applications) should be available as a set of callable services that directly facilitate business processes. In other words, an SOA does what it says on the box - it is an architecture that is oriented around services.

It is fast becoming apparent, however, that such simplicity is not necessarily how the vendors see it, and many of them are running the risk of confusing their prospective customer base through complexity, wrong focus and lack of coherence. From a developer perspective, however, the SOA message is reasonably strong. What seems to be challenging the vendors is translating the technical elegance of an SOA into language and approaches that business decision makers can understand.

As proof of the mixed messages on SOA, I can point to two events I attended in the past month - an IBM analyst event and Microsoft's TechEd conference. During each of these, the host company provided an overview of its thoughts on SOA. Along with the majority of others present, I was bemused by the message put across.

For IBM, having created the 'e-business' brand in the 1990s, the move through to 'business on demand' has been managed carefully and successfully. Of all the players, IBM should be able to simplify the SOA message, because it has many of the pieces of the puzzle and has the strength of being able to demonstrably work in a heterogeneous environment.

IBM has come up with a consultancy approach called the component-based business model (CBM). This attempts to take the existing IT environment as a set of vertical silos (for example, CRM, ERP, SCM), then layer across the horizontal process needs of the business and therefore turn the intersects into components. These components provide services, and so by taking the CBM approach, we nominally get our SOA.

Sounds OK, but it is full of holes. For a start, where do the company's existing horizontal services such as middleware fit in? To what extent should a company break its IT infrastructure into components? Too few components, and we have silliness such as SAP being a component in itself. Too many, and we have the problem of attempting to piece together processes from meaningless pieces of technology, for example, a single SAP screen.