| Document | Stage | Purpose | Content |
| Solution vision statement | Initiaton | Definition of why a solution is being considered | Description of problem area Vision of solution with ideas and concepts Ownership and stakeholder information |
| Architecture initiation document | Initiation | Contract between business and solution architecture | |
| Architecture input catalogue | Discovery | | |
| Stakeholder register (and optional comms plan) | Discovery | | |
| Conceptual design | Solution Outline | To promote discussion and reach agreement on the concept design to take forawrd | Visual representation of concept solution. Should be easy to understand by multiple stakeholders. |
| Stakeholder-focussed concept designs | Solution outline | To allow particular stakeholder groups to have more detail relevant for them. show the concept design in a more stakeholder-specific view | Tweaked versions of the main concept diagram. Tables, maps, storyboards, scenarios that explain how the concept design meets this stakeholder group’s needs |
| Traceability grid | Solution outline | Shows how the solution concept has evolved from the business requirements | A cross-reference grid showing the links between the solution components and the original solution vision, including explanation of variations |
| Business case/options | Analysis | To allow sponsor and stakeholders to settle on a single approach to take forwards | Options appriasal showing high level comparison of costs/benefits/risks/effort/impact |
| Scope definition | Analysis | Identify the areas the solution will impact | A list of items such as business units, processes, jobs roles, IT systems and infrastructue that need to be changed, removed or created as part of the solution |
| Solution Building Block model | Analysis | Identify new and existing building blocks that form the solution | A list of building blocks, including an assessment of the changes that are needed to any existing building blocks that are found. |
| Solution interface catalogue | Analysis | Shows how the building blocks interact with one another | Details of the data, direction, triggers of each interaction between building blocks |
| “High level design”? | Logical design | A complete specification for a single solution to implement | A solution model that covers the whole scope definition Itemised solution components and interfaces Itemised changes to business units, processes, technology etc Itemised data and information requirements Itemised design decisions that have brought the design to this point Details of KPIs/measures and how they can be incorporated in the design |
| Solution views for stakeholders | Validation | To make sure stakeholders agree with the solution design | A set of viewpoint definitions (security, buniess org, applications etc) that will satisfy stakeholder concerns. For each viewpoint, at least two views showing the current and future state architecture. |
| Impact analysis report | Validation | Categorise and list all changes and their impacts | An itemised list of all the changes that the solution will bring, and for each one a list of impacts with details about the type or impact and whether it is positive, negative or neutral. |
| Gap analysis report | Validation | Breaks down the changes to the component level | what needs to be added/modified/removed, along with the costs, risks, resource, dependencies involved |
| Roadmap | Roadmap | Communication with stakeholders about when the solution components will be delivered | Normally a visual timeline showing how the delivery will unfold, including delivery of key functionality, sequencing, timescales and milestones. |