Most organizations today have strategy documents, capability maps, and target architectures.
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.
The Core Problem: Static Architecture in a Dynamic World
In many organizations, critical architecture artefacts are either missing or disconnected:
- Strategy lives in executive decks
- Capability maps exist without ownership
- Target and transition architectures are undefined
- Roadmaps are detached from structure
- Delivery lives in Jira
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.
Common Architecture Anti-Patterns
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:
The Missing North Star
No explicit target architecture exists.
Instead, the organization relies on:
- Strategy slogans
- Isolated solution designs
- Vendor roadmaps
Without a shared future state, every initiative optimizes locally.
Capability Maps Without Ownership
Capabilities are documented but not governed.
They are:
- Not linked to investment
- Not linked to accountability
- Not linked to outcomes
They become descriptive rather than directive.
Roadmaps Without Architecture
Roadmaps are built from project lists.
Not from:
- Capability gaps
- Technical debt
- Platform evolution
This leads to sequencing problems and structural drift.
Architecture by Exception
Standards exist on paper.
In practice:
- Every major initiative requests deviations
- Exceptions become the norm
- Coherence erodes
Architecture becomes negotiable.
Repository-Driven Architecture
Success is measured by documentation volume.
Not by:
- Decision quality
- Delivery outcomes
- Structural improvement
Architecture becomes an archival function.
These anti-patterns rarely appear in isolation.
They reinforce each other.
Weak Steering and the Absence of Architectural Principles
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:
- Teams optimize for speed over sustainability
- Platforms evolve inconsistently
- Integration patterns proliferate
- Technical debt accumulates silently
Decisions are made based on:
- Local constraints
- Individual preferences
- Short-term delivery pressure
Instead of long-term coherence.
Principles as Strategic Constraints
Well-designed principles do not limit innovation.
They enable it.
Effective principles are:
- Few (typically 8–12)
- Explicitly linked to strategy
- Technically actionable
- Enforced through governance
Examples include:
- “Prefer platform services over custom solutions”
- “All customer data has a single authoritative source”
- “APIs before integrations”
- “Security controls are embedded by default”
These principles create architectural gravity.
They make the right decisions easier than the wrong ones.
Governance as a Design Capability
In mature organizations, governance is not a review process.
It is a design capability.
It provides:
- Clear decision rights
- Fast escalation paths
- Consistent interpretation of principles
- Predictable approval processes
When governance is weak:
- Architects become advisors without authority
- Reviews become symbolic
- Exceptions accumulate
- Platforms fragment
Strong governance is not bureaucracy.
It is what allows autonomy to scale.
Why Change Takes Time: The Human Side of Architecture
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:
- Roles and responsibilities
- Power structures
- Competence profiles
- Career paths
- Daily routines
These impacts create natural resistance.
Not because people are negative.
Because they are protecting stability.
Resistance Is Often Rational
In many cases, resistance is a signal — not a problem.
It reflects:
- Fear of losing relevance
- Uncertainty about future roles
- Fatigue from past failed initiatives
- Lack of trust in leadership
- Competing delivery pressures
Ignoring this resistance does not remove it.
It pushes it underground.
Where it becomes more destructive.
Adoption Is a Learning Process
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:
- Coaching and enablement
- Community building
- Safe experimentation
- Progressive onboarding
- Visible role models
Without this, architecture remains theoretical.
Patience as a Leadership Capability
Sustainable change requires leadership patience.
This does not mean low ambition.
It means:
- Sequencing change responsibly
- Protecting critical transitions
- Allowing parallel learning curves
- Accepting temporary inefficiencies
Organizations that rush transformation often create more technical and organizational debt than they remove.
Architecture as Relationship Management
A significant part of architectural work happens outside diagrams.
It happens in:
- One-on-one conversations
- Design workshops
- Conflict resolution
- Expectation management
- Trust building
Architects who ignore this dimension rarely achieve lasting impact.
Architecture is as much about relationships as it is about structures.
Architecture as a Continuous Design Cycle
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.
The EDGY Foundation
EDGY provides the structural backbone of this playbook.
Every step balances three core facets.
Identity
Why we exist
Who we serve
What differentiates us
Experience
How customers and users interact
Journeys and touchpoints
Perceived value
Architecture
Capabilities
Platforms
Information
Technology
Transformation only works when these evolve together.
The Architecture Playbook
1. Sense: Strategic and Environmental Awareness
Transformation starts with sensing.
At this stage, the focus should be on:
- Strategic direction
- Market signals
- Regulatory pressure
- Customer expectations
- Operational friction
The goal is shared understanding.
Not analysis paralysis.
Output:
Strategic themes and design drivers.
2. Frame: Capability-Based Structure
Capabilities translate intent into structure.
Using EDGY and TM Forum models, organizations should establish:
- Stable L2–L3 capability maps
- Ownership models
- Capability maturity views
Capabilities become the backbone for:
- Investment
- Prioritization
- Governance
- Measurement
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.
3. Design: The North Star Architecture
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:
- Business architecture
- Information flows
- Platform landscape
- Integration patterns
- Security architecture
It is not an idealized end-state.
It is a navigational instrument.
A reference for decisions.
4. Shape: Transition States and Roadmaps
Between current and future lies complexity.
This is handled through transition states.
For each major domain:
- Current state
- Target state
- Decommissioning paths
Roadmaps are capability-driven, not project-driven.
This keeps change coherent.
5. Align: Portfolio and Governance Integration
Architecture must influence where money goes.
At this stage, organizations should connect:
- Capabilities
- Roadmaps
- Initiatives
- Investment cases
Governance focuses on:
- Decision rights
- Design principles
- Architectural guardrails
- Escalation paths
Governance becomes a design system — not a control function.
6. Enable: Platforms and Guardrails
Delivery teams need freedom within structure.
Teams are enabled through:
- Reference architectures
- Approved patterns
- API and event standards
- Security baselines
- Platform services
The objective is autonomy with alignment.
If teams constantly need exceptions, the system is broken.
7. Deliver: Capability-Oriented Execution
Execution is organized around capabilities, not systems.
Teams are aligned to:
- Value streams
- Customer journeys
- Platform domains
Architecture supports:
- Incremental delivery
- Parallel modernization
- Legacy coexistence
Change becomes continuous, not episodic.
8. Learn: Feedback and Adaptation
Every cycle produces learning.
Organizations should continuously monitor:
- Capability performance
- Technical debt
- Platform adoption
- Delivery lead times
- Business impact
This feeds back into sensing and strategy.
Architecture becomes adaptive.
Core Artefacts
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.
Example: Applying the Playbook in Practice
In a telecom environment, organizations often encounter:
- Siloed customer and service platforms
- Overlapping digital and assisted channels
- High cost of change
- Slow time-to-market
- Limited end-to-end visibility
Using this cycle:
- Strategy focused on self-service and automation
- Capabilities were reframed around journeys
- A platform-based North Star was defined
- Legacy systems were phased via transitions
- Portfolio was restructured around domains
- Teams were enabled with APIs and events
- Continuous feedback improved prioritization
Within two years:
- Channel duplication reduced
- Release cycles shortened
- Operating costs decreased
- Customer satisfaction improved
Structure enabled speed.
Related Reading
This post is part of a broader series on capability-driven and design-led transformation:
- EDGY & ADM: From Architecture Method to Operating Model
- Why Your Capability Map Doesn’t Change Anything
Together, these articles describe how enterprise architecture can evolve from static documentation into a continuous organizational capability.
Final Thoughts: Architecture as an Organizational Capability
Enterprise architecture is not documentation.
It is a continuous design capability.
When done well, it:
- Aligns identity, experience, and structure
- Enables decentralization
- Reduces friction
- Builds resilience
- Sustains long-term change
Architecture is not about control.
It is about coherence.
And coherence is what makes organizations move.