SOA Governance Best Practices – Architectural, Organizational, and SDLC Implications
Taking the management of services to the next level
Jan. 29, 2006 10:00 AM
How do we achieve these high standards for our services under development? By establishing standardized governance/review checkpoints throughout the service SDLC. We recommend that at a minimum, organizations should review services under development at these points in the SDLC:
- Requirements Complete: All business requirements documented and initial service definition specified (ideally as WSDL), allowing reviewers to validate the service against its business architectural context
- Design Complete: Implementation approach defined with sufficient documentation (e.g., UML design models completed, relevant legacy APIs identified) to allow reviewers to validate design against technical and application/integration architectural contexts
- Implementation Complete: Service implemented and deployed in a test environment, with sufficient supporting documentation (e.g., sample client code, automated/manual test cases and test results, usage guide) to enable a potential consumer to understand the service and to trust its quality and stability
Other review points may also be appropriate based on organizational needs and objectives. However, don't overwhelm your development teams with process for the sake of process: you will quickly instill a revolt of the masses if you force seemingly arbitrary hoops for developers to jump through in the process of completing their work. Your objective should be "just enough process" - don't overwhelm your project teams with unnecessary workload, but rather provide enough guidance at key points in the production and consumption life cycles to make sure things stay on track. You are very likely going to have to iteratively reach the right level of process for your organization - start with as lightweight a process as you think will work, and then add process steps only as you find need for them. A well-designed services registry/repository can assist in automating these governance processes, thereby reducing the "organizational friction" that could otherwise hinder people from "doing the right thing."
Production Best Practice: Versioned Services Governance
Because services (like components) are meant to be used in more than one application, organizations need to plan for the incremental enhancement of their services over a long deployment lifetime. In effect, organizations planning to build a robust, stable, and extensible SOA need to treat their services as "products."
What does treating a service as a "product" mean to our IT organization?
1. Each produced service must have a regular and well-defined release cycle. This release cycle needs to occur often enough to meet consumer needs on a timely basis, but not so often as to churn existing consumers. Typically a release cycle of somewhere between three and six months is appropriate for most organizations, and allows them to meet new service needs without unduly disrupting existing applications. As multiple versions of a service are released, consider defining these life-cycle states for your services:
- Under Development: Available for requirements gathering and application development team planning purposes
- Production: Mainline version for use in new development
- Retired: Still in use by existing applications but not allowed for use by new apps
- Obsolete: All applications should be migrated off this version; version metadata is maintained for traceability/audit purposes only
2. Services must preserve backward compatibility wherever possible. Deprecation techniques (where obsolete operations are identified as such and notice is given to consumers that those operations will be removed from service interfaces in future releases) give existing consumers time to migrate to newer service releases. Service providers should provide n-1 version support at a minimum - all services provided in the prior version (except those marked as deprecated) should be preserved intact in the current version. In addition, consider providing a "grace period" where both service versions are deployed to allow consumers to make any necessary changes to integrate the new service version. Dynamic run-time binding techniques via Web services management infrastructure (e.g., service proxies or UDDI-based late binding) can also simplify the migration process from old to new service version.
3. Mechanisms for gathering requirements from current and potential "customers" need to be established by the enterprise architecture and service review teams. Consider establishing a "product manager" role within these organizations, one that manages the aggregate set of business requirements for the service and works to prioritize requirements with its current and potential consumers.
Again, a well-designed services repository/registry can help organizations manage service versions over their lifetimes, with automated notifications, embedded discussion forums for requirements gathering and analysis, and filter-based search capabilities that expose services to potential consumers based on service state (e.g., new application project developers should not be able to search for "Retired" or "Obsolete" services).
Distribution Best Practice: Service Distribution via Services Repository/Registry
Now that we have a set of broadly reusable services produced through our application of the aforementioned best practices, how are we going to get them into the hands of our application developers? This takes us back to the discoverability and consumability aspects of services production. Simply put, unless your services are all as simple as the ubiquitous Stock Quote example so often used in articles discussing Web services, WSDL is not enough. Syntactic definition does not equate to semantic understanding. Potential service consumers need ready access to supporting artifacts (e.g., usage guide, sample client code) to make the service consumable to them. The service also needs to be discoverable - wrapping the service with metadata that allows the user to search for useful services using varying techniques and user interfaces. \A well-designed services repository/registry goes a long way to helping IT organizations to efficiently deliver services to potential consumers. At a minimum, such a repository/registry should support both browser-based access and deep IDE integration to enable users with varying roles to discover the right services. For example, a business architect will likely feel most comfortable using domain terminology searches within a browser, while a designer or developer would prefer a UML-based visual search mechanism within their preferred IDE.
Consumption Best Practice: Service Usage Registration and Traceability by Application Development Projects
The third leg of the SOA governance stool - consumption - comes into play as we begin to build, deploy, and maintain applications based on our previously produced and distributed services. Application-based tracking of service consumption is essential for a number of reasons: to support internally defined and externally imposed business governance mandates, to simplify the process of ongoing impact analysis and change management as the SOA matures, and to provide a quantitative ROI based on real service usage statistics back to the C-level within the enterprise.
Let's take a quick look at governance mandates. Business-level governance (through the form of government regulations such as HIPAA, SOX, and Basel III) is increasingly making its way down to IT. As a result, increasing numbers of auditability and traceability requirements are being applied to the IT organization, and these requirements cannot be met without some form of service usage registration mechanism (and again, for IT organizations of any size, this registration mechanism needs to be automated through the services repository/registry).
Remember also that our services will change over time as new requirements are identified (as discussed above in the "Production Best Practice: Versioned Services Governance" section). Existing application teams need to be kept abreast of planned and implemented changes to the services they are using, both to participate in requirements feedback and to prepare for the eventual obsolescence of back-level services as new service versions are deployed.
Finally, since enterprises are not in business to serve IT but rather it's the other way around, our organization's C-level executives are certainly going to expect a quantifiable ROI from any SOA initiative. Without direct traceability over service usage, it becomes arduous at best and impossible at worst to assemble such a quantifiable ROI based on service use and reuse. On the other hand, if usage registration is built right into the services repository/registry, quantifiable ROI is as simple as running a periodic report.
Don't think managing your services operationally is enough. Just because you can keep tabs on a service's execution doesn't ensure that the service is really supporting the overall business goals of the SOA. Traceability back to the business goals/priorities through EA to SDLC to operations will make SOA successful in the enterprise. Also, don't minimize organizational impacts that may be needed - monolithic, project-centric funding models are not likely to work in the loosely coupled world of SOA.