Purpose: To validate the solution design to make sure it addresses stakeholder concerns and at the same time achieves maximum positive impact for the business while minimising unplanned disruption and negative impacts.
Activities:
- Build and validate viewpoints: examine the solution with respect to the current architecture and the proposed architecture. Multiple viewpoints will be produced to allow different stakeholders (or groups of stakeholders with similar concerns) to confirm that both the existing and target designs represent the situation accurately. This process can highlight missing requirements, or misrepresentations, which will then need to be fed back into the solution design and require re-validation. Ideally this would not happen, because stakeholders should have been fully involved in the process so far and the requirements have been identified earlier on in the process..
- Impact analysis: identify and categorise the impacts of all the changes that the solution bring about
- Gap analysis: Itemises and categorises the things that need to change to get from the current to future state
Outputs:
- Current and future solution architecture views from multiple viewpoints
- Documented approval/sign off of viewpoints from stakeholders
- Impact report
- Gap analysis report
Phase 6: Validation Phase – HowTo
A set of formal views need to be created to allow stakeholders to agree to the solution.
Start by checking that the stakeholder register is complete and documents the concerns of the stakeholders accurately. This can be done via a review process, consultative with the stakholders.
The aim is to come up with a set of viewpoints that can be used to generate representations of the architecture that are fit-for-purpose for allowing stakeholders to accept the solution that is being proposed. It probably makes sense to use some standard viewpoints, for example one that allows a security-minded stakeholder to assess whether the solution meets the expected standards and shows where the risks lie.
Rather than one viewpoint per stakeholder, it may be possible to group them based on similar concerns to allow for a reduced number to be generated.
For each viewpoint identified:
- Identify the list of architectural elements that need to be in the view
- Identify the best way to present the information. This could be diagrams, tables, graphs, maps etc
- Generate two views using the identified items – one showing the baseline architecture for this solution area, and one showing the target solution.
- Use the views to work with stakeholders to ensure that the solution addresses their concerns adequately
- Work with stakeholders to gain sign-off on the solution. This needs to be formally recorded, e.g. In meeting minutes or similar.
Ideally at this stage, you would also want to be able to formally test the solution against the Enterprise Architecture. E.g. To make sure that it is aligning with target architecture and other solution activity. Since the solution architect has been involved from the start, this would often be baked in to the design anyway.
The validation phase includes feedback loop that may identify problems that mean going nback to the logical design phase and changing the solution, in which case, the validation needs to be completed again. It is an iterative process.
Impact analysis
In order to capture all changes, first need to revalidate that the scope identified during analysis phase is still correct. Use the scope definition.
First identify business areas that will be affected. E.g. Capabilities, staffing, business services, business processes. The changes can include changes to interfaces, such as relationships with externals.
For each identified area, record:
- Category (revenue, operating costs, capex, penalties/fines/sanctions, customer experience, staff impact)
- Type of impact
- An overall assessment of whether the impact is positive, negative or zero.
Gap analysis
Break down the changes to component/SBB level. Show the changes that are needed to these components to get from current to future. This can include information such as cost/resouce needed, risks and interdependencies. This can be used later in the roadmap stage.
Create gap models to show the transtion to current state. They can be based on the views created in the validate viewpoint phase. Gap models should show all things in scop, including things that don’t change. These can be used as a basis to create the gap analysis report and provide supporting information for it.