Chief Architect or Chief Coding Supervisor - Redefining the Role of the Chief Architect
- Krish Ayyar
- 7 hours ago
- 4 min read
Category: Organizational & People-Driven Change, Architecture Governance
Context: Retail Lending Platform
Perspectives Covered: Strategy, Business Process, System Logic, Component Specification, Implementation, Operations
The Situation: A Platform Under Delivery Pressure
A large retail bank had spent several years building what it proudly described as a unified lending platform.
The system supported home loans, personal loans, refinancing products, and partner-originated lending programs.
Applications could originate through multiple channels — mobile apps, branch systems, call centers, and partner portals.
On paper, the technology landscape looked modern. The platform used APIs, had multiple specialized services, and operated through a continuous delivery pipeline.
Yet inside the organization, a different reality was slowly emerging.
Product teams were increasingly struggling to understand how decisions were made across the platform.
Eligibility rules behaved slightly differently across channels.
Pricing logic appeared in multiple systems.
Production escalations were becoming frequent.
Every release seemed to require deeper involvement from the architecture team just to ensure that systems behaved consistently.
At the center of this environment was the Chief Architect.
Originally, the role had been created to define the architecture of the lending platform and ensure that the platform advanced the bank’s long-term lending strategy.
But over time, the role had gradually shifted. Instead of defining architecture across the platform, the Chief Architect was now spending most of the week attending sprint design reviews, resolving implementation disagreements between teams, and assisting with production escalations when complex failures occurred.
The organization still believed that it had a Chief Architect guiding the architecture. But in reality, the role had drifted toward something else.
The Chief Architect had quietly become a Chief Coding Supervisor.
Understanding the Drift
This transformation had not occurred because the architect lacked capability.
It happened because delivery pressure steadily pulled the role closer to implementation.
Every time teams faced uncertainty about how to implement a feature, they turned to the Chief Architect:
When a new vendor tool had to be evaluated quickly, the architect was asked to step in. When systems behaved unpredictably in production, escalation meetings required architectural presence.
Each of these decisions seemed reasonable in isolation. But over time they produced an unintended effect.
The architect’s attention shifted almost entirely to implementation and operational issues, while the deeper architectural responsibilities gradually lost ownership.
The organization continued delivering software, but the architecture that should have connected strategy, processes, systems, and components was slowly fading from view.
The Realization
An internal review eventually raised a simple but uncomfortable question.
If the Chief Architect was primarily supervising implementation activity, who was responsible for the architecture of the platform?
To answer this question, the leadership team revisited the role through the lens of the Enterprise Anatomy Model, which defines architecture across six interconnected perspectives.
This perspective made the issue immediately clear. Architecture is not limited to implementation decisions. It spans the entire chain connecting enterprise strategy to operational behavior.
Once the role was examined through this lens, the organization realized that the Chief Architect’s true responsibility had never been implementation supervision. The role was intended to ensure the continuity of architecture across all six perspectives.
What a Chief Architect Actually Owns
A true Chief Architect owns the continuity of architecture across all six perspectives.
P1 – Strategy
The Chief Architect ensures that system architecture supports enterprise goals.
This includes:
linking platform decisions to product strategy
reflecting regulatory objectives in system logic
maintaining traceability between business goals and technology structure
Architecture exists to realise enterprise strategy, not merely to support implementation.
P2 – Business Process
The Chief Architect ensures that enterprise workflows are architecturally defined.
This includes:
loan lifecycle process logic
channel alignment across digital, branch, and partner channels
exception handling across operational scenarios
Systems must reflect the enterprise process structure, not invent their own versions of
it.
P3 – System Logic
The Chief Architect defines system responsibility boundaries.
This includes determining:
which system owns eligibility logic
where pricing rules are executed
how decision engines interact with core systems
Clear system logic prevents duplication and integration confusion.
P4 – Component Specification
Architecture becomes visible through well-defined components.
Responsibilities include defining:
rule catalog structures
API interaction patterns
UI interaction structures
data lineage models
Components translate system architecture into governable elements.
P5 – Implementation Alignment (Limited Oversight)
The Chief Architect ensures that implementation aligns with architectural structure.
This involves:
defining architectural guardrails
reviewing alignment between implementation and architecture
The role does not supervise sprint execution or coding decisions.
Implementation should follow architecture, not redefine it.
P6 – Operations Alignment
Architecture must survive real-world operations.
The Chief Architect ensures that:
operational monitoring reflects architectural logic
incident diagnosis remains traceable to architecture
exception escalation pathways align with system structure
Operations must reflect the architecture, not contradict it.
The Real Role of the Chief Architect
Once these responsibilities were clearly articulated, the organization realized something important.
The Chief Architect is not responsible for supervising coding activities.
The real responsibility of the role is to ensure that the architectural chain connecting strategy, processes, systems, components, implementation, and operations remains intact.
When this connection exists, architecture becomes a governing discipline that guides the evolution of the platform.
When it disappears, architecture quietly collapses into implementation supervision.
And the Chief Architect becomes a Chief Coding Supervisor without anyone noticing.
Architecture governance does not begin with new tools, frameworks, or methodologies.
It begins with redefining the role of the Chief Architect.
