Behaviour Architecture Q & A

Tell me abput a time your architecture decision backfired.

S – Situation:

I was leading the architecture for a customer onboarding system at a financial institution. To accelerate development and isolate responsibilities, I designed the system with multiple fine-grained microservices — each responsible for a small domain like KYC, customer validation, document upload, and notifications.

T – Task:

My objective was to increase agility and support independent deployments by breaking down the onboarding flow into 7+ small microservices with REST interfaces and shared APIs.

A – Action:

We went live with this microservice setup. While the design looked clean on paper, in reality: Services had too many synchronous dependencies. There was tight coupling in the onboarding workflow due to lack of event-based orchestration. A single slow service (e.g., document verification) caused end-to-end slowness. Deployment coordination became complex, and troubleshooting took longer due to distributed tracing gaps.

R – Result:

Within weeks, we faced customer complaints due to timeouts and delays. The platform’s reliability metrics dropped, and onboarding success rate decreased by ~18%.We reworked the architecture to: Group tightly coupled domains into coarser-grained services. Use asynchronous messaging (Azure Event Grid) for critical flows. Introduce retry and circuit breaker patterns for resilience.

✅ Lesson Learned:

I learned that going “too micro” too soon can backfire — especially when team maturity, tooling, and observability aren’t fully in place.Today, I advocate for “modular monolith first” or “macroservices”, followed by gradual decomposition, and I validate operability and team readiness before deep fragmentation.

🖼️ Slide Title:

Architecture Decision Backfired – Lessons & Remediation

Issue	Cause	Remediation Strategy
Over-fragmented microservices for onboarding	Too many synchronous dependencies, increased latency	Consolidated into macroservices, introduced async communication via Event Grid
Tight coupling between services	REST APIs without circuit breakers or retries	Implemented fallback mechanisms and circuit breakers
Complex deployment & debugging	Distributed systems without full tracing	Introduced centralized logging, App Insights, and distributed tracing
Decreased onboarding success rate	High end-to-end latency and fragile chains	Re-architected for resilience, monitored key workflow KPIs

Tell me about a strategic architecture decision that delivered business value.”

🎤 Answer: Strategic Architecture Decision – Delivered Business Value

✅ S – Situation:

At my previous company, we were facing slow time-to-market for mutual fund products. Launching a new fund required changes across a monolith platform — from UI to backend to reporting — which took 3–4 months per release and was error-prone due to tight coupling.

✅ T – Task:

My responsibility was to re-architect the platform to improve agility, reduce release cycles, and align with SEBI compliance and investor experience goals.

✅ A – Action:

I proposed and led a domain-driven, microservices-based architecture on Azure. Key strategic decisions included: Segmenting the platform by business capabilities (Onboarding, Transaction, NAV, Compliance, Portfolio) Deploying services on Azure Kubernetes Service (AKS) with independent pipelines Implementing an API-first strategy using Azure API Management for secured access Introducing Azure Event Grid for decoupled workflows (e.g., investment events → portfolio update → notification) Building CI/CD automation with GitHub Actions and Terraform, enabling on-demand releases Integrating Azure Sentinel, Key Vault, and Defender for a security-first approach

✅ R – Result:

The new architecture achieved the following business outcomes:

Time-to-market for new fund schemes reduced from 90 days to under 30 days

Investor onboarding time dropped from 10+ minutes to under 3 minutes

Compliance audit readiness improved (100% success across SEBI checkpoints)

Enabled 50% more releases per quarter with zero critical P1s

Gave business teams the confidence to pilot new investor journeys and digital experiences

💡 Summary Lesson:

This experience reinforced that strategic architecture isn’t just about tech stacks — it’s about enabling agility, compliance, and innovation at scale. By aligning architecture decisions directly with business KPIs, we moved from being a support function to a true business enabler.

how did you align architecture with business okr

Aligning architecture with business OKRs (Objectives and Key Results) is a hallmark of strong enterprise leadership. Here's a structured, senior-level answer you can use in interviews or strategic discussions:

🎤 How Do You Align Architecture with Business OKRs?

✅ 1. Start with Business Objectives, Not Technical Tools

I begin by partnering with business leaders to understand their top OKRs—whether it's growing AUM by 15%, reducing investor onboarding time, or increasing digital product adoption. Architecture decisions are then reverse-engineered from those goals, not built in isolation.

✅ 2. Translate Business OKRs to Architecture-Influenced Key Results

Business Objective (O)	Architecture-Influenced KRs
Reduce onboarding TAT by 50%	Deliver eKYC microservice with <3s API response time
Improve fund product release cycle from 90d → 30d	CI/CD automation + modular microservices in AKS
Ensure 100% SEBI compliance	Immutable audit logs + policy-as-code + Azure Sentinel
Grow active investors by 20%	Scalable APIs, frictionless UI, and real-time portfolio view

✅ 3. Create Architecture Metrics Tied to OKRs

Every major system design includes business-aligned KPIs like:

• API latency

• Platform uptime (SLOs)

• Time to onboard a new fund product

• Recovery Time Objective (RTO) for DR

• Cost per transaction

These metrics become part of quarterly health checks, reviewed alongside OKRs.

✅ 4. Establish Architecture Governance That Supports OKRs

I set up Architecture Review Boards (ARB) where designs are assessed not just for technical correctness but for their impact on OKRs.For example: a proposal may be rejected if it doesn't move the needle on agility, even if it's technically sound.

✅ 5. Close the Loop with Feedback and OKR Retrospectives

After delivery, I ensure we assess whether architecture moved the business needle.This informs future design patterns, capability prioritization, and technical debt payoff.

🧠 Summary Thought:

Architecture aligned with OKRs transforms IT from a delivery engine to a strategic business enabler. I focus on traceability from OKRs → capabilities → architecture → delivery metrics.

🎯 Slide Title: Aligning Architecture with Business OKRs

Business Objective (O)	Architecture-Influenced Key Results (KR)
Reduce onboarding TAT by 50%	eKYC microservice with <3s API response time
Improve fund product release cycle from 90d → 30d	CI/CD automation + modular AKS microservices
Ensure 100% SEBI compliance	Immutable audit logs, policy-as-code, Azure Sentinel
Grow active investors by 20%	Scalable APIs, real-time dashboards, frictionless UI/UX

Footer/Closing Text (Optional):“Architecture is not just about systems — it’s about driving outcomes. OKR mapping helps us trace technical decisions directly to business value.”

1. 
   

📦 1. Handling Legacy Systems – STAR Example

S – Situation:At a bank, we inherited a 15-year-old legacy loan origination platform built on EJB and Oracle Forms. Enhancing it was risky and extremely time-consuming.

T – Task:We needed to add a new KYC compliance workflow — but the legacy system’s design made this nearly impossible to deliver within the SEBI timeline.

A – Action:I proposed a strangulation strategy:

• Built a new kyc-service as a standalone Spring Boot microservice.

• Routed requests conditionally from the old UI to the new service using a proxy layer.

• Deployed it in Azure with CI/CD and added monitoring via App Insights.

R – Result:The new KYC flow launched on time with 99.99% uptime and became the first step toward decoupling the legacy core. This gave the business confidence to fund full modernization the next year.

🔁 2. Refactoring Project – STAR Example

S – Situation:In an investment portal, the portfolio-view module had a mix of UI logic, database queries, and business rules all crammed into one service.

T – Task:Fix performance bottlenecks and improve maintainability as we prepared for mobile rollout.

A – Action:I led a modular refactor:

• Separated business logic into a new service layer.

• Extracted DB calls using a repository pattern.

• Rewrote unit tests and added service contracts (OpenAPI).

• Migrated to async data calls for faster UI loads.

R – Result:

• Page load dropped from 5.2s → 1.3s

• Mobile team integrated in 2 weeks without issues

• Developer onboarding time cut by 40% due to cleaner code and service separation

⚖️ 3. Balancing Innovation vs. Technical Debt – STAR Example

S – Situation:We were building a mutual fund advisor chatbot powered by LLMs. Business wanted it fast. Devs wanted to clean old code first.

T – Task:Ensure fast innovation without destabilizing the core platform.

A – Action:I used a two-track delivery model:

• Fast-lane team worked on chatbot POC using a decoupled service + GenAI APIs.

• A “stability lane” team cleaned up debt in existing APIs (pagination, error handling, logging).

I also set SLAs that chatbot code would be refactored post-MVP before scaling.

R – Result:We shipped a working chatbot demo in 3 weeks.Tech debt was kept in check, and we avoided long-term quality compromise.