A modernisation plan connects organisational objectives, existing systems, target architecture and the work required. Its scope may be a single service, several sites or a broader development programme, depending on the project and the material already available.
The following is a proposed working structure. Its sections can be developed iteratively: assessment results refine requirements, while testing options may change the scope of work. This is a planning guide, not an account of a particular client engagement.
1. Objectives and scope
Define an owner, users and an intended outcome for the modernisation task. Examples include: reduce manual transfer of requests, make service recovery testable or provide access to current technical documentation.
Record four things: the process to change, who needs the change, the present obstacle and what improvement would mean. State constraints separately: permitted interruption, data access, available resources and dependencies on other work.
This establishes a boundary. Dependencies that directly affect the intended result belong in the assessment. The rest of the infrastructure does not automatically need immediate replacement.
2. Current state and dependencies
For the selected process, complement the equipment and application inventory with a dependency map: user action → application → data → integrations → infrastructure → operational owner.
Access to documentation, for example, may depend on file quality, permissions, employee identities, index updates and the availability of the source repository—not only the search engine. Before choosing a new tool, establish which dependency actually constrains the result.
Include system and data owners, authoritative sources, important exchanges and manual transfer points. Mark unknowns explicitly. “We assume every document has an owner” is not equivalent to “ownership has been established for all sources in this process.”
This section records dependencies and gaps that could affect the choice of solution.
3. Target state and requirements
The target architecture should explain how the process will operate after the change. Where is the authoritative data? Who may read or modify it? How does information move between systems? What happens when an exchange fails? Who operates the result?
Express these as requirements first: users see only permitted documents; a repeated event does not create a duplicate task; the main process remains available when analytics is unavailable. Then compare technical ways of meeting them.
Current-versus-target comparison also appears in other disciplines. NIST CSF, for example, uses current and target cybersecurity profiles to identify gaps. This is a useful analogy, not a claim that a cybersecurity profile replaces enterprise architecture. [1]
4. Gaps and required decisions
The transition often contains different kinds of work. Some gaps need technical changes; others need a decision about ownership, access rules or approval processes. Record the required decision and its owner for each issue.
A simple working structure is:
| Gap | Required change | Decision owner | Validation |
|---|---|---|---|
| No shared asset identifier | Agree identifiers and matching rules | Data owner | Match records unambiguously across selected systems |
| Search and source permissions differ | Define consistent access checks | Service and security owners | Test permitted and prohibited requests |
| Recovery has not been exercised | Prepare a recovery scenario and test | Operations owner | Execute recovery and record the result |
This is an illustrative template, not a finding about any particular organisation. Its purpose is to connect each gap with an action and evidence of completion.
5. Priorities and work dependencies
A valuable initiative cannot always begin first. It may depend on access controls or a decision about source data. Conversely, an expensive change may be deferred by limiting the initial use case.
Assess expected value, dependencies, uncertainty, effort, operational consequences and reversibility. Identify information that could change the assessment. A transparent explanation can be more useful than a precise-looking score built from arbitrary weights.
Distinguish necessary preparation, a bounded test, implementation and later expansion. Set a condition for continuing from each stage. For example, expanding the set of sources may require successful access and search-quality checks on the initial collection.
6. Implementation and operating costs
Include data preparation, integration, migration, training, support, monitoring and possible supplier changes. For an AI use case, separate model or compute costs, evaluation, human review and correction of errors.
Until sufficient evidence exists, use ranges and scenarios. Distinguish one-off work, recurring expenditure and assumptions. Do not present released employee time as money already saved: the mechanism that converts capacity into an economic outcome still needs to be established.
Ask not only what an option costs, but also which uncertainty should be resolved to make the comparison more reliable.
7. AI use cases
Depending on the task, compare options such as: improve the existing process, automate it through explicit rules and integrations, or introduce AI for a defined part of the work.
In an illustrative documentation-search scenario, source ownership, consistent access checks and update rules may need attention first. The team can then compare conventional search with answers generated from retrieved documents. Select the option that best meets the agreed task, accounting for errors, cost and operations.
AI risk management also extends beyond launch. NIST AI RMF connects trustworthiness with the design, development, use and evaluation of AI systems. It is a voluntary framework, not a certificate that a solution is compliant or safe. [2]
8. The initiative record
Use a short card for each item so that the plan can be executed:
| Field | What to record |
|---|---|
| Challenge and boundary | The process being changed and what is out of scope |
| Owner | Who makes decisions and accepts the result |
| Baseline | The evidence behind the current assessment |
| Intended outcome | What should become possible or improve |
| Option and alternatives | Why this approach was selected |
| Dependencies | Work or decisions required first |
| Resources and cost | A range, its components and important assumptions |
| Validation | A scenario, measure and acceptance criterion |
| Review condition | What would change or stop the initiative |
| Operations | Who supports the result after launch and how |
Keep technical measures separate from business outcomes. Successful delivery of messages between applications is not the same as reduced request-processing time. The relationship between the two should nevertheless be explicit.
The completed plan
For the selected area, the team should understand the current design, target state, important gaps, sequence of work and validation criteria. These materials support agreement on the scope and sequence of change.
The plan records available evidence, assumptions, required tests and conditions for review.
Related reading: IT strategy and architecture · Architecture & Infrastructure · RTO and RPO: testing recovery.
Sources
- NIST — CSF 2.0 Profiles. The source for comparing current and target cybersecurity profiles. The broader article presents a proposed working method, not a mandatory standard.
- NIST — AI Risk Management Framework. A voluntary framework for addressing AI risks across the lifecycle.