In-Depth

Five Rules for Development-time SOA Governance

In our rush to adopt new technologies, we sometimes forget old disciplines that supported rigorous software development. Here are five rules that can help IT reduce the risk of failed SOA initiatives.

• By Kelly A. Shaw
• 05/08/2007

In a previous article (see http://www.esj.com/news/article.aspx?EditorialsID=2149) I discussed why governance is necessary for the successful implementation of SOA-based application development. New technologies and techniques make developers a bit giddy. We tend to forget the lessons of the past and forget also, in our rush to adopt the new and the interesting, that our disciplines need to follow us forward as well.

While governance is necessary for all successful software development projects, not all governance is the same. You still need rigor and discipline, but what has worked in the past will need to be modified to account for the new way SOA-based software is developed. While most current thinking about SOA governance addresses running applications, effective governance should reach all the way back to project inception, move through the development phase, and continue into production. Most importantly and most often neglected, SOA governance must extend to the consumption side of SOA.

Leaving the run-time SOA governance discussion to others, I’ll concentrate on governance as it relates to the application lifecycle. I call this development-time SOA governance, which begins when the project management office (PMO) or other approving agency that gives the green light for a project and ends when the application is moved into production.

While development-time SOA governance is a rich and complex subject, I’ll highlight the five most vital rules you need to follow when moving to SOA-based application development. These rules will help you reduce the risk of failed SOA initiatives.

Rule #1: The requirements for SOA-based development projects should focus first and foremost on the delivered applications, not the services.

This may sound obvious, but it isn’t. Many failed SOA initiatives are the result of developers’ focus on deconstructing existing applications into component services with little or no business value. This scenario is so common that it has its own acronym: a bunch of services (ABOS). 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. They are much less ambiguous than text documents or reports from a requirements management system. Additionally, a visual model is a blueprint for application development; a document that focuses on the application rather than the services. Visual application models are your best defense against your SOA initiative degrading into ABOS.

The visual model is a perfect starting point for a developer to begin designing the application. The design process will essentially result in two buckets:

• the application orchestration, choreography, infrastructure, and GUIs that provide the structure for the application
• a list of Web services

This leads me to the next rule.

Rule #2: Services should be re-used, re-factored, used from a third party where appropriate and built new only as a last resort.

How do developers know the category into which their services fall? Obviously, they need to be able to search for existing services. A registry isn’t enough. What they 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 so developers can easily perform keyword searches, mock-up new services, propose interface changes and perform impact analysis.

The repository should also be integrated with your registry (if you use one) so new and updated services can be deployed to test and production environments, and so runtime information can be pulled from the registry back to the repository.

This metadata will help on the production side so developers know what to build. On the consumption side, developers know when services will become available. Between the two, QA will use the metadata to validate that the service delivered meets quality and functional expectations.

Speaking of quality…

Rule #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. If you have a successful reuse policy, a single bad service could cause a large number of applications to fail.

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. Third-party services are not exempt from this rule. If your vendor doesn’t provide you with unit tests, build them yourself before you put the service into production.

However, you should be wary of Web service unit tests alone. We’ve learned the hard way that unit tests don’t always cover the complete range of uses possible from a service. This leads to what is possibly the most important rule you can follow to mitigate risks to production applications.

Rule #4: Always perform consumption-side tests before deploying a service into production.

This may seem like a simple rule, but the corollaries are interesting. To perform comprehensive consumption-side tests, you need to perform an impact analysis to find out which applications consume the service. Therefore, you need application metadata including a bill of materials listing the assets needed by the application. In an ideal world application metadata would also include other data such as static and dynamic libraries, build instructions, outstanding defects and other data federated into what amounts to an application CMDB. Few ALM vendors support application metadata repositories, so you may need to repurpose your issue management system, your SCM system, or even use the standard fallback tool, a spreadsheet. What 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.

Rule #5: Separate your production deployments from your consumption deployments.

Separate rollout of the production and consumption sides of your application will reduce the overall complexity of your 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.

Summary

SOA-based development is complex, perhaps even chaotic. Every rollout is different, every deployment an adventure. I don’t pretend that following these rules will guarantee a successful SOA-based development project. However, these rules will help you reduce the risk of failure, giving you the breathing room necessary to get the rest of your SOA governance initiatives under control.

One final note: Always deploy your new and updated services before you deploy the consuming application. The other way won’t work.