Enterprise Architecture Governance

What is Enterprise Architecture Governance?

Enterprise Architecture Governance (EAG) is a practice encompassing the fundamental aspects of managing a business. It involves firm leadership, complete knowledge of organizational structure, a confident direction, and the enablement of effective IT processes to promote an enterprise’s strategies. The objective of EA Governance is to harmonize the architectural requirements of an enterprise into an understandable set of policies, processes, procedures, and standards—all of which to ensure an organization’s visions and standards are aligned with actual business requirements.

Enterprise architecture governance is defined by the US Bureau of Census as “a critical component of enterprise architecture which provides for continuous improvement, migration, and measurement of business systems so that business and technology coalesce to meet the mission of the enterprise.” Other authors see architecture as a mechanism for governance of the complexity of digital organizations with a focus on business-IT alignment. Common to these two views is the importance of aligning business and technology in a dynamic environment. A key difference is that one view defines governance as a component of enterprise architecture and the other recognizes that enterprise architecture in turn is a tool for enterprise governance. Apparently, two different aspects of enterprise architecture have to be recognized: how it contributes to governance, and how it is governed in itself.

The Scope of Enterprise Architecture Governance (EAG)

• Corporate Strategy: defines what the company will be and how it will compete
• Product Strategy: defines what the company sells and how it sells it
• Functional Strategies: define how to operate the company,
• IT Tactical Plans & Execution: Implementation processes and tracking mechanisms

source: Level 3

Components of Enterprise Architecture Governance

There are three components of effective EA Governance. The first two are commonly recognized as being part of "EA", while the third is an EA function in a strategic sense but is not solely owned and executed by traditional EA teams.

• An Architecture Review Process: This process establishes periodic reviews of solutions at various points in the technology delivery lifecycle and proposes changes to the body of architecture standards. It is tactically focused; with the objective of ensuring conformance to strategy and standards, identifying exceptions, and documenting issues with enterprise impacts. Most mature architecture organizations have some form of architecture review, however, some overlook a fundamental benefit - review provides a chance to educate and seek consensus.
• A Standards Management Process: The Standards Management Process establishes change control over architecture standards. It defines how an organization tracks deficiencies and gaps in its body of enterprise standards and methodically works toward improvement. While the Architecture Review Process is about the review of solutions and changes in the standards; the Standards Management Process is about controlling the change process and communicating the impacts. A good standards management process -
  • Identifies and documents enterprise standards that need or present an opportunity for improvement.
  • Assigns accountability and responsibility for improving the standards.
  • Takes input from and proposes changes to technology and business components of an Enterprise Roadmap.
  • Measures and reports against changes to determine effectiveness.
• A Roadmap Management Process: A final element of effective EA Governance is managing change against the Enterprise Roadmap. This is considered an EA process even though it is not entirely owned and executed by the EA group (depending on the organization's definition of EA.) In many IT shops, management against strategic assets such as a roadmap is the function of a business strategy and planning group. This team is, in a broad sense, part of the organization's EA function, whether so named or not. An effective roadmap management process has several elements. First, a clear definition of what the roadmap is and is not is essential; creating this definition can be tough. Is the roadmap a PowerPoint presentation? Is it the underlying data about the proposed investments and technology landscape? Is it statements about strategy and desired outcomes made in other communications? Once the contents of the roadmap have been defined, components that will be controlled, Rules about how changes are made, and who approves them must be clearly documented. The Roadmap Management Process helps set expectations, promoting continued business and IT partnership through transparency. Without it, the benefits of the roadmap quickly vanish as uncontrolled changes make the roadmap irrelevant and governance impossible.

The Balanced EA Governance Model

There are multiple EA governance models possible, as per the level of architecture maturity and corporate structures across organizations, as well as any major change transformation planned. A typical and rightly balanced model for centralized environments, where IT projects are managed and delivered centrally, looks like this:

source: Sumeet Goenka

• The Domain Design Authorities (DDAs), in this model, are “business domain aligned”, for ex. Retail Operations, CRM & eCommerce, Supply Chain & Logistics, etc., and are led by EA Domain Architects. The DDAs provide a point of contact for project teams (vendor-run or internal) to ensure compliance with architecture standards and the overall EA direction, along with ensuring the quality of solutions being delivered.
• The Enterprise Design Authority (EDA) is responsible for setting corporate-level architecture vision and direction, along with setting best practices, processes, guiding principles, standards, reference architectures, and other architecture guardrails. The EDA is led by the Chief Architect and is primarily overseen by the Chief Information Officer (CIO), with occasional oversight by other CXOs (COO, CFO, CEO) as the situation demands.

The EDA and DDAs should consist of representatives from IT and business both. Once a detailed EA governance process is formalized, it should be properly communicated to relevant stakeholders to ensure a common understanding and smooth execution.

Enterprise Architecture Governance Implementation

Implementation of any EA governance process will require several steps.

• First, the EA governance framework must be reviewed and approved by the organizational entities and stakeholders who are involved in or are impacted by the EA program. Even though this is a lengthy process, a consensus must be reached before proceeding any further. *Second, as the EA program matures, selected EA governance procedures that will describe “how-to” details of the EA governance will need to be developed. The following EA governance procedures are particularly critical:
  • Introduction of a new standard or standard update.
  • Prioritization process and criteria for inclusion of IT projects in the Transition Plan.
  • IT project impact analysis.
  • Alignment of IT projects with EA at SDLC milestones.
  • Waiver requests for noncompliance with IT standards with Enterprise Architecture.
• Third, an EA governance implementation plan should be written that will expand on the EA governance framework and provide a schedule for implementing additional items not included in the framework. The implementation of the EA governance process within an organization will be the responsibility of the EA program manager or chief architect. The first step in implementing the EA governance process will be reviewing, fine-tuning, and approving the EA governance framework. Once the framework has been finalized and approved, the supporting EA governance procedures will need to be developed and communicated to all parties involved.

See Also

• Architecture Review Board (ARB)

Further Reading

• Enterprise architecture governance: the need for a business-to-IT approach Robert Winter, Joachim Schelp
• Framing a Collaborative Enterprise Architecture Governance Program within the Context of Service-Oriented Software Systems Development Mark McClure
• Enterprise Architecture Governance Procedures epa.gov
• Enterprise Architecture Governance: A Framework Approach Tyson Brooks