Quick Navigation
- Start here — Why current state matters
- Documenting current state
- Defining target state
- Transition states
- Maturity levels
- Gap analysis
- AI readiness
- Keeping it current
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
You can't plan a journey without knowing where you're starting from. Yet most architecture programmes define a target state without honestly assessing the current one. I've seen beautiful future-state diagrams that nobody could reach because nobody mapped the terrain between here and there. The result: plans that don't survive contact with reality.
Current state describes what exists today — including the problems, debt, and constraints. Target state describes what must exist to meet future business needs. Transition states are the realistic intermediate steps. The gap between current and target is where transformation planning lives.
None of these are optional. Skip current state and you design in a vacuum. Skip target state and you drift without direction. Skip transition states and you produce plans no one can execute.
Keep it in mind.
1. Why current state matters — The danger of designing in a vacuum
Architects love designing the future. It's tempting to skip the messy present and go straight to the clean target state.
When current state isn't documented, teams design solutions that ignore existing constraints — integration debt, legacy dependencies, data quality issues, regulatory requirements, and organisational capacity. The result is a target state that's technically elegant and practically unreachable.
The danger signs: "We'll just migrate to the new platform" — without understanding what's on the old one. "The target state is microservices" — without knowing the monolith has 40 integration points. "We'll replace the legacy system" — without understanding what it actually does today. "The data will flow through the new pipeline" — without knowing the current data quality.
flowchart TD
SKIP["Skip Current State"] --> VACUUM["Design in a Vacuum"]
VACUUM --> SURPRISE["Surprises During Delivery"]
VACUUM --> OVERBLOWN["Overblown Plans"]
VACUUM --> REWORK["Rework and Delay"]
SURPRISE --> COST["💸 Cost\nBudget overrun\nTimeline slip"]
OVERBLOWN --> COST
REWORK --> COST
HONEST["Document Current State\nHonestly"] --> REAL["Realistic Plans\nBased on reality"]
REAL --> DELIVER["Deliverable Transformation\nAchievable steps"]
The honest truth about current state: It's always messier than anyone wants to admit. It includes technical debt, workarounds, tribal knowledge, and shadow IT. Documenting it honestly is uncomfortable — but it's the only way to plan realistically. The current state isn't a criticism of past decisions — it's a record of what exists.
Why current state documentation fails: Roses-coloured — only good things documented; problems hidden. Fix: include debt, gaps, and pain points explicitly. Outdated — documented 2 years ago, never updated. Fix: link to living artefacts — landscape, dependency maps. Too detailed — every class and method documented. Fix: focus on significant decisions and boundaries. Too shallow — "we use Java and AWS" — no useful detail. Fix: capture integrations, data flows, dependencies. Nobody owns it — no one is responsible for accuracy. Fix: assign ownership to domain architects.
What good current state documentation includes: Applications — what systems exist, what they do, who owns them. Integrations — how systems talk to each other — point-to-point, middleware, APIs. Data — where data lives, how it flows, who owns it, quality issues. Technology — platforms, languages, infrastructure, versions, support status. Debt — known problems, workarounds, end-of-life systems, skill gaps. Constraints — regulatory, budget, organisational, contractual.
Skip current state and you design for a world that doesn't exist.
Try it yourself — The current state check
Can you answer these questions about your current state?
| Question | Your answer |
|---|---|
| How many applications do you run? | |
| How many integration points exist? | |
| What's your biggest technical debt? | |
| What constraints are you working within? |
If you can't answer any of these honestly, you're designing in a vacuum.
2. Documenting current state — What to capture, what to leave out
Current state can be documented at infinite depth. Capture too little and it's useless. Capture too much and no one maintains it.
You need a pragmatic scope — enough to make decisions, not so much that documentation becomes the project.
What to capture: Applications — what systems exist, what they do, who owns them. Integrations — how systems connect — APIs, messaging, files, databases. Data — where data lives, quality, ownership, flow. Technology — platforms, infrastructure, versions, supportability. Debt — known issues, workarounds, end-of-life risks. Constraints — regulatory, contractual, organisational, budget.
What to leave out: Internal implementation details — class structures, algorithms, code patterns. Individual team processes — how teams run standups or manage backlogs. Temporary states — in-flight migrations, experiments, POCs.
flowchart TD
CURR["Current State Documentation"] --> CAP["Capture"]
CURR --> LEAVE["Leave Out"]
CAP --> A["Applications\nWhat, who owns, health"]
CAP --> I["Integrations\nHow systems connect"]
CAP --> D["Data\nWhere, quality, ownership"]
CAP --> T["Technology\nPlatforms, versions, support"]
CAP --> DB["Debt\nIssues, workarounds, EOL"]
CAP --> C["Constraints\nRegulatory, budget, org"]
LEAVE --> L1["Code internals\nClass structures, algorithms"]
LEAVE --> L2["Team processes\nStandups, backlogs"]
LEAVE --> L3["Temporary states\nIn-flight migrations"]
The documentation tiers: Executive summary — 1 page: top systems, major pain points, key constraints. For board presentations, strategy discussions. Architecture overview — 5-10 pages: systems, integrations, data flows, technology. For architecture reviews, planning sessions. Detailed landscape — full register: every application, integration, technology. For rationalisation, migration planning. Deep dive — per-system detail: internal structure, API specs, data models. For specific modernisation projects.
Sources for current state information: Architecture documentation — intended design. Often outdated. CMDB / asset register — what systems exist. Depends on maintenance. Code repositories — what is actually built. High reliability — source of truth for code. Integration middleware — how systems actually connect. High reliability — runtime truth. Team interviews — tribal knowledge, workarounds, pain points. High for context, low for completeness. Monitoring / observability — runtime behaviour, dependencies, performance. High reliability — what actually happens.
The discovery workshop approach: Gather 8-12 people who know different parts of the system. Start with a blank wall or whiteboard. "Draw every application you interact with." "Draw the arrows — how do they connect?" "What breaks most often? What's the biggest pain?" Capture, digitise, validate. This is faster and more accurate than any documentation review.
Capture at the boundary level — applications, integrations, data flows, technology — not at the implementation level.
Try it yourself — The discovery exercise
If you ran a discovery workshop today, who would you invite?
| Role | What they know | What they'll reveal |
|---|---|---|
If you can't name 8-12 people, your current state documentation is based on too few perspectives.
3. Defining target state — Connecting future architecture to business goals
Target states defined by technology preferences — "we should be on Kubernetes" or "everything should be serverless" — are solutions looking for problems.
A target state must be driven by business goals. The question isn't "what cool technology should we use?" but "what must exist to achieve our strategic objectives?"
The process: Start with business outcomes — what is the organisation trying to achieve? Identify what must change — which capabilities, systems, or structures need to be different? Define the target architecture — the structure that enables those outcomes. Validate with stakeholders — does this actually solve the business problem? Keep it at the right level — principles and boundaries, not implementation details.
flowchart TD
BIZ["🎯 Business Outcomes\nWhat the org is trying to achieve"]
BIZ --> CHANGE["🔄 What Must Change\nCapabilities, systems, structures"]
CHANGE --> TARGET["📐 Target State Architecture\nThe structure that enables outcomes"]
TARGET --> VALID["✅ Stakeholder Validation\nDoes this solve the business problem?"]
VALID --> PRIN["📏 Principles & Boundaries\nNot implementation details"]
What a good target state includes: Principles — guiding rules: "API-first," "data owned by domains," "cloud-native." Capabilities — which capabilities are enabled, improved, or new. Boundaries — how the system is decomposed — services, domains, platforms. Integration — how components connect — patterns, not products. Technology direction — cloud strategy, platform choices, standards — not vendor selections.
What a target state does NOT include: Specific product selections — that comes later. Implementation details — that's solution design. Timelines — that's the roadmap. Costs — that's the business case.
Target state quality criteria: Outcome-driven — every element connects to a business outcome. Test: "Which outcome does this enable?" Constraint-aware — account for regulatory, budget, and organisational limits. Test: "Can we actually do this?" Technology-agnostic where possible — principles over products. Test: "Would this still be valid if we changed vendor?" Achievable — within reach given organisational capacity. Test: "Can our teams build and operate this?" Testable — clear criteria for success. Test: "How will we know we arrived?"
Target state anti-patterns: Technology-driven — "our target is Kubernetes." Fix: start with outcomes, derive technology. Copy-paste — "Company X did this, so should we." Fix: design for your context, not theirs. Big bang — "everything changes on day one." Fix: define transition states. Vague — "modern, scalable, cloud-native." Fix: specific enough to make decisions. Unachievable — requires 5x current capacity. Fix: right-size for your organisation.
Target state = the architecture that enables business outcomes — not a technology wishlist.
Try it yourself — The target state test
Take your target state. Run it through the test:
| Question | Your answer |
|---|---|
| Which business outcome does this enable? | |
| Can our teams actually build this? | |
| Is it specific enough to make decisions? | |
| Would it still be valid if we changed vendor? |
If any answer is "no" or "I don't know," your target state isn't ready.
4. Transition states — The realistic steps between here and there
The gap between current state and target state is often too large to cross in one step. Attempting to do so creates big-bang transformations that fail.
Transition states are the intermediate architectures — the realistic steps that the organisation passes through on the way to the target. Each transition state must be a viable, operating architecture — not a half-built mess.
Example: Year 0 (Current): Monolith, on-prem, batch processing. Year 1 (Transition): Monolith + API layer, hybrid cloud, event streams for key flows. Year 2 (Transition): Modular monolith + extracted services, cloud-first, real-time for priority capabilities. Year 3 (Target): Domain services, cloud-native, event-driven architecture.
Each year is a working system. Each year delivers value. Each year is one step closer to the target.
flowchart LR
C["🟢 Current\nMonolith, on-prem,\nbatch processing"]
C --> T1["🟡 Transition 1\nAPI layer, hybrid cloud,\nkey event streams"]
T1 --> T2["🟡 Transition 2\nModular + extracted services,\ncloud-first, real-time"]
T2 --> T3["🟢 Target\nDomain services,\ncloud-native, event-driven"]
Rules for transition states: Each transition must be a working system — not a partial migration. Each transition must deliver business value — not just technical progress. Each transition must be reversible in principle — minimise one-way doors. Each transition must be achievable with available capacity — not aspirational. Each transition must reduce risk toward the next step.
Designing transition states: Identify the gap — what must change between current and target? Sequence the changes — what must happen before what? Dependencies first. Group into transitions — what changes can be delivered together as a coherent state? Validate viability — is each transition a working system that delivers value? Size to capacity — can the organisation actually deliver each transition?
Transition state template: Transition State N: [Name]. What changes: [list of architectural changes in this step]. Business value delivered: [what this step enables]. Dependencies: [what must be in place before this step]. Risk: [what could go wrong]. Duration: [realistic estimate]. Reversibility: [can we undo this step if needed?].
Transition states = viable architectures on the path to the target — each one works, each one delivers value.
Try it yourself — The transition design
What are your transition states?
| Transition | What changes | Business value | Dependencies |
|---|---|---|---|
If you only have "current" and "target," you're planning a big bang. Don't.
5. Maturity levels — Assessing where the organisation is on each dimension
Not all parts of the organisation are at the same level of architectural maturity. Some domains have well-designed, well-governed architecture. Others have accidental complexity and no documentation.
Maturity assessment provides a structured way to measure where each domain, capability, or system stands — and where investment is needed.
A simple maturity scale:
| Level | Label | What it means |
|---|---|---|
| 1 | Ad hoc | No deliberate architecture — structure emerged by accident |
| 2 | Documented | Key decisions and structures are captured |
| 3 | Governed | Reviews ensure architecture decisions are consistent |
| 4 | Measured | Fitness functions and metrics track architecture health |
| 5 | Adaptive | Architecture evolves deliberately and continuously |
flowchart LR
L1["1. Ad hoc\nAccidental structure"] --> L2["2. Documented\nDecisions captured"]
L2 --> L3["3. Governed\nReviews enforce consistency"]
L3 --> L4["4. Measured\nMetrics track health"]
L4 --> L5["5. Adaptive\nContinuous deliberate evolution"]
Applying maturity to capabilities:
| Capability | Current Maturity | Target Maturity | Gap Action |
|---|---|---|---|
| Customer Analytics | 1 — Ad hoc | 4 — Measured | Document, govern, instrument |
| Order Fulfilment | 3 — Governed | 3 — Governed | Maintain |
| Product Launch | 2 — Documented | 4 — Measured | Add governance, add metrics |
| Risk Assessment | 1 — Ad hoc | 5 — Adaptive | Full maturity build |
Dimensions to assess: Documentation — are decisions captured? Are diagrams current? Governance — are decisions reviewed and enforced? Standards — are there agreed patterns and technology choices? Measurement — are there metrics for architecture health? Evolution — is architecture deliberately adapted over time? Communication — do teams understand and follow architectural guidance?
Maturity levels give you a structured way to assess where you are and where you need to be — per capability, per domain, per system.
Try it yourself — The maturity check
Rate your top 5 capabilities on maturity (1-5):
| Capability | Current maturity | Target maturity | Gap action |
|---|---|---|---|
If everything is at the same level, you're not assessing honestly.
6. Gap analysis — Turning the difference into a structured programme of work
You have the current state, the target state, and the transition states. But how do you turn the gap between them into an actionable plan?
Gap analysis is the structured comparison between current and target — identifying what must be created, changed, retired, or sustained to reach the target.
The four categories:
| Category | Meaning | Action |
|---|---|---|
| Create | Capabilities, systems, or structures that don't exist yet | Build new |
| Change | Capabilities, systems, or structures that exist but must be different | Modernise or transform |
| Retire | Capabilities, systems, or structures that must be removed | Decommission |
| Sustain | Capabilities, systems, or structures that remain as-is | Maintain |
flowchart TD
GAP["Gap Analysis"] --> C["🆕 Create\nNew capabilities, systems,\nstructures that don't exist"]
GAP --> CH["🔄 Change\nExisting elements that\nmust be different"]
GAP --> R["⬛ Retire\nElements that must\nbe removed"]
GAP --> S["🟢 Sustain\nElements that remain\nas-is"]
C --> PLAN["Transformation Programme"]
CH --> PLAN
R --> PLAN
S --> PLAN
The gap analysis output:
| Element | Current State | Target State | Gap Category | Priority | Dependencies |
|---|---|---|---|---|---|
| Customer Analytics | Partial — BI only | Full — real-time + BI | Change | High | Data platform |
| Risk Assessment | Missing | Full — automated engine | Create | High | — |
| Legacy CRM | 15-year-old on-prem | Retire — replaced by new platform | Retire | Medium | New platform live |
| Order Fulfilment | Full — ERP-based | Full — ERP + API layer | Change | Medium | API gateway |
| Financial Reporting | Full — governed | Full — as-is | Sustain | Low | — |
The gap analysis process: Current state documented → compare current vs target → identify gaps → categorise (create, change, retire, sustain) → prioritise based on business impact → sequence based on dependencies → programme of work.
Prioritisation criteria: Business impact — does this gap block a strategic outcome? Risk — does this gap create compliance, operational, or security risk? Dependencies — do other gaps depend on this being resolved first? Cost — how expensive is this gap to close? Speed — how quickly can this gap be closed?
The 2×2 prioritisation: High impact, easy to close — do first. Quick wins. High impact, hard to close — plan carefully. Strategic investments. Low impact, easy to close — do when possible. Housekeeping. Low impact, hard to close — consider deferring. May not be worth it.
Gap analysis = create, change, retire, sustain — turning the difference into action categories.
Try it yourself — The gap analysis
Take three elements. What's the gap?
| Element | Current | Target | Gap category | Priority |
|---|---|---|---|---|
If everything is "sustain," you're not being honest about the gap.
7. AI readiness as current state — Documenting AI debt, data silos, and integration gaps
In 2026, every organisation is evaluating or adopting AI. But most current state assessments don't account for AI readiness — the data quality, integration maturity, and governance foundations that AI requires.
Teams plan AI initiatives without honestly assessing whether the current state can support them. The result: AI projects that stall because the data is siloed, the integrations are brittle, or the governance is absent.
AI readiness dimensions:
| Dimension | What to assess | Why it matters |
|---|---|---|
| Data quality | Is the data accurate, complete, and timely? | AI amplifies bad data — garbage in, garbage out |
| Data accessibility | Can AI systems access the data they need? | Siloed data blocks AI capabilities |
| Integration maturity | Can data flow in real-time or only in batches? | Real-time AI needs real-time data |
| Governance | Is there data classification, access control, lineage? | AI governance depends on data governance |
| Infrastructure | Can the platform support AI workloads — compute, storage, latency? | AI inference needs appropriate infrastructure |
| Skills | Does the team understand AI capabilities and limitations? | AI adoption requires literacy, not just tooling |
flowchart TD
AI["AI Readiness Assessment"] --> DQ["Data Quality\nAccurate, complete, timely?"]
AI --> DA["Data Accessibility\nSiloed or accessible?"]
AI --> IM["Integration Maturity\nBatch or real-time?"]
AI --> GOV["Governance\nClassification, access, lineage?"]
AI --> INF["Infrastructure\nCompute, storage, latency?"]
AI --> SK["Skills\nAI literacy across teams?"]
DQ --> BLOCK{"Blocks AI\nadoption?"}
DA --> BLOCK
IM --> BLOCK
GOV --> BLOCK
INF --> BLOCK
SK --> BLOCK
BLOCK -->|"Yes"| FIX["🔴 Fix before AI initiative"]
BLOCK -->|"No"| PROCEED["🟢 Proceed with awareness"]
The uncomfortable truth: Most organisations have data silos that prevent AI from accessing cross-domain information. Most organisations have batch-only integrations that prevent real-time AI inference. Most organisations lack data governance mature enough for AI workloads. Documenting this honestly in the current state prevents AI initiatives from failing later.
AI debt — the hidden current state problem: Data debt — poor quality, siloed, ungoverned data. AI models produce unreliable results. Integration debt — batch-only, brittle, undocumented integrations. AI can't access data in real-time. Infrastructure debt — no compute for training or inference. AI workloads can't run at scale. Governance debt — no data classification, no access control. AI can't be deployed compliantly. Skills debt — no AI literacy across teams. AI adoption stalls at pilot stage.
The AI readiness scorecard:
| Dimension | Score 1 (Blocked) | Score 3 (Partial) | Score 5 (Ready) |
|---|---|---|---|
| Data quality | Inaccurate, incomplete, no ownership | Partial quality, some ownership | High quality, governed, owned |
| Data accessibility | Siloed in systems, no APIs | Some APIs, mostly batch | Real-time APIs, unified access |
| Integration maturity | Point-to-point, file-based | Middleware, some events | Event-driven, API-first |
| Data governance | No classification, no lineage | Basic classification | Full governance, lineage, access control |
| Infrastructure | On-prem, no AI compute | Hybrid, limited GPU | Cloud-native, AI-optimised |
| Skills | No AI literacy | Some data science capability | Cross-functional AI fluency |
AI readiness = data quality + accessibility + governance + infrastructure + skills — document it honestly in the current state or watch AI initiatives stall.
Try it yourself — The AI readiness check
Score your organisation on each dimension (1-5):
| Dimension | Score | Gap action |
|---|---|---|
| Data quality | ||
| Data accessibility | ||
| Integration maturity | ||
| Governance | ||
| Infrastructure | ||
| Skills |
If your average is below 3, you're not ready for AI. Fix the foundation first.
8. How to keep it current — Architecture that reflects reality, not aspiration
Current state assessments are done once, filed, and never updated. Within months, they no longer reflect reality.
Stale current state documentation is worse than no documentation — it creates a false sense of understanding. Decisions based on outdated information produce plans that don't match the real landscape.
Ways to keep it current: Link to living artefacts — connect current state to CMDB, code repos, monitoring — auto-refresh where possible. Annual review cycle — scheduled review of the full current state — at least annually. Event-triggered updates — major changes (new system, decommission, merger) trigger current state update. Ownership — assign current state ownership to domain architects — not just the EA team. Lightweight format — if it takes a week to update, it won't be updated — keep it lightweight.
flowchart TD
CURR["Current State Documentation"] --> LINK["Link to Living Artefacts\nCMDB, repos, monitoring"]
CURR --> ANNUAL["Annual Review Cycle\nScheduled full refresh"]
CURR --> EVENT["Event-Triggered Updates\nMajor changes trigger review"]
CURR --> OWN["Assign Ownership\nDomain architects own their slice"]
CURR --> LIGHT["Keep Lightweight\nEasy to update = actually updated"]
LINK --> FRESH["✅ Current State\nReflects Reality"]
ANNUAL --> FRESH
EVENT --> FRESH
OWN --> FRESH
LIGHT --> FRESH
The maintenance model: Annual review — full refresh of current state — all layers. EA team + domain architects. New system — add to landscape, update integrations, assess capability coverage. Domain architect. Decommission — remove from landscape, update dependencies. Domain architect. Major change — update affected capabilities, integrations, technology. Domain architect. Merger / acquisition — full refresh — new landscape, new capabilities. EA team. Architecture review — verify current state matches what teams describe. Review forum.
Automation opportunities: Application inventory — CMDB, cloud provider APIs. Integration map — API gateway logs, middleware monitoring. Technology versions — dependency scanning, build pipelines. Deployment topology — Kubernetes / cloud console APIs. Data lineage — data catalog tools.
Stale architecture is worse than no architecture — build maintenance into the process from the start.
Try it yourself — The maintenance check
How current is your current state documentation?
| Question | Your answer |
|---|---|
| When was it last updated? | |
| Who owns it? | |
| How long would it take to update? | |
| Is it linked to living artefacts? |
If it's older than 12 months or takes more than a day to update, it's stale.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
C["🟢 Current State\nWhat exists today\nIncluding debt and gaps"]
T["🎯 Target State\nWhat must exist\nDriven by business outcomes"]
TR["🪜 Transition States\nRealistic intermediate steps\nEach one works, each one delivers"]
C --> GAP["📐 Gap Analysis\nCreate · Change\nRetire · Sustain"]
T --> GAP
GAP --> TR
TR --> ROAD["🗺️ Roadmap\nSequenced delivery plan"]
C --> MAT["📏 Maturity Assessment\nWhere each domain stands"]
T --> MAT
C --> AI["🤖 AI Readiness\nData quality, integration,\ngovernance, skills"]
ROAD --> EXEC["✅ Execution\nDeliver, measure, adapt"]
AI --> ROAD
The foundation:
Current state must be documented honestly — including debt, gaps, and problems. Skipping it means designing for a world that doesn't exist. Target state must be driven by business outcomes, not technology preferences. "We should be on Kubernetes" isn't a target state. Transition states are the bridge — each one must be a viable, working architecture that delivers value. Big-bang transformations fail; sequenced transitions succeed. Current state + target state + transition states = the complete picture for any architecture transformation.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Current state (as-is) | What exists today, honestly | Document applications, integrations, data, debt, constraints |
| Target state (to-be) | What must exist for business outcomes | Driven by strategy, not technology preferences |
| Transition states | Intermediate viable architectures | Each one works, each one delivers value |
| Gap analysis | The structured comparison | Create, change, retire, sustain |
| Maturity levels | Where each domain stands | Assess documentation, governance, standards, measurement |
| AI readiness | Data, integration, governance, skills | Document honestly — AI initiatives will stall without it |
| Keeping it current | Stale is worse than none | Link to living artefacts, annual review, assign ownership |
How to know if this landed
You'll know this has landed when someone stops defining target states without documenting current state first. Can describe the current state of the architecture — including debts and gaps. Can articulate the target state in terms of business outcomes, not technology. Has defined at least one transition state between current and target. Has completed a gap analysis categorised as create, change, retire, sustain. Has assessed AI readiness as part of the current state. Reviews the current state at least annually — or after major changes. And uses current/target state in investment cases and roadmap planning.
What changes when the mental model clicks
I've run this session with a financial services company where leadership defined a "digital-first" target state with no current state documentation. Programme of work started with a cloud migration — discovered 40 undocumented integration points mid-project. AI initiative launched to automate risk assessment — stalled because data was siloed across 6 systems with no common identifiers. The gap at the start is usually not about understanding transformation — it's about not documenting where you actually are.
What changes after this session:
Teams stop designing target states in isolation and start connecting them to honest current state assessments. The discovery workshop exercise — "draw every application you interact with" — is always the moment things click. People stop treating transition states as optional and start treating them as the only way to cross the gap. Their results get better. They stop attempting big-bang transformations when the real problem was that they hadn't designed viable intermediate states.
The gap analysis exercise tends to immediately change how teams think about their transformation programmes. They start categorising gaps as create, change, retire, sustain. Their clarity goes up. They stop trying to sustain everything when the real problem was that they hadn't identified what to retire.
Book a Workshop
Ready to honestly assess where you are and design a realistic path to where you need to be?
or
1-day workshop includes current state discovery exercise with your real systems and stakeholders, target state definition driven by your business outcomes, transition state design — realistic intermediate steps for your context, gap analysis — create, change, retire, sustain for your portfolio, maturity assessment across your key domains and capabilities, AI readiness assessment — data, integration, governance, skills, and as-is / to-be architecture canvas + transition state design + maturity scale + AI readiness assessment.