SOA - "Super Open" Architectures

I was reading the snippet on SOA in this Javalobby article and it struck me that a large number of people consider SOA to be "yet another software architect's differentiating gravy boat", and to a certain extent it is. If you approach a classic consulting architect and ask them to drive you down the SOA road, then chances are they will "do you for the basics" - in other words you might get an ESB (tarted up MOM layer), a set of technology components (repackaged Tuxedo) and a half proven (Corba style) interface framework with the badge 'SOA'.

The challenges of a standard SOA implementation have not really been solved. The vendors of the likely SOA platforms are only just now getting around the table to either buy each other, swap specs or invite each other into court, and almost no implementation has been accepted as the 'industry leader' (not even IBM imho).

The general idea of having well defined component interfaces that meet the broad requirements of all their possible clients is understood by the designers of SOA systems, but the technical challenges of having complete consistent and efficient interfaces for all the range of service users are very difficult to reconcile.
The issues are further compounded by the lack of a real answers to the following:

• How do you achieve reliable communications?


• How do you ensure enterprise standard security?


• How do you keep the business logic and processes out of the technical quagmire?


• How do you maintain integrations with legacy systems?

Add to this the transitional issues related to rolling out architectural change across business critical systems and you have a challenge that is beyond most technical architects.

From my own experience, it has become clear that a successful SOA implementation is more down to defining good services and having well organised interfaces into those services than any ESB or BPEL integration. The stock answer from a consulting architect is normally, base yourself on vendor X and Y, use the backbone technology Z and the platform technology U, and then defining your interfaces is as easy as ABC and glue it all together with XML. The trick is in the bit that they typically skip, or leave to the troops on the ground - the systems design.

But how do you design a component to be 'at home' in any system? With great difficulty. The problem is like having a house that you should be able to pick up and move anywhere, one that will automatically connect up to the local pipes and facilities after each relocation. One of my colleagues likens SOA design to changing jobs every month, where each time you have to forge new trust relationships, define your role in the organisation and get your email and business cards. In both analogies it takes time to get to know your surroundings, and so it follows that any component must also adapt as we do to changes. And although self adapting software does exist, the best we can hope for is configurable scripted tailoring and 'hints' management. But to script or hint correctly you need to understand the system design.

I fear that most people use SOA to hide the true cost of having a good systems design. The technologies in use work well to enable flexible systems implementations, and as such allow the architect the opportunity to rework the systems design without a great deal of cost. But your first SOA implementation will typically be only about 50% efficient. And that is why I refer to SOA as "Super Open" and not "Service Oriented", architects tend to leave the systems questions open and use low quality scripts and inefficient messages to paper over the cracks.