In an earlier blog I discussed the need for SOA Governance. Effective SOA Governance provides enterprises with visibility into, and oversight of, the relationships and inter-dependencies that connect services to other elements of the SOA across the enterprise. It encompasses people, process, and technology to effectively manage and optimize your organization’s investment in SOA and improve decision-making.
Let us get the obligatory SOA Governance definition of of the way
An agile and efficient decision and accountability framework to effectively direct and assist in realizing the benefits of SOA, while encouraging a cultural evolution in how an organization delivers SOA to the enterprise
There can be no single model of SOA Governance because each enterprise has differences and nuances. Enterprises have existing IT organization structures in place; their geographical footprint, size of organization, and level of SOA maturity can differ; and they have their own working culture and political considerations. The model may also be affected by differences in existing IT and EA governance regimes.
An enterprise needs to answer a number of questions to define their SOA governance model.
- What Decisions Need to be Made for YOUR Organization to have Effective SOA Governance?
- Who Should Make these SOA Governance Decisions?
- How will these SOA Governance Decisions be Made and Monitored?
- What Structures, Processes, Communication, and Tools should be Deployed?
As I have stated earlier, it is not possible to have a single model of good SOA Governance, but having a SOA Governance Reference Model assists enterprises in expediting the construction of their own SOA Governance model, and captures best practices and patterns as a basis for a common approach. In effect a SOA Governance model must:
- Enable the Definition of Policies and Processes to Guide Management into making Effective SOA Decisions
- Define Structures which Enable the Policies and Processes.
- Enable Management of all SOA assets not just Services
- Aid in Minimizing or Avoiding Potential Conflicts of Interest and in Making Decisions that are fair to all parties
- Enable Collaboration from Stakeholders to adhere to processes and Authority Structures
- Enable Authorized Groups to Encourage/Enforce Alignment to SOA Architecture and Cultural Orientation
SOA Governance Reference Model
So what aspects need to be considered as part of your overall SOA Governance model? I have seen too many enterprises focus purely on governing the service lifecycle, this is a very narrow viewpoint of SOA Governance. But SOA Governance has to focus not only on the development aspects of SOA, but also on the strategic requirements. In addition, SOA Governance has to make sure that any investments made into SOA assets continue to
add value.
The SOA Governance Reference Model can be categorized into five inter-related groups:
- SOA Portfolio Governance
- Service Lifecycle Governance
- SOA Organization Governance
- Solution Lifecycle Governance
- SOA Vitality Governance
At a high-level lets tackle each of these categories
SOA Portfolio Governance
A key area for SOA Governance is in the area of SOA Portfolio Management, which manages SOA projects, SOA assets, and associated metadata in a holistic manner and is a key enabler for Service identification. While enterprises not accustomed to managing portfolios today might feel this area of SOA Governance is an overhead or as a barrier to entry for SOA this can be addressed by scoping the portfolio within the boundaries of the SOA initiative.
It is critical that SOA Governance monitors and regulates all of the areas and phases of SOA Portfolio Management:
- Identification and Categorization
- Evaluation and Approval
- Prioritization and Roadmap
- Funding and Charge-backs
- Sourcing and Ownership
SOA Governance policies within this area are not only key within the identification/justification and approval of Services/ SOA projects but also making sure the taxonomy and classification of Services are inline with agreed policies and standards. It is common to see roles such as Service librarians and SOA portfolio owners to assist with the process in combination with a technology solution.
Without SOA Governance policies within this area it is common to see Service sprawl whereby duplicate Services exist and/or Services existing in production that are not being utilized. These challenges can be caused by Services being identified that are not in alignment with business requirements and duplicate Services created across different business units.
Service Lifecycle Governance
An area that tends to get the lion’s share of focus is Service lifecycle governance. It is imperative that both the design-time and run-time aspect of a Service is governed as each is equally important. Example goals of Service lifecycle governance are:
- Services are delivered that align and support the defined business and IT objectives.
- Services are delivered in a consistent manner that comply with the defined polices, standards, and guidelines to promote interoperability, re-use, and agility.
- Services meet security requirements such as access control and encryption.
- Services are published and classified against an agreed taxonomy to promote a standardized discovery process which promotes service visibility and reuse.
- Multiple versions of Services are managed in a standardized manner.
One key aspect that needs to be in place before Service lifecycle governance can be deployed is defining and documenting the states which a Service can go through. The Service lifecycle tracks the Service from inception through retirement, and includes the evolution of the Service through multiple Service versions.
Solution Lifecycle Governance
While much focus is given to the governance of the Service lifecycle it is also advantageous to govern the delivery of solutions that utilize Services. Example goals of solution lifecycle governance are:
- Solutions are identified that align with the business and SOA objectives before being given funding.
- Solutions are delivered in-line with the approved SOA reference architecture.
- Solutions are reviewed for asset harvest opportunities.
- Governance of asset consumption whereby solutions are monitored for appropriate Service reuse.
Applying governance across the SOA solution lifecycle requires defining and updating the enterprise organizational structures and processes. An example is defining a SOA project approval process that assists enterprises in evaluating the appropriateness and alignment of a project with the agreed SOA roadmap. This process tends to supplement the existing project investment process. Another example is complementing an existing software development lifecycle process by adding formal design and architecture evaluation reviews at key inspection points. This ensures projects are aligned with the agreed policies such as adherence to established architectural criteria and business objectives. For each of these processes, it is necessary to understand the participation required of any of the governance organizations and the nature of that participation.
SOA Vitality Governance
SOA can be seen as a journey where enterprises are required to plan strategically and act tactically. Therefore, it is imperative that any SOA investments made by an enterprise are routinely reviewed, and remain current, accurate, and most importantly, relevant. In essence, an enterprise should view their SOA investments as living assets and execute a continuous improvement feedback loop to maintain their value and relevance.
A continuous improvement program should be initiated that routinely reviews SOA Assets. Example of SOA assets that should be routinely reviewed are:
- SOA Strategy and Roadmap
- SOA Reference Architecture
- Standards and Best Practices
- Processes such as service engineering, service identification, etc.
- SOA Metrics and Scorecards
- SOA Organizational Structure
- Services
The continuous improvement program can be activated for various events. Example of these events include:
- Strategic Change – Assets should be reviewed in the event of a strategic business, IT, or SOA change. For example, a change in the business strategy of the enterprise (maybe via an M&A) may change the intent and focus of the current SOA initiative. Therefore, the SOA strategy and associated SOA roadmap should reviewed to make sure it is still relevant or the appropriate updates are made.
- Operational Exception – Assets should be reviewed when a number of duplicate operational exception events occur. For example, maybe there are a number of projects that do not align with the SOA Reference Architecture. Rather then having an enforcement approach, look at the root-cause of the exception. The cause could be the result of some new best practices, updated SOA Reference Architecture design patterns, etc. If required, the appropriate SOA assets should be reviewed and updated accordingly with the new/updated patterns.
- Technology Revision – Assets should be reviewed when a technology revision event may require SOA assets to be updated. For example, new SOA security standards may have been released by OASIS and are available in the new version of the service bus. Therefore, the SOA Reference Architecture and SOA infrastructure should be reviewed and updated accordingly.
- Periodic – Assets should be reviewed on a periodic basis if no other event has forced a review. Different periodic review timings should be allocated to the different classes of SOA assets.
SOA Organization Governance
The most challenging and misunderstood aspect of SOA is the effect and requirements it has on the enterprise and its employees. SOA Governance requires the establishment of a viable and pragmatic organizational and change management model. Governance can be seen as an impediment by certain stakeholders; therefore, tools must be utilized to ease and automate as many processes and policies as possible. Examples of these tools include registries, repositories, policy management systems, policy compliance testing systems, policy enforcement systems, and testing/diagnostic systems. Even though automating the SOA Governance processes minimizes the opportunities that stakeholders can circumvent it, there are still a number of human decisions that need to be made.
I think that will do. Governance can be heavy topic and one not willingly digested. In the next couple of blogs I think I will cover some example governance structures, change management techniques and an approach to continuous improvement of a SOA Governance program.
Good Luck, Now Go Architect Govern..
An Enterprise Architect's Musings 