David Linthicum

You need SOA governance, design time, and runtime. However, SOA governance does not come out of a box. Simply put, it's really a matter of people and processes put in place to ensure that the services are designed, deployed, and operated as effectively as possible. However, people and SOA vendors seem to be dropping the ball around design time, in terms of both people and tools. It's more about missing approaches and missing features, and once again there needs to be some education out there as to how organizations need to approach SOA.

First of all, those who define SOA governance as a set of technologies are missing the boat on this concept. The humans need to be factored into the equation. Second, when you do focus on the tools, many things that are required for good SOA governance design are missing, and there are no signs that things will get better.

First, let's deal with the humans.

The fact of the matter is that SOA governance, and governance in general, is really a people and process thing, with technology only coming into play to automate the processes and support the people. If you don't establish that, you're going to fail at SOA governance and thus fail at SOA, no matter how much technology you "invest" in.

Thus, people rely more on tools and technology than education when it comes to SOA governance, when it really needs to be the other way around. Indeed, I promote the 80/20 rule when considering SOA governance. Eighty percent of the time, effort and money should be spent on learning how to create and operate an effective SOA governance strategy, in terms of people and processes. Then you can spend the remaining 20 percent learning about the tools. Most drive toward the tools first, then to the approach as defined by the tools. In doing that, you assume your tools are correct in their approach and function, which is typically not the case, and my next point.

Now, let's deal with the technology.

The issue with design-time SOA governance technology (not runtime) is how deeply the technology goes to serving the true notion of "design" as outlined above. The fact is that most don't go that deep, and many who design a SOA are left wanting more robust features and functions, including true modeling and simulation capabilities based on SOA design and development best practices. They don't consider SOA holistically, but instead focus on the design and management of new and existing services. That's a very small part of SOA, when you get right down to it.

Another issue with design-time SOA governance technology, and as with most SOA technology, is the lack of a standard approach to design-time SOA governance. While there are a few standards emerging, most SOA governance technology providers have gone off in their own proprietary directions, using their own approaches, and no two are alike. Thus, not only are you picking a tool, but you're picking a design approach that may or may not be right for you. The tools should never dictate the approach; they should support best and proven practices, as well as drive design that holistically supports more strategic modeling and simulation features, and supports what SOA is...an architecture.

The whole notion of design-time SOA governance could be getting us off track when it comes to the proper approach to SOA. This is really the fault of the humans who focus way too much on the technology and not the processes or approaches, and the fault of the SOA design-time vendors who need to do a great deal more work on their offering, else the SOA architects will just jump directly into SOA runtime governance, which, as it seems, many are already doing today if you look at the penetration of the technology into the market. I suspect the design-time SOA governance vendors will be fixing a lot of things this year and next.