I had a podcast chat with Anne Thomas Manes this week. The podcast will be available next week. However, I had one takeaway from the conversation that's been bugging me for a few days: in essence, instances where SOA governance is actually distracting to the progression of SOA.
The reality is that those doing project-level SOA are working hard on the fundamentals, including understanding that information, existing candidate services, core business processing, and SOA governance tools should be something that is considered a bit further down the road -- especially design time.
No, I'm not saying that SOA governance should be ignored; indeed, it's the foundation of a well-defined and designed SOA -- the approach, not the technology. The issue is that SOA is about getting things right from the foundation to the higher level processes, and SOA governance technology has a tendency to muddy up the water in the early stages of the project when forced into the mix. I know of a few projects that are in trouble because they chased SOA governance as defined by the technology they purchased, and did not focus on the fundamentals.
The real issue is how you defined SOA governance. If you define it as a systemic concept to SOA, and build it into your SOA project plan as a concept, that's fine. If you define it as technology or tools, then chances are you'll find that the early adoption of such technology is actually counterproductive. The data points coming in from the field are proven that out.
So, some free advice:
First, only purchase SOA governance technology, if it's indeed needed, after you have a complete semantic-, service-, and process-level understanding of the problem domain. Never before.
Second, focus on SOA governance as an approach and practice, not as technology. Create a SOA governance strategy first, and make sure it's considered during each step.
Finally, and more importantly, make sure that your architecture is independent of the technology you select.