|
👷🚧🏗️👷♂️👷♀️ This page is under construction. 👷🚧🏗️👷♂️👷♀️ |
Requirements & Outcomes
For each requirement statement the architect needs to assess how well the architecture and supporting processes meet the objective of the requirement and the overall dimension of the SAF.
There may be different ways a requirement can be met. We SHOULD focus on the outcome BUT we MUST satisfy ourselves that the evidence provided can meet the stated outcome.
The assessment can be made via interviews, document reviews, cloud provider Well Architected Framework reviews1, delivery team meetings and ceremonies etc. It is not a one size fits all and will vary depending on the team make up etc. At all times we be risk based.
An assessment spreadsheet has been created which allows for a score based on the criteria below. Each requirement is some form of weighting to ensure more significant or complex requirements are accounted for. (Note. The weighting will be subject to change and review.)
SAF Requirements
| 0 | No evidence that the requirement is supported and as such presents significant service risk. |
| 1 | Limited evidence that the requirement is supported with high risks gaps. |
| 2 | Some elements of the requirement are met with an acceptable level of evidence but significant number of notable gaps. |
| 3 | Much of the requirement is met with an acceptable level of evidence but there are notable gaps which present risk which require mitigating action. |
| 4 | Most of the requirement is met with good levels of evidence but there are some gaps but are not thought to present significant risk. |
| 5 | Comprehensive evidence that the requirements is met and exceeds expectations in several areas. We would consider this an exemplar. |
Based on the assessment the architect and product owner will need to agree a remediation plan for those areas considered more significant e.g. where one of the dimensions has a “AMBER” or “RED” score.
The proposal is that remediation planning be reported and tracked via the relevant architecture governance group e.g. TRG, P&P DA or for more significant issues ADA. This detail needs to be worked through.
We need to be able to reflect the health of our solution architectures in a simple and digestible form. The example below demonstrates a simple dashboard view for each product, this view will be enhanced as we undertake the initial review exercises and gather stakeholder feedback.