You've heard it all before; technology should add value to a concept like SOA, not control it. Lately I've run into SOA efforts that are not playing by that rule. Indeed, the focus is on ESBs and governance layers, and not on getting SOA right from an architecture standpoint. I thought SOA was architecture, right?

At issue are the multi-billion dollar marketing budgets that vendors bring to the SOA world, and thus lead through sheer volume of sales. Those who promote the architectural value of SOA, perhaps like yours truly, are not being heard above the noise and flash of the SOA-in-a-box movement that's occurring all around us. The end state is, and will be, a failed project due to the misuse of technology, and project managers who do not understand their own issues before pulling out credit cards and buying technology. Thus, too much focus on technology is hurting SOA.

Don't get me wrong, I'm not attacking the vendors here. That's just too easy. What I am doing is pointing out the fact that technology, while being very powerful and necessary within the world of architecture, needs to occur as an outcome of the architecture, and not drive it. While most of you will see that as a logical piece of information, it's still a de facto practice to take an "ESB-oriented" approach to SOA, no matter what the issues are at hand, or, perhaps an "App Service-oriented" approach, or a "Governance-oriented" approach, or... Okay, I'll stop.

The result, in many cases, is not something that does not work; it's something that does not work as well as needed. Thus, many settle for sub-optimal solutions that have to be redone every few years to keep up with business demands versus solving the problem once and for all, maturing the architecture over the years and not having to keep replacing it.

The approach is simple. You start with your core requirements, understanding all aspects of the business, existing services, existing data, processes, etc., and then create a vision of the end state architecture and a complete map for getting there. You understand patterns here, not instances of technology, and once understood, back the correct technology into the problem domain, making sure that the core requirements are met.

I would suggest following this processes, at the very least: