Actions

Enterprise Architecture Governance

Enterprise Architecture Governance Definition[1]

Enterprise Architecture Governance (EAG) is a practice encompassing the fundamental aspects of managing a business. It involves firm leadership, a 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.


The Scope of Enterprise Architecture Governance (EAG)[2]

  • 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


The Scope of Enterprise Architecture Governance
source: Level 3


Components of Enterprise Architecture Governance[3]

There are three components of an 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 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[4]

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

EA Governance Model
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 point of contacts 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 situation demands.

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


Enterprise Architecture Governance Implementation[5]

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 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 particu-larly 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 non compliance IT standards with EA.
  • 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

Enterprise Architecture Enterprise Architecture Framework
Enterprise Architecture Management (EAM)
Enterprise Architecture Value Framework (EAVF)
Application Architecture
Business Architecture
Architected, Model-Driven Development (AMD)
Architected Rapid Application Development (ARAD)
Architectural Pattern
Architectural Principles
Risks in Architecture
Architectural Style
Architecture Description Language (ADL)
Architecture Development Method (ADM)
Architecture Driven Modernization
Architecture Tradeoff Analysis Method (ATAM)
IT Governance (Governance of Information Technology)
Corporate Governance
Governance
Governance, Risk And Compliance (GRC)


References

  1. Defining Enterprise Architecture Governance LeanIX
  2. What is The Scope of Enterprise Architecture Governance (EAG)? Nathaniel Palmer
  3. Components of Enterprise Architecture Governance cio.com
  4. The Balanced EA Governance Model Sumeet Goenka
  5. Enterprise Architecture Governance Implementation Tyson Brooks


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