I met John Crupi - CTO of Sun's Enterprise Web Service Practice - at OOPSLA last year. Very cool guy. I hadn't realized he started blogging last month until Steve Vinoski linked to him. There seems to be some disagreement regarding using a top-down approach to SOA. Steve writes that SOA, like other "real-world development" is usually a mix of top-down and bottom-up. John writes that SOA is about a business driven architecture instead of an IT driven architecture. I liked this quote:
"[W]e cannot do SOA without a mutual effort between IT and the BU. Gone are the days of throwing the requirements over the fence and hoping it hits. Not only do these two groups have to work together, they have distinct roles and responsibilities. Basically, the BU runs the show and owns the business drivers, use-cases and processes. IT implements the BU requirements and owns the service definitions. It's unfortunate that we really do have to refer to this as a "shift", because we should be doing this anyway. But, the reality is that IT and BU typical function as disparate groups and rarely work together to have the business use-cases drive the process and service definition."
John Evdemon made two points relevant to this issue several months ago:
SOA does not enable or ensure the alignment of IT and business. The IT industry has been promising this for decades – there is no silver bullet for aligning IT and business. Alignment of IT and business is an organizational issue that will not be resolved by an architectural design philosophy alone. Service Orientation will happen in your organization in one of two possible ways: chaotically (typical approach) or in a disciplined manner. The path your organization takes (and the cost of later fixing that path) is up to you.
SOA does not enable or ensure the alignment of IT and business. The IT industry has been promising this for decades – there is no silver bullet for aligning IT and business. Alignment of IT and business is an organizational issue that will not be resolved by an architectural design philosophy alone.
Service Orientation will happen in your organization in one of two possible ways: chaotically (typical approach) or in a disciplined manner. The path your organization takes (and the cost of later fixing that path) is up to you.
I'm with John on this one. Traditional approaches to new problems are rarely successful.