EA Governance at ABC Bank

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

Stakeholders: CTO, CIO, BU Heads, EA Lead, Project Managers, Architects

Stakeholder Questions:

• What is the current EA structure and governance process?

• What are the pain points or gaps in architecture decisions?

• Strategic business objectives for 1–3 years?

• Regulatory and compliance requirements?

• How are technology investments prioritized?

• What is the current EA maturity (standards, reuse, documentation)?

• Who are the decision-makers and influencers?

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

Stakeholders: Steering Committee, CTO, BU Heads, EA Lead

Questions:

• Centralized or federated? Why?

• How much autonomy should each BU have?

• How are conflicts between BU and enterprise priorities resolved?

• What types of projects require enterprise-level approval?

• Expected level of compliance across BUs?

• Regulatory or audit 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

Stakeholders: EA Lead, CoE Leads, BU Leads, Domain Architects, Project Architects

Questions:

• What CoEs need to exist? Scope?

• Role of EARB and SARB in decision-making?

• BU EA Committees coordination in federated model?

• Who is R, A, C, I for each layer?

• Meeting frequency per governance body?

• Escalation paths to Steering Committee?

Outputs:

• Governance bodies, roles, responsibilities

• RACI matrix

• Governance operating model

• RACI & Cadence (Summary):

Body	R	A	C	I	Cadence
Steering Committee	EA Office	CTO/CXO	BU Heads, CoE Leads	PMs, Architects	Quarterly
EA Office / EA Lead	EA Analysts	EA Lead	Steering Committee, CoE Leads	BU Architects	Weekly / Monthly
Technology Council	CoE Leads	CTO / EA Lead	BU Architects, SMEs	PMs	Monthly / Ad-hoc
CoEs	CoE Architects	CoE Lead	EA Office, BU Architects	PMs	Monthly
EARB	Domain / Enterprise Architects	EA Lead	CoE Leads, BU Architects	Steering Committee	Bi-Weekly / Ad-hoc
BU EA Committees (Federated)	BU Architects	BU EA Lead	EA Office	EARB	Bi-Weekly / Ad-hoc
SARB	Project / Solution Architects	Domain Architect	BU Leads, EA Office	EARB	Weekly / Ad-hoc

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

Questions:

• Current project intake process?

• What checklists/templates are required?

• How are exceptions handled?

• How do project teams collaborate with CoEs/ARBs?

• Workflow steps: mandatory vs optional?

• How to track adoption & compliance?

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

Questions:

• Which EA repository tool to use? Why?

• What artifacts should be stored centrally?

• How to track project approvals, reuse metrics, compliance KPIs?

• Who needs access & at what level?

• Integration with PM or DevOps tools?

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

Questions:

• How are EA standards and policies communicated to BUs?

• What workshops or training sessions are needed?

• How to handle resistance or non-compliance?

• How to capture feedback?

• Frequency of updates for project teams & leadership?

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

Questions:

• What KPIs measure governance effectiveness?

• Frequency of quarterly/annual reviews?

• How are gaps, deviations, risks identified & mitigated?

• How to report findings to Steering Committee/CTO?

• Continuous improvement mechanisms for EA processes?

Outputs:

• Quarterly EA governance report

• Updated standards & policies

• Continuous improvement plan

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

KPIs Across Layers

• Project compliance %

• Reuse of standard components

• Architecture approval turnaround time

• Deviations approved

• Strategic alignment, standardization, risk-managed execution

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.

ABC 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:

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

✅ Key Interview Tip:

"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."

1️⃣ EA Organization Structure (Org Chart)

👉 What it is:The EA Org Chart defines who does the work — the reporting lines, roles, and responsibilities of people who run and manage Enterprise Architecture within the organization.

It represents the operational organization of the EA function.

Example: Centralized EA Org Structure

Group CTO / CIO
│
├── Chief Enterprise Architect (Head of EA Office)
│   ├── Business Architecture Lead
│   ├── Application Architecture Lead
│   ├── Data & Analytics Architecture Lead
│   ├── Technology Architecture Lead
│   ├── Security Architecture Lead
│   └── AI / GenAI Architecture Lead
│
└── EA Governance & Compliance Office
    ├── EA Tool Admin (SparxEA / LeanIX)
    ├── EA Metrics Analyst
    └── EA Governance Coordinator

In a Federated Model

Chief Enterprise Architect (Central EA Office)
│
├── Central EA Core Team
│   ├── Defines EA principles, standards, reference architectures
│
└── BU / Domain EA Teams (for each business line)
    ├── BU EA Lead
    ├── Domain Architects (App/Data/Tech)
    ├── Solution Architects (Project Level)

EA Org Chart Focus

Aspect	Description
Purpose	Who manages and drives EA across enterprise
Focus Area	Roles, responsibilities, reporting lines
Ownership	CTO and Chief Enterprise Architect
Examples	Business Architect, Data Architect, Solution Architect, EA Tool Admin
Outcome	Clear accountability for EA work and deliverables

2️⃣ EA Governance Bodies

👉 What it is:The EA Governance Bodies define who makes decisions — committees or boards that review, approve, and control enterprise-wide architecture decisions, standards, and compliance.

These are decision-making and oversight bodies, not operational roles.

Example: EA Governance Structure

Strategic Layer

• Enterprise Architecture Steering Committee (EASC)

  • Members: CXO, CTO, CIO, CFO, CDO, Chief EA

  • Purpose: Approve enterprise architecture strategy, budget, roadmap, and investment priorities.

  • Cadence: Quarterly

Tactical Layer

• Enterprise Architecture Review Board (EARB)

  • Members: Chief EA, Domain Leads, PMO, Tech Council

  • Purpose: Approve EA principles, reference architectures, and cross-domain standards.

  • Cadence: Monthly

• Solution Architecture Review Board (SARB)

  • Members: Domain Architects, Delivery Heads, Security Lead

  • Purpose: Review solution-level designs for compliance with EA standards.

  • Cadence: Bi-weekly

• Technology Council / Platform CoEs (Cloud, DevOps, Data, AI)

  • Members: Platform Architects, SMEs

  • Purpose: Evaluate and standardize technology stack; update Technology Radar.

  • Cadence: Monthly

Operational Layer

• Architecture Working Group

  • Members: EA office, domain architects, delivery teams

  • Purpose: Discuss implementation feedback, updates to standards, and best practices.

  • Cadence: Weekly

EA Governance Focus

Aspect	Description
Purpose	Decision-making and compliance enforcement
Focus Area	Committees, review boards, CoEs
Ownership	EA Office, chaired by CTO or Chief EA
Examples	EARB, SARB, Tech Council, Steering Committee
Outcome	Architecture decisions approved, compliance maintained, standards enforced

3️⃣ Relationship Between EA Org & EA Governance

Aspect	EA Org Chart	EA Governance Bodies
Focus	People structure	Decision & review forums
Drives	Execution & delivery of EA work	Oversight & control of EA decisions
Operated by	EA Office (Chief EA + Architects)	Multi-stakeholder committees
Scope	Internal EA function	Enterprise-wide oversight
Output	Architecture deliverables (principles, blueprints, standards)	Architecture decisions, approvals, compliance status
Cadence	Continuous operational	Defined periodic meetings

4️⃣ Example in Banking Context

At Kotak Bank, when setting up EA governance:

• EA Org Structure→ Built under the CTO Office, headed by a Chief Enterprise Architect.→ Included domain architects for Retail, Corporate, Risk, and Treasury systems.→ Each had dedicated application/data/security/AI architects.

• EA Governance Structure→ Created a Steering Committee (CTO, CIO, CRO, CDO, Chief EA).→ Established EARB for approving enterprise-wide standards.→ Set up SARB at program level to review each solution design.→ Formed CoEs (Cloud, Data, DevOps, GenAI) to standardize platforms and patterns.

Together:

• The EA Org Chart handled execution and delivery.

• The EA Governance Bodies ensured control, alignment, and accountability.

✅ In Interview, You Can Say:

“I clearly differentiate between the EA organization model and the EA governance structure.The EA Org Chart defines who executes architecture work — the Chief Enterprise Architect, domain architects, and supporting roles under the CTO Office.The EA Governance Bodies define who makes and approves architecture decisions — such as the Steering Committee, EARB, SARB, and Technology Councils.Together, they ensure both execution capability and decision accountability across the enterprise.”

🧭 Developing Architecture Vision & Statement of Architecture Work

(For a Digital Transformation Engagement in a Bank)

🎯 Objective

To define why the transformation is happening, what outcomes are expected, and how architecture will guide it — capturing scope, stakeholders, goals, constraints, and success measures.

These are formal outputs of the TOGAF ADM Phase A – Architecture Vision.

1️⃣ Step 1: Understand Business Context and Drivers

Activities:

• Conduct discovery workshops with CXOs, BU Heads, and Product Owners.

• Capture strategic objectives — e.g.:

  • Modernize core banking and lending systems.

  • Improve time-to-market for new products.

  • Enhance customer experience through AI and digital channels.

  • Ensure regulatory compliance (RBI, SEBI, etc.).

• Identify pain points in current architecture (silos, legacy, manual processes).

Inputs:

• Bank’s business strategy & vision documents

• Annual operating plan

• Transformation charter

• Regulatory mandates

Stakeholders:

• CEO, CIO, CTO, CRO, CDO

• BU Heads (Retail, Lending, Wealth, Risk)

• PMO and Enterprise Architecture Office

Output:

• List of business drivers, pain points, and strategic goals

2️⃣ Step 2: Identify Stakeholders & Concerns

Activities:

• Map all key stakeholders → capture their concerns and success criteria.

Example:

Stakeholder	Concern	Desired Outcome
CIO	Reduce TCO	Decommission legacy systems
CTO	Scalability	Cloud-native microservices
CRO	Risk & compliance	Secure, auditable data lineage
CDO	AI enablement	AI-driven insights, personalization
Business Head	Faster launch	50% faster go-to-market

Output:

• Stakeholder matrix and concerns catalog

3️⃣ Step 3: Define Scope & Boundaries

Activities:

• Identify what’s in scope (e.g., loan origination, KYC, customer servicing).

• Identify dependencies or exclusions (e.g., core banking remains on-prem).

• Define business units, regions, and systems impacted.

Output:

• Scope definition document

• Context diagram showing in-scope vs. out-of-scope

4️⃣ Step 4: Develop Architecture Vision (To-Be)

Activities:

• Create a high-level architecture view that shows the future state of business, data, application, and technology landscape.

• Use reference models (TOGAF, BIAN, FIBO, Cloud Adoption Framework).

• Define key architectural principles (e.g., API-first, cloud-native, zero-trust, explainable AI).

Output (Architecture Vision):

• 1-page architecture vision statement

• High-level future state diagram

• Business outcomes mapped to architecture capabilities

Example (for Digital Lending):

“Enable a unified, cloud-native digital lending platform that automates customer onboarding, credit scoring, and loan servicing through AI-driven workflows, ensuring scalability, resilience, and compliance across the enterprise.”

5️⃣ Step 5: Create the Statement of Architecture Work (SoAW)

This is a formal document that defines what architecture work will be done, how, and under what constraints.It’s approved by the Architecture Board or Steering Committee.

Typical Content of SoAW:

Section	Description
Purpose	Objective of the architecture engagement
Scope	Domains (business, data, app, tech, security) and boundaries
Assumptions & Constraints	Budget, timelines, regulatory, technology
Architecture Deliverables	Vision, baseline, target, roadmap, standards
Governance	Review bodies (EARB, SARB), checkpoints, KPIs
Tools & Methodology	TOGAF ADM, ArchiMate, Sparx EA, LeanIX
Stakeholders & Roles	EA, Domain Architects, PMO, BU Leads
Approval	Sign-off by Architecture Board / CTO

Example Excerpt:

“The scope of this architecture engagement covers the modernization of the digital lending platform, including customer onboarding, loan origination, and servicing.The architecture work will deliver target state blueprints, integration patterns, and an implementation roadmap, leveraging microservices on Azure Cloud and AI/GenAI-based risk models.”

Output:

• Approved Statement of Architecture Work (SoAW)

• Architecture Charter / Mandate

6️⃣ Step 6: Define Success Criteria & KPIs

You define measurable outcomes tied to business value:

Dimension	KPI
Business	Loan approval time reduced from 5 days → 1 day
Technology	90% of services containerized on AKS
Data	Single customer view across channels
Security	100% compliance with RBI/ISO standards
AI/GenAI	95% accuracy in credit scoring, bias <5%
Operations	Uptime > 99.9%, CI/CD automation for 80% apps

7️⃣ Step 7: Validate & Communicate Vision

Activities:

• Conduct Architecture Vision Workshop with all key stakeholders.

• Validate alignment with business strategy and funding.

• Communicate vision through visual blueprints, one-page summaries, and executive decks.

Outputs:

• Signed-off Architecture Vision document

• Approved SoAW

• Transformation roadmap initiation

🧩 Example: Digital Transformation Architecture Vision (for Interview)

“For Kotak Bank’s digital transformation, I started by conducting stakeholder workshops to understand the business goals of improving customer onboarding, accelerating loan disbursement, and enhancing personalization using AI.I captured these into an Architecture Vision document, which outlined a cloud-native microservices architecture on Azure integrated with GenAI for credit risk scoring and customer support.I then prepared the Statement of Architecture Work (SoAW) detailing the scope, deliverables, governance structure, and KPIs.This SoAW was approved by the EA Review Board and became the formal architecture charter driving the engagement.”

📘 Tools and Frameworks Used

• Frameworks: TOGAF ADM (Phase A – Architecture Vision), BIAN, Zachman

• Modeling Tools: Sparx EA, LeanIX, ArchiMate, Lucidchart

• Governance Tools: ServiceNow EA, Jira, Confluence

• GenAI Tools (for Vision Automation): Azure OpenAI (for narrative generation, architecture summary, stakeholder mapping)

✅ Summary (Interview Short Answer):

“I define the Architecture Vision by first aligning with business strategy through CXO workshops, identifying pain points, and articulating how architecture enables strategic goals.I formalize it in the Statement of Architecture Work (SoAW) — which defines scope, deliverables, governance, and KPIs — and get it approved by the Architecture Board.This ensures a clear mandate for the architecture team and traceability between business goals and architecture execution.”