SOA Governance - A Moving Target

The typical enterprise architect embarking on an SOA initiative is trying very hard to deal with the whole governance space. They understand that there are some key things under the governance umbrella that need to be addressed but are having a hard time figuring out just exactly what those things are, and how the market is trying to solve them. In fact there are at least three different problem areas where governance is being used as a solution, but it’s a very immature market. There are inconsistencies and lack of synergies that customers are dealing with now that in the future they shouldn’t be. I’ll identify those three areas and give a little insight on what I think might be happening with each in the near future. 1. The first area of SOA governance is the registry and repository area. This is how we register services to be made available for use, how we describe them, and the storing of the different characteristics, uses, and users of those. Early on this was somewhat of an interesting space, but at this point it is pretty much a commodity, and I believe long term it will be considered just another feature of the SOA platform. You can think of UDDI no differently than CORBA CosNaming or J2EE’s JNDI or any other kind of technology along these lines in many respects. 2. The second (of the three of these SOA governance areas) is along the lines of runtime monitoring and intermediaries. Think of this as an SOA-specific systems management area. For example: security vulnerability testing, audits on transactional behavior, performance level measurements, and the pieces of technology that might even insure -- or try to insure at least -- adherence to certain service level agreements. This area is interesting and is maturing over time. This space is where a lot of old tools are getting new names and lots of new tools are popping up. We have a long way to go before we can know what the market is going to do here. Right now there are a few independent vendors that are doing a pretty decent job. But again it looks like the platform players are likely to end up delivering a lot of these solutions as part of the platform itself with specialized vendors plugged in for certain domains. 3. Possibly the best name for the third area is lifecycle governance. Consider this the governance concerns throughout the lifecycle to achieve adherence at runtime. This area is relatively new even compared to the other two areas. Examples of this are the performance, policy, and quality expectations for SOA. Most people have looked at quality issues as a pre-production problem and not a production problem. But as it relates to governance, teams need the assurance that they have continuously validating monitors on the services that they are dependent on. In just the same way, those who might be reusing services will need to continuously ensure that their expected behaviors are validated. And when new versions of services are released, those contracts, if you will, are not broken. This is the nature of governance. From all three of these areas we can’t break those contracts. We can’t break security policies or service level agreements; and we can’t break the functional integrity of those services as well. So in summary I think these three areas will evolve fairly independent of each other in terms of what the markets are going to do, but all three need to be addressed in order to have a comprehensive governance strategy.