Roles and Responsibilities in SOA

Stephan Lahanas posted on the top-10 reasons SOA projects fail.  I think many of his points are very valid (especially the one about how it's the business that matters, not the standards or the hype).

But, I think one of his points is a bit off the mark:

"Design drives development not the other way around, we wouldn't want the drywall guy designing a skyscraper, yet that happens in SOA implementations (figuratively speaking)...You can't really do 'Agile SOA'..."

Well, I certainly wouldn't want the architect of a skyscraper putting up my drywall.

But seriously, creating a SOA infrastructure isn't like creating a skyscraper. Creating a SOA is not an orderly progression of activities that lead to a defined end result.  It's more like a financial market: anyone can do whatever they want to make themselves wealthier, as long as they don't violate the rules (i.e. the law).  There is no defined end-result for a financial market: everyone is free to try and achieve their own optimal end result.  And many financial markets are extremely agile.

So, can you do "Agile SOA?" Absolutely.  As long as you've optimized the rules - your SOA governance - to allow for agility (which many people get horribly wrong, of course).  Provided the rules are not cumbersome, if someone else has built the services you can very quickly create consumers for those services without any muss-or-fuss.  No waterfall model of software development needed; no systems engineers needed.

If, on the other hand, you think of your organization's SOA as one big project, then almost certainly there is no way to be agile.  But, if you're thinking about it this way, you've already lost anyways. Central planning never has been (nor ever will be) agile.