Governance on-the-fly

Aah! Remember the days when service-oriented architecture (SOA) was being touted as the next big thing in enterprise application integration, a panacea if you like for companies' integration woes as it allowed them to re-use IT components or invoke them as part of a business service regardless of the technology platform or location underpinning them.

SOA is certainly not a new concept. It has been around for 15 years or more, but has come into its own in the last few years with the proliferation of web services standards. But like most technologies that are over-hyped, the initial fervour and enthusiasm soon gives way to the practical realities and considerations that accompany implementation.

It is only once companies started getting their hands dirty that the industry is now starting to have the debate about 'run-time governance and SOA'. Given that SOA allows anyone within an IT organisation to re-use IT components or invoke them as part of a new business service, their needs to be some form of overarching governance framework in place, otherwise the left hand is not really going to know what the right hand is doing.

Needless to say because vendors and companies have been learning 'on-the-job', it is only now with the benefit of hindsight and SOA implementations in place that some of the tarnish of service-oriented architectures is starting to wear off.

In a white paper on Runtime Governance and SOA, Progress Software makes the following comment:

"Many SOA implementations are just not working in production as designed or expected. Problems range from service interruptions to entire business processes failing, to compliance risks that generate costly delays and lengthy triage cycles."

Understandably firms that have or are in the process of implementing SOAs may be miffed that nobody warned them of the pitfalls beforehand. The industry has certainly done a good job of overhyping SOA and then almost as an afterthought, bothering to educate firms about governance and service re-usability issues within a SOA.

"Leading the charge for governance have been enterprise architects who know quite well that for SOA systems to deliver value, there must be control in areas ranging from how a service is built and the process of deployment, to granular
items such as schemas and WSDL creation," write Progress Software.

It reminds me of the Maturity Models that a number of vendors have published regarding SOA, which demonstrate the different levels of maturity of a SOA implementation, with most firms occupying the relatively immature stages striving to attain the peak level of maturity, which let's face it, is not going to happen overnight.