Practical experience of service-oriented design and development is driving one critical requirement to the top of the agenda: the need for strong governance over developers.

	express delivery
	• print  • comment
	Making sure that developers adhere to corporate policies in an SOA requires imaginative compliance and incentive systems: Poor governance undermines the intended benefits of SOA Enterprises must monitor, audit and enforce compliance with established policies Individual projects may be tempted to ignore enterprise-wide policies Governance strategies must aim to neutralize such conflicts Emerging tools for governance offer a range of capabilities
	Glossary terms: governance, SOA, development, runtime, UDDI, lookup tool Sponsored links: your text link here

Development organizations have found they must evolve new compliance and incentive systems to ensure their SOAs are built on stable foundations. Without governance, unfettered ad-hoc development of services threatens to undermine the promised benefits of SOA, such as improved productivity through service reuse and better alignment with the business. Instead, SOA initiatives may lead organizations in a backwards direction, pouring development dollars into a black hole.

Motti Vaknin, founder and CEO of WebLayers, a Cambridge, MA-based vendor of SOA governance tools, gives the example of one telecoms company where the vendor was invited to audit the planning and execution of a B2B integration strategy. "What we found over there was the gap between top management [intentions] and the deployment in the field was so great that it caused the company to lose millions of dollars through late delivery and development that was outside the stated requirements."

In addition, when the company needed to modify those developments, it couldn‘t because implementation had not been carried out as the overall architecture required it should be — resulting in, for example, missing documentation or non-standard design.

This isn’t a one-off example. A similar story would probably emerge at any Fortune 500 company or government agency today, if they took the time to investigate. Most don’t — and so only become aware of the problem when they embark upon some overarching integration project or similar enterprise initiative.

Compliance gap

The move to SOA is set to hike the issue of developer governance up the agenda, according to research that BEA and InfoWorld carried out early this year. Of almost 700 companies surveyed, 27% were already adopting SOA, and nearly a third of these implementations ranged across different divisions. The research found that the top two resources these companies required were implementation models and reference architectures — effectively an admission that most were moving ahead without a clearly defined roadmap. In response, application server vendor BEA has put together a consulting service, based on bespoke work already carried out, designed to help organizations get started on SOA in the context of an enterprise strategy for three years down the line.

There’s little use in having an enterprise strategy, though, unless developers adhere to the policies and practices it sets out. Early adopters of SOA have discovered the importance of monitoring, auditing and enforcing compliance with established policies, and are testing out a variety of mechanisms for increasing the willingness of developers to fall into line with centrally agreed SOA policies.

If the early experience of vendors and their users is anything to go by, it is the tension between the project and enterprise view that will be one of the greatest faultlines exposed in the move to SOA. If an SOA is going to deliver enterprise-wide reuse and interoperability, then individual projects and business units must accommodate the needs of the enterprise architecture. This can open up a can of worms in the corporate culture, with clashes of interest flaring up.

The tools to help enforce these policies in an XML and web services world are only just emerging — and there is still some disagreement about how far they should go: governance can cover any number of bases from compliance at a development stage, through control from an access perspective right down to deployment. Some early adopters of UDDI have attempted to take on this whole lifecycle. Others prefer to focus on the design and development phase, leaving the runtime binding and oversight to management vendors.

This is an abridged extract from a four-page feature article published in the May 2005 Loosely Coupled monthly digest. To read more about the developer governance challenges faced by early adopters of SOA and the strategies they adopt, subscribe here today.

More on this topic