When Architecture went out with the Chief Architect — and SDLC could not cope with Team frustration
- Krish Ayyar
- 2 days ago
- 3 min read
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 Retail Lending Platform Scenario
The Chief Architect of a retail lending platform resigned after seven years.
He had designed the eligibility engine, defined repayment triggers, introduced prepayment rules, and resolved system boundary conflicts between the Loan Origination System (LOS), Loan Management System (LMS), and Billing Engine.
He knew:
Why eligibility overrides repayment triggers.
Why two systems enforce similar rule logic.
Why foreclosure calculation sits in one system but exception handling in another.
Why a specific regulatory rule was embedded in three components.
But none of this was externally modeled across P1–P4. Within three months, the symptoms appeared.
Why Conventional SDLC Failed
Here’s what started happening once architectural thinking did not survive its author.
When P1–P4 were not visibly modeled and interconnected, SDLC collapsed into P5 execution. And the symptoms appeared everywhere.
1. Disengaged Teams and Low Morale
Engineers were frustrated.
There was no architectural map linking Goals (P1) to Components (P4).
Process logic (P2) was implicit, not modeled.
System responsibility (P3) was assumed, not defined
Every change request felt like a guess. Developers depended on “who knows this area” instead of structural traceability.
The result?
Implementation became interpretational. People did not lack skill. They lacked visibility.
2. Fragmented Architecture Causing Project Delays
Without a unified P1–P4 model:
Two systems enforced overlapping rules.
Data ownership was unclear.
Process sequences conflicted.
Component boundaries drifted.
So when one module changed, Another unexpectedly broke.
Debugging became detective work because there was no structural dependency map.
SDLC managed tickets. It did not manage structural relationships.
3. Knowledge Gaps Leading to Risky Ad-Hoc Fixes
A regulatory threshold changed. Developers modified a rule.
But they could not see:
Where else the rule was used.
Which process branch depended on it.
Which system enforced it.
Which component consumed it.
There was no centralized Rule view (P4). No system enforcement clarity (P3). No process dependency mapping (P2).
One patch led to three new bugs.
Not because of incompetence. Because architecture was never externalized.
4. Poor Change Management
Change requests continued to arrive.
But there was:
No traceability from change → Goal (P1).
No visibility into impacted Processes (P2).
No system-level impact model (P3).
No component dependency structure (P4).
So teams reacted. They scattered updates.They performed last-minute code rewrites. They discovered dependencies in production. SDLC controlled tasks. It did not control structural alignment.
How P1–P6 Anatomy Resolved Team Frustration
The bank then introduced P1–P6 structural modeling. The focus was not on rewriting code. It was on externalizing architectural relationships.
1. Engineers Saw the “Why” (P1)
Every major feature was linked to a Goal.
Instead of: “Implement this rule change.” They saw: “This change supports Goal X.”
Motivation increased because implementation became traceable to purpose.
2. Engineers Saw the “Flow” (P2)
Process logic was modeled visually.
They could see:
Sequence of events.
Exception branches.
Cross-functional dependencies.
No guessing. No hallway clarification meetings.
3. Engineers Saw System Responsibility (P3)
The model showed:
Which system enforced which rule.
Where data was authoritative.
Where orchestration lived.
What was out of scope.
Boundary clarity reduced conflict between teams.
4. Engineers Saw Component Structure (P4)
Component specifications became traceable:
API responsibilities.
Rule catalog references.
Data structures.
Configuration logic.
So when a change happened: They traced impact before coding.
That reduced fear. It reduced rework. It reduced escalation.
5. Implementation Became Guided (P5)
P5 tasks were no longer interpretational. They were anchored to P1–P4.
Developers moved from guessing intentto executing structured logic.
6. Operations Became Predictable (P6)
Because structural traceability existed:
Monitoring aligned to Goals.
Incidents mapped back to process logic.
Fixes aligned to architectural layers.
No firefighting chaos.
The Deeper Insight
Team frustration was not a people problem. It was an architectural invisibility problem.
When architecture existed only in memory: Teams depended on individuals.
When P1–P4 were visually modeled: Teams depended on structure.
Structure scales. Memory does not.
Closing Reflection
Conventional SDLC managed activities.
P1–P6 Anatomy managed structural relationships.
And when structural relationships became visible,team frustration transformed into structural confidence.
