While the end objective of SOA is to achieve enterprise agility, the actual path to achieving the same is 'counter-agile', as Thomas Erl states. The actual process of building and hosting the services in a distributed environment is not simple. And on top of it, if you add the products that promise to implement successful SOA, the complexity will only multiply.
This post is a continuation of my two previous posts - IT industrialization and Product Line Architecture. When I was discussing with my fellow Architect in this regard, we concluded that the need of the hour is 'simplicity'. And I can no way refer any of the existing products in this category.
And there is also lot of discussion going on in the web about the promise of SOA. Someone has asked, if SOA is evolutionary and promising to bring tremendous benefits to the enterprise, how come we are building SOA with same old technologies?. - very thought provoking. You may say - Web services is new technology. But, the fundamentals are still the same.
The only way I see the complexity can be reduced is by bringing a fundamentally new technology or language that would simplify 'building' SOA. And I am not wrong!. Check out this language - Somebody is not only thinking but working on those lines.
Another way of looking at simplicity is use of 'Domain Specific Languages'. I see DSLs are the only thing that is common between Agile Camp and SOA. Both of them agree to gain benefit out of them. While the 'Agile' camp approaches DSL for productivity/Accleration in Development cycle, SOA approaches DSL from 'semantics' perspective. Both stand to gain from it. I believe well designed DSLs would make the 'building' part of SOA lot more 'faster', not necessarily 'simpler'.
But unfortunately, it looks like DSLs are going to become obsolete even before they mature! Yes, Microsoft is planning to adopt UML instead of DSLs for modeling SOA.