Case Study: When Customers Felt the Drift — and Architecture Was the Missing Link

Category: Organizational & People-Driven Change, Team churn, leadership shifts, missing documentation, reactive delivery.

Series: Rethinking Requirements: How the ICMG Enterprise Anatomy Model Makes Systems Change-Ready

Perspectives Covered: Strategy, Business Process, System, Component Specification, Implementation, Operation.

A national retail bank had built what it proudly called a “unified” lending platform.

Home loans. Personal loans. Top-up products. Partner-originated applications.

All running on a shared core.

The technology stack was modern. APIs were clean. Deployment pipelines were automated. Yet customer complaints were increasing:

• A customer approved online was rejected in-branch.

• A prepayment quote differed between the mobile app and call center.

• Eligibility thresholds appeared inconsistent across channels.

• Operations teams were manually overriding decisions to “fix anomalies.”

Nothing catastrophic had failed. But customers were experiencing something worse"-Inconsistency.

The Hidden Source of Customer Confusion

An internal review revealed something uncomfortable.

The original architectural thinking — why rules were structured a certain way, why processes branched in specific scenarios, why one system enforced eligibility while another handled repayment exceptions — was never visually modeled.

It lived in:

• Email threads

• Design meeting notes

• Institutional memory

• The original Chief Architect’s understanding

Over time

• teams changed.

• Requirements were enhanced.

• Regulatory thresholds evolved.

But P1–P4 were never visibly interconnected. SDLC continued. Code evolved. Intent drifted. And the drift reached the customer.

Where Conventional SDLC Fell Short

The bank discovered that SDLC was preserving code, not architectural intent.

Each symptom traced back to structural invisibility.

1. Goals Were No Longer Explicit (P1)

Originally, a regulatory eligibility rule had a clear Goal. Protect risk exposure under specific threshold conditions.

But over time:

• Teams enhanced the rule for new products.

• Channels introduced variations.

• Exception handling expanded.

The original Goal was not structurally preserved. New architects interpreted requirements based on current tickets — not original intent.

The result? The same scenario produced different outcomes depending on channel and product context. Customers felt inconsistency because Goals were being reinterpreted.

2. Process Logic Diverged Across Channels (P2)

The lending journey had evolved. Online flow optimized for speed. Branch flow allowed manual review. Partner flow introduced third-party validations.

But

1. Process flow was never formally modeled.

2. Exception branches were undocumented.

3. Channel-specific variations were embedded directly in code.

So when enhancements were introduced teams modified “their” process view. No one saw the full process logic across channels.

Customers experienced the consequences. The same application behaved differently depending on entry point. Not because policy changed. Because process logic fragmented.

3. System Responsibility Was Ambiguous (P3)

Eligibility logic existed in:

• Loan Origination System

• Product Engine

• API Gateway layer

Prepayment calculations were partially enforced in:

• Loan Management System

• Billing Engine

Data ownership was unclear.

Integration contracts evolved without system-level modeling.

So when a regulatory threshold changed , One system updated immediately. Another retained legacy logic. Customers received conflicting outputs.

The problem was not coding error. It was unmodelled system boundary logic.

4. Rules Lived in Code, Not in Structure (P4)

Rule enforcement had grown organically.

Thresholds were:

• Hard-coded in some services.

• Configurable in others.

• Duplicated for performance reasons.

• Partially overridden for specific products.

There was no structural mapping of rule dependencies.

When regulatory changes occurred. Teams updated what they knew.

But they could not see:

• All rule usage points.

• All process dependencies.

• All component consumers.

Legacy behavior resurfaced in specific channels. Customers experienced “old logic” in new journeys.

Introducing P1–P6 Structural Modeling

The bank did not start by rewriting code. It started by externalizing architecture.

Step 1: Make Goals Visible (P1)

Every major rule and enhancement was linked to an explicit Goal. Eligibility changes were mapped to risk exposure Objectives. Prepayment rules were mapped to financial fairness Objectives.

Now, when teams modified requirements. They could see the overarching Goal. Reinterpretation stopped. Consistency improved.

Step 2: Structured Process Modeling (P2)

All lending flows were modeled:

• Application sequence

• Decision branches

• Exception handling

• Channel variations

Branching logic became explicit. Channel differences were structurally defined — not hidden in code. Enhancements aligned to the canonical model. Customer journeys became consistent across channels.

Step 3: Define System Responsibility (P3)

System boundaries were clarified. Each system had defined responsibility for:

• Rule enforcement

• Data authority

• Orchestration logic

Overlapping enforcement was eliminated. Data ownership was visible. Integration contracts were structurally mapped. When thresholds changed again, every impacted system was identified before implementation. Customers received uniform decisions.

Step 4: Centralize Rule Structure (P4)

A rule catalog was created. Each rule was:

• Identified

• Linked to Goals

• Linked to Process branches

• Linked to System enforcement

• Linked to Component specifications

Now, when regulatory updates arrived. The architecture showed exactly where impact existed. No hidden enforcement. No partial updates. No legacy logic resurfacing.

Implementation and Operations Alignment (P5–P6)

With P1–P4 visible:

1. Implementation stopped being interpretational.

2. Developers executed against structured logic.

3. Operations monitoring aligned to architectural layers.

4. Drift was detected before customers experienced it.

5. Escalations reduced.

6. Manual overrides decreased.

7. Consistency returned.

The Structural Insight

Customer confusion did not originate at the customer interface. It originated when architectural intent stopped being externalized.

• When P1–P4 were invisible:

• Each team interpreted.

• Each rule evolved independently.

• Each channel drifted.

When P1–P6 Anatomy was introduced, Intent became visible. Logic became governable. Consistency became structural.

Closing Reflection

Conventional SDLC preserved code. P1–P6 Anatomy preserved intent.

And once intent was structurally preserved, customers stopped experiencing confusion — because the lending platform began behaving as one coherent architecture, not as a collection of inherited interpretations.