This metamodel supports the conduct of a Solution Health Check: a lightweight evaluation of a solution’s architecture. It introduces the Solution Health Check component type, which is used to set up and record an evaluation of how well an application’s architecture satisfies the demands of its most significant quality characteristics.
Contents
To gain a more detailed understanding of the value of conducting Solution Health Checks with Ardoq, and how this Solution has been designed, please read Solution Health Check: Purpose, Scope and Rationale. With this Solution, you will be able to address the following questions:
Which quality characteristics (e.g. Reliability, Security, Usability) make up a solution’s quality criteria?
How well does a solution’s architecture meet its quality criteria?
How might a solution’s architecture be improved to meet its quality criteria more effectively?
Has the health check revealed any new technical debt that needs recording and addressing?
Are there new risks that should be recorded associated with a solution’s current architecture?
What new initiatives should be proposed to address the review team’s recommendations?
Who has approved a given Solution Health Check?
When should a health check be conducted on this technology solution?
Solution Dependencies
A Solution Health Check is conducted against the architecture of a subject Application, with a Has Subject reference from the Solution Health Check component to its subject Application component. It is therefore a pre-requisite that Applications that may be the subject of a Health Check are represented with Application components in the Ardoq knowledge graph. In most situations, the Health Check is being conducted against the solution architecture, of which the Application is just the most visible or recognisable part. The solution architecture may comprise a more detailed decomposition of the application (its interfaces, modules, databases) and how they connect to each other, and the supporting software and hardware environments and infrastructure that enable the Application to run, and that facilitate its delivery of quality requirements, such as security and reliability. We use a single reference from the Solution Health Check to its subject Application to avoid creating a large number of references to all of the related components. It identifies the primary subject of the health check.
The criteria for each Health Check are selected from a Quality Model. Three example quality models are included with the Solution, being the same examples that are also included with the Technical Debt Management Solution. Whilst the same Quality Model workspace and components are used in both Solutions, the Technical Debt Management Solution is not a pre-requisite for this Solution.
Use of the automated workflows, including approvals, does require that there is a People workspace populated with Person components who have recorded email addresses.
The focal point of the Solution Health Check’s evaluation process is a workshop attended by a panel of experts. See Solution Health Check: Purpose, Scope and Rationale and How to use Architecture Reviews to identify Technical Debt for more details about how to run such workshops. The discussions in such workshops are often the source of new Debt Items, Risks and Initiatives. The Solution Health Check Solution has optional links to the Technical Debt Management, Application Risk Management, Compliance Assurance and Strategy to Execution Solutions to facilitate the creation and management of these artifacts. But these are not pre-requisites, and it is perfectly possible to adopt the Solution Health Check solution without these solutions. If you have already deployed any of these connected Solutions, and wish to extend the Solution Health Check solution to link to them, see the Solution Health Check Configuration Guide for details.
Solution Health Check Metamodel
The Quality Model
The criteria for evaluating a solution’s architecture in a Solution Health Check are selected from a Quality Model in the Quality Models Workspace, with each quality characteristic or sub-characteristic being represented as a Requirement component. Three example quality models are included with the Solution, and surveys and broadcasts are provided out of the box for us with the Ardoq Quality Model or the ISO 25010 Quality Model.
Ardoq Quality Model
ISO 25010 Quality Model (reproduced with the kind permission of BSI Group)
UK.GOV Service Standard
See the Solution Health Check Configuration Guide for details of how to switch this to a different quality model or a set of Architecture Guiding Principles.
The provided quality models all follow the modelling approach described in How to represent Policies, Principles, Standards and Frameworks in Ardoq.
Requirement Fields
This Solution adds two fields to the Requirement component type that forms part of a quality model representation in the Quality Models Workspace.
Field | Field Type | Description |
Component Level | Calculated Number | Records the level of this component in the parent/child hierarchy. In the supplied examples, the root parent is an Information Artifact component. The supplied requirement components will therefore have Component Level values of 2 or 3, depending on whether they represent Quality Characteristics or Quality Sub-characteristics. This is used, for example, to enable a Survey to invite the user to select from among just the Sub-characteristics of a model (excluding the parent Characteristics i.e. only Level 3). |
Model Name | Calculated Text | Records the name of the model to which it belongs (e.g. “Ardoq Quality Model”, picking up the name of its nearest ancestor that is of type Information Artifact. This is used in advanced searches to constrain the selection to just those Requirements that belong to the same Quality Model. |
Component Level - Gremlin
g.V(ids).project('id', 'name', 'value'). by(id). by('name'). by( emit().repeat( out('ardoq_parent')). count()) |
Model Name - Gremlin
g.V(ids). project('id', 'name', 'value'). by(id). by('name'). by(repeat(out('ardoq_parent')).until(hasLabel('Information Artifact')).values('name')) |
The Solution Health Check Component Type
Components of this type represent individual Health Check evaluations that are being, or have been, conducted against the architecture of a given Application. Past Health Checks are retained as separate records, so it is possible for there to be more than one Solution Health Check component associated with the same Application component (representing, for example, an ongoing evaluation, and one or more past ones).
Solution Health Check Fields
Field | Field Type | Description |
Decision Concern | Text paragraph | Describes the context / reason for conducting this health check. |
Decision Text | Text paragraph | A summary of the expert panel’s overall conclusions. |
Decision Rationale | Text paragraph | The rationale in support of the panel’s conclusions. |
Review Date | Date Time | The most recent date/time when one of the surveys relating to this Health Check was submitted. |
Live | Date Range | The period during which this health check remains valid. |
Live Status | Calculated List | The current status of this health check. One of Proposed, Live, Recently Retired or Long Retired depending on the relationship between today’s date and the date range of the Live field. Recently Retired indicates a Live End Date within the last 90 days, Long Retired beyond that. |
SHC Model | Text | Populated automatically using a Hidden Field when the New Solution Health Check Survey is submitted, with a value of Ardoq Lite, Ardoq Full, Ardoq Mixed, ISO 25010 Lite, ISO 25010 Full or ISO 25010 Mixed. It is used by the renewal process to identify which model was previously used. |
Live Status - Gremlin
today = new Date().format('yyyy-MM-dd') longThreshold = (new Date()-90).format('yyyy-MM-dd') // set to 90 days ago
g.V(ids). project('id', 'name', 'value'). by(id). by('name'). by( choose(has('live_end_date', lt (longThreshold)), constant('Long Retired'), choose(has('live_end_date', lt (today)), constant('Recently Retired'), choose(has('live_start_date', lte (today)), constant('Live'), constant('Proposed')))) ) |
Has Subject Reference
The Has Subject reference goes from a Solution Health Check component to one or more Application components, identifying the Application or Applications whose architectures are the subject of the health check evaluation.
Depends On References
A set of Depends On references are used to show the criteria that are being used to evaluate the health of the subject Application. Each of these references points to a Requirement component, representing a quality characteristic or sub-characteristic that forms part of a Quality Model. By using Reference Fields to record the views of the application owner and expert panel about the quality characteristic in the context of this particular Health Check, the one Quality Model can serve multiple Health Checks. This facilitates the collection of data about the different quality characteristics, and their importance and achievement across a growing number and variety of Solution Health Checks.
The Reference Fields contain the expert views of the panel.
Field | Field Type | Description |
Importance | Number | A number, on the scale of 1.0 to 5.0, representing the importance or significance of this quality characteristic to the application that is the subject of this health check. |
Level of Concern | Number | The expert panel’s agreed level of concern regarding how this quality characteristic is achieved by the architecture of the application that is the subject of this health check. A number, on the scale of 1.0 to 5.0, with 5.0 representing a very high level of concern (i.e. the solution does not address the characteristic at all satisfactorily). |
Exposure | Reactive Number | The product of Importance and Level of Concern, representing the relative exposure of the solution architecture to this quality characteristic. |
Comments | Text Paragraph | The collective comments of the expert panel regarding how the application’s architecture addresses this quality characteristic. |
Recommendations | Text Paragraph | The collective recommendations of the expert panel regarding how the application’s architecture addresses this quality characteristic. |
Characteristic Description | Calculated Text | The description field that defines this quality characteristic, automatically replicated here so that it can be used in Surveys (as a read-only field) to guide the expert panel. |
Characteristic Description - Gremlin
g.E(ids). project('id', 'value'). by(id). by(inV().values('description')) |
Refers To Reference to Initiative
This optional reference type is used to associate a Solution Health Check to one or more Initiative components that have been created to address the concluding recommendations of the expert panel. See Strategy to Execution Metamodel for more details about the Initiative component type.
Refers To Reference to Debt Item
This optional reference type is used to associate a Solution Health Check to one or more Debt Item components that were identified and created during the health check process. See Technical Debt Management Solution Metamodel for more details about the Debt Item component type.
Refers To Reference to Risk
This optional reference type is used to associate a Solution Health Check to one or more Risk components that were identified and created during the health check process. See Compliance Assurance Metamodel and Application Risk Metamodel for more details about the Risk component type.
Approved By Reference
This reference type links the Solution Health Check to one or more Person components indicating that those people have approved the final conclusions of the expert panel who collaborated on this health check.