Recommended Service SDLC Governance Checkpoints
After defining our first set of services we need to build and deliver. Developing services in REST (i.e., for purposes of reuse across multiple applications) usually requires more of the production team than a single-use component, module, or object. For example, a reusable service is maintainable, discoverable, and consumable.
Maintainability introduces such concepts as version control, models, and other design documentation. In addition, maintainability involves requirements traceability (why was the asset implemented in a certain way from a technical and business perspective).
Discoverability forces us to consider how we help potential consumers of the asset find the asset.
Consumability involves looking at the asset from a downstream project planning point of view to determine how to use the asset. For instance, is there a user guide, a well-documented API, sample code, and other artifacts available to help a user rapidly understand how to apply the asset? Further, are dependencies on other assets (and to prior versions of the asset) specified and easily navigated?
We achieve high standards for our services under development by establishing standardized governance/review checkpoints throughout the service SDLC. Taliferro IT Consulting recommends at a minimum, organizations should review services under development upon reaching the following points in the SDLC:
- Requirements Complete: All business requirements documented and initial service definition specified (ideally as WADL) to allow reviewers to validate the service against its business architectural context
- Design Complete: Implementation approach defined with sufficient documentation (e.g., design models, relevant legacy APIs identified) to allow reviewers to validate design against technical, application and/or integration architectural contexts
- Implementation Complete: Service implemented and deployed in a test environment with sufficient supporting documentation (e.g., sample code, test cases and results, usage guide) to enable a potential consumer to understand the service and to trust its quality and stability
Other review points are necessary based on organizational needs and objectives. However, refrain from overwhelming your development teams with process for the sake of process. Otherwise, you will quickly instill a revolt of the masses by forcing seemingly arbitrary hoops for developers to jump through in the process of completing their work.
Management’s objective should be to instill “just enough process” – not an unnecessary workload. Provide enough guidance at key points in the production and consumption life cycles to make sure things stay on track. Using the approach described, you will very likely reach the right level of process for your organization.
Begin with as lightweight a process as you think will work, and then add process steps as needed. Ultimately, a well-designed services registry/repository can assist in automating governance processes. The result is a reduction in “organizational friction” that often hinders all involved from “doing the right thing.”