Many organizations treat architecture as a function.
They create an architecture team, appoint architects, establish review boards, and define governance processes.
Architecture becomes something performed by architects.
The problem is that architecture is rarely implemented by architects.
It is implemented by delivery teams.
This creates a fundamental challenge.
The people responsible for architectural decisions are often not the people making them.
As organizations become more digital, distributed, and product-oriented, this gap becomes increasingly difficult to manage.
Architecture therefore creates the most value when it is treated not as a centralized function, but as an organizational capability.
In many organizations architecture operates as a separate function.
The model typically looks something like this:
Business
↓
Architecture
↓
Delivery
Architects define standards.
Architects create target architectures.
Architects review solutions.
Delivery teams then implement those decisions.
While this approach can create consistency, it often introduces a new problem:
The people closest to the work have limited ownership of architectural decisions.
As delivery speed increases, centralized architecture functions frequently become bottlenecks.
The result is often one of two extremes:
Neither outcome is desirable.
Capabilities describe what an organization must be able to do.
They are not organizational units.
They are not job titles.
They are enduring abilities that enable an organization to achieve its objectives.
Examples include:
Architecture should be viewed in the same way.
Architecture is the organizational ability to make intentional design decisions about business, information, technology, and change.
This ability cannot reside solely within a small architecture team.
It must be distributed across the organization.
When architecture is treated as a capability, responsibility shifts.
Instead of architects owning architecture, the organization owns architecture.
Instead of architects making all decisions, decision-making is distributed closer to where work happens.
Instead of controlling delivery, architecture enables delivery.
The operating model evolves from:
Architecture Team
↓
Governance
↓
Delivery Teams
to:
Architecture Capability
↓
Principles
Guardrails
Standards
Communities
↓
Delivery Teams
Architects remain important.
Their role simply changes.
In a capability-oriented model, architects become:
Their objective is not to approve every solution.
Their objective is to improve the quality of decisions made throughout the organization.
This means focusing less on control and more on enablement.
Typical responsibilities include:
The architect becomes a multiplier rather than a bottleneck.
Many organizations struggle with architecture governance because governance is often interpreted as control.
Effective governance is something different.
Governance defines:
It does not require architects to approve every change.
Good governance enables teams to make independent decisions while remaining aligned.
The goal is not compliance.
The goal is alignment.
One of the most overlooked aspects of architecture capability is community.
Architectural knowledge cannot remain isolated within architecture teams.
It must be shared.
Architecture communities help organizations:
Communities often scale architecture more effectively than additional governance forums.
Organizations frequently measure architecture through artifacts:
These are outputs.
Capabilities should instead be measured through outcomes.
Examples include:
The objective is not more architecture.
The objective is better outcomes.
Organizations do not transform through architecture documents.
They transform through thousands of decisions made every day.
Architecture creates value when it improves those decisions.
That is why architecture should not be viewed as a centralized function.
Functions create outputs.
Capabilities create outcomes.
Architecture is the organizational ability to guide change intentionally, consistently, and sustainably.
In other words:
Architecture is not a team.
Architecture is not a governance board.
Architecture is not a collection of diagrams.
Architecture is an organizational capability for continuous change.
If you found this article useful, you may also enjoy:
]]>Architecture reviews often fail for a surprisingly simple reason: every architect asks different questions.
One review focuses on integrations. Another focuses on security. A third focuses on technology choices. Meanwhile, ownership, information management, operational readiness, and long-term sustainability are often overlooked.
Over the years I have found that successful architecture governance is less about creating more documentation and more about creating consistency.
Checklists provide that consistency.
They ensure that the same critical questions are asked regardless of whether the solution is a SaaS platform, a commercial off-the-shelf product, a custom-built application, or a strategic enterprise platform.
Architecture is not about approving technology.
Architecture is about enabling business outcomes while managing complexity, risk, cost, and change over time.
Most organizations have architecture principles.
Many have target architectures.
Some have architecture boards.
Yet many architecture decisions still depend heavily on individual experience and institutional knowledge.
A structured review process helps create repeatable governance by ensuring that every solution is evaluated across the same dimensions:
The goal is not bureaucracy.
The goal is to prevent expensive surprises later.
What started as a simple architecture checklist has evolved into a lightweight Architecture Review & Governance Toolkit.
The toolkit now includes:
A high-level assessment for introducing new systems, platforms, SaaS solutions, or vendor products.
A structured assessment used when introducing, acquiring, inheriting, or evaluating systems.
A detailed technical architecture assessment covering application, information, integration, security, infrastructure, and operational concerns.
A reusable template for documenting architecture reviews, findings, decisions, and recommendations.
A governance model defining decision rights, review processes, roles, responsibilities, and architectural guardrails.
Business Need
↓
Overview Checklist
↓
System Onboarding Checklist
↓
IT Architecture Checklist
↓
Architecture Review
↓
Architecture Decision
↓
Implementation & Governance
One of the recurring themes in my work is that architecture should be viewed as an organizational capability rather than a centralized function.
Architecture should enable teams to make better decisions through principles, guardrails, transparency, and shared accountability.
The objective of governance is therefore not to create bottlenecks.
It is to provide teams with decision support.
The complete toolkit is available on GitHub:
The repository currently contains:
Architecture governance should not be a centralized approval process.
It should be an organizational capability that enables better technology decisions through principles, guardrails, transparency, and shared accountability.
The Architecture Review & Governance Toolkit is one practical approach to achieving that.
]]>I don’t arrive at this architecture because it’s fashionable or “cloud-native”.
I arrive here because I keep seeing the same failure modes repeat themselves in enterprise platforms — regardless of tech stack, vendor, or organizational model:
What these systems usually have in common isn’t a lack of layers or patterns.
It’s a lack of enforced boundaries.
This architecture combines client/server interaction, gateway-based edge control, cell-based decomposition, and adapter-driven design to make boundaries explicit, enforceable, and hard to bypass.
TL;DR
Layered architecture fails not because layers are wrong, but because boundaries are unenforced. Over time, shortcuts erode structure, business logic leaks outward, and systems become fragile and slow to change. Combining gateways, cell-based decomposition, and adapter-driven design makes boundaries explicit and painful to violate. Adapters protect the domain, cells limit blast radius, and together they turn architecture from a diagram into a system that actively resists decay.
At a system level, the architecture is structured as:
Clients
↓
Gateway (API Gateway / BFF)
↓
Cells (independent runtime units)
└─ Layered + adapter-based internal design
Each architectural pattern addresses a different concern:
Together, they form a coherent and evolvable platform architecture.
Clients (web, mobile, partner systems, internal tools) interact with the platform using stable, versioned APIs.
Key principles:
This keeps client change cheap and predictable.
The gateway acts as the single controlled entry point into the platform.
Typical responsibilities include:
The gateway enforces policy, not business behavior.
No business logic belongs in the gateway.
In larger systems this is often implemented as:
The platform is decomposed into cells — autonomous runtime units that include:
Each cell:
Traffic is routed to cells based on criteria such as tenant, geography, customer segment, or partition key.
This design turns system-wide failures into contained, local incidents.
Inside each cell, a layered architecture is combined with ports and adapters.
Inbound Adapters
↓
Application Layer
↓
Domain Layer
↓
Outbound Adapters
This structure is intentional and enforced.
I’ve seen layered architecture go wrong more times than I can count.
On paper, the boundaries look clean.
In reality, they often blur fast:
What started as a layered architecture quietly turns into a layered illusion.
Everyone still talks about “the domain layer”, but no one can really point to where it begins or ends.
When layered architecture starts to decay, the symptoms are rarely dramatic.
What I’ve learned is that every “small” shortcut almost always breaks a very specific architectural rule.
Making those rules explicit is what turns architecture from intention into constraint.
Smell: Controllers calling repositories directly
Violated rule: All business interactions must go through application use cases.
This bypasses orchestration, authorization, and consistency boundaries.
It turns the UI or API layer into an accidental application layer.
Smell: “Just this once” logic in adapters
Violated rule: Adapters translate — they do not decide.
Inbound and outbound adapters exist to isolate the core from the outside world.
Once business rules appear here, the direction of dependency is already broken.
Smell: An application layer that keeps growing
Violated rule: The application layer orchestrates behavior; it does not contain it.
When business rules accumulate here, the domain is being hollowed out and the model loses meaning.
Smell: Domain objects depending on frameworks or SDKs
Violated rule: The domain must be technology-agnostic.
Framework annotations, persistence concerns, or vendor SDKs in the domain are a direct breach of this rule — and they make change expensive later.
Smell: Shared utility packages used everywhere
Violated rule: Reuse must not create hidden coupling.
Utilities that “everyone depends on” quickly become informal shared infrastructure with no clear ownership or lifecycle.
Smell: Developers unsure where new logic belongs
Violated rule: Every change must have an obvious home.
When placement becomes a discussion rather than a decision, boundaries are no longer doing their job.
Smell: Architecture diagrams that look right but don’t match the code
Violated rule: Architecture must be enforced, not just documented.
When diagrams and reality diverge, the architecture has already lost authority — even if no one says it out loud.
None of these violations are dramatic on their own.
Together, they are a reliable signal that the system is no longer protecting its core.
The issue isn’t that layered architecture is flawed.
The issue is that layers without ownership and enforcement are just naming conventions.
Without clear rules:
By the time the pain is visible, the boundaries are already gone.
## Architecture principles I rely on
When I say “layers” or “adapters”, I’m not talking about boxes in a diagram.
I’m talking about constraints that make the right thing easy and the wrong thing uncomfortable.
These are the principles I use to keep boundaries real.
All business interactions must be expressed as application use cases (commands/queries).
No controller, UI, scheduler, or consumer should reach into repositories or domain objects directly.
Implication: request handlers should be thin; orchestration lives in the application layer.
Adapters exist to isolate the core from protocols, vendors, and transport concerns.
They can validate, map, normalize, and enrich context — but they must not contain business rules.
Implication: if business logic appears in an adapter, the boundary is leaking.
The application layer coordinates work: transactions, authorization, consistency, workflows.
Business rules and invariants live in the domain model.
Implication: if the application layer keeps growing, it’s usually absorbing domain behavior that should be modeled explicitly.
The domain must not depend on frameworks, persistence, SDKs, or vendor APIs.
If the domain can’t be unit tested without infrastructure, it’s not isolated enough.
Implication: keep annotations, mappers, repositories, and clients outside the domain.
Shared libraries are allowed, but only when they do not become a “global dependency magnet”.
If everyone depends on a utility package, it needs ownership, versioning, and a lifecycle — just like a product.
Implication: prefer duplication over accidental coupling when ownership is unclear.
A healthy architecture makes it obvious where new logic belongs.
If engineers debate placement, boundaries are unclear or principles aren’t enforced.
Implication: clarify responsibilities until “where does this go?” becomes a non-question.
Diagrams are useful, but they don’t create architecture — constraints do.
If the code and the diagram diverge, the code wins, and the architecture has already lost authority.
Implication: enforce boundaries via reviews, tests, and automation (where possible).
Cells exist to make ownership and failure boundaries explicit.
A cell owns its runtime, dependencies, and data. Crossing boundaries must be intentional and visible.
Implication: if teams can’t evolve independently, the cell boundaries are wrong (or not real).
This is why I don’t rely on layers alone.
Adapters make boundaries explicit and enforceable:
It becomes obvious when something is in the wrong place — and just as obvious when someone tries to bypass a layer.
Cell-based architecture adds another level of pressure in the right direction.
When each cell owns its runtime, data, and dependencies:
You can’t casually reach across layers or cells without feeling the cost.
Inbound adapters translate external interaction models into internal use cases.
Examples include:
They handle protocols, validation, mapping, and context propagation — but contain no business logic.
The application layer orchestrates use cases.
Its responsibilities include:
The application layer is procedural and explicit, but deliberately thin.
The domain layer contains the core business logic:
The domain layer has no dependency on infrastructure, frameworks, or vendors.
This is the layer the architecture is designed to protect.
Outbound adapters connect the application and domain layers to external systems such as:
They handle protocol translation, data mapping, retries, and resilience patterns.
The domain remains unaware of how integration and persistence are implemented.
Each cell owns its data.
Cross-cell interaction is:
This enforces ownership, autonomy, and clarity.
The architecture supports guardrail-based governance:
Architecture becomes an enabler for change rather than a constraint.
Layered architecture is not enough by itself.
Without explicit boundaries, enforcement, and ownership, layers decay into convention — and convention decays under pressure.
Adapters make boundaries explicit.
Cells make boundary violations painful.
Together, they turn architecture from a diagram into a system that pushes back.
Good architecture should make the right thing the easy thing, and the wrong thing uncomfortable.
That’s the difference between drawing boxes and designing systems.
]]>TL;DR
Most organizations believe their speed is determined by:
In reality, something else has far more influence:
Dependencies.
Who depends on whom.
Which systems rely on which data.
Which teams must coordinate to deliver value.
This is the hidden architecture that controls your pace of change.
And in many organizations, it is shaped by a few central platforms.
Often: one CRM, one billing system, and one ERP.
Every organization has an architecture.
Some design it deliberately.
Others let it emerge through:
In both cases, dependencies form the real structure of the enterprise.
They determine:
And they rarely appear in official diagrams.
Unmanaged dependencies create friction everywhere.
When many teams must align to release one feature, velocity collapses.
Planning becomes negotiation.
Changes ripple across platforms.
Small updates become high-risk deployments.
A few critical systems or teams become unavoidable chokepoints.
Everything waits.
Experimentation becomes expensive.
Failure becomes dangerous.
So teams stop trying.
Over time, the same patterns repeat.
One CRM.
One billing platform.
One ERP.
One integration hub.
Used by everyone.
Owned by no one.
All analytics depend on one team.
All insights wait in one queue.
“Internal platforms” with no roadmap, funding, or accountability.
Point-to-point connections multiplied over years.
No one fully understands the landscape.
What started as simplification becomes structural complexity.
The rationale is usually sound.
Organizations aim for:
Across customer, revenue, and operations.
From a governance perspective, this looks like maturity.
And in many contexts, it is.
At first.
It is important to be clear:
Choosing one CRM, one billing system, and one ERP is often the right decision.
Standardization reduces several very real forms of complexity.
Fewer platforms mean:
This lowers operational risk.
With unified core systems:
This matters in regulated environments.
Clear systems of record reduce:
Trust in data increases.
Shared platforms enable:
Cost per transaction decreases.
In many organizations, consolidation is a necessary step toward maturity.
If dependencies define speed, then capability design defines structure.
Decomposing the enterprise by business capabilities is one of the most effective ways to manage complexity.
Capabilities represent:
They form a natural foundation for architecture.
This reduces accidental coupling.
Domains can evolve independently.
Local change stays local.
Strategy becomes:
Without losing meaning.
CRM, billing, and ERP become service providers.
Not power centers.
Over time, new realities emerge.
Products, channels, and markets become tied to the same backbone.
If it doesn’t, it waits.
Or dies.
Exceptions multiply.
Standardization erodes silently.
Strategic freedom decreases.
Negotiation power weakens.
The platforms start shaping strategy.
One of the most common mistakes is confusing:
Capability ownership with system ownership.
Capabilities are end-to-end.
Systems are assets.
When capabilities depend on too many platforms, autonomy disappears.
And speed follows.
Fast organizations are dependency-aware.
Map:
Continuously.
Change becomes local.
Ownership is unambiguous.
Coordination is minimized.
CRM, billing, and ERP have:
Ask:
Organizations start with:
“One system per domain.”
They end with:
“One backbone controlling everything.”
Each project adds:
Until change becomes surgery.
Architecture is not about diagrams.
It is about shaping dependencies.
Every decision answers:
If you don’t decide, the organization will.
Across value streams, platforms, and teams.
Where work consistently waits.
Target the biggest constraint.
Stabilize interfaces and data semantics.
Predictability builds trust.
Organizations don’t become slow by accident.
They become slow through unmanaged dependencies.
Often embedded in core platforms.
Speed comes from:
That is architecture’s real impact.
If your transformation feels stuck, look at your dependencies. They usually tell the real story.
]]>Yet very little actually changes.
Projects run.
Roadmaps are updated.
PowerPoint decks grow.
But business outcomes remain stubbornly flat.
After working across telecom, insurance, and financial services, it becomes clear that transformation rarely fails because of missing frameworks.
It fails because organizations lack a system for continuous change.
This post outlines a practical playbook — inspired by EDGY and ADM — that organizations can use to turn strategic intent into executed transformation.
This playbook builds on earlier work where I explored:
How EDGY and an ADM-inspired cycle enable continuous enterprise design
(EDGY & ADM: From Architecture Method to Operating Model),
Why capability models are the foundation of meaningful change
(Why Your Capability Map Doesn’t Change Anything
Together, these posts form a coherent view of architecture as a system for transformation — not a collection of artefacts.
In many organizations, critical architecture artefacts are either missing or disconnected:
Some artefacts exist in repositories.
Others exist only in presentations.
Many never exist at all.
Together, this creates an environment where decisions are made without architectural context.
The result is static architecture:
well-designed, well-documented — and quickly outdated.
Modern organizations need architecture that continuously adapts.
Not snapshots.
Not documents.
Systems.
Over time, the same structural problems repeat across organizations.
They rarely stem from lack of competence.
They stem from weak systems.
Some of the most common anti-patterns include:
No explicit target architecture exists.
Instead, the organization relies on:
Without a shared future state, every initiative optimizes locally.
Capabilities are documented but not governed.
They are:
They become descriptive rather than directive.
Roadmaps are built from project lists.
Not from:
This leads to sequencing problems and structural drift.
Standards exist on paper.
In practice:
Architecture becomes negotiable.
Success is measured by documentation volume.
Not by:
Architecture becomes an archival function.
These anti-patterns rarely appear in isolation.
They reinforce each other.
Even when artefacts exist, many organizations struggle to steer change.
The root cause is often weak architectural leadership and missing design principles.
Without clear principles:
Decisions are made based on:
Instead of long-term coherence.
Well-designed principles do not limit innovation.
They enable it.
Effective principles are:
Examples include:
These principles create architectural gravity.
They make the right decisions easier than the wrong ones.
In mature organizations, governance is not a review process.
It is a design capability.
It provides:
When governance is weak:
Strong governance is not bureaucracy.
It is what allows autonomy to scale.
Even with strong frameworks, clear artefacts, and solid governance, transformation is rarely fast.
Change is slow because organizations are human systems — not technical ones.
Every major architectural shift affects:
These impacts create natural resistance.
Not because people are negative.
Because they are protecting stability.
In many cases, resistance is a signal — not a problem.
It reflects:
Ignoring this resistance does not remove it.
It pushes it underground.
Where it becomes more destructive.
New architectures require new skills.
New platforms require new ways of working.
New governance requires new decision behaviors.
None of this happens instantly.
Mature transformation programs invest in:
Without this, architecture remains theoretical.
Sustainable change requires leadership patience.
This does not mean low ambition.
It means:
Organizations that rush transformation often create more technical and organizational debt than they remove.
A significant part of architectural work happens outside diagrams.
It happens in:
Architects who ignore this dimension rarely achieve lasting impact.
Architecture is as much about relationships as it is about structures.
Inspired by EDGY and TOGAF ADM, and as outlined in
EDGY & ADM: From Architecture Method to Operating Model),
a recommended approach is to treat architecture as a repeating cycle:
Sense → Design → Align → Enable → Deliver → Learn → Adapt
This is not a waterfall.
It is an operating model.
Architecture becomes a permanent management capability.
EDGY provides the structural backbone of this playbook.
Every step balances three core facets.
Why we exist
Who we serve
What differentiates us
How customers and users interact
Journeys and touchpoints
Perceived value
Capabilities
Platforms
Information
Technology
Transformation only works when these evolve together.
Transformation starts with sensing.
At this stage, the focus should be on:
The goal is shared understanding.
Not analysis paralysis.
Output:
Strategic themes and design drivers.
Capabilities translate intent into structure.
Using EDGY and TM Forum models, organizations should establish:
Capabilities become the backbone for:
Without this layer, change remains fragmented.
I explored this problem in depth in
Why Your Capability Map Doesn’t Change Anything,
where I show how static models fail without execution mechanisms.
In this playbook, capabilities are treated as active management instruments — not documentation.
The North Star represents the desired future state.
In many organizations, this artefact is missing entirely — replaced by vague ambition statements or disconnected solution designs.
Without an explicit target architecture, transformation becomes reactive and incremental.
It integrates:
It is not an idealized end-state.
It is a navigational instrument.
A reference for decisions.
Between current and future lies complexity.
This is handled through transition states.
For each major domain:
Roadmaps are capability-driven, not project-driven.
This keeps change coherent.
Architecture must influence where money goes.
At this stage, organizations should connect:
Governance focuses on:
Governance becomes a design system — not a control function.
Delivery teams need freedom within structure.
Teams are enabled through:
The objective is autonomy with alignment.
If teams constantly need exceptions, the system is broken.
Execution is organized around capabilities, not systems.
Teams are aligned to:
Architecture supports:
Change becomes continuous, not episodic.
Every cycle produces learning.
Organizations should continuously monitor:
This feeds back into sensing and strategy.
Architecture becomes adaptive.
Across this cycle, a small, consistent toolkit is recommended:
| Layer | Artefact |
|---|---|
| Strategy | Strategic themes |
| Business | Capability Map (L2–L3) |
| Architecture | Target & North Star Architecture |
| Change | Transition Roadmap & States |
| Governance | Principles & Guardrails |
| Delivery | Reference Architectures |
When any of these artefacts are missing — especially target and transition architectures — organizations default to local optimization and short-term fixes.
Everything else is optional.
In a telecom environment, organizations often encounter:
Using this cycle:
Within two years:
Structure enabled speed.
This post is part of a broader series on capability-driven and design-led transformation:
Together, these articles describe how enterprise architecture can evolve from static documentation into a continuous organizational capability.
Enterprise architecture is not documentation.
It is a continuous design capability.
When done well, it:
Architecture is not about control.
It is about coherence.
And coherence is what makes organizations move.
]]>A lot of organizations have a capability map.
It’s approved.
It’s well-structured.
It’s referenced in presentations.
And yet — nothing actually changes.
Funding decisions look the same.
The same initiatives get prioritized.
Architecture is still consulted after commitments are made.
If this feels familiar, the problem isn’t your capability map.
The problem is what you expect it to do — and where it stops.
Capability maps are often treated as:
But real decisions are made elsewhere:
If your capability map isn’t explicitly connected to those arenas, it becomes descriptive — not directive.
A capability map that doesn’t influence priorities is just a classification model.
In many organizations, the architecture journey looks like this:
What’s missing is the translation layer.
Architecture stops at representation instead of continuing into decision-making.
Capabilities don’t change anything on their own.
Decisions do.
To make capabilities matter, they must be used to:
That requires a fundamental shift:
Capabilities must become a decision framework, not a taxonomy.
What I’ve seen work repeatedly is making the flow explicit:
Strategy
↓
Business Outcomes
↓
Capabilities
↓
Investment Themes
↓
Initiatives & Products
This model does three important things:
This is where architecture starts influencing reality.
Even well-designed capability maps fail when:
In short:
The map exists — but architecture lacks mandate.
Fixing this isn’t about redrawing the map.
It’s about changing how the map is used.
Overlay your capability map with:
Heat creates tension.
Tension drives decisions.
Every initiative should clearly answer:
If it can’t answer that question — why is it funded?
This is where architecture earns trust.
Examples:
A capability map that never blocks anything isn’t doing its job.
Architecture influence doesn’t come from review boards.
It comes from:
If architects aren’t there, the capability map won’t be either.
When capability maps are used properly:
This is the difference between:
“We maintain the capability map”
and
“We help steer the organization’s investments.”
Capability maps don’t fail because they’re wrong.
They fail because organizations stop using them too early.
]]>If your capability map doesn’t change priorities, funding, or direction —
it isn’t architecture.
It’s illustration.
In the previous post, we introduced a Level 1 (L1) capability map for financial institutions, providing an enterprise-wide view of what a financial organization must be able to do.
The natural next step is to decompose these high-level domains into Level 2 (L2) capabilities.
L2 capabilities describe distinct, stable business abilities that sit below enterprise domains and above detailed processes and systems. This level is often the most useful for transformation planning, regulatory analysis, application mapping, and portfolio prioritization.
This post presents a pragmatic L2 capability decomposition aligned with the previously defined L1 capability map.
Strategic Management
Defines the long-term direction of the institution, aligning mission, vision, and strategic priorities with ownership and regulatory expectations.
Business Planning & Objectives
Translates strategy into measurable business objectives and enterprise-level plans.
Capital & Funding Strategy
Ensures a sustainable capital structure and funding model aligned with regulatory capital requirements.
Sustainability & ESG Governance
Establishes governance, targets, and accountability for sustainability and ESG commitments.
Corporate Governance
Defines ownership structures, board governance, and executive accountability.
Policy Management
Creates, maintains, and governs internal policies across the enterprise.
Regulatory Framework Management
Interprets external regulations and translates them into enterprise-wide requirements.
Decision Governance & Mandates
Defines decision rights, mandates, escalation paths, and accountability structures.
External Reporting & Ownership Dialogue
Manages structured reporting and communication towards owners, state authorities, and key stakeholders.
Business Architecture Management
Maintains a coherent business capability and operating model aligned with strategy.
Target Architecture Management
Defines and governs future-state business, data, application, and technology architectures.
Change & Transformation Governance
Ensures change initiatives are aligned with strategy and architectural principles.
Portfolio Management
Manages and prioritizes the portfolio of initiatives and investments.
Initiative & Program Management
Provides governance and coordination across programs and major initiatives.
Roadmap Management
Maintains time-based plans linking strategy, capabilities, and initiatives.
Benefits & Value Realization
Tracks and ensures realization of expected business and strategic benefits.
Customer Segmentation
Defines and manages customer segments based on business, risk, and strategic criteria.
Relationship Management
Manages ongoing customer relationships across the full lifecycle.
Customer Communication
Ensures consistent, compliant, and effective communication with customers.
Contract Management
Manages contractual agreements throughout their lifecycle.
Customer & Deal Onboarding
Ensures compliant and efficient onboarding of customers and transactions.
Credit Assessment
Assesses creditworthiness and risk exposure of customers and transactions.
Risk-Based Pricing
Determines pricing based on credit risk, capital usage, and strategic considerations.
Decision Support & Delegation
Supports operational credit and business decisions within defined mandates.
Loan Origination
Manages the creation and structuring of loans and financing products.
Financing Structures
Defines and manages different financing models and structures.
Credit Administration
Handles administrative activities related to credits and loans.
Disbursement Management
Manages controlled release of funds according to contractual conditions.
Repayment & Amortization
Manages repayment schedules and amortization over the credit lifecycle.
Terms & Conditions Management
Maintains and enforces contractual terms throughout the lifecycle.
Guarantees Management
Manages guarantees and risk-sharing instruments.
Export Finance
Supports export-related financing in line with the institutional mandate.
Deal Structuring
Structures complex transactions involving multiple parties and instruments.
Collaboration with Banks & Guarantee Institutions
Coordinates with external financial partners and guarantee providers.
Contract Performance Monitoring
Monitors compliance with contractual obligations and performance criteria.
Covenant & Condition Follow-up
Ensures contractual covenants and conditions are fulfilled.
Enterprise Risk Framework
Defines the overall risk management framework and risk appetite.
Credit Risk Management
Identifies, measures, and manages credit risk exposure.
Market Risk Management
Manages risks related to market movements and valuation.
Liquidity Risk Management
Ensures sufficient liquidity under normal and stressed conditions.
Operational Risk Management
Manages risks arising from processes, systems, people, and external events.
Regulatory Compliance
Ensures adherence to applicable laws and regulations.
AML / CTF
Prevents money laundering and terrorist financing.
KYC & Customer Due Diligence
Ensures customer identity and risk profiles are properly assessed.
Sanctions Management
Ensures compliance with international sanctions regimes.
Export Control
Ensures compliance with export control regulations.
Internal Control Management
Establishes and operates internal controls across the organization.
Control Framework Management
Maintains structured control frameworks aligned with regulations.
Issue & Deviation Management
Manages identified issues, breaches, and remediation actions.
Internal Audit
Provides independent assurance of governance, risk, and control.
Treasury Operations
Manages daily cash, funding, and financial market operations.
Liquidity Management
Ensures availability of liquidity across time horizons.
Funding Strategy
Defines funding sources and instruments.
Capital Market Operations
Manages issuance and interaction with capital markets.
Hedging & Derivatives
Manages financial risk mitigation using derivatives.
General Ledger
Maintains the core financial accounting records.
Financial Close
Ensures timely and accurate period-end closing.
Financial Reporting
Produces internal and external financial statements.
Regulatory & IFRS Reporting
Ensures compliance with accounting and reporting standards.
Supervisory Reporting
Reports financial information to supervisory authorities.
Budgeting
Plans financial resources and allocations.
Forecasting
Predicts future financial performance.
Cost Management
Controls and optimizes operational costs.
Performance Management
Measures and manages financial performance.
Transfer Pricing
Manages internal pricing between entities or units.
Information Governance
Defines ownership, accountability, and governance of data assets.
Master Data Management
Manages core business entities such as customers and counterparties.
Reference Data Management
Maintains shared reference data used across the enterprise.
Data Quality Management
Ensures accuracy, completeness, and consistency of data.
Metadata Management
Manages definitions and context of data assets.
Management Reporting
Provides insights for executive and management decision-making.
Risk & Credit Reporting
Supports risk oversight and credit monitoring.
Regulatory Reporting
Produces data-driven regulatory submissions.
ESG & Sustainability Reporting
Supports sustainability and ESG disclosures.
Decision Support
Supports informed decision-making using analytical insights.
Scenario Analysis
Evaluates outcomes under different scenarios.
Credit Models
Provides quantitative models for credit assessment.
Risk Models
Models financial and non-financial risk exposures.
AI & Advanced Analytics
Applies advanced techniques to enhance analysis and decision-making.
Application Management
Manages the application portfolio across its lifecycle.
Integration Management
Ensures reliable data and process integration.
Platform Management
Provides shared technology platforms.
Architecture Governance
Ensures architectural consistency and compliance.
Information Security Management
Protects information assets and confidentiality.
Identity & Access Management
Controls access to systems and data.
Security Risk Management
Identifies and mitigates security risks.
Legal Advisory
Provides legal guidance and interpretation.
Contractual Support
Supports contract drafting and review.
Regulatory Analysis
Interprets regulatory developments and impacts.
Talent Management
Ensures access to required skills and competencies.
Competence Development
Develops skills and capabilities across the organization.
Leadership Development
Builds leadership capability.
Culture & Change Enablement
Supports cultural alignment and adoption of change.
Procurement Management
Manages sourcing and procurement activities.
Vendor Management
Manages supplier relationships and performance.
Third-Party Risk Management
Manages risks related to external partners.
Contract Lifecycle Management
Manages contracts with third parties throughout their lifecycle.
A well-defined Level 2 capability map turns high-level strategy into something actionable and governable.
Combined with the Level 1 capability map, it provides a stable backbone for regulatory change, digital transformation, and long-term architectural planning in financial institutions.
Future follow-ups can naturally extend this work into:
Financial institutions operate in one of the most complex and highly regulated environments of any industry. Strategic objectives, capital requirements, risk management, regulatory compliance, sustainability mandates, and operational efficiency must all be balanced simultaneously.
To manage this complexity, organizations need a shared and stable structure that bridges strategy, business, IT, risk, and data. An enterprise capability map provides exactly that foundation.
This article presents a Level 1 (L1) capability map for financial institutions, suitable for banks, credit institutions, and policy-driven financial organizations. It can be used as a baseline for business architecture, transformation planning, and target architecture development.
A capability map describes what the organization must be able to do, independent of how it is organized or which systems are used.
In financial institutions, capability mapping helps to:
Because capabilities evolve slowly, they form a reliable anchor for long-term architectural and transformation work.
This capability area focuses on enterprise-level direction, control, and governance.
Key capabilities include:
This domain represents the value-creating core of the financial institution.
Key capabilities include:
Risk and compliance are integral to the business, not supporting functions.
Key capabilities include:
This domain ensures financial integrity, transparency, and capital efficiency.
Key capabilities include:
Modern financial institutions are fundamentally data-driven.
Key capabilities include:
Enabling capabilities provide the foundation for scalability, security, and sustainable change.
Key capabilities include:
This L1 capability map can be used to:
For financial institutions, a capability map is not just an architectural artifact — it is a strategic management tool.
Used correctly, it enables both control and innovation, providing a stable structure in a highly dynamic regulatory and market environment.
Every organization faces the same challenge: the pace of change is accelerating, while the complexity of systems and processes continues to grow. Transformation initiatives pile up — new platforms, modernized infrastructure, digital customer experiences — yet the big picture is often missing.
In these situations, architecture can feel like it’s running behind the business rather than guiding it. That’s where the Architecture North Star comes in. It’s the compass that ensures transformation programs, roadmaps, and investments all point in the same direction.
The North Star is not a detailed roadmap. It’s a guiding vision expressed in architectural terms — a statement of where the organization needs to be able to operate in the future.
Key traits:
A useful way to test if your North Star is meaningful:
Without a North Star, organizations risk:
With a North Star, architecture becomes:
Think of it as the why behind the roadmap.
Capabilities are the perfect building blocks for a North Star:
A good North Star typically highlights 5–7 critical capabilities — enough to be concrete, but not so many that focus is lost.
Instead of vague aspirations like “become digital”, the North Star should express tangible, enterprise-level outcomes such as:
EDGY provides a simple but powerful way to link strategy to execution, using three lenses:
The North Star sits in the Architecture lens, but it is meaningless without Identity and Experience:
This ensures the North Star is not only aspirational but also executable.
Use a capability map with highlighted North Star areas. This makes strategy visible and concrete, not hidden in a slide deck.
Every roadmap, initiative, or investment should articulate how it moves the enterprise closer to the North Star.
Define leading indicators that reflect progress:
Make the North Star part of governance rituals:
From my own work:
The Architecture North Star is not just a metaphor. It’s a practical enterprise design tool.
By framing it in terms of capabilities, and embedding it in the EDGY lenses of Identity, Experience, and Architecture, architects ensure that strategy and execution stay connected.
In times of constant change, the North Star prevents fragmentation and reactivity. It provides a stable compass that keeps every investment, design decision, and roadmap aligned with the enterprise’s purpose.
Do you use a North Star in your architecture work? Connect with me on LinkedIn and share your perspective.
]]>These are useful, but by the time we see them, it’s already too late to change course.
Leading indicators are early signals that tell us if we’re moving in the right direction.
Examples:
These don’t prove success yet — but they show whether momentum is building.
As architects, we often design target states and roadmaps. But real transformation depends on behavioral shifts.
When I coach or lead architectural change, I’ve learned to celebrate these small early signals.
They don’t guarantee outcomes — but they predict direction.
Transformation is less about the final ROI graph, and more about noticing the first signs of a new way of working.
When shaping your own transformation, ask:
If you can answer these three questions, you already have the first draft of your leading indicators.