SOA Service Lifecycle Governance Process
The SOA / Integration Service Lifecycle Governance Process is fundamental and of the critical importance to the Enterprise SOA success. Without implementing this process in a mature and scalable manner, SOA will most likely end up being just another “one-off-soon-to-be-forgotten-project” or “just-a-bunch-of-web-services” (JABOWS). It is important to remember that the end goal of implementing SOA in any Enterprise is not about creating a SOA Platform infrastructure, or even being able to integrate a couple of systems. Rather, it is to implement a single unified, consistent, flexible and federated business meaningful SOA API that exposes key Master and Reference data sets (MDM), as well as enables key operational processes. SOA API that enables Enterprise to do integration in a quick, fast, low cost and consistent manner by utilizing existing services. The SOA API implementation is only possible in iterative manner with a multi-year vision and portfolio of agile projects focused on API enablement while applying consistent best practices in modeling, design and implementation across them. Contrary to the faulty idea in some minds – implementing SOA is not a “one off project” and not even a project at all!
While some might think that there a rocket science to SOA Governance, in reality this process is no different for SOA Service than for creating a car or any other product. All products – whether software or material based – go through a series of lifecycle stages: from idea (or request), to funding and planning, design and implementation, release and utilization and later to be decommissioned. What is different across various products is the artifacts that are being created during those phases.
The SOA Service Lifecycle Governance Process can be described in 5 phases:
Integration / SOA Lifecycle Governance Process
Link to other IT or Business Governance
Before we dive into details of various phases, I will try to answer a couple of questions that are probably on people’s mind:
- What about Software Development (SD) Process?
- How does it fit into larger IT Governance?
- How does fit into business compliance, like SoX, GXP etc..?
The SOA Service Lifecycle Governance Process is not replacing any of those. The SOA Service Lifecycle Governance Process is relying on those and is a part of a larger IT Governance. The IT Governance and Business Compliance ensure Enterprise Technical Standard Compliance as well as Regulatory Compliance and SOA Service Lifecycle Governance is relying on those to define core technical standards that will be used during SOA service creation and utilization as well as to identify business internal or external regulatory laws required for all software components. Software Governance Process is a more low level process that is focused software component development part of lifecycle during Phase 1 through to the Phase 3 to ensure governance is applied by various roles during service development.
SOA Lifecycle Tollgates
Instead, SOA Service Lifecycle Governance Process is focused on taking SOA Service through key lifecycle tollgates:
- ensures validity of the SOA service (integration) request and need for a new service. Alternatively it simply points to reuse an existing, submit service CR or do something else
- alignment with SOA API roadmap and across multiple initiatives
- ensures analysis and SOA service design guidelines consistency and SOA Standards and Guidelines alignment
- ensure appropriate funding during various phases
SOA Governance Board
It is impossible to implement SOA governance process without having a core centralized SOA Capability supported and sponsored by IT leadership. Typically, there is an idea of a core SOA Governance board being tasked with ensuring that SOA Service Lifecycle Governance is applied for all projects that deliver into or taking advantage of SOA API. Very often this groups consist of the SOA Capability Lead (board chair) as well as Sr. SOA Architects (canonical and technical design authority) and Sr. Business Architects (domain knowledge). Nearly always business stakeholders (information owners and SOA API sponsors) and IT consumer requestors (stakeholders) are present during tollgate reviews as well – after all, SOA is about delivery of the business meaningful API and should be aligned with large business facing IT portfolio that serve as consumers or API enablers!
Key tollgate artifacts
To achieve consistency and ensure quick and agile manner, there is a list of artifacts agreed to be required for each review tollgate (see key SOA Standards and Guidelines). It is very typical to have a single artifact to capture important key review points for each tollgates:
- TG1 – Service request and business requirements (Integration / SOA Service Request)
- TG2 – Service analysis and canonical design (Integration / Service Design Proposal) and technical implementation design (Technical Architecture Document)
- TG3 – Service release and support checklist
- TG4 – Test report
- TG5 – Service utilization report, Consumer On-boarding Requests, Change Requests
During each of the phases, the best fit Software Development process is chosen and is being used with appropriate documentation delivered as required per process. but those review documents can be easily assembled by extracting key information and artifacts and aggregating them into required tollgate documentation.
From those documents listed above, TG2 and Integration Service Design Proposal document is one of the most importance as it serves as a consumer interface contract and is later being used to produce technical contract artifacts such as WSDL and XSD documents.
Categories: SOA Governance, SOA Strategy
The Enterprise Architecture 
Leave a comment