EARB Session

Anand Nerurkar
12 hours ago
20 min read

🏛️ Enterprise Architecture Review Board (EARB) — Practical Walkthrough

🎯 Purpose of EARB

The Enterprise Architecture Review Board (EARB) ensures that:

All solution and technical designs align with enterprise standards, principles, and target architecture.
Architecture decisions are governed, reviewed, and traceable.
New initiatives are risk-controlled, cost-optimized, and strategically consistent with the organization’s IT roadmap.

It acts as the architecture governance backbone during digital transformation or cloud adoption.

🧩 1. Setup Phase (Before Conducting EARB)

Step	Activity	Details / EA Role
1.1 Define EARB Charter	Purpose, scope, authority	EA drafts the charter — defines which types of projects/designs must go through review (e.g., new apps, cloud migrations, integrations, security-sensitive systems).
1.2 Define Membership	Who sits on the board	Typically includes: • Chief Architect / Head of EA (Chair) • Domain Architects (App, Infra, Data, Security) • Cloud CoE Lead • Security Head (CISO Rep) • DevOps / Operations Lead • Business Relationship Manager (optional for impact validation)
1.3 Define Cadence	Frequency of meetings	Usually bi-weekly for active transformation programs, monthly for BAU. Ad-hoc sessions for urgent design reviews.
1.4 Prepare Governance Artifacts	Templates, checklist, process	EA prepares: - Architecture Review Checklist (based on TOGAF & Cloud Well-Architected Framework) - Submission template (Solution Overview, Diagrams, NFRs, Risks) - Decision log format

🧭 2. EARB Operating Model

Phase	Activity	Owner / Role	Tools / Frameworks Used	Output
2.1 Intake & Scheduling	Project team submits design for review (through ServiceNow / Jira).	Project Architect	ServiceNow EARB module / SharePoint tracker	Review queue / agenda
2.2 Pre-Review Screening	EA team screens submission for completeness, maturity (L0–L3 designs).	EA Team	EA repository (LeanIX, ADOIT, ArchiMate)	Eligible designs shortlisted
2.3 Conduct Review Session	Formal meeting with all board members.	Chief Architect (Chair)	Architecture diagrams, cloud blueprints, Well-Architected Tool	Minutes of Meeting, Risks Identified
2.4 Decision & Recommendation	Board decides: ✅ Approved / 🟡 Conditional / ❌ Rejected.	EARB	TOGAF ADM Phases D–F, AWS WAF, Azure CAF	Decision recorded in log
2.5 Follow-up Actions	Teams fix issues, re-submit for approval.	Solution Team	Jira / ServiceNow tracking	Approved Architecture Design
2.6 Continuous Improvement	Analyze trends (recurring issues, delays).	EA Office	Power BI Dashboard / Excel	EARB KPI Dashboard

👥 3. Stakeholders and Roles

Role	Responsibility
Chief Architect (Chair)	Presides over meetings, ensures alignment with strategy, final approval authority.
Domain Architects (Infra, App, Data, Security)	Review from domain perspective (performance, scalability, data compliance, security posture).
Cloud CoE Lead	Validates cloud-specific design alignment (landing zone, IAM, network).
CISO / Security Rep	Ensures risk, compliance, and data protection adherence.
Project / Solution Architect	Presents the design, explains rationale and trade-offs.
PMO Representative	Tracks actions and maintains EARB calendar.
Business Sponsor (optional)	Provides business context and impact assessment.

🧱 4. Inputs & Outputs

Inputs	Outputs
- Solution Architecture Document (SAD) - High-Level Design (HLD) - Non-Functional Requirements (NFRs) - Risk Register - Compliance Checklist	- EARB Decision Log - Approved Architecture - Risk & Deviation Report - Action Tracker - Updated Architecture Repository

⚙️ 5. Tools / Frameworks Typically Used

Type	Examples
EA Repository	LeanIX, MEGA HOPEX, ADOIT, Sparx EA
Workflow / Tracking	ServiceNow, Jira, Confluence
Frameworks	TOGAF ADM, SABSA (Security), Cloud Well-Architected Framework, ITIL v4
Templates	EA Review Checklist, Architecture Decision Record (ADR), RACI
Visualization	ArchiMate / Draw.io / Lucidchart

📈 6. KPIs Tracked

KPI	Description / Target
% of projects reviewed vs. total	>90%
Avg. turnaround time for review	< 7 working days
% of approved designs without deviations	>80%
# of repeated design deviations	<5 per quarter
Compliance to architecture principles	100% adherence
Stakeholder satisfaction score	>8/10

🧩 7. Governance & Escalation Model

CIO / CTO
  │
  ├── Enterprise Architecture Council
  │     └── Enterprise Architecture Review Board (EARB)
  │           ├── Cloud Review Board (sub-committee)
  │           ├── Security Review Board (CISO Office)
  │           └── Data Governance Council
  │
  └── Change Advisory Board (CAB)

EARB is the authoritative body for design approval before CAB authorizes deployment.
Escalation Path: Solution Architect → Domain Architect → Chief Architect → EARB → EA Council.

🧭 8. RACI (EARB Process)

Activity	R	A	C	I
Design submission	Solution Architect	PMO	EA Team	BU Head
Screening	EA Team	Chief Architect	Domain Architects	CIO
Review session	EARB Members	Chief Architect	Cloud CoE, CISO	Project Team
Decision & Approval	EARB	CIO / Chief Architect	Security, Risk	PMO
Tracking & closure	PMO	EA	Project Architect	Steering Committee

💬 How to Explain in Interview

“As an Enterprise Architect, I chaired or co-led EARB sessions to ensure every solution design aligned with enterprise principles and cloud standards.I defined the EARB charter, standardized templates, and created a cadence where project architects presented their designs for review.Using tools like LeanIX and ServiceNow, I tracked submissions, recorded decisions, and measured KPIs like turnaround time and compliance rate.This process not only improved design quality but also reduced rework and audit issues by enforcing architectural governance early in the lifecycle.”

🧭 EARB Charter – Enterprise Architecture Review Board Charter

1. Purpose

The Enterprise Architecture Review Board (EARB) ensures that all technology and solution designs across the organization are:

Aligned with enterprise strategy, standards, and principles
Supporting business objectives and transformation roadmap
Compliant with security, regulatory, and architectural guardrails
Designed for scalability, interoperability, and cost efficiency

Essentially, the EARB is the governance body that balances innovation with standardization.

2. Objectives of the Charter

Define the governance framework for architecture review and compliance
Establish decision rights, roles, and responsibilities for architecture stakeholders
Ensure architectural consistency across business units, platforms, and projects
Drive reusability, technology rationalization, and cloud adoption standards
Manage risk and technical debt through structured deviation handling

3. Scope

All new projects, major enhancements, and technology onboarding initiatives must go through EARB review.
Covers solution architecture, integration patterns, security architecture, and cloud architecture decisions.
Ensures alignment with enterprise reference architecture and technology standards catalog.

4. Governance Structure

Governance Body	Role	Key Focus
Enterprise Architecture Review Board (EARB)	Chaired by Chief Architect / CTO	Strategic review, compliance, approvals
Domain Architecture Councils	Domain / BU Architects	Tactical design review, domain patterns
Architecture Working Group (AWG)	Solution Architects, SMEs	Hands-on collaboration, documentation

5. Roles & Responsibilities (RACI Summary)

Role	Responsibility
Chief Architect (A)	Approves design decisions, manages exceptions
EA Reviewers (R)	Conducts design reviews, evaluates compliance
Solution Architects (R/C)	Prepare design, present for review
CISO (C)	Validates security alignment
Program / Delivery Head (C/I)	Ensures delivery adherence
PMO (I)	Tracks actions, reports compliance metrics

6. Inputs & Outputs

Phase	Input	Output
Pre-Review	Design document, EA standards, NFR checklist	Review plan
Review	Architecture presentation, impact assessment	Review observations
Post-Review	Waiver requests, remediation plan	Approval / conditional approval / rejection
Continuous	Metrics, lessons learned	Updated standards & reference models

7. KPIs Tracked

% of projects reviewed by EARB
% of architecture compliance
Number of deviations approved vs rejected
Average review turnaround time
% of tech debt closed per quarter

8. Tools & Frameworks Used

Frameworks: TOGAF, Zachman, SAFe (for Lean-Agile governance)
Tools: LeanIX / Sparx EA for repository, Jira for tracking, Confluence for documentation

9. Cadence

EARB meetings: Bi-weekly or monthly for strategic initiatives
Tactical working sessions: Weekly with domain architects
Emergency reviews: As-needed for time-sensitive delivery

10. Outcomes

Approved / conditionally approved / rejected architecture designs
Published decision records (ADR)
Updated architecture standards repository
Improved architectural maturity & reduced duplication

✅ **Example Statement (Interview-Ready Summary)

“The EARB Charter defines how we govern architectural decisions across the enterprise. It establishes the purpose, scope, membership, decision rights, and process for architecture reviews. The goal is to ensure all initiatives are aligned with enterprise strategy, standards, and guardrails while balancing compliance with delivery agility. We use TOGAF as the base framework and LeanIX for traceability of reviews, with KPIs like compliance %, deviation trend, and turnaround time.”

Perfect — this is a must-have artifact for any Enterprise Architect leading or participating in an EARB (Enterprise Architecture Review Board).

Below is a comprehensive, realistic “Architecture Review Checklist” — exactly the kind used in banks, insurers, and large transformation programs.

🧩 Architecture Review Checklist (Enterprise Architecture Review Board)

Category	Checklist Items	Purpose / Validation Point	Remarks
1. Business Alignment	✅ Does the solution align with the overall business strategy and transformation roadmap?	Ensure technology serves business goals
	✅ Have key business outcomes and KPIs been clearly identified and mapped to architecture decisions?	Check business traceability
	✅ Are all relevant business capabilities, processes, and stakeholders impacted identified?	Identify integration & change dependencies
2. Architectural Principles & Standards	✅ Does the design adhere to defined EA principles, reference models, and technology standards?	Consistency & reuse
	✅ Are deviations documented and approved via Architecture Exception Process?	Manage exceptions
3. Functional Architecture	✅ Are all major business functions and use cases addressed in the architecture?	Coverage validation
	✅ Has the data flow and integration between modules been clearly defined?	Completeness
4. Non-Functional Requirements (NFRs)	✅ Are performance, scalability, and availability requirements defined and validated?	Ensure operational SLAs
	✅ Is the resiliency and failover design documented and tested?	High availability
	✅ Have security, privacy, and compliance requirements been addressed (GDPR, PCI-DSS, RBI/SEBI, etc.)?	Regulatory compliance
	✅ Are monitoring, observability, and logging strategies included (ELK, Prometheus, Grafana)?	Ops readiness
5. Security & Compliance	✅ Is there an approved threat model and security architecture review by InfoSec / CISO?	Security posture
	✅ Have IAM, encryption, and data protection controls been incorporated?	Data protection
	✅ Has a vulnerability and compliance scanning process been defined (e.g., Azure Defender, Prisma)?	Continuous compliance
6. Integration & Data Management	✅ Are integration patterns consistent with enterprise integration strategy (e.g., API-first, event-driven, Kafka)?	Interoperability
	✅ Have data ownership, lineage, and data quality rules been established?	Data governance
7. Application & Technology Stack	✅ Is the tech stack approved within the technology catalog?	Tech standardization
	✅ Are open-source components reviewed for licensing and support risk?	Risk management
	✅ Have scalability and capacity planning been done for chosen platforms?	Cloud readiness
8. Cloud Architecture (if applicable)	✅ Is the cloud deployment model (Public/Private/Hybrid) justified?	Strategic alignment
	✅ Are landing zones, IAM, network, and tagging aligned with cloud governance?	Compliance
	✅ Are FinOps, cost optimization, and autoscaling strategies in place?	Cloud efficiency
	✅ Is DR/BCP (Disaster Recovery/Business Continuity) architecture documented and tested?	Resilience
9. DevSecOps & Delivery	✅ Are CI/CD pipelines defined and automated with code quality and security gates?	Delivery governance
	✅ Has environment strategy (dev, QA, staging, prod) been defined?	Release consistency
	✅ Are IaC (Infrastructure as Code) and configuration management tools standardized?	Reproducibility
10. Operations & Support Readiness	✅ Has the support model (L1/L2/L3) been defined?	Operability
	✅ Is there a defined runbook / playbook for incident management?	Operational continuity
	✅ Are SLAs, SLOs, and error budgets defined and agreed with business/ops?	Accountability
11. Risk & Compliance Management	✅ Have key architecture risks been identified and logged in risk register?	Risk transparency
	✅ Is there a mitigation plan and residual risk approval by stakeholders?	Risk closure
12. Cost, Licensing, and ROI	✅ Is the TCO (Total Cost of Ownership) evaluated for 3–5 years?	Financial viability
	✅ Has ROI been validated with business sponsors?	Business case integrity
13. Governance & Traceability	✅ Are architecture decisions documented in ADR (Architecture Decision Record)?	Audit trail
	✅ Have all artifacts been stored in EA repository (e.g., LeanIX, Sparx EA)?	Repository compliance
	✅ Is there traceability between business capabilities, applications, and technology components?	Capability mapping

🧰 Tools / Frameworks Commonly Used

Frameworks: TOGAF ADM, Zachman, SAFe (Lean Portfolio Mgmt)
Tools:
- Architecture repository: LeanIX, Sparx EA
- Collaboration: Confluence, Jira, MS Teams
- Security & compliance: Prisma, Azure Defender
- Monitoring: Prometheus, ELK, Grafana

📊 KPIs to Track

% of projects reviewed by EARB
% of architecture compliance with standards
Number of design deviations approved vs rejected
Review turnaround time
Architecture risk closure rate
Cost optimization achieved through reuse / rationalization

🧭 Governance Cadence

Solution Review: Before design freeze
Final Architecture Review: Before build phase
Periodic Compliance Audit: Every 6 months
Exception Handling: Ad-hoc via Architecture Waiver Process

You’re absolutely right that both EARB (Enterprise Architecture Review Board) and SARB (Solution Architecture Review Board) review designs —but their scope, intent, and timing are very different.

Let’s break this down clearly and practically, based on how it works in real enterprise programs 👇

🧭 EARB vs SARB — Key Differences and Why Both Are Needed

Aspect	EARB (Enterprise Architecture Review Board)	SARB (Solution Architecture Review Board)
Purpose	Ensures enterprise-level strategic alignment and compliance with standards, principles, and reference architectures	Ensures solution-level design integrity, completeness, and fit-for-purpose implementation
Scope	Enterprise-wide — reviews architecture blueprints, reference models, technology standards, target states	Project or program specific — reviews solution design, data flow, integration, NFRs, cloud configuration
Focus	- Strategy alignment - Enterprise risk - Reuse & rationalization - Compliance to EA guardrails	- Detailed technical solution - Component-level design - Implementation readiness - Operational feasibility
Timing	Conducted early — during concept / initiation / architecture vision stages	Conducted later — during solution design / build preparation stages
Participants	Chief Architect (Chair), Domain Architects, Security Architect, Cloud CoE, Business Architect	Solution Architect (Presenter), Platform Leads, Infra, DevOps, InfoSec, Delivery Manager
Review Artifacts	Enterprise Architecture Roadmap, Reference Architecture, Standards Catalog, Target State Models	HLD (High-Level Design), LLD (Low-Level Design), Data Flow Diagrams, NFR checklist
Decision Outcome	Approves / updates enterprise standards and principles, grants deviations or waivers	Approves solution design for implementation or requests rework
Governance Cadence	Monthly or quarterly	Weekly / bi-weekly (per project)
Tools Used	LeanIX, Sparx EA, ArchiMate	Confluence, Draw.io, Lucidchart, Jira
Output Artifacts	- Approved target architecture - Technology reference models - EA compliance reports	- Approved design - Implementation go-ahead - Deviations & mitigations recorded

🧩 How They Work Together (Real Scenario)

Let’s take an example of a Cloud Transformation Program in a bank:

1️⃣ Phase 1 – Enterprise Architecture Level (EARB)

EARB defines Cloud Reference Architecture, Security Guardrails, Integration Patterns, and Technology Standards (e.g., Azure landing zones, API gateway, Kafka standards).
The goal: Create a strategic baseline and approved enterprise-level design principles.

2️⃣ Phase 2 – Solution Design Level (SARB)

Individual projects (e.g., Loan Origination, Payments, or Fraud Analytics) develop their Solution Architecture following those EA guardrails.
SARB reviews each solution’s design for compliance with those EARB-approved principles.
If the project needs an exception, SARB can escalate to EARB for approval.

3️⃣ Phase 3 – Delivery & Operations

SARB ensures the implemented solution remains aligned with the approved design.
EARB periodically reviews metrics, compliance trend, and risk posture across all SARBs.

🎯 In Summary — When Asked in Interview

“EARB and SARB are complementary governance layers.The EARB is strategic — it defines enterprise standards, target architectures, and ensures alignment to business strategy.The SARB is tactical — it validates that each solution or project design adheres to those enterprise guardrails and is technically sound for delivery.In large programs, EARB provides the ‘what’ and ‘why’, while SARB governs the ‘how’.SARB may escalate deviations to EARB for exception handling and risk acceptance.”

1️⃣ Pre-Initiation / Concept Phase — Enterprise Architecture Review (EARB – Strategic Review)

Purpose: Validate strategic fit, cloud adoption feasibility, and alignment with enterprise principles.Timing: Before project kickoff.

Key Inputs:

Business case / project charter
Target business capabilities
Initial high-level architecture concept
Enterprise standards, principles, and technology strategy

Key Stakeholders:

Chief Architect (Chair)
Enterprise Architects (Domain, Data, Security)
Business Architect
Program Sponsor / Business Head

Key Actions:

Check business alignment, reuse potential, compliance with enterprise strategy.
Approve high-level direction (“Yes, this initiative fits the enterprise roadmap”).

Output:

Approved “Statement of Architecture Work”
Go-ahead for detailed solution design
Recorded architectural decisions (ADR)

2️⃣ Solution Definition Phase — Domain / Solution Architecture Review (SARB – Tactical Review)

Purpose: Validate solution-level architecture for design completeness, standards compliance, and delivery feasibility.Timing: Before development or build phase.

Key Inputs:

High-Level Design (HLD) and Low-Level Design (LLD)
Security, Integration, and Infrastructure architecture documents
Non-functional requirements (NFRs)

Key Stakeholders:

Solution Architect (Presenter)
Domain Architect (Application / Data / Infra)
Security Architect
Cloud CoE Representative
Delivery Manager / PMO

Key Actions:

Deep-dive review of the solution components, integration patterns, and NFR compliance
Identify deviations; recommend mitigation or raise exception to EARB if required
Verify cloud landing zone, DevSecOps, IAM, and observability standards

Output:

Design approved for implementation (or conditional approval)
Risk register updated
Action plan for any remediation

3️⃣ Build / Implementation Phase — Technical Design Review (TDR)

Purpose: Validate technical implementation design decisions and environment readiness.Timing: Before build deployment or major milestone releases.

Key Inputs:

Updated LLDs, configuration scripts (IaC), CI/CD pipelines
Security and performance testing plan

Key Stakeholders:

Technical Leads / Dev Leads
Infrastructure & Cloud Engineers
Security Engineers

Key Actions:

Ensure build scripts, IaC, and security controls adhere to architecture-approved design
Validate test coverage, DR plan, and rollback strategy

Output:

Implementation readiness approval
Sign-off to move into deployment

4️⃣ Post-Implementation / Operational Readiness Review (ORR)

Purpose: Ensure the system is stable, secure, and compliant before go-live.Timing: Before production cutover.

Key Inputs:

Test results (UAT, performance, penetration testing)
Runbook / playbook
Monitoring dashboards & alerting setup

Key Stakeholders:

Operations / SRE Team
Security Operations (SOC)
Delivery Manager / Product Owner

Key Actions:

Validate NFRs in real conditions
Verify observability, DR, backup, and support model readiness

Output:

Go-live approval
Updated architecture repository with final implementation details

5️⃣ Continuous Compliance Review (EA Compliance Audit)

Purpose: Periodic review to ensure continued compliance with EA principles post-deployment.Timing: Quarterly / half-yearly

Key Stakeholders:

Enterprise Architect
Platform Owner
Security / Compliance Teams

Key Actions:

Check for drift from approved design
Track metrics: compliance %, deviations, risk posture
Feed learnings into reference architecture updates

Output:

EA compliance report
Architecture improvement actions

🧩 Visual Summary (Textual Flow)

[Business Case / Concept]
        ↓
(1) EARB Review – Strategic Fit & Approval
        ↓
(2) SARB Review – Solution Design & Standards Compliance
        ↓
(3) TDR – Technical Implementation Readiness
        ↓
(4) ORR – Operational Readiness & Go-Live Approval
        ↓
(5) Continuous EA Compliance Review – Post Go-Live

🧠 Key Insight (Interview-Ready Line)

“In a mature architecture governance setup, reviews flow from enterprise-level (EARB) to solution-level (SARB) and finally to technical and operational readiness reviews.EARB ensures strategic alignment, SARB validates design compliance, and TDR/ORR ensure delivery quality and operational stability.This layered sequence maintains both strategic control and delivery agility.”

Based on the architecture review checklist- does domain architect present solution in the same form- as per parameter

Let’s walk through this step-by-step from an Enterprise Architecture Review perspective 👇

✅ When a Domain Architect Presents a SolutBon for Review

Yes — the Domain Architect (for example: Application, Data, Infra, Integration, or Security Architect) presents the solution using the Architecture Review Checklist as the guiding template.However, the presentation is not just a “checklist readout” — it’s structured around the parameters defined in the checklist to ensure consistency, completeness, and compliance.

🔹 How It Works Practically

Before the Review (Preparation Phase):
- EA Governance team or EARB Secretariat circulates the Architecture Review Checklist (Excel or Confluence form).
- The Domain Architect fills in all relevant parameters:
  - Business alignment
  - Architecture principles compliance
  - Security and regulatory checks
  - Integration patterns
  - Data flow, lineage, privacy
  - Scalability, HA, DR
  - Tool/Technology adherence
  - Risk and deviation list
Input Artifacts:
- Solution Architecture Document (SAD)
- HLD (High-Level Design)
- Reference Architecture Mapping Sheet
- Deviation Requests (if any)
During the Review (Presentation Phase):
- The Domain Architect (often supported by Delivery or Solution team) presents the solution section by section, mapped to the checklist parameters.
- Example flow of presentation:
  1. Business context & capabilities impacted
  2. Solution overview & key design decisions
  3. Alignment with Target State Architecture
  4. Cloud pattern used (IaaS, PaaS, SaaS)
  5. NFR coverage (availability, performance, DR, RTO/RPO)
  6. Security architecture, encryption, IAM
  7. Integration pattern (event-driven, API, batch)
  8. Data management & governance
  9. Risk, mitigation, and technical debt
- Each of these sections corresponds to the Architecture Review Checklist criteria.
- The EARB Panel evaluates and marks each parameter as:✅ Compliant | ⚠️ Partially Compliant | ❌ Non-Compliant
After the Review (Decision Phase):
- The EARB issues one of the following outcomes:
  - Approved (fully compliant)
  - Approved with conditions (minor deviations, must be tracked)
  - Rejected / Rework required (major non-compliance)
- The Architecture Compliance Report is generated and stored in the EA repository (like LeanIX, ADO, or Confluence).
- Deviations, if any, are logged for periodic follow-up or future refactoring.

🔹 Example: How Domain Architect Uses Checklist Parameters

Parameter	What Domain Architect Presents	EA Board Expectation
Business Alignment	Business capability impacted, KPIs supported	Mapping to strategic themes
Architecture Principles	Which principles are satisfied or violated	Adherence score
Integration	API Gateway pattern, sync/async design	Use of enterprise integration standard
Security	Authentication, authorization, data encryption	Compliance with InfoSec standards
Cloud/Infra	Cloud service model, region, redundancy	Fit with Cloud Reference Architecture
Data	Storage, lineage, retention	Compliance with DGC (Data Governance Council)
NFRs	Load, HA, DR strategy	Meets SLA/RPO/RTO
Risks	List of deviations, mitigation plan	Acceptance or escalation

✅ So in summary

✔️ The Domain Architect presents the solution based on the checklist parameters — the checklist acts as the review lens.✔️ The presentation is structured to prove compliance, alignment, and traceability to enterprise standards.✔️ EARB captures final decision, deviations, and corrective actions in a formal log.

Template for Each

=====

🧭 1️⃣ EARB — Enterprise Architecture Review Board

🎯 Purpose

To validate strategic alignment and adherence to enterprise standards before any major initiative proceeds to design or implementation.

📄 Template / Deck Sections

Section	Description
Business Context	Capability/initiative overview, business drivers, KPIs
Architecture Vision	Target state, transition architecture, alignment with roadmap
Compliance Check	Principles, standards, reference architecture mapping
Cloud & Infra Strategy	Deployment model, multi-cloud alignment
Security & Risk	Alignment with InfoSec framework
Integration & Data	Enterprise integration patterns, master data impacts
Risk/Deviation	Non-compliance areas and mitigation plan
Decision	Approve / Approve with condition / Reject

🧰 Inputs

Business case
Conceptual architecture
Reference architecture mapping sheet
EA principles and standards

🧾 Output

EARB approval memo
Compliance report
Deviation log

🏗️ 2️⃣ SARB — Solution Architecture Review Board

🎯 Purpose

To validate the solution architecture design at the domain level — ensuring the implementation aligns with approved enterprise patterns.

📄 Template / Deck Sections

Section	Description
Solution Overview	Functional & non-functional requirements
Architecture Diagram	Logical, deployment, and integration views
Technology Stack	Approved tech catalog compliance
Security & Compliance	Application-level security controls
Integration Design	API design, messaging, and data exchange
Performance & Scalability	Load, throughput, and failover
Cost & Cloud Sizing	Cost optimization plan (FinOps alignment)
Risk & Dependencies	Identified risks and mitigations

🧰 Inputs

EARB-approved target architecture
High-level design document (HLD)
Technology standards catalog

🧾 Output

SARB decision record
Architecture compliance scorecard

🔩 3️⃣ TDR — Technical Design Review

🎯 Purpose

To validate detailed technical design and implementation readiness before build/deploy — ensuring design decisions meet both architectural and operational expectations.

📄 Template / Deck Sections

Section	Description
Module-level Design	Components, interfaces, class & sequence diagrams
Infra & Config	Network topology, VPC, IAM, CI/CD setup
Security Controls	TLS, secrets management, key rotation
Data Flow	DB schema, data mapping, encryption at rest/in-transit
Monitoring & Logging	AppInsights / ELK / Prometheus integration
Test Strategy	Unit, integration, and performance tests
Deployment Plan	Blue-green/canary rollout, rollback strategy
Operational Readiness	DR drill, backup, patching strategy

🧰 Inputs

Detailed design document (LLD)
Infra-as-code template
SARB-approved architecture

🧾 Output

TDR approval
Go-Live readiness certificate

🏛️ 4️⃣ How They Link Together (Sequence)

Idea / Business Case
     ↓
EARB  → Approves architecture direction & principles
     ↓
SARB  → Validates solution design and patterns
     ↓
TDR   → Approves detailed technical implementation
     ↓
Deployment & Post-Implementation Review

🔐 5️⃣ Governance Integration & Traceability

Each review template feeds into the Architecture Repository (Confluence, LeanIX, ADO).
Deviations raised in SARB or TDR are traced back to EARB decisions.
Compliance scorecards are maintained per project.
KPIs tracked: compliance %, rework %, architecture debt, approval lead time.

✅ Summary View

Board	Focus	Key Stakeholders	Tool / Framework	Output
EARB	Strategy & target alignment	Enterprise & Domain Architects, CIO, CTO	TOGAF, ADM Phases A–D	Architecture Charter, Compliance Report
SARB	Solution & design compliance	Domain, Solution, Infra, Security Architects	TOGAF, ISO 42010	Solution Approval, Scorecard
TDR	Build readiness	Tech Leads, DevOps, QA, Infra Teams	Cloud Well-Architected Framework	Go-Live Certificate, Residual Risk Log

🧭 1️⃣ EARB — Enterprise Architecture Review Board

🎯 Purpose

Review initiative or portfolio-level architecture for strategic alignment with enterprise roadmap, principles, and target state.

👤 Presenter

Enterprise Architect / Domain Architect (depending on scope)They present:
- Problem statement
- Target architecture vision
- Alignment with enterprise roadmap & standards
- Deviation or waiver requests

👥 Approvers (Voting Members)

Role	Responsibility
Chief Enterprise Architect (Chair)	Final approval authority
CTO / Chief Architect Office	Endorses strategic alignment
CISO / Security Head	Signs off on security compliance
Head of Infrastructure / Cloud CoE	Validates deployment alignment
Head of Data / Integration	Ensures data & integration standards
Program Director / Portfolio Manager	Represents delivery impact
Enterprise PMO (optional)	Tracks governance compliance

✅ Output

Approved / Approved with conditions / Rejected
Architecture Compliance Score
Deviation Log (if any)

🏗️ 2️⃣ SARB — Solution Architecture Review Board

🎯 Purpose

Review solution-level design for compliance with enterprise architecture and ensure all NFRs, data, security, and integration patterns are properly implemented.

👤 Presenter

Solution Architect / Domain ArchitectThey present:
- End-to-end solution design (HLD)
- Technology stack selection (vs. approved catalog)
- Integration, data flow, and API patterns
- Security, scalability, DR, and NFR coverage

👥 Approvers (Voting Members)

Role	Responsibility
Enterprise Architect (Chair)	Ensures solution aligns with EA target state
Security Architect	Validates InfoSec & compliance requirements
Cloud/Infra Architect	Validates hosting, HA/DR, FinOps alignment
Data Architect	Ensures compliance with data model & governance
Integration Architect	Validates API and messaging patterns
DevOps / Delivery Lead	Reviews delivery feasibility
Business / Product Owner	Confirms alignment with business KPIs

✅ Output

Approved / Conditional / Rejected
SARB Minutes of Meeting
Action log for remediation

🔩 3️⃣ TDR — Technical Design Review

🎯 Purpose

Review detailed technical implementation to ensure alignment with approved SARB design and readiness for deployment.

👤 Presenter

Technical Lead / Solution Architect / DevOps EngineerThey present:
- LLD (Low-Level Design)
- Infra setup, CI/CD, security controls
- Testing and monitoring readiness
- DR & rollback strategy

👥 Approvers (Voting Members)

Role	Responsibility
Lead Solution Architect (Chair)	Ensures design-to-implementation consistency
Infra / Cloud Architect	Approves infra and deployment design
Security Officer / CISO Rep	Validates access, IAM, encryption
QA / DevOps Lead	Confirms readiness for build & release
Application Owner / Business SME	Signs off functional acceptance
Operations Manager / SRE	Validates operational readiness

✅ Output

TDR approval for go-live
Deployment readiness checklist signed off
Residual risk log

📋 Summary Comparison Table

Review Board	Presenter	Approvers / Members	Focus Area	Output
EARB	Enterprise / Domain Architect	Chief EA, CTO Office, CISO, Cloud CoE	Strategic alignment, target architecture	Architecture charter approval
SARB	Solution / Domain Architect	Enterprise, Security, Cloud, Data, DevOps Leads	Solution design compliance	SARB approval or conditions
TDR	Technical Lead / Solution Architect	Solution, Cloud, Security, Ops Leads	Implementation & deployment readiness	Go-live readiness approval

✅ Governance Flow (Practical Sequence)

EARB  →  SARB  →  TDR
  ↑         ↑         ↑
 Strategic  Solution   Implementation
 Alignment  Design     Readiness

As enterprise Architect for ABC Bank,Align technical design with regulatory compliance, risk, and data privacy mandates.

ChatGPT said:

Perfect — this is exactly the kind of practical, scenario-based question that senior enterprise architecture interviews ask (especially in BFSI environments).

Let’s walk through — as if you’re the Enterprise Architect at ABC Bank, and you’ve been tasked to align technical design with regulatory compliance, risk, and data privacy mandates during a major transformation or cloud migration program.

🧭 Scenario Context

ABC Bank is modernizing its core systems, adopting microservices and moving workloads to cloud (Azure/AWS hybrid).You, as the Enterprise Architect, are responsible for ensuring that every technical design — whether on-prem or cloud — complies with banking regulations, data privacy laws, and enterprise risk policies.

🧱 1️⃣ Establish Governance & Accountability

Step	What You Do	Stakeholders	Output
1.1 Form the Architecture Risk & Compliance Council (ARCC)	Set up a working group with representatives from Enterprise Architecture, Risk, Compliance, and Information Security.	CISO, Head of Risk, Compliance Officer, Data Protection Officer (DPO), Chief Architect	ARCC charter & meeting cadence
1.2 Define Ownership	Assign data & compliance ownership at domain level (e.g., Risk Architect for Risk Controls, Security Architect for Cloud IAM).	Domain Architects, Risk Leads	RACI matrix for compliance accountability

⚙️ 2️⃣ Understand Applicable Regulations and Mandates

Area	Regulatory Reference	Examples
Data Privacy	GDPR, PDPB (India), RBI Data Localization	Data residency, consent management, right to erasure
Risk & Controls	RBI Master Directions, SOX, COBIT 5	Access control, segregation of duties, audit trails
Information Security	ISO 27001, NIST CSF	Encryption, vulnerability management, key rotation
Cloud Compliance	RBI Cloud Risk Guidelines, CSA CCM	Shared responsibility, data sovereignty, exit strategy

✅ You map each relevant clause to architecture control requirements.

🧩 3️⃣ Embed Compliance in Technical Design Lifecycle

Stage	Action	Tool / Framework	Output
EARB (Enterprise Architecture)	Validate architecture principles for compliance: data locality, encryption, zero trust, resilience.	TOGAF ADM (Phase B–D), NIST, RBI Guidelines	Compliance checklist per initiative
SARB (Solution Architecture)	Ensure solution design includes controls for data protection (masking, tokenization, IAM).	Cloud Well-Architected Framework (Security, Reliability)	SARB compliance report
TDR (Technical Design)	Verify encryption, access, logging, and audit trails are technically implemented.	DevSecOps pipelines, automated compliance scans	Signed TDR checklist

🔒 4️⃣ Define Architectural Controls and Patterns

Control Type	Architecture Enforcement
Data Security	All PII data encrypted (AES-256) in transit & at rest. Use KMS/HSM with key rotation.
Access Management	Enforce MFA, RBAC via Azure AD/Okta; least privilege principles.
Audit & Logging	Centralized SIEM (Splunk/Sentinel); immutable audit logs for RBI/SOX.
Data Residency	Customer data stored only in India regions (Azure Central India / AWS Mumbai).
Third-party Integration	Use API Gateway with OAuth2; ensure vendor SOC2/ISO27001 compliance.

📊 5️⃣ Embed Compliance into DevSecOps Pipeline

Step	Automation Control	Tools
Static Security Scan	SAST for code-level vulnerabilities	SonarQube, Checkmarx
Dependency Scan	Detect CVEs in libraries	OWASP Dependency Check
Infra Compliance	IaC policy enforcement	Terraform Sentinel, Azure Policy
Runtime Compliance	Container scan & config validation	Prisma Cloud, Aqua Security
Audit Evidence	Automated compliance reports	Confluence + ServiceNow integration

🔍 6️⃣ Periodic Review and Risk Governance

Review Board	Frequency	Focus	Output
EARB	Monthly	Strategic architecture & compliance posture	Architecture compliance dashboard
SARB	Per project milestone	Solution-level risk & control validation	Risk mitigation tracker
Risk & Compliance Council	Quarterly	Enterprise risk aggregation	Residual risk log, RCA summaries

📈 7️⃣ KPI & Metrics to Track

KPI	Description	Target
Architecture Compliance Score	% of designs compliant with EA & regulatory standards	≥ 95%
Residual Risk	% of open compliance findings post-review	≤ 5%
Audit Readiness	% of projects with traceable audit evidence	100%
Data Residency Violations	# of incidents per quarter	0
Automated Control Coverage	% controls automated in CI/CD	≥ 70%

🏁 8️⃣ Deliverables

Compliance-aligned Architecture Blueprint
Architecture Risk Register (linked to enterprise risk matrix)
Compliance-by-Design Framework (reusable reference for all future projects)
Updated EA Repository (LeanIX / Confluence / ADO) with evidence traceability
Quarterly Compliance Posture Report to CTO & CIO

🧠 How You’d Explain in an Interview

“At ABC Bank, I drove alignment between our cloud and on-prem designs with RBI and data privacy mandates.I established a governance model where every design went through compliance validation via EARB, SARB, and TDR.We automated checks for encryption, access, and data residency in our CI/CD pipelines using Azure Policy and Terraform Sentinel.I also chaired quarterly Architecture Risk Reviews with the CISO and DPO to ensure all deviations were tracked and mitigated.This reduced regulatory audit findings by 80% within two quarters.”