Successful SOA Reference Model meeting

Last week, I headed over to Vienna Austria to work with the SOA Reference Model TC to hopefully polish the working draft of the specification sufficiently that we can make committee draft by early next year. From where we started earlier this year until now, there has been a tremendous amount of thinking that has gone into Service Oriented Architecture. One of the biggest points of improvement last week was a reorganization of the material related to services. In simple words, these sections correspond to "What You Need" and "What You Do." Effectively, these sections of the specification explicitly call out and address both a static as well as dynamic nature to the understanding of 'service.' Essentially, earlier debates on whether service is an action or an object are just another way of expressing this duality.

When we started thinking about things in terms of duality, it quickly becomes apparent that the duality of static/dynamic is not the only duality - need and capability; potential and actual; business and technology are other examples that emerge.

The last idea: SOA is about business and technology together, is one that seems to be gaining momentum in the industry. Recently, XML.org cited an IBM whitepaper titled "IBM's SOA Foundation: An Architectural Introduction and Overview" that states, "SOA is about the business results that can be achieved from having better alignment between the business and IT." I agree, almost. Earlier, the statement is made that SOA is about aligning business with IT to make both more effective. Certainly itrecognizes the synergy that comes from treating business and IT as a duality. However, we need to remember that, when it comes right down to it, IT is a tool. Having spent considerable amount of time trying to isolate why the nuances of a single word clouded my understanding, I'd suggest that we think instead about SOA as "aligning IT to business" rather than the other way around.

When trying to clearly express what is different about service oriented architecture, SOA if you will, this explicit recognition of dualities becomes a clear way to think about the differences in the approach - and it is encouraging that many in the industry are converging on this same recognition