lustratus LiteBytes

This is one of the classics of Service Oriented Architecture discussions and has recently resurfaced.

Joe McKendrik over on his ZDnet blog rounds up some of the recent discussion. The heart of the issue is that SOA is not a product category because it is an architecture. Furthermore it is an architecture which requires significant focus around governance and organisation and therefore just selecting some products does not deliver SOA. Early on when SOA was close to synomious with Web Services, this was an important point to make: Just deploying a Web Services stack did not make what you did a SOA (giving rise to the delightful acronym JBOWS – Just a Bunch Of Web Services – to distinguish this approach from ‘true’ SOA).

However, from this entirely rational view grew the corollary that SOA can be implemented with anything. While theoretically this may be true, it can be taken to extremes: Clearly, the right product is bound to make it easier to implement SOA than the wrong product – even if you already own the wrong product. Also clear is the fact that you can buy important components of your SOA infrastructure from registries to management to ESBs. Furthermore, there is every reason to believe that software vendors will over time continue to move beyond ‘just’ providing infrastructure to providing larger chunks of SOA ‘out of the box’ – just as SAP et al do for ERP (as Jack van Hoof points out ).

Therefore today and in the future, SOA programmes must absolutely start at the architecture level and not simply select products. However, today and increasingly in the future it makes complete sense to use commercial (or Open source) software to ease the implementation:  SOA is othogonal to packaged software – not an alternative.

Ronan