Purpose: To narrow down the options to a single solution option to take forwards
Activities:
- Business case. Put forward a range of options to allow stakeholders to decide which one to take forwards. May involve modifications in order to get agreement.
- Scope definition: formalise the scope of the solution – the impacted components, including business areas as well as processes, services and technology
- Solution Building block definition: working out whether there are new/existing SBBs
- Solution interfaces definition: cataloguing the interfaces between solution building blocks
Sometimes two or three options might be taken forwards to allow them to be compared by people deciding on the business case, however as each one involves significant effort, a single solution is the preferred output of this phase.
Outputs:
A single solution option
A catalogue of in-scope solution building blocks
A catalogue of interfaces between solution building blocks
Stage 4 – Analysis phase – HowTo
Each option in the business case has a:
- Description,
- assessment of scale of change using gap analysis
- Cost/benefit analysis
- Return on investment report
- Risk assessment
At this stage, many details have not yet been worked out, so these can only be high level outlines. Even so, they should be able to give an indication of effort, impact, cost and scale of change to allow for comparison.
All stakeholders may have input into the option selection process, the business sponsor has the final say and authorises the option to take forwards.
Scope definition
This itemises each area where there is going to be change, including
Business units, job roles, business processes, products and services, IT systems and infrastructure
For each item named, the scope should include whether the item is new or existing, and for existing items whether it is to be modified, removed or replaced (replace = remove+new, as long at the interfaces are kept intact or enhanced)
Each item in the scope definition should be linked to any relevant architecture documentation. Also, architecture documentation being produced needs to be submitted to EA function in case there is overlap with existing work that this solution might not be aware of.
Solution Building Block analysis
Using the scope definition and the concept design, investigate whether these components already exist in the organisation. If not, can other components provide all/part of the necessary functionality (e.g. Could an existing team take on responsibility for a role identified)
If an existing building block is found, assess whether it is acceptable as-is, including whether it could be replace in future with the same interfaces, or whether it would need to be rebuilt (or sourced) from scratch in order to be useful. May include examples such as an existing building block that in theory matches, but is built on legacy infrastructure and has a limited life remaining.
The output is a list of SBBs, detailing:
- Name
- Category
- Ownership
- Current state
- Required modifications
- Any other org-specific useful info
Solution interface analysis
Construct a list of all the touch-points, hand-offs and interfaces between the SBBs. This can be framed in a common format, such as:
- Source
- Destination
- Trigger and other events
- Items exchanged, including supporting information
- Sequence
- Pre- or post- conditions