SOA governance largely not established
The SOA Forum surveyed over 500 organizations and concluded that nine out of ten haven’t figured out SOA governance. I’m quoting it here because this find actually matches my experience with SOA initiatives I’m seeing in financial services IT organizations. The banks that have advanced their SOA initiatives certainly have some form of governance, but it’s overwhelmingly manual and, for the most part, cover only some areas. In those organizations, there are some impressive metrics, but they are compiled manually, and quality and policies are implemented casually (or not implemented at all). The IT organizations I deal with have multi-billion dollar IT budgets and thousands of employees, so formalized and automated governance is going to be key at some point, or it simply won’t scale, and there is a high degree of risk the SOA will fail.
Some more color is needed here though, because SOA governance means different things to different people. Many view policy enforcement as the sole mechanism for governance, and although a managed policy structure with automation is indeed and very relevant and important, there are other quite necessary functions in the governance realm as well, and few IT shops have implemented them. For instance, successful SOA projects have established a common support framework mapped to their process including automation supporting the following:
- Requirements capture and management
- Project management
- Ticketing management
- Collaboration between teams around common services
- Registration of services and the certification of the advertised state of each
- Discovery of services for orchestration of composite solutions
- Consumption of services in development, testing and production
- Metering and billing of components in the runtime environment
Clearly, automated policy management can “check” things going in and out of registries and a few other places but a complete approach to governance is rarely seen implemented, (meaning a unified approach to cover the project management activities, runtime metering, bugs recorded, collaborative activities surrounding moving components forward or integration strategies, etc). The convergence of these things in an automation paradigm coupled with a federated process to ensure teams are on the same page makes up the governance strategy of a successful SOA.
The survey referred to above also mentions that 56% of the respondents indicated that more than half of the software artifacts developed in-house are not reviewed for compliance before moving into production. This problem isn’t going to be solved with a merely a policy manager. Unless governance reaches the various functions and activities that touch a component, there will always be ways in which policies can slip through the cracks. SOA governance needs a very broad, horizontal approach, one that maps process to support infrastructure covering the bulleted items I’ve listed above.
Although the survey asked the respondents for an estimate of how many services are checked when automated policy management is in place (to which the survey reports 88% say more than half of their services are checked, and 50% indicated all are checked), the question I have to ask is: what is “policy management” in the minds of the respondents? There isn’t a clear answer here, and based upon my interactions with IT organizations in large financial institutions, I tend to believe there are varying ideas out there with respect to the definition of policy enforcement.
Other survey’s I’ve seen report very low percentages regarding satisfaction with governance solutions, but trend upwards for those with automation solutions. Relatively speaking, it’s safe to say that automation supporting governance processes is key, and the broader the automation covers the more beneficial the governance is to the business.