Wednesday, November 28, 2012

Exploring Governance Process - part 2


Part two of the Exploring Governance post focuses on prototypical process steps. As noted in the previous post, this example relates to an enterprise-wide SOA governance initiative. Governance process can be applied to any number of areas or can be made available universally to all IT functions (e.g. Data, SOA, Security, SDLC/ALM). Each organization needs to determine for itself how lean or robust the process (and its steps) should be - those decisions will determine which steps (or variations thereof) listed below might be appropriate. 

  1. Submission – submission can involve "ideation" but usually is handled as requirements management. The goal is to make this as flexible and open-ended as possible in order to allow the process and the SARB to serve as a funnel for all the necessary information to build an enterprise roadmap for services across the enterprise. Given that this process will be occurring before any automation is in place and at the beginning of a SOA adoption initiative it is important to make sure that we provide paths for different types of information to come in. So there will be legacy capabilities without specific designs for formal requirements. There will be functional requirements without designs. There will be functional requirements with designs and there will be designs without functional requirements. All of this could be viewed as idea submission. Depending upon whether or not designs or requirements were included the governance process would obviously have to coordinate with related processes to make sure that the service submission met basic standards.

  1. Requirement Acknowledgement – this is a relatively straightforward step in that the SARB would simply be providing some sort of formal acknowledgement that an idea or requirement had entered the services governance process.

  1. Capability Allocation – capability allocation or classification is somewhat more complicated. This involves mapping requirements to a specific set of definitions for capability from the retail enterprise perspective. As noted previously this will require the prerequisite of some sort of preliminary capability inventory. This inventory will take the form of a taxonomy or ontology that can later be applied to a variety of process automation tools including ALM tools, project portfolio management tools as well as configuration management software (including SOA CM).

  1. 1st Level Analysis / Review – the first level analysis and review step involves coordination between review board members and designated technical staff to ensure that the idea or requirement submission meets basic technical standards. The deliverable provided by this step in the process would be a checklist indicating that those initial criteria have been met or not and based upon that a determination would be made whether or not the requirement satisfied the standards necessary to achieve first level approval. It is important to note here that the governance process is not the design process nor is it meant as a replacement for the application lifecycle management process. Governance is meant to provide technical and business oversight and to ensure that enterprise standardization is occurring.

  1. Requirement Logging – requirement logging is a fairly straightforward step in the process and that it merely represents annotations being made by the CM point of contact within the SOA COE wiki.

  1. Initial Approval – initial approval then merely represents that the requirement has been properly submitted and formatted and meets basic criteria for moving forward in the process.

  1. 2nd Level Analysis – second level analysis represents the most complex part of the overall process. This requires coordination through a small group or integrated product team including board members, technical staff and business stakeholders. This is not meant to be a complex engineering endeavor, but rather an examination to determine whether the well-defined service requirements provided from the previous steps in the process conflict or overlap with other requirements or other existing services. In this sense then we are dealing with enterprise or systems level reconciliation as opposed to validation of the service logic in its own context. This analysis involves technical review of service contracts, WSDL's and other service logic at the functional level. It also involves comparison of business logic, rules and functional expectations.

  1. Recommendation & Architecture Update – The result of the second level analysis is a consensus recommendation that is then properly documented by the SARB and included into the SOA architecture roadmap. It is likely then that the architecture board would support some sort of “to be” reference architecture which would include all of the recommendations that had been approved up to this stage.

  1. Handoff to ALM – any artifacts that reach SARB recommendation level would then be provided as roadmap updates to the ALM process. No actual work would occur on these until management approval was obtained.

  1. Deployment Preparation – the CM point of contact would then prepare the service information for final potential deployment. This would include any standardization for modification to WSDLs or service contracts.

  1. Final Approval - this step is provided to ensure that management retains control of the service release process and/or any follow-on work that may need to occur.
The PMO must govern a wide spectrum of IT processes and capability

Process Implementation Considerations
As noted previously, all the roles defined in this process may not necessarily be used. For example the CM role may represent a member of the SARB. This process provides a general guideline and the templates for future governance processes, but in order to test its efficacy within the enterprise environment we would need to demonstrate it utilizing actual requirements and working with the likely participants among the stakeholders. In order to engage in that sort of dry run activity, the prerequisites would also need to be in place.


Copyright 2012  - Technovation Talks, Semantech Inc

0 comments:

Post a Comment