Five Rules for Design-time Governance

SOA in Action Blog

« The SOA-Virtualization Connection: Is This a Good Thing? | Main | Technology Won't Clear SOA Bottlenecks; Here's What Will »

May 13, 2007

Five Rules for Design-time Governance

Last fall, ebizQ put together a very comprehensive survey of SOA governance policies at 313 companies last fall, which found that those sites that have runtime and design-time automation are far more likely to report high levels of comfort with their governance solution than those who rely on manual enforcement. ZDNet colleague Beth Gold-Bernstein emphasized that the most value is gained during the development-time process for SOA services. (The Webinar is archived here.)

In this new post over at Enterprise Systems, Kelly Shaw has put together five additional pointers for effective development-time governance:

1) Focus first and foremost on the delivered applications, not the services. "Many failed SOA initiatives are the result of developers’ focus on deconstructing existing applications into component services with little or no business value... Instead, developers must work closely with end-user representatives or business analysts who have a business perspective about what capabilities the application must provide.... Visual models work best. They provide a common frame of reference understood both by the business analyst and the development organization."

2) Services should built new only as a last resort. Developers "need is a metadata repository that includes interface definitions, data definitions, SLAs, security requirements, known defects, application lifecycle information, and historical information from the runtime such as performance data." This repository should be integrated with the IDE and registry.

3) Services need to be delivered with a comprehensive set of unit tests. "You can’t afford to have poor quality services in production. Similarly, updating a service that is already in production is a risky proposition... You can mitigate the risks associated with updating production services by requiring that all services be delivered with a comprehensive set of unit tests that can be run to validate the quality and correctness of the service."

4) Always perform consumption-side tests before deploying a service into production. "...you shouldn’t do is skip this step or you won’t be able to perform a reliable impact analysis, and your risk of production failure will dramatically increase."

5) Separate your production deployments from your consumption deployments. "You can get your updated service into production, resolving any problems without the added complexity of a new application release. If something does go wrong, you know where the problem is and can revert to the previous service version without fuss."

Posted by joemckendrick in SOA | Digg This | Add to del.icio.us