EA Governance

Anand Nerurkar
Nov 1
33 min read

1. Understanding EA Governance

EA Governance ensures that architectural decisions are aligned with business strategy, technology standards, risk management, and compliance requirements. Its goals:

Align business and IT strategy
Standardize architecture principles, standards, and policies
Approve/review projects for architectural compliance
Manage technology risk and ensure innovation adoption

Frameworks and tools commonly used:

Frameworks: TOGAF ADM, COBIT, Zachman Framework
Tools: Orbus iServer, BiZZdesign, LeanIX, Avolution ABACUS, ServiceNow (for EA workflows & approvals)

2. Step-by-Step Approach to Set Up EA Governance

Step 1: Assess Current State

Inputs:

Existing IT and business architecture artifacts
Current governance processes (if any)
Current technology landscape
Regulatory/compliance requirements

Activities:

Conduct EA maturity assessment
Identify gaps in architecture processes and governance
Understand decision-making bottlenecks

Outputs:

EA Governance baseline report
Recommendations for governance model (Centralized vs Federated)

Tools: Surveys, interviews, EA tools for artifact mapping, TOGAF EA maturity assessment templates

Step 2: Define Governance Model

Decide between Centralized or Federated governance based on:
- Size of the organization
- Complexity of business units
- Level of autonomy required by business units
- Regulatory compliance requirements

Centralized Governance: Single EA team controls standards and decisions.Federated Governance: Shared governance between central EA and business unit architects.

Inputs: Assessment report, business priorities, regulatory requirementsActivities: Workshop with senior management to finalize modelOutputs: Selected governance model, draft RACI, scope of central vs business unit EA responsibilities

Step 3: Define EA Governance Bodies

1. Centralized EA Governance Bodies:

Governance Body	Responsibilities	RACI
EA Steering Committee	Approve architecture principles, ensure alignment with strategy	R: CTO/Head IT, A: EA Lead, C: Business Unit Heads, I: Project Managers
Architecture Review Board (ARB)	Review & approve project architecture	R: EA Lead/ARB Chair, A: Steering Committee, C: Project Architects, I: Developers
Technology Standards Committee	Evaluate & approve technology stack	R: CTO/Tech Lead, A: EA Lead, C: SMEs, I: IT Ops
EA Working Group	Maintain EA artifacts, perform compliance reviews	R: EA Analysts, A: EA Lead, C: Project Architects, I: Business Analysts

2. Federated EA Governance Bodies:

Governance Body	Responsibilities	RACI
Central EA Office (EA CoE)	Define enterprise standards, policy, architecture frameworks	R: EA Lead, A: CTO, C: Business Unit Architects, I: Project Teams
Business Unit EA Committees	Apply central standards, review unit-level projects	R: BU Architects, A: BU Head, C: Central EA, I: Project Teams
Project ARB (Unit Level)	Approve solution design within unit	R: BU Architects, A: BU Head, C: Central EA, I: Dev Teams
Technology Council	Recommend tech selection, compliance checks	R: BU Tech Lead, A: Central EA, C: SMEs, I: Project Teams

Step 4: Define EA Processes

Core Processes:

Architecture Principles & Standards Management
- Input: Business strategy, compliance mandates
- Activity: Define principles, policies, and standards
- Output: EA Principles Document, Technology Standards Catalog
Architecture Review & Approval (Project Intake)
- Input: Project charter, high-level design
- Activity: Conduct Architecture Review Board meetings
- Output: Approval/rejection/feedback, EA compliance report
Technology Evaluation & Selection
- Input: Tech proposals, vendor evaluation
- Activity: Conduct POC, assess against EA standards
- Output: Approved technology stack
EA Artifact Management
- Input: Project designs, integration diagrams
- Activity: Document architectures in EA repository
- Output: EA repository updated with current state and target architectures
EA KPIs & Metrics
- Example KPIs:
  - % Projects compliant with EA standards
  - % Reuse of standard components
  - Time to approve project architecture
  - Number of technology deviations approved

Step 5: Set Up EA Organization Structure

1. Centralized EA Structure:

                     CTO
                      |
               EA Lead / Chief Architect
                      |
    -----------------------------------------
    |             |             |           |
 Business EA    Solution EA   Technology EA Governance & Standards
  Architects    Architects       Architects      Analysts

2. Federated EA Structure:

                     CTO
                      |
             Central EA Lead / Chief Architect
                      |
    ------------------------------------------
    |              |               |        
 EA CoE       Standards & Tech   Enterprise Architects
 (Central)    Governance          (Business Units)
                      |
    ------------------------------------------------
    |          |          |           |
 BU1 EA    BU2 EA    BU3 EA     BU4 EA
 (Projects) (Projects) (Projects) (Projects)

Step 6: Implement Tools & Repository

Tools:

EA Repository & Modeling: Orbus iServer, BiZZdesign, Avolution ABACUS
Collaboration & Workflow: ServiceNow, Jira, Confluence
Tech Evaluation & Approval: Excel templates, internal dashboards

Activities:

Set up EA repository (current & target state)
Define templates for architecture documentation, ARB requests, and approvals
Integrate with project management and DevOps pipelines

Outputs:

Repository accessible to all stakeholders
Automated workflow for architecture approval and compliance

Step 7: Communication & Change Management

Communicate governance model, bodies, processes, and RACI to all stakeholders
Conduct EA awareness workshops for business & IT teams
Establish feedback loops for continuous improvement

Outputs:

EA Governance charter
Communication plan
Training plan

Step 8: Monitor & Improve

Define KPIs and dashboards
Periodic ARB audits
Continuous improvement of EA standards and governance processes

KPIs Examples:

Project compliance rate
Standard reuse rate
Architecture approval turnaround time
Technology adoption metrics

Summary Table

Aspect	Centralized EA	Federated EA
Decision Authority	EA Lead / Central EA	Shared: Central EA + BU EA
Project Review	Central ARB	BU ARB + Central oversight
Flexibility	Low	High (BU autonomy)
Standardization	High	Moderate
Org Structure	Single EA org	Central EA + BU architects
RACI	Central EA: R, Business: I/C	Central EA: A/C, BU EA: R, Project: I
Tooling	EA repository, workflow tools	Same, plus BU access

EA Governance Setup (Text-Only Version)

Phase 1 – Current State Assessment & EA Maturity

Goal: Understand current architecture, governance, and gaps.
Inputs:
- Existing IT & business architecture artifacts
- Current governance processes (ARB, approvals)
- Technology landscape & integrations
- Regulatory/compliance requirements (RBI, IT Act, Data residency)
Activities:
- EA maturity assessment (TOGAF ADM)
- Map applications, integration, cloud/on-prem landscape
- Identify gaps, redundancies, risks
- Conduct interviews/workshops with stakeholders
Outputs:
- EA Maturity Assessment Report
- Gap analysis & recommendations
- Initial recommendation for governance model
Stakeholders & Workshops:
- CTO / Head IT → 1:1 strategy workshop
- BU Heads → Workshop for business priorities & autonomy
- Project Managers / Delivery Leads → Workshop on intake & approvals
- Architects / SMEs → Group workshop on current architecture
Tools: TOGAF ADM templates, EA repository, Excel for artifact mapping

Phase 2 – Define Governance Model

Goal: Select Centralized vs Federated EA governance.
Inputs:
- Assessment report & gap analysis
- BU autonomy & business complexity
- Regulatory constraints
Activities:
- Senior management workshops to evaluate pros/cons
- Define decision authority for central EA vs BUs
- Draft RACI for governance model
Outputs:
- Selected governance model
- Draft governance bodies & roles
- High-level RACI
Stakeholders & Workshops:
- CTO / CIO → approve model
- BU Heads → validate BU involvement & autonomy
- EA Lead → explain operational implications

Phase 3 – Define Governance Bodies & RACI

Centralized Governance Bodies

Body	Responsibilities	RACI
EA Steering Committee	Approve EA strategy, principles, policies	R: CTO, A: EA Lead, C: BU Heads, I: Project Managers
Architecture Review Board (ARB)	Approve project architectures, enforce standards	R: EA Lead/ARB Chair, A: Steering Committee, C: Architects, I: Developers
Technology Standards Committee	Evaluate & approve tech stack	R: CTO, A: EA Lead, C: SMEs, I: IT Ops
EA Working Group	Maintain repository, perform compliance checks	R: EA Analysts, A: EA Lead, C: Project Architects, I: Business Analysts

Federated Governance Bodies

Body	Responsibilities	RACI
Central EA Office / EA CoE	Define enterprise standards, policies, frameworks	R: EA Lead, A: CTO, C: BU Architects, I: Project Teams
BU EA Committees	Review & apply standards at BU level	R: BU Architects, A: BU Head, C: Central EA, I: Project Teams
Project ARB (Unit Level)	Approve solution designs within BU	R: BU Architects, A: BU Head, C: Central EA, I: Dev Teams
Technology Council	Recommend tech adoption & compliance	R: BU Tech Lead, A: Central EA, C: SMEs, I: Project Teams

Workshops:
- Governance charter workshop with Steering Committee & EA Lead
- ARB process walkthrough with architects & project teams

Phase 4 – Define EA Processes & Workflows

Process	Inputs	Activities	Outputs	Stakeholders	Workshop
Architecture Principles & Standards	Business strategy, regulations	Define principles, standards catalog	EA Principles Doc, Tech Standards Catalog	EA Lead, CTO, BU Heads	Validate principles
Project Architecture Review	Project charter, solution design	Conduct ARB meetings, approve/reject	Compliance report, recommendations	EA Lead, Project Architects, BU Heads	ARB process workshop per BU/project
Technology Evaluation & Selection	Vendor proposals, POC	Evaluate against standards, approve	Approved tech stack	EA Lead, Tech Council, SMEs	Tech selection workshop
EA Artifact Management	Project designs, integration diagrams	Maintain repository, version control	Updated EA repository	EA Analysts, Project Architects	Repository training
KPI & Reporting	Project compliance data	Track metrics, generate dashboards	KPI dashboards, quarterly reports	EA Lead, Steering Committee	Quarterly review workshop

Tools: Orbus iServer, BiZZdesign, Avolution ABACUS, ServiceNow, Jira

Phase 5 – EA Organization Structure

Centralized EA

CTO
 |
EA Lead / Chief Architect
 |
-------------------------------------------------
|             |             |           |
Business EA  Solution EA  Technology EA Governance & Standards Analysts

Federated EA

CTO
 |
Central EA Lead / Chief Architect
 |
-------------------------------------------------
|       |        |      
EA CoE  Standards & Tech Governance  Enterprise Architects
 |
-------------------------------------------------
|     |      |     |
BU1 EA BU2 EA BU3 EA BU4 EA

Stakeholders & Workshop: Org alignment session with CTO, EA Lead, BU Heads

Phase 6 – Implement Tools & Repository

Activities:
- Set up EA repository (current & target state)
- Define ARB submission templates, tech approval forms, compliance checklists
- Integrate with project management and DevOps pipelines
Outputs:
- EA repository with artifacts
- Automated architecture approval workflow
- KPI dashboards
Stakeholders & Workshop: EA Analysts, Project Architects, IT Ops → Repository hands-on training
Tools: Orbus iServer, BiZZdesign, ServiceNow, Jira, Confluence

Phase 7 – Communication & Change Management

Activities:
- Communicate governance model, RACI, responsibilities
- Conduct EA awareness workshops for BU & IT teams
- Establish feedback mechanism for continuous improvement
Outputs:
- EA Governance Charter
- Training & communication plan
- Feedback & improvement log
Stakeholders & Workshop: CTO, EA Lead, BU Heads, Project Managers, IT teams → Awareness & adoption workshops

Phase 8 – Monitor, Measure & Improve

Activities:
- Track KPIs: % compliance, reuse rate, approval turnaround time
- Conduct periodic ARB audits & governance reviews
- Update standards & policies based on lessons learned
Outputs: KPI dashboards, quarterly governance reports, updated EA policies
Stakeholders & Workshop: EA Lead, Steering Committee, BU Architects → Quarterly KPI review & improvement workshops

Key KPIs for EA Governance

% of projects compliant with EA standards
Reuse of standard components & services
Time to approve project architecture
Number of technology deviations approved
% of architecture artifacts updated in repository

This text-only version covers:

Realistic step-by-step EA governance setup
Inputs, activities, outputs
Stakeholders & workshops
Tools & frameworks
Governance bodies & RACI
Org structure for centralized and federated models
KPIs

EA Governance Layers and Bodies – Explanation

In Enterprise Architecture (EA) Governance, we usually divide the decision-making and oversight into three layers: Strategic, Tactical, and Operational. Each has a distinct purpose, scope, and decision-making authority.

1. Strategic Layer

Purpose: Align architecture with business strategy and ensure that long-term decisions support corporate objectives.

Key Players: CXO-level executives, CTO, Steering Committee, EA Lead/Office

Components:

Component	Role / Purpose
CTO Office	Owns the EA function; ensures alignment of IT with business strategy. Makes final architectural decisions for strategic initiatives.
Enterprise Architecture (EA) Office	Defines enterprise-wide standards, principles, and policies; maintains EA repository; supports decision-making at all layers.
Steering Committee	CXO-level committee (CTO, CFO, BU Heads) that approves architecture strategy, major technology investments, and policy exceptions.

Typical Responsibilities:

Approve architecture strategy, standards, and policies
Approve large programs or technology investments
Set priorities across business units

Outputs: EA Strategy, Enterprise Standards, Approved High-Level Architecture

2. Tactical Layer

Purpose: Translate strategic directives into actionable technology and process initiatives; oversee adoption of standards across BU/project level.

Key Players: Technology council, CoEs (Center of Excellence), EA leads, platform/DevOps teams

Components:

Component	Role / Purpose
Technology Council	Evaluates new technologies, recommends adoption, ensures compliance with EA standards.
Platform CoE	Defines reusable platforms, services, and reference architectures for development teams.
Cloud CoE	Manages cloud adoption, architecture, security, and cost optimization.
DevOps CoE	Standardizes CI/CD pipelines, deployment practices, and DevOps tools.

Typical Responsibilities:

Evaluate technology choices for projects
Recommend reusable platforms, frameworks, and services
Ensure compliance with EA principles and policies
Support ARB and SARB reviews

Outputs: Approved technology stacks, reusable components, guidelines for projects

3. Operational Layer

Purpose: Execute architecture governance at the project or domain level. This is the layer closest to implementation.

Key Players: Domain Architects, BU Leads, Solution Architects, ARB/SARB

Components:

Component	Role / Purpose
Domain Architects	Design solutions for specific business domains; ensure designs comply with enterprise standards.
BU Leads / Application Owners	Own BU-specific projects; coordinate with EA office and domain architects.
Enterprise ARB (EARB)	Reviews projects for alignment with enterprise-wide standards (cross-BU initiatives, high-risk projects).
Solution ARB (SARB)	Reviews project-level architecture within BU/domain, ensuring compliance with EA standards.

Typical Responsibilities:

Review and approve project architectures
Ensure alignment with EA principles and platform standards
Identify risks, exceptions, or deviations and escalate to tactical/strategic layers

Outputs: Project approval, architecture compliance reports, exception logs

How It All Fits Together

Strategic Layer → Decisions for enterprise-wide alignment, policy, and investment approval.
Tactical Layer → Decisions for technology adoption, platform services, and shared capabilities.
Operational Layer → Decisions for project-level design, implementation compliance, and exceptions.

Hierarchy Example (Text Version)

Strategic Layer:
----------------
CTO / CXO
   |
Steering Committee
   |
EA Office / EA Lead

Tactical Layer:
----------------
Technology Council
Platform CoE
Cloud CoE
DevOps CoE

Operational Layer:
------------------
Domain Architect
BU Lead / Application Owner
EARB (Enterprise ARB)
SARB (Solution ARB)

Key Points to Remember

Strategic Layer: Long-term, high-impact decisions; enterprise-wide view; CXO-led
Tactical Layer: Medium-term, technology-level decisions; CoE-led; enforces standards
Operational Layer: Day-to-day project execution; domain/BUs; ensures compliance
EARB vs SARB:
- EARB → Enterprise-wide projects / high-risk initiatives
- SARB → BU-specific or project-level architecture review

EARB (Enterprise Architecture Review Board) and SARB (Solution Architecture Review Board) sit at different layers based on their scope and purpose:

1. EARB – Enterprise Architecture Review Board

Layer: Tactical / Strategic boundary (closer to tactical)
Scope: Enterprise-wide initiatives, cross-BU projects, high-risk or high-impact programs
Role: Ensure alignment with enterprise standards, policies, and EA principles across the bank
Decision Type: Approve/reject major architectural designs, escalate exceptions to Strategic Layer (Steering Committee/CTO) if needed
Stakeholders: EA Lead, Enterprise Architects, BU Architects, Project Architects

✅ Think of EARB as tactical governance for enterprise-level projects, sometimes escalating to strategic decisions if needed.

2. SARB – Solution Architecture Review Board

Layer: Operational / Tactical boundary (closer to operational)
Scope: BU-level or domain-level projects, day-to-day solution designs
Role: Ensure compliance with EA principles, platform standards, and CoE guidelines for each project
Decision Type: Approve/reject solution-level designs, exceptions escalated to EARB if they impact enterprise standards
Stakeholders: Domain Architects, BU Architects, Project Architects, BU Leads

✅ Think of SARB as operational governance for individual projects, focused on practical compliance with standards.

Summary Table

Review Board	Layer	Scope	Decision Type	Escalation
EARB	Tactical (with Strategic visibility)	Enterprise-wide / cross-BU / high-risk projects	Approve/reject major architectures	Strategic Steering Committee if exceptions are critical
SARB	Operational (with Tactical visibility)	BU-level / project-level solutions	Approve/reject solution designs	EARB if enterprise-level impact

💡 Rule of Thumb:

EARB = Enterprise-level / cross-domain / high-impact → Tactical/Strategic boundary
SARB = Project/BU-level → Operational layer, reports up to EARB

Perfect! Here’s a complete text-only hierarchy of EA Governance for a bank, showing Strategic, Tactical, and Operational layers, including Steering Committee, EA Office, CoEs, EARB, SARB, stakeholders, and RACI. You can use this directly in interviews.

ABC Bank – EA Governance Text-Only Hierarchy

1. Strategic Layer

Purpose: Long-term, enterprise-wide decisions; align IT with business strategy.

Strategic Layer
---------------
CTO / CXO
   |
Steering Committee
   - Approves EA strategy, principles, policies
   - Approves major technology investments
   - Escalation point for critical architectural exceptions
   |
EA Office / EA Lead
   - Defines EA principles, standards, policies
   - Maintains EA repository
   - Supports all governance layers

Key Stakeholders: CTO, CIO, CFO, BU Heads, EA LeadWorkshop / Interaction: Strategic alignment workshops with CXO, approval of EA charter, policy reviews

2. Tactical Layer

Purpose: Translate strategic directives into technology & process initiatives; evaluate and approve enterprise-wide solutions.

Tactical Layer
--------------
Technology Council
   - Evaluates and approves new technologies
   - Recommends adoption of enterprise platforms
Platform CoE
   - Defines reusable platforms, frameworks, services
Cloud CoE
   - Manages cloud adoption, architecture, security, cost
DevOps CoE
   - Standardizes CI/CD pipelines, deployment, DevOps tools
EARB (Enterprise Architecture Review Board)
   - Reviews enterprise-level / cross-BU / high-risk projects
   - Approves major architecture designs
   - Escalates critical exceptions to Steering Committee

Key Stakeholders: EA Lead, BU Architects, Enterprise Architects, CoE LeadsWorkshop / Interaction:

Technology evaluation workshops
EARB architecture review meetings
CoE sessions for standardization & reusable platforms

3. Operational Layer

Purpose: Execute EA governance at project or domain level; ensure designs comply with EA standards.

Operational Layer
----------------
Domain Architects
   - Design solutions for specific business domains
   - Ensure compliance with EA standards
BU Leads / Application Owners
   - Own BU-specific projects
   - Coordinate with EA office and domain architects
SARB (Solution Architecture Review Board)
   - Reviews project/BU-level architecture
   - Ensures compliance with EA principles & CoE standards
   - Escalates exceptions to EARB if needed
Project Architects / Solution Architects
   - Prepare architecture for review
   - Implement approved designs

Key Stakeholders: Domain Architects, BU Leads, Project/Solution ArchitectsWorkshop / Interaction:

SARB review sessions for each project
Domain workshops for standard compliance
Exception handling escalation workshops

4. Hierarchy Summary (Text-Only)

Strategic Layer:
----------------
CTO / CXO
   |
Steering Committee
   |
EA Office / EA Lead

Tactical Layer:
----------------
Technology Council
Platform CoE
Cloud CoE
DevOps CoE
EARB (Enterprise Architecture Review Board)

Operational Layer:
------------------
Domain Architects
BU Leads / Application Owners
SARB (Solution Architecture Review Board)
Project / Solution Architects

Decision Flow / Escalation

SARB → EARB → Steering Committee → CTO/CXO
Project-level exceptions start at SARB, enterprise-impacting issues go to EARB, critical strategic decisions go to Steering Committee.

RACI Example by Layer

Layer	Role	Responsibility
Strategic	Steering Committee	Approve EA strategy, high-level policies
Strategic	EA Lead	Advise Steering Committee, maintain EA standards
Tactical	Technology Council / CoEs	Recommend and approve technology & platforms
Tactical	EARB	Review enterprise-level architecture compliance
Operational	Domain Architects / BU Leads	Design domain/BU solutions, ensure compliance
Operational	SARB	Review & approve project/solution architectures

This text-only structure now clearly shows:

Layers: Strategic, Tactical, Operational
Bodies: Steering Committee, EA Office, CoEs, EARB, SARB
Roles & responsibilities
Stakeholders and workshops
Decision & escalation flow

EA Governance – ABC Bank)

1. Strategic Layer

"At the strategic level, the EA governance ensures that all IT and architecture decisions align with the bank’s business strategy. The CTO and the CXO-level Steering Committee approve the enterprise architecture strategy, principles, and major technology investments. The EA Office, led by the EA Lead, supports this layer by maintaining EA standards, policies, and the architecture repository. This layer sets the direction, defines policies, and handles escalations for critical architectural decisions."

Key points to emphasize:

Strategic alignment with business goals
Steering Committee approves policies & high-impact initiatives
EA Office maintains standards & repository

2. Tactical Layer

"The tactical layer translates strategy into actionable technology and platform decisions. Here, the Technology Council evaluates and approves new technologies, while the Platform, Cloud, and DevOps CoEs ensure reusable services, cloud adoption, and standardized deployment practices. The Enterprise Architecture Review Board (EARB) reviews enterprise-wide or high-risk projects to ensure compliance with EA standards. Any critical exceptions are escalated to the Steering Committee."

Key points to emphasize:

CoEs standardize platforms, cloud, and DevOps
EARB focuses on enterprise-level architecture review
Tactical layer bridges strategy and operations

3. Operational Layer

"At the operational layer, governance focuses on project-level and domain-level execution. Domain Architects and BU Leads design solutions and ensure they comply with EA principles and CoE guidelines. The Solution Architecture Review Board (SARB) reviews project-level architecture, approves solutions, and escalates exceptions to EARB if they impact enterprise standards. Project and Solution Architects prepare designs for review and implement approved architectures."

Key points to emphasize:

Domain Architects / BU Leads own solution design
SARB ensures compliance at project level
Escalation path: SARB → EARB → Steering Committee

4. Decision & Escalation Flow

"The governance follows a clear escalation path: project-level exceptions start with SARB; enterprise-impacting issues go to EARB; and critical strategic decisions escalate to the Steering Committee and CTO/CXO. This ensures that all architecture decisions, from projects to enterprise platforms, are aligned, compliant, and risk-managed."

5. RACI Highlights

Steering Committee: Accountable for strategy and policies
EA Office: Responsible for standards, principles, and repository
CoEs: Responsible for platform, cloud, and DevOps standardization
EARB: Responsible for enterprise-level architecture review
SARB: Responsible for project-level solution compliance
Domain Architects & BU Leads: Responsible for design and implementation

6. Optional Add-On for Interviews

"We also track KPIs like project compliance %, reuse of standard components, architecture approval turnaround time, and deviations approved. This continuous monitoring ensures EA governance is effective, transparent, and adds value to both business and IT teams."

✅ Tip for speaking in interview:

Speak layer by layer: Strategic → Tactical → Operational
Use roles and boards as examples (Steering Committee, CoEs, EARB, SARB)
Mention decision flow and escalation path
End with KPI tracking and continuous improvement to show maturity

Perfect! Here’s a single, interview-ready speaking narrative for Kotak Bank EA Governance, combining Centralized and Federated models, layer by layer, with stakeholders, boards, RACI, and decision flow. You can speak this fluently without flipping pages.

ABC Bank – EA Governance

Introduction

"At ABC Bank, the goal of Enterprise Architecture governance is to ensure that IT and architecture decisions are fully aligned with business strategy, compliant with regulations, and risk-managed, while enabling innovation and reuse. EA governance can be implemented in either a centralized or federated model depending on business unit autonomy, complexity, and regulatory requirements."

1. Centralized EA Governance

"In a centralized governance model, the EA function is owned by the CTO’s office. At the strategic layer, the Steering Committee, comprising the CTO, CXOs, and BU Heads, approves EA strategy, enterprise-wide standards, and major technology investments. The EA Office, led by the EA Lead, maintains EA standards, policies, and the architecture repository, supporting all governance layers."

"At the tactical layer, CoEs such as the Platform, Cloud, and DevOps CoEs ensure standardization, reusable services, cloud adoption, and deployment practices. The Enterprise Architecture Review Board (EARB) reviews high-impact or cross-BU projects for compliance with EA principles. The Technology Council evaluates and approves new technologies across the enterprise."

"At the operational layer, Domain Architects and BU Leads design domain-specific solutions. The Solution Architecture Review Board (SARB) reviews project-level architectures for compliance, escalating exceptions to EARB when needed. Project and Solution Architects prepare designs and implement approved solutions."

"In this centralized model, all architecture decisions, approvals, and exceptions follow a clear path: SARB → EARB → Steering Committee → CTO. The EA Lead ensures policies and standards are enforced consistently across all BUs, projects, and technologies."

2. Federated EA Governance

"In a federated governance model, the EA function is distributed across business units while a Central EA Office maintains enterprise-wide standards. At the strategic layer, the Steering Committee and EA Lead still define strategy, standards, and policies. The EA Office ensures enterprise alignment, but BU-level autonomy is higher."

"At the tactical layer, each BU has its own EA Committee to review and apply standards locally. The Enterprise ARB (EARB) continues to review enterprise-impacting projects, but BU committees can approve smaller or domain-specific initiatives. CoEs remain centralized for cross-cutting services like Platform, Cloud, and DevOps, providing guidance and reusable services."

"At the operational layer, Domain Architects and BU Leads execute projects, ensuring compliance with standards. SARB exists at the BU/project level to approve solution architectures. Exceptions or deviations that affect enterprise standards are escalated to EARB. Project Architects implement solutions according to approved designs."

"The decision and escalation flow remains similar: SARB → BU EA Committee → EARB → Steering Committee. This model balances standardization with BU-level autonomy, enabling faster innovation while maintaining governance."

3. RACI Highlights (Both Models)

Layer	Role	Responsibility
Strategic	Steering Committee	Accountable for strategy, policies, major tech investment approvals
Strategic	EA Office / EA Lead	Responsible for EA standards, principles, policies, and repository
Tactical	CoEs (Platform, Cloud, DevOps)	Responsible for standardization, reusable services, deployment & cloud practices
Tactical	EARB	Responsible for enterprise-level architecture review and compliance
Operational	SARB	Responsible for project/solution-level architecture review
Operational	Domain Architects / BU Leads	Responsible for design, compliance, and implementation
Federated Only	BU EA Committees	Responsible for BU-specific architecture approvals and standard application

4. KPIs and Monitoring

"We track KPIs such as project compliance percentage, reuse of components, approval turnaround times, and deviations approved. Continuous monitoring and quarterly reviews ensure EA governance adds value, maintains alignment with strategy, and reduces architectural risks."

STRATEGIC LAYER

---------------

CTO / CXO

Steering Committee

- Approves EA strategy, principles, policies

- Approves major technology investments

- Escalation point for critical architecture exceptions

EA Office / EA Lead

- Maintains EA standards, policies, and repository

- Supports tactical and operational layers

- Advises Steering Committee on escalations

TACICAL LAYER

-------------

Technology Council

- Evaluates and approves new technologies

Platform CoE

- Defines reusable platforms, services, reference architectures

Cloud CoE

- Manages cloud adoption, architecture, security, cost

DevOps CoE

- Standardizes CI/CD pipelines, deployment, and tools

EARB (Enterprise Architecture Review Board)

- Reviews enterprise-level or cross-BU projects

- Approves major architectures

- Escalates exceptions to Steering Committee

FEDERATED ONLY

---------------

BU EA Committees

- Review BU-specific projects

- Apply central EA standards locally

- Escalate enterprise-impacting issues to EARB

OPERATIONAL LAYER

-----------------

Domain Architects

- Design solutions for specific business domains

BU Leads / Application Owners

- Own BU-specific projects

- Coordinate with EA Office and Domain Architects

SARB (Solution Architecture Review Board)

- Reviews project-level architectures

- Ensures compliance with EA principles and CoE standards

- Escalates exceptions to EARB if needed

Project / Solution Architects

- Prepare architectures for review

- Implement approved designs

DECISION FLOW / ESCALATION

--------------------------

SARB → BU EA Committee (federated) → EARB → Steering Committee → CTO / CXO

RACI HIGHLIGHTS

---------------

Strategic Layer:

- Steering Committee → Accountable for strategy and policies

- EA Office / EA Lead → Responsible for standards, repository

Tactical Layer:

- CoEs (Platform, Cloud, DevOps) → Responsible for standardization & guidance

- EARB → Responsible for enterprise-level architecture review

Operational Layer:

- SARB → Responsible for project-level architecture review

- Domain Architects / BU Leads → Responsible for design & implementation

- BU EA Committees → Responsible for BU-specific approvals (federated only)

Centralized: All approvals and compliance checks are directly managed by central EA; BUs follow the same standards with no local EA committees.
Federated: BU EA Committees enforce standards locally, allowing faster BU-specific approvals, while central EA ensures enterprise alignment.
CoEs (Platform, Cloud, DevOps) remain centralized in both models to maintain technology standardization.
EARB vs SARB:
- EARB handles enterprise-wide or high-risk projects.
- SARB handles project-level compliance.
Escalation flow differs only by presence of BU EA Committee in federated model.

ABC Bank – EA Governance Setup – Step-by-Step Execution

Phase 1: Current State Assessment & EA Maturity

Objective: Understand the existing architecture, governance, and maturity gaps.

Actions / Approach:

Conduct 1:1 interviews with CTO, CIO, BU Heads, and Project Managers to understand business priorities and pain points.
Organize workshops with architects and SMEs to map existing applications, integrations, and technology landscape.
Send questionnaires/surveys to project teams to capture current design, technology, and compliance practices.
Document regulatory requirements (RBI guidelines, data residency).
Assess EA maturity using TOGAF ADM and EA maturity models.

Inputs:

Existing architecture artifacts
Current governance processes (approval workflows, ARBs)
Technology landscape & integration maps
Regulatory requirements

Outputs:

EA Maturity Assessment Report
Gap analysis & recommendations
Initial recommendation for governance model (centralized vs federated)

Stakeholders Engaged: CTO, CIO, BU Heads, Project Managers, Solution Architects, SMEs

Phase 2: Decide Governance Model (Centralized vs Federated)

Objective: Select the governance model based on business needs, autonomy, and complexity.

Actions / Approach:

Conduct strategic workshops with CTO, BU Heads, and CIO to evaluate pros/cons of centralized vs federated model.
Discuss BU autonomy, decision-making authority, and risk appetite.
Draft high-level governance structure and RACI for each body.

Inputs:

EA assessment & gap analysis report
BU structure and decision-making autonomy
Regulatory constraints

Outputs:

Finalized governance model (Centralized / Federated)
Draft governance bodies, roles, and RACI matrix
Initial EA charter

Stakeholders Engaged: CTO, BU Heads, CIO, EA Lead

Phase 3: Define Governance Bodies, Roles, and RACI

Objective: Set up formal governance bodies and define responsibilities.

Actions / Approach:

Define Strategic Layer: Steering Committee, EA Office / EA Lead
Define Tactical Layer: EARB, CoEs (Platform, Cloud, DevOps), Technology Council
Define Operational Layer: SARB, Domain Architects, BU Leads, Project Architects
For Federated model, define BU EA Committees
Conduct workshops with stakeholders to validate roles and responsibilities
Create RACI matrix mapping each body and layer to responsibilities

Inputs:

Governance model decision
EA principles, standards, policies
Project portfolio data

Outputs:

Governance bodies, roles, responsibilities
RACI matrix
Governance operating model

Stakeholders Engaged: EA Lead, CTO, BU Heads, CoE Leads, Architects

Phase 4: Define EA Processes & Workflows

Objective: Ensure standardization, compliance, and repeatable review processes.

Actions / Approach:

Map project intake to architecture approval workflows
Define ARB submission templates, approval forms, checklists
Define technology evaluation and approval process
Conduct workshops with project teams to explain processes
Integrate CoEs into review and compliance workflows

Inputs:

Project intake forms
Current project workflows
EA standards and principles

Outputs:

Defined ARB/SARB workflow and approval templates
Technology evaluation checklist
Process documentation & guidelines

Stakeholders Engaged: Project Managers, Solution Architects, Domain Architects, CoEs

Phase 5: Implement Tools & EA Repository

Objective: Provide visibility, traceability, and automation in EA governance.

Actions / Approach:

Select EA repository tool (e.g., Orbus iServer, BiZZdesign, Avolution ABACUS)
Migrate existing architecture artifacts to repository
Set up KPI dashboards for compliance, approvals, and reuse
Conduct hands-on training sessions for architects and analysts

Inputs:

EA artifacts and documentation
Governance processes

Outputs:

Centralized EA repository with all artifacts
Workflow automation for architecture review
KPI dashboards

Stakeholders Engaged: EA Analysts, Project Architects, CoEs, IT Ops

Phase 6: Communication & Change Management

Objective: Ensure adoption of governance model and standards.

Actions / Approach:

Conduct EA awareness workshops for BU Heads, Project Managers, and architects
Communicate governance roles, responsibilities, and escalation paths
Provide training on repository, workflows, and CoE guidelines
Collect feedback for continuous improvement

Inputs:

EA governance charter
Process documentation

Outputs:

Adoption plan & training completion
Feedback logs for improvement

Stakeholders Engaged: BU Heads, Project Teams, Architects, CoEs

Phase 7: Monitoring & Continuous Improvement

Objective: Track effectiveness, compliance, and process improvement.

Actions / Approach:

Define KPIs: % compliance, reuse rate, architecture approval turnaround, deviations approved
Schedule quarterly governance review workshops with Steering Committee and EA Lead
Update standards, policies, and processes based on lessons learned

Inputs:

Project compliance data
KPI dashboards

Outputs:

Quarterly EA governance report
Updated standards & policies
Continuous improvement plan

Stakeholders Engaged: EA Lead, Steering Committee, CoEs, BU Architects

✅ Key Interview Tip:

When asked, you can walk through each phase like this:

"First, I assessed current architecture and governance by interviewing CTO, BU Heads, and PMs, and conducted workshops with architects. Then, I recommended centralized/federated model based on BU autonomy. Next, I defined governance bodies and RACI through stakeholder workshops. I set up ARB/SARB workflows, CoEs, and technology evaluation processes, implemented an EA repository for artifact management, conducted awareness workshops, and finally monitored KPIs and continuously improved governance."

"When I was asked to set up EA Governance at ABC Bank, I approached it in a structured, phased manner. First, I conducted a current-state assessment to understand the existing architecture, governance processes, and EA maturity. I interviewed the CTO, CIO, BU Heads, Project Managers, and conducted workshops with architects and SMEs. We also circulated surveys to project teams to capture technology usage, design patterns, and compliance practices. The output was a detailed EA maturity assessment and a gap analysis, which formed the foundation for the governance model decision."

"Next, I facilitated strategic workshops with the Steering Committee, CTO, and BU Heads to evaluate centralized versus federated governance models. We discussed BU autonomy, regulatory requirements, and decision-making authority. Based on these discussions, we finalized the governance model and drafted the high-level structure and RACI for each body."

"In the third phase, I defined governance bodies across layers: the strategic layer included the Steering Committee and EA Office; the tactical layer had CoEs for Platform, Cloud, and DevOps, along with the Enterprise ARB (EARB); and the operational layer included Solution ARB (SARB), Domain Architects, BU Leads, and Project Architects. In the federated model, BU EA Committees were added to handle local approvals."

"I then designed the EA processes and workflows, including project intake, architecture reviews, ARB submission templates, and technology evaluation processes. Workshops were held with project teams and CoEs to ensure understanding and adoption. We implemented an EA repository to centralize artifacts, automate approvals, and track KPIs such as compliance percentage, reuse of components, and approval turnaround times."

"Finally, I conducted awareness sessions and training workshops for BU Heads, architects, and project teams to ensure adoption. We established quarterly governance review meetings to monitor effectiveness, track KPIs, and continuously improve processes. The overall approach ensured strategic alignment, enterprise-wide standardization, and risk-managed execution while allowing flexibility for BU-specific needs in the federated model."

Here’s a bullet-point version of the 2-minute spoken narrative for quick recall in an interview. You can glance at it and narrate naturally without reading full sentences:

EA Governance Setup – Quick Recall Bullet Points

Phase 1: Current-State Assessment & EA Maturity

Interview CTO, CIO, BU Heads, PMs
Conduct workshops with architects & SMEs
Circulate surveys/questionnaires to project teams
Document regulatory requirements
Outputs: EA maturity assessment, gap analysis, recommendation for governance model

Phase 2: Decide Governance Model

Strategic workshops with Steering Committee, CTO, BU Heads
Evaluate centralized vs federated model (BU autonomy, complexity, risk)
Draft high-level governance structure & RACI
Outputs: Selected governance model, draft charter

Phase 3: Define Governance Bodies & RACI

Strategic Layer: Steering Committee, EA Office / EA Lead
Tactical Layer: CoEs (Platform, Cloud, DevOps), Technology Council, EARB
Operational Layer: SARB, Domain Architects, BU Leads, Project Architects
Federated: BU EA Committees for local approvals
Conduct workshops to validate roles and responsibilities
Outputs: Governance bodies, RACI matrix, operating model

Phase 4: Define EA Processes & Workflows

Map project intake → architecture review workflows
Define ARB submission templates, checklists, and technology evaluation process
Workshops with project teams & CoEs for adoption
Outputs: Documented ARB/SARB workflows, technology evaluation checklist

Phase 5: Implement Tools & Repository

Select EA repository tool (Orbus iServer / BiZZdesign / ABACUS)
Migrate existing artifacts
Set up KPI dashboards for compliance, approvals, reuse
Conduct training sessions for architects & analysts
Outputs: EA repository, automated workflows, KPI dashboards

Phase 6: Communication & Change Management

Awareness workshops for BU Heads, PMs, architects
Explain governance roles, responsibilities, escalation paths
Training on repository, workflows, CoE guidelines
Outputs: Adoption plan, feedback logs for improvement

Phase 7: Monitoring & Continuous Improvement

Define KPIs: compliance %, reuse %, approval turnaround, deviations approved
Quarterly governance review workshops with Steering Committee & EA Lead
Update standards, policies, and processes based on lessons learned
Outputs: Quarterly EA governance report, updated policies, continuous improvement plan

Decision / Escalation Flow

Centralized: SARB → EARB → Steering Committee → CTO/CXO
Federated: SARB → BU EA Committee → EARB → Steering Committee → CTO/CXO

Perfect! Here’s a single, text-box style mnemonic version of EA Governance for fast recall in interviews. You can memorize this in under a minute and narrate confidently:

ABC Bank EA Governance – Quick Mnemonic Text

STRATEGIC LAYER:
CTO / CXO → Steering Committee → EA Office / EA Lead
- Approves EA strategy, principles, policies
- Escalation point for critical architecture issues

TACICAL LAYER:
Technology Council
Platform CoE | Cloud CoE | DevOps CoE
EARB (Enterprise ARB)
- Enterprise-level project approval
- Reviews cross-BU/high-risk projects
- Escalates to Steering Committee
(Federated only: BU EA Committees → local BU approvals → EARB)

OPERATIONAL LAYER:
Domain Architects | BU Leads / Application Owners
SARB (Solution ARB)
Project / Solution Architects
- Project-level compliance & design approval
- Escalates exceptions to EARB

DECISION FLOW:
SARB → BU EA Committee (federated) → EARB → Steering Committee → CTO/CXO

PHASES TO SPEAK:
1. Assessment & Maturity – Interviews, workshops, surveys → Output: EA maturity & gap analysis
2. Decide Model – Centralized/Federated workshops → Output: governance model & draft RACI
3. Define Bodies & RACI – Strategic, Tactical, Operational layers → Output: RACI & operating model
4. Define Processes & Workflows – ARB/SARB templates, checklists → Output: process docs
5. Tools & Repository – EA repository & KPI dashboards → Output: central EA repo, KPIs
6. Communication & Change – Awareness workshops & training → Output: adoption & feedback
7. Monitoring & Improvement – Quarterly reviews & KPI tracking → Output: continuous improvement

TIPS:
- Emphasize stakeholder interaction & workshops
- Highlight outputs at each phase
- Explain centralized vs federated differences
- Mention KPIs: compliance %, reuse %, turnaround time

✅ Why this works:

All layers, boards, and escalation flows in one text box
Covers phases, stakeholders, workshops, outputs, and KPIs
Perfect for fast recall before or during an interview
Helps you sound like you actually implemented EA Governance

When I was asked to set up EA Governance at Kotak Bank, I approached it in a structured, phased manner. First, I conducted a current-state assessment to understand existing architecture, governance processes, and EA maturity. I interviewed the CTO, CIO, BU Heads, and Project Managers, conducted workshops with architects and SMEs, and circulated surveys to project teams to capture technology usage, design patterns, and compliance practices. The output was a detailed EA maturity assessment and gap analysis, which helped determine the right governance model."

"Next, I facilitated strategic workshops with the Steering Committee, CTO, and BU Heads to evaluate centralized versus federated governance, considering BU autonomy, risk, and regulatory requirements. Based on these discussions, we finalized the governance model and drafted the high-level governance structure along with a RACI for each layer."

"I then defined the governance bodies across layers. At the strategic layer, the Steering Committee and EA Office set policies and standards. The tactical layer included CoEs for Platform, Cloud, and DevOps, the Technology Council, and the Enterprise Architecture Review Board (EARB) for enterprise-level project approvals. The operational layer included Solution ARB (SARB), Domain Architects, BU Leads, and Project Architects for project-level reviews. In the federated model, BU EA Committees were added to handle local approvals."

"After that, I designed EA processes and workflows, including ARB/SARB submission templates, checklists, and technology evaluation processes, and conducted workshops to ensure adoption. We implemented an EA repository to centralize artifacts, automate approvals, and track KPIs such as compliance percentage, reuse rate, and approval turnaround time."

"Finally, I conducted awareness workshops and training sessions for BU Heads, architects, and project teams to ensure adoption. We established quarterly governance review meetings to monitor effectiveness, track KPIs, and continuously improve standards and processes. This approach ensured strategic alignment, standardization across the enterprise, and risk-managed execution, while allowing BU-specific flexibility in a federated model."

✅ Why this works in an interview:

Covers all phases from assessment to continuous improvement.
Highlights stakeholder engagement, workshops, outputs, and KPIs.
Explains centralized vs federated governance naturally.
Flows chronologically, easy to remember and deliver.
Positions you as experienced, practical, and results-driven EA.

KOTAK BANK EA GOVERNANCE – QUICK CHEAT SHEET

LAYERS & BODIES:

Strategic: CTO/CXO → Steering Committee → EA Office/EA Lead

Tactical: Technology Council | Platform CoE | Cloud CoE | DevOps CoE | EARB

Federated Only: BU EA Committees

Operational: SARB | Domain Architects | BU Leads | Project Architects

DECISION / ESCALATION FLOW:

Centralized: SARB → EARB → Steering Committee → CTO/CXO

Federated: SARB → BU EA Committee → EARB → Steering Committee → CTO/CXO

PHASES TO SPEAK:

1. Assessment & Maturity: Interviews, workshops, surveys → Output: EA maturity & gap analysis

2. Decide Model: Centralized/Federated workshops → Output: governance model & draft RACI

3. Define Bodies & RACI → Output: governance bodies & operating model

4. Define Processes & Workflows → Output: ARB/SARB templates & checklists

5. Tools & Repository → Output: EA repository & KPI dashboards

6. Communication & Change → Output: adoption & feedback

7. Monitoring & Improvement → Output: quarterly governance review & continuous improvement

KPIs / VALUE:

- Project compliance %

- Reuse of standard components

- Architecture approval turnaround time

- Deviations approved

- Strategic alignment, standardization, risk-managed execution

TIPS:

- Speak chronologically: Assessment → Model → Bodies → Processes → Tools → Communication → Monitoring

- Highlight workshops, stakeholders, outputs

- Explain centralized vs federated differences

- Mention KPIs & continuous improvement

1️⃣ RACI Definition

RACI is a framework for defining roles and responsibilities:

R – Responsible: Person/team who does the work.
A – Accountable: Person who is ultimately accountable for the decision/outcome. Only one per task.
C – Consulted: Stakeholders consulted for input before the decision.
I – Informed: Stakeholders kept informed after the decision.

2️⃣ RACI for EA Governance – Layers & Bodies

Layer / Body	Role / Activity	R	A	C	I	Cadence
Strategic Layer
Steering Committee	Approve EA strategy, principles, major tech investment	EA Office	CTO/CXO	BU Heads, CoE Leads	PMs, Architects	Quarterly
EA Office / EA Lead	Define EA standards, policies, repository, escalate issues	EA Analysts	EA Lead	Steering Committee, CoE Leads	BU Architects	Weekly / Monthly
Tactical Layer
Technology Council	Evaluate new technologies & frameworks	CoE Leads	CTO / EA Lead	BU Architects, SMEs	PMs	Monthly / Ad-hoc
Platform CoE	Define reusable platforms, reference architecture	Platform Architects	CoE Lead	EA Office, BU Architects	PMs	Monthly
Cloud CoE	Manage cloud adoption, security, cost	Cloud Architects	CoE Lead	EA Office, Security Team	BU Architects	Monthly
DevOps CoE	Standardize CI/CD pipelines & deployment	DevOps Architects	CoE Lead	EA Office, PMs	BU Architects	Monthly
EARB (Enterprise Architecture Review Board)	Review enterprise-level projects, approve exceptions	Domain / Enterprise Architects	EA Lead	CoE Leads, BU Architects	Steering Committee	Bi-Weekly / Ad-hoc
Federated Only
BU EA Committee	Approve BU-specific projects, ensure standard compliance	BU Architects	BU EA Lead	EA Office	EARB	Bi-Weekly / Ad-hoc
Operational Layer
SARB (Solution Architecture Review Board)	Review project-level architectures, approve deviations	Project / Solution Architects	Domain Architect	BU Leads, EA Office	EARB	Weekly / Ad-hoc
Domain Architects	Design solutions per domain	Solution Architects	Domain Lead	BU Leads	EA Office	Daily / Project-based
BU Leads / Application Owners	Ensure BU projects comply with standards	Project Teams	BU Lead	Domain Architects	EA Office	Weekly / Project-based
Project / Solution Architects	Prepare architecture for review & implementation	Project Architects	Domain Architect	CoEs	SARB	Project-based

3️⃣ Cadence Notes

Strategic Layer: Quarterly Steering Committee meetings; EA Office updates weekly/monthly.
Tactical Layer: CoE and Technology Council monthly; EARB bi-weekly or on-demand for urgent projects.
Federated BU EA Committees: Bi-weekly or ad-hoc depending on project submissions.
Operational Layer: SARB weekly or ad-hoc per project; Domain Architects & Project Architects work day-to-day on design tasks.

Phase 1: Strategic Layer (CTO, Steering Committee, EA Office)

Objective: Set vision, principles, governance model.

Typical Questions:

How did you decide between centralized and federated governance?
How did you align EA strategy with business objectives?
What inputs and stakeholders did you engage to define EA standards?
How did you prioritize enterprise-level technology investments?
How did you handle conflicts between BU needs and enterprise standards?
How often did the Steering Committee meet, and what was discussed?
How did you measure success of EA governance at strategic level?

Phase 2: Tactical Layer (Technology Council, CoEs, EARB, BU EA Committees)

Objective: Evaluate technologies, enforce standards, approve enterprise projects.

Typical Questions:

How did you set up CoEs, and what was their scope?
How did the Technology Council evaluate and approve new technologies?
What projects went through EARB, and how were exceptions handled?
For federated governance, how did BU EA Committees coordinate with central EA?
How did you ensure CoEs’ recommendations were adopted across BUs?
How did you manage conflicting technology proposals from multiple BUs?
What KPI metrics did you track at the tactical layer?

Phase 3: Operational Layer (SARB, Domain Architects, BU Leads, Project Architects)

Objective: Review project-level designs, ensure compliance with standards, manage risks.

Typical Questions:

How did you set up SARB, and what types of projects were reviewed?
What templates and checklists were used for architecture reviews?
How did Domain Architects and Project Architects collaborate with BUs?
How did you escalate deviations or exceptions to EARB or Steering Committee?
How did you ensure adherence to EA standards at project level?
How did you balance delivery deadlines vs compliance with architecture principles?
What KPIs or dashboards did you maintain for operational layer compliance?

Phase 4: EA Processes & Workflows

Objective: Standardize approval workflows, ARB/SARB processes.

Typical Questions:

How did you define project intake and ARB submission process?
What tools or templates did you use to track architecture reviews?
How did you ensure workflow adoption by project teams?
How did you integrate CoEs and ARBs into the workflow?
How did you automate or track KPIs for architecture approval?

Phase 5: Tools & Repository

Objective: Maintain EA artifacts, KPIs, compliance tracking.

Typical Questions:

What EA repository tools did you evaluate and why did you select one?
How did you migrate existing artifacts into the repository?
How did you track reuse, compliance, and project approvals?
How did you train architects and project teams to use the tool?
Did you integrate the repository with project management tools or dashboards?

Phase 6: Communication & Change Management

Objective: Ensure adoption of EA governance across BU and project teams.

Typical Questions:

How did you communicate governance policies and standards to BUs?
What workshops or training sessions did you conduct?
How did you handle resistance from project teams or BUs?
How did you track adoption and collect feedback?
How did you ensure continuous engagement with CoEs and BUs?

Phase 7: Monitoring & Continuous Improvement

Objective: Track governance effectiveness and evolve standards.

Typical Questions:

What KPIs did you track to measure EA governance effectiveness?
How did you conduct quarterly or annual governance reviews?
How did you identify gaps or improvements in standards or processes?
How did you report EA effectiveness to Steering Committee or CTO?
How did you adapt EA governance to changing business or technology needs?

✅ Tip for Interview:

Always mention the stakeholder, output, and tools while answering.
Example: “During operational layer SARB reviews, Domain Architects were responsible, BU Leads were accountable, EA Office was consulted, and Steering Committee informed. We used ARB templates and repository dashboards to track approvals weekly.”
Interviewers love specificity with roles, cadence, tools, and outputs.

Phase 1: Strategic Layer – Current-State Assessment & EA Maturity

Objective: Understand existing architecture, governance, and business alignment.