EARB/ARB

1️⃣ How Do You Run ARB? (Architecture Review Board)

ARB is not a meeting.It’s a governance mechanism to control architecture quality, risk, cost, and alignment.

🎯 Step 1: Define ARB Charter

Clearly define:

• Scope (All new systems? Only Tier-1 changes?)

• Review triggers:

  • New platform

  • Major integration

  • Cloud adoption

  • Vendor onboarding

  • Regulatory-impacting change

Without scope clarity, ARB becomes chaos.

🎯 Step 2: Standardized Submission Template

Every proposal must include:

1. Business objective

2. Current architecture

3. Proposed architecture diagram

4. NFRs (availability, performance, RTO/RPO)

5. Security model

6. Data classification

7. Integration points

8. Cost estimate

9. Build vs Buy analysis

10. Risk assessment

This prevents emotional decisions.

🎯 Step 3: Structured Review Dimensions

ARB evaluates across 7 pillars:

Pillar	What We Check
Alignment	Does it align with enterprise target architecture?
Security	IAM, encryption, PII handling
Reliability	HA, DR, resiliency patterns
Integration	Event-driven? APIs? Tight coupling?
Data	Duplication? Data ownership?
Cost	Capex/Opex impact
Compliance	RBI/GDPR/SOX implications

🎯 Step 4: Decision Outcomes

ARB decisions should be:

• Approved

• Approved with conditions

• Rework required

• Rejected

And everything documented.

No informal approvals.

🎯 Step 5: Post-Approval Governance

ARB doesn’t end after approval.

You track:

• Design compliance

• Drift detection

• Production alignment

Otherwise teams deviate later.

2️⃣ What Do You Evaluate?

This is critical. Interviewers want structure.

🏗 Architecture Evaluation Areas

1️⃣ Technical Fit

• Does it align with hybrid architecture?

• Does it reuse shared services (Kafka, API Gateway)?

• Is it introducing a new stack unnecessarily?

2️⃣ NFR Coverage

• Availability target?

• Scaling model?

• Latency expectations?

• DR plan?

3️⃣ Integration Strategy

• REST vs Event?

• Synchronous dependencies?

• Risk of cascading failures?

4️⃣ Data Governance

• Source of truth defined?

• Data duplication?

• Audit trail available?

5️⃣ Operational Readiness

• Monitoring defined?

• SLOs documented?

• Support model defined?

6️⃣ Vendor Risk (If Buy)

• Lock-in risk?

• Exit strategy?

• SLA commitment?

7️⃣ Long-Term Sustainability

• Tech roadmap?

• Skills availability?

• Community support?

🏛 1️⃣ ARB – Solution / Domain Level

Scope:Project or application specific.

Covers:

• Detailed solution architecture

• Cloud design

• Integration pattern

• Security model

• Data flow

• Deviation requests

When it happens:

• Before PTB (mandatory)

• Sometimes before PTD (high-level)

• During change requests

• During deviation handling

Frequency:

• Weekly or bi-weekly

Audience:

• Domain architects

• Security architect

• Infra architect

• App owner

• EA representative

Think of ARB as execution governance.

🏛 2️⃣ EARB – Enterprise Level

Scope:Strategic and cross-domain decisions.

EARB focuses on:

• Enterprise-wide technology standards

• New platform adoption

• Major transformation programs

• Core banking replacement

• Cloud strategy changes

• Vendor selection

• Enterprise data architecture shifts

EARB does NOT review every application.

It reviews:

• Things that affect the entire bank.

Frequency:

• Monthly or quarterly

• Or triggered by major strategic proposal

Audience:

• Chief Architect

• CTO / CIO

• Domain architecture heads

• Risk / Compliance leadership

Think of EARB as strategy governance.

🏦 Example to Make It Real

Let’s say bank decides to:

• Move to hybrid cloud

• Adopt a new event backbone

• Replace legacy core (e.g., Finacle modernization)

• Standardize on Kubernetes platform

That decision goes to EARB.

After EARB approves:

Each individual application migration goes to ARB for implementation review.

🔄 How They Connect

Flow typically looks like:

1. Strategic decision → EARB approval

2. Reference architecture/blueprint/principles.standard created

3. Individual solutions → ARB for compliance

So:

👉 EARB sets direction👉 ARB enforces alignment

🎯

“ARB operates at solution level, reviewing detailed architecture before Permit to Build. EARB operates at enterprise level, approving strategic architecture direction, new platform adoption, or major transformation initiatives. Once EARB approves a reference architecture, ARB ensures individual solutions conform to it.”

“Can ARB override EARB?”

Correct answer:

No.

EARB decisions are strategic standards.ARB enforces them and escalates conflicts back to EARB if needed.

🏦 Typical ARB Frequency in Banks

1️⃣ Weekly/BiWeekly ARB (Most Common for Active Transformation Programs)

In large transformation phases:

• ARB happens weekly

• Fixed slot (e.g., every Thursday 4–6 PM)

• Covers:

  • New solution proposals

  • Major design changes

  • Deviation requests

  • Cloud onboarding reviews

Why weekly?Because:

• Banking programs run continuously

• Delays impact business timelines

• Governance must not become bottleneck

This is most common in digital banking transformation.

2️⃣ Bi-Weekly (Stable Organizations)

If:

• Change velocity is moderate

• Fewer large programs running

ARB may happen every 2 weeks.

Still structured.Still mandatory for Tier-1 systems.

3️⃣ Ad-Hoc / Emergency ARB

In production-critical situations:

• Major incident

• Regulatory urgency

• Critical vendor change

You may call an extraordinary ARB session.

This shows maturity.

🎯 How to Run ARB

“In my previous role, we conducted ARB weekly during active transformation programs. For smaller change requests, we used a lightweight review model. Critical or regulatory-impacting changes required full ARB approval, while low-risk enhancements followed a fast-track review.”

That sounds practical.

📊 Realistic Governance Model in Banking

You can mention categorization:

Change Type	ARB Required?	Frequency
New platform onboarding	Yes	Weekly
Core banking change	Yes	Weekly
Cloud infra change	Yes	Weekly
Minor UI change	No (Lite Review)	On demand
Security deviation	Yes	Immediate

This shows governance tiering.

Say this:

“Governance should scale with risk. High-risk changes go through full ARB. Low-risk changes should not be delayed unnecessarily.”

That shows enterprise maturity.

Scenario: Deviation Request in ARB – Direct DB Access to Core Banking

Context:Core banking platform like Finacle

🔹 Situation

A Digital Lending team came to ARB with a request:

“For faster loan eligibility checks, we want read-only direct DB access to core banking customer tables instead of going through APIs.”

Reason they gave:

• API latency 250–300 ms

• High-volume eligibility checks during campaign

• Concern about performance impact

This was clearly against enterprise principle:No direct DB access to core banking.

How I Handled It (Step-by-Step)

1️⃣ First – I Didn’t Reject Immediately

Very important.

In ARB, if you immediately say “No,” teams feel blocked.

Instead I said:

“Let’s understand the performance bottleneck and business urgency.”

That changes tone from policing to partnership.

2️⃣ Clarified Business Impact

I asked:

• What is expected peak TPS?

• What happens if eligibility response is 300 ms?

• Is this revenue-critical campaign?

• What is fallback if DB access causes lock escalation?

They admitted:

• This was a marketing-driven timeline pressure.

• No proper load test had been done on APIs.

3️⃣ Explained Risk in Banking Terms

I framed risk in business language:

If we allow direct DB access:

• Core DB contention during EOD

• Potential deadlocks

• Audit observation risk

• Upgrade complexity

• RBI scrutiny (segregation violation)

Then I added:

“Core banking DB is a Tier-0 asset. Stability outweighs short-term speed.”

That sounds senior.

4️⃣ Proposed Alternative Architecture

Instead of rejecting, I gave solution:

Option A: Read Replica

• Create near real-time read replica

• Eligibility engine reads from replica

• No impact on production core

Option B: Cached Profile Store

• Build eligibility microservice

• Pre-fetch and cache customer risk data

• Event-driven updates from core

Option C: Bulk Pre-Computation

• Pre-calculate eligibility nightly

• Use incremental updates via events

Now ARB becomes solution forum.

5️⃣ Formal Governance Handling

Since they insisted timeline was critical:

We processed as temporary deviation with:

• Documented risk acceptance

• 60-day validity

• Monitoring thresholds

• Mandatory migration plan

• CTO sign-off

Deviation was time-bound.

After 45 days:We moved them to read-replica model.

Why This Sounds Realistic

Because in banking:

• Marketing pressure exists

• Core stability is sacred

• Audit trail matters

• Deviations are controlled, not emotional

“Yes, I handled a deviation request where a lending team requested direct DB access to core banking for performance reasons. Instead of rejecting, I evaluated business urgency, quantified risk, and proposed safer alternatives like read replicas and event-driven caching. We allowed a time-bound deviation with risk documentation and CTO approval, and transitioned them within 60 days. Governance must be firm but solution-oriented.”

🔹 Scenario – Security Deviation (Hardcoded Secrets in Microservice)

Context

Digital onboarding microservice deployed on cloud.

Team requested deviation:

“We want to temporarily store DB credentials in config file because Vault integration is taking time.”

This violates DevSecOps and security principles.

🚨 Risk

• Credential exposure

• Audit observation

• RBI cyber security non-compliance

• Insider threat risk

🧭 How I Handled It

Step 1: Understand Timeline Pressure

They had a regulatory launch deadline.

I asked:

• Is production go-live dependent?

• Can we isolate environment?

• What is blast radius?

Step 2: Define Guardrails Instead of Flat Rejection

I did NOT allow plaintext secrets.

Instead approved deviation with:

• Encrypted config using KMS

• Restricted IAM role

• Network isolation

• Mandatory migration to Vault in 30 days

• Security team sign-off

• Deviation logged in risk register

Step 3: Follow-Up Mechanism

• Added expiry date in governance tracker

• Reviewed in next ARB

• Ensured Vault integration completed before scale-out

🎤

“Yes, I handled a security deviation where a team wanted to bypass secret management due to timeline pressure. Instead of rejecting outright, I enforced encryption, IAM restrictions, documented the risk, and approved it as a 30-day temporary exception with mandatory remediation. Governance must reduce risk without blocking delivery.”

🔹 Scenario – Cloud Cost Deviation (Overprovisioned Kubernetes Cluster)

Context

Payments modernization project.

Team proposed:

• Always-on high-capacity Kubernetes cluster

• Multi-zone active-active

• For a product with 200 TPS peak

Clearly over-engineered.

🚨 Risk

• 3x infrastructure cost

• Low utilization

• No clear SLO justification

🧭 How I Handled It

Step 1: Ask Business Justification

• What is target SLA?

• What is revenue impact per hour outage?

• What is actual TPS forecast?

Turned out:

• No formal capacity planning done

• Designed based on “future scale”

Step 2: Propose Right-Sized Architecture

Instead:

• Active-passive DR

• Auto-scaling enabled

• Horizontal pod autoscaler

• Performance testing before scale commitment

Step 3: Conditional Approval

Approved lower capacity cluster with:

• Load testing milestone

• 60-day scale reassessment

Saved ~35% infra cost annually.

🎤 How to Say It in Interview

“I’ve rejected over-engineered cloud designs where resilience was not justified by business criticality. In one payments case, we right-sized Kubernetes deployment based on actual SLO and TPS projections, saving nearly 30–40% cost while maintaining availability targets.”

This shows cost governance maturity.

🔹 Scenario – Regulatory Data Localization Conflict

Context

Analytics team wanted to use global SaaS data warehouse.

But RBI requires:

• Data localization

• Controlled cross-border data flow

🚨 Risk

• Regulatory penalty

• Data sovereignty breach

• Reputational risk

🧭 How I Handled It

Step 1: Involve Compliance Early

Called:

• CISO

• Compliance head

• Legal

Never handle regulatory deviation alone.

Step 2: Architectural Compromise

Instead of full SaaS:

• Sensitive data masked

• PII tokenized

• Raw data retained onshore

• Only anonymized aggregates sent offshore

Step 3: Risk Documentation

• Legal clearance obtained

• Data flow documented

• Periodic audit review mandated

🎤 How to Say It in Interview

“In a data localization scenario, we avoided outright rejection by designing a hybrid model — keeping sensitive customer data onshore and exporting only anonymized aggregates. Governance must align innovation with regulatory boundaries.”

🏛 Scenario 1: ARB Escalates to EARB

📌 Situation: Enterprise Event Platform Standardization

Bank had standardized on a single event backbone (say Kafka-based) approved at enterprise level.

A Wealth Management program came to ARB proposing:

• Adoption of a niche event streaming product bundled with a vendor platform

• Argument: “It’s optimized for low-latency trading use case.”

This conflicts with enterprise standard.

🚨 Why ARB Couldn’t Decide Alone

ARB’s role:

• Enforce standards

• Evaluate deviations

But here:

• The decision affects enterprise event strategy

• Impacts platform standardization

• Impacts licensing and skill strategy

• Creates long-term tech fragmentation

This exceeds ARB authority.

🧭 What I Did

Step 1: Structured Risk Assessment

We evaluated:

• Latency requirements

• Capability gap in existing enterprise platform

• Vendor lock-in risk

• TCO impact

• Skill impact across org

Step 2: Documented Trade-off Paper

Prepared a short architecture decision paper including:

• Current enterprise standard

• Business justification

• Alternatives

• Risk if exception granted

• Impact if denied

Step 3: Escalated to EARB

Presented to EARB because:

• This is strategic deviation

• Impacts enterprise platform direction

🏁 Final Outcome

EARB decision:

• No new event platform adoption

• Instead enhance enterprise Kafka cluster

• Create low-latency configuration for wealth use case

Enterprise consistency maintained.

🎤 How to Say It in Interview

“In one case, ARB encountered a deviation that conflicted with enterprise technology standards. Since the decision would fragment platform strategy, we escalated it to EARB with a structured trade-off paper. EARB decided to enhance the enterprise platform rather than introduce a new one, preserving long-term architectural consistency.”

🏛 Scenario 2: Business vs EARB Conflict

📌 Situation: Cloud Data Residency Issue

Bank had EARB-approved policy:

• All customer PII must remain onshore.

Business unit wanted:

• Quick deployment of global SaaS CRM platform

• Hosted outside India

• To meet aggressive growth targets

🚨 Conflict

Business:

• Speed and global integration

EARB:

• Regulatory compliance

• Data localization

• RBI cyber security risk

🧭 How I Handled It

Step 1: Don’t Position as “Business vs Architecture”

Instead framed as:

“How do we achieve business objective within regulatory guardrails?”

Tone matters.

Step 2: Conduct Structured Impact Analysis

Evaluated:

• Which data fields are truly PII?

• Can we tokenize?

• Can we split architecture?

• Can sensitive data stay onshore?

Step 3: Proposed Hybrid Model

• Core PII stored in local data center

• SaaS CRM stores tokenized IDs

• Real-time API fetch from onshore system

• Audit logging enabled

Step 4: Took Revised Model to EARB

EARB approved hybrid model.

Business achieved launch timeline.Compliance maintained.

🎤 How to Say It in Interview

“When business objectives conflict with enterprise standards, my approach is not to block but to reframe the problem. In a SaaS CRM case, instead of violating data localization policy, we designed a hybrid architecture keeping PII onshore and tokenizing external data. EARB approved the revised design, balancing growth and compliance.”

🔥 Scenario 1: Tough CTO Challenges Your EARB Escalation

📌 Situation

You escalated a platform deviation to EARB because it violated enterprise standard (e.g., introducing a second event streaming platform when one already exists).

CTO says in meeting:

“Why are we slowing down business with bureaucratic escalation? Let the program proceed.”

Now this is a power moment.

❌ What NOT to Do

• Do not argue emotionally.

• Do not defend ego.

• Do not say “Policy says so.”

• Do not contradict CTO publicly.

You must show calm strategic reasoning.

✅ How You Handle It (Step-by-Step)

1️⃣ Acknowledge Business Urgency

Start with alignment:

“I completely understand the urgency and revenue impact.”

This shows you’re not rigid.

2️⃣ Frame Escalation as Risk Management, Not Bureaucracy

Then say:

“The escalation was not to delay delivery, but because adopting a second platform affects long-term cost, skills, vendor lock-in, and enterprise integration.”

Now you shift the lens from short-term to strategic.

3️⃣ Offer Structured Trade-Off View

Say:

“If we approve this, we create fragmentation. If we enhance the enterprise platform, we maintain standardization and reduce future TCO.”

Make it data-driven, not emotional.

4️⃣ Offer Controlled Alternative

Very important:

“If business timeline is critical, we can allow temporary exception with defined sunset and parallel enhancement of enterprise platform.”

🎤

“In one instance, a CTO questioned why we escalated a deviation to EARB. I clarified that the escalation was due to enterprise-wide impact, not procedural rigidity. I presented a structured trade-off analysis and proposed a time-bound controlled exception if urgency required it. Governance must protect long-term architecture without appearing bureaucratic.”

Pause.

🔥 Scenario 2: “Have You Ever Been Overruled?”

This is a classic ego test.

Correct answer is:👉 Yes.

If you say no, you look unrealistic.

📌 Example

Business wanted to adopt a vendor digital onboarding suite that overlapped with an internal platform.

You recommended:

• Extend internal platform

• Avoid duplicate stack

• Reduce TCO

But executive committee approved vendor due to time-to-market pressure.

🧭 How You Handled It

1️⃣ Accept Decision Professionally

“Once decision was taken, my role shifted from resisting to risk-mitigating.”

Very mature line.

2️⃣ Reduced Future Risk

You ensured:

• API-based integration (avoid deep coupling)

• Data ownership clarity

• Contract exit clauses

• No DB-level integration

• Vendor performance SLAs

You protected enterprise architecture even though your recommendation wasn’t chosen.

3️⃣ Captured Architectural Debt

Documented as:

• Strategic exception

• Future consolidation opportunity

🎤

“Yes, I have been overruled. In one case, a faster vendor solution was chosen over extending an internal platform. Once the decision was made, I focused on minimizing architectural risk by enforcing loose coupling and clear data ownership. Enterprise architecture is not about winning arguments — it is about safeguarding long-term stability.”

“At enterprise level, architecture is about influence, not authority.”

No — Tollgates and ARB are related, but they are NOT the same thing.

Let me explain.

🏗️ 1️⃣ What Are Tollgates?

Tollgates are stage-control checkpoints in the modernization lifecycle.

Typical flow in banks:

• Permit to Design (PTD)

• Permit to Build (PTB)

• Permit to Test

• Permit to Deploy

• Permit to Operate (PTO)

These are program governance controls.

They answer:

“Is this initiative mature enough to move to the next phase?”

Tollgates are lifecycle-based.

🧩 2️⃣ What Is ARB?

ARB (Architecture Review Board) is:

A technical governance forum that ensures solution alignment with enterprise architecture principles.

ARB reviews:

• Architecture design

• Deviation requests

• Technology choices

• Integration patterns

• Cloud onboarding

• Security posture

ARB is architecture-focused, not phase-focused.

🎯 How They Relate

ARB often feeds into tollgates.

Example:

Before Permit to Build:

• Architecture must be approved by ARB.

Before Permit to Operate:

• Production architecture review

• DR readiness review

• Security sign-off

So:

👉 Tollgate = Program approval checkpoint👉 ARB = Technical architecture validation forum

🏦 Real Banking Scenario

In a core modernization program (e.g., decoupling services from Finacle):

Permit to Design (PTD)

• Business case approved

• High-level architecture presented

• Initial ARB review conducted

Permit to Build (PTB)

• Detailed architecture approved by ARB

• Security clearance

• Cost approval

• Data governance clearance

Permit to Operate (PTO)

• DR tested

• Performance validated

• Observability configured

• Final architecture compliance confirmation

Notice:ARB participates at multiple stages — but tollgate is bigger governance event.

🧠

“Tollgates and ARB serve different purposes. Tollgates are lifecycle control checkpoints such as Permit to Design or Permit to Operate. ARB is the technical forum that validates architecture alignment. Typically, ARB approval is a prerequisite for passing certain tollgates like Permit to Build.”

“Who owns tollgates vs ARB?”

You answer:

• Tollgates → Program governance / PMO / Steering committee

• ARB → Enterprise Architecture function

“Strong governance integrates ARB decisions into tollgate outcomes, ensuring architecture compliance is not bypassed for schedule pressure.”

🏗 How ARB and Tollgates Actually Work in Practice

Think of it like this:

• Tollgate = Phase control checkpoint

• ARB = Technical compliance checkpoint

They intersect — but they are not identical.

🧭 Typical Banking Lifecycle Flow

1️⃣ Before Permit to Design (PTD)

Usually:

• High-level architecture is reviewed.

• Conceptual solution is validated.

In many banks:

• A lightweight ARB or architecture pre-review happens here.

• Focus is on direction, not deep design.

Not always a full ARB.

2️⃣ Before Permit to Build (PTB) → This is Critical

This is where ARB is almost always mandatory.

Why?

Because now:

• Detailed solution architecture is ready

• Technology stack is chosen

• Integration patterns defined

• Security model defined

• Data model defined

At this stage:ARB ensures:

• Alignment to enterprise principles

• No duplication

• No policy violations

• Cost optimization

• Cloud readiness

• Security compliance

So yes — ARB typically must clear before PTB.

3️⃣ Before Permit to Operate (PTO)

This is not always called ARB.

Instead it may be:

• Production Readiness Review (PRR)

• Operational Readiness Review (ORR)

• Security sign-off

• DR validation

Architecture team may participate, but it’s broader than ARB.

🏦 Realistic Model in Large Banks

You can explain it like this:

Stage	ARB Required?	Type
PTD	Sometimes (High-level review)	Concept Review
PTB	Yes (Mandatory)	Full ARB
PTO	Architecture validation may be part of ORR	Operational Review

“ARB does not necessarily precede every tollgate, but detailed ARB approval is typically mandatory before Permit to Build. Before Permit to Operate, architecture validation becomes part of production readiness or operational review rather than a pure ARB session.”

“In mature governance models, ARB decisions are recorded as formal decision logs, which become prerequisite artifacts for tollgate approvals.”

🏗 Scenario: Multi-Wave Cloud Migration Program

Example:

• Wave 1 → 8 applications

• Wave 2 → 10 applications

• Wave 3 → 7 applications

Each application follows:

• PTD

• PTB

• PTO

Now the question is:

👉 Does ARB happen for every application before PTD/PTB?👉 Or do we do something smarter?

🎯 How Mature Banks Handle This

You don’t run a full ARB independently for every app in every wave.

Instead, governance is layered.

1️⃣ Wave-Level Architecture Approval (Foundation ARB)

Before Wave 1 starts:

You present a reference cloud architecture:

• Landing zone design

• Network topology

• IAM model

• Logging & monitoring

• DR pattern

• CI/CD pipeline

• Security baseline

This is reviewed in a program-level ARB.

Once approved:

All applications in that wave must conform to it.

This avoids repeated debate.

2️⃣ Application-Level Review (Conformance Check)

Now each application:

Before PTB:

• Submits architecture pack

• Shows how it aligns to approved reference

• Highlights deviations (if any)

If:

• Fully aligned → Fast-track approval

• Minor gap → Conditional approval

• Major deviation → Full ARB discussion

This keeps throughput high.

3️⃣ What Happens at PTD?

PTD typically includes:

• Migration strategy (Rehost / Refactor / Replatform)

• Dependency map

• Data sensitivity classification

• Cloud cost estimate

A lightweight architecture review is sufficient here.

Deep technical ARB happens before PTB.

4️⃣ Before PTO

Architecture team participates in:

• Production readiness review

• DR validation

• Observability confirmation

• Security closure check

But this is not always a full ARB forum.

🏦 Realistic Interview-Ready Answer

You can say:

“In multi-wave cloud migration programs, we first conduct a wave-level ARB to approve the cloud reference architecture. Then each application goes through a conformance review before Permit to Build. Only deviations are escalated to full ARB. This ensures governance without slowing program velocity.”

Pause.

That sounds operationally experienced.

🔥 Very Important – Show Risk-Based Governance

Add this:

“High-risk applications — such as those integrating with core banking platforms like Finacle — receive deeper ARB scrutiny compared to low-risk internal applications.”

1️⃣ “Can you operate under executive pressure?”

“Yes, and I believe pressure is part of enterprise architecture, especially in banking where regulatory, business, and technology priorities often collide.”

• Production incident during high-value campaign

• Executive asking for immediate rollout despite incomplete risk assessment

• You balanced urgency with control

Explain what you did:

1. Acknowledged urgency

2. Presented risk clearly in business terms

3. Proposed controlled rollout (feature toggle / phased deployment)

4. Defined rollback strategy

Close with:

“Under pressure, my role is to slow down chaos without slowing down delivery.”

That line is strong.

2️⃣ “Do you escalate appropriately?”

“I escalate when a decision crosses domain boundaries, affects enterprise standards, or introduces systemic risk. I do not escalate operational disagreements.”

Then give clarity:

I escalate when:

• Strategic platform deviation

• Regulatory exposure

• Multi-domain impact

• Vendor lock-in risk

I don’t escalate when:

• Minor implementation choice

• Local optimization issue

• Team-level conflict

Close with:

“Escalation should be about risk exposure, not hierarchy.”

3️⃣ “Do you protect enterprise interest?”

“Yes. My responsibility is to think beyond the immediate project and evaluate impact on cost, risk, operability, and architectural integrity.”

Give example:

• Business wanted quick SaaS adoption

• You ensured:

  • Data localization compliance

  • Exit clauses in contract

  • API-based integration

  • Avoided hard coupling

“Enterprise architecture must safeguard tomorrow while enabling today.”

4️⃣ “Do you drop ego when needed?”

“Absolutely. Architecture is about influence, not authority. Once a decision is made at executive level, my focus shifts from advocating to risk mitigation.”

Give example:

• Your build recommendation rejected in favor of vendor buy

• You ensured loose coupling

• Captured architectural debt

• Planned future consolidation

Close with:

“It’s not about being right. It’s about protecting the organization.”

5️⃣ “Do you enable business even after disagreement?”

“Yes. In fact, that’s when architecture adds the most value.”

Explain:

When business decision differs from your recommendation:

1. Accept decision professionally

2. Identify risk areas

3. Add compensating controls

4. Monitor impact

5. Revisit if needed

Example:

• Overruled on vendor choice

• You ensured API isolation, SLA clauses, data ownership clarity

Close with:

“Once direction is decided, I fully support execution while ensuring risks are visible and managed.”

🔥 The Meta Message You Must Convey

Across all answers:

• Calm

• Structured

• No ego

• Risk-aware

• Business-aligned

• Regulatory-conscious

• Long-term thinker

💎 One Powerful Closing Thought

“At enterprise level, architecture is less about diagrams and more about judgment under pressure.”

🧨 1️⃣ “Why can’t we just move everything to cloud and simplify?”

Why This Is a Trap

They want to see:

• Are you cloud-blind?

• Do you understand regulatory constraints?

• Do you think strategically?

How to Answer

“Cloud is an enabler, not a strategy by itself.”

Then explain:

• Regulatory constraints (data localization, RBI guidelines)

• Core banking latency dependencies

• EOD batch impact

• Network dependency risk

• Cost unpredictability at scale

Add balance:

“I believe in cloud-first, but not cloud-only. The decision should be workload-based.”

🧨 2️⃣ “If ARB slows business, should we remove it?”

Why This Is a Trap

They’re testing whether you defend bureaucracy or defend agility.

How to Answer

“If ARB is slowing business, the issue is process design — not governance itself.”

Then explain:

• Risk-based tiering

• Fast-track reviews for low-risk changes

• Reference architecture reuse

• SLA for ARB response time

Close with:

“Governance should accelerate safe delivery, not obstruct it.”

That shows you don’t cling to power.

🧨 3️⃣ “Have you ever made a wrong architectural decision?”

“Yes. Early in a transformation program, I underestimated integration complexity with a legacy payments switch.”

Then show learning:

• Caused delay

• You introduced integration blueprint template afterward

• Improved dependency mapping process

Close with:

“Architecture maturity comes from recognizing blind spots early.”

That shows growth mindset.

🧨 4️⃣ “If business head says ‘I’ll take the risk,’ do you still block?”

Why This Is a Trap

They’re testing whether you understand regulatory accountability.

Strong Answer

“In banking, certain risks cannot be transferred verbally. Regulatory, cyber, and systemic risks must be formally documented and approved at appropriate governance level.”

Then clarify:

• If risk is strategic → escalate to EARB / risk committee

• If operational → document and monitor

• If regulatory breach → cannot approve

Close with:

“Enterprise architecture cannot override regulatory boundaries.”

That’s a powerful line.

🧨 5️⃣ “Why do we need an Enterprise Architect at all?”

This is psychological.

They want to see if you understand the value of the role.

Good Answer

“In complex banking environments, individual solutions may optimize locally but create enterprise-wide fragmentation. Enterprise architecture ensures coherence — across cost, risk, scalability, and compliance.”

Then add:

• Avoid duplicate platforms

• Prevent vendor sprawl

• Protect core stability

• Enable long-term agility

Close with:

“Enterprise architecture is about protecting systemic integrity while enabling change.”

“Microservices or monolith?”

Correct answer:

“Context-driven decision. High-change domains benefit from microservices. Stable domains may remain modular monolith.”

🏦 Example 1: Cloud Migration of Core Banking Workloads

(Example: Core on Finacle)

Situation

Bank wanted to migrate core banking middleware layer to cloud.

Options Evaluated

1️⃣ Lift-and-shift to IaaS2️⃣ Replatform to managed PaaS (DBaaS, managed Kubernetes)3️⃣ Hybrid – core DB on-prem, app tier on cloud

Cost-Benefit Analysis You Can Say

“We conducted TCO analysis over 5 years, including infra cost, licensing, operational manpower, DR setup, and regulatory compliance overhead.”

Option 1 – Lift & Shift

• Lower short-term migration effort

• No refactoring cost

• But high ongoing infra cost

• No operational efficiency gain

Option 2 – Replatform

• Higher upfront transformation cost

• Reduced ops manpower

• Improved elasticity

• Lower DR cost due to managed services

Option 3 – Hybrid

• Lower regulatory risk

• Controlled migration

• But higher integration complexity

Recommendation Framing

“We recommended phased replatforming for non-critical workloads first to reduce operational overhead by ~20–25% while keeping regulatory-sensitive components hybrid. This balanced cost optimization with operational risk.”

That sounds very real.

💳 Example 2: Enterprise API Gateway Consolidation

Bank had:

• Separate API gateways for retail and corporate.

Problem

• Duplicate licensing

• Separate support teams

• Inconsistent security policies

Your Cost-Risk-Performance View

“We compared continued domain autonomy versus enterprise consolidation.”

Costs Considered:

• Licensing duplication

• Support FTE cost

• DR duplication

• Security audit overhead

Risk Considered:

• Security fragmentation

• Inconsistent throttling rules

• Regulatory audit complexity

Performance Considered:

• Latency impact

• Throughput scaling

Recommendation

“We recommended consolidation into enterprise-grade API gateway with shared governance but domain-level routing autonomy. This reduced licensing cost by ~18%, improved security posture, and simplified compliance audits.”

That’s an enterprise answer.

☁️ Example 3: Managed Database vs Self-Hosted Database

For lending platform modernization.

Options:

1️⃣ Self-managed database on VM2️⃣ Managed DB service (cloud provider)

Trade-Off Analysis You Can Say

“While managed database appeared 15–20% more expensive on pure infra comparison, we factored in operational cost, patching overhead, security compliance effort, backup management, and DR testing manpower.”

When you add:

• 24x7 DBA support

• Regulatory audit effort

• Patch management risk

• Outage impact cost

Managed DB often becomes cost-effective long-term.

Smart Conclusion

“We recommended managed database for customer-facing workloads to reduce operational risk and improve resilience, while retaining self-managed database for stable internal batch systems where elasticity was not required.”

That shows nuanced thinking.

🔐 Example 4: IAM Platform Consolidation

Proposal: Replace multiple authentication systems with enterprise IAM platform (e.g., Ping Identity)

Cost Factors:

• Licensing

• Migration effort

• Integration rework

Benefit Factors:

• Reduced fraud risk

• Unified audit trail

• Improved customer experience

• Reduced regulatory penalties risk

Interview Line

“Although upfront licensing investment was significant, the long-term benefit included fraud reduction, simplified compliance reporting, and improved digital onboarding. We evaluated potential fraud loss exposure and regulatory penalty risk as part of cost-benefit modeling.”

Now you sound like someone thinking beyond infra cost.

🧠 Important: How to Structure Answer in Interview

Use this 5-step pattern:

1️⃣ Define problem2️⃣ List options3️⃣ Mention cost dimensions (infra, licensing, manpower, DR, audit)4️⃣ Mention risk dimensions (regulatory, operational, security, vendor lock-in)5️⃣ Recommend balanced approach

🎯 Golden Line for Banking

You can say:

“In banking, cost optimization cannot be viewed purely from infrastructure expense. We evaluate total cost of ownership including regulatory compliance overhead, operational resilience requirements, and potential risk exposure.”