Assessing Applications with Ardoq

Most IT departments apply a level of governance over their applications estate. The nature of that governance varies considerably depending on the size of the organization, its industry and its culture. Sometimes governance is largely devolved to the application teams themselves and is simply a matter of self-certification. Sometimes it is more collaborative, involving peer reviews, while other organizations adopt a more authoritarian top-down approach. It might be largely internally driven by policies, principles and quality standards, or dictated by legal requirements and regulations, or a combination of these. Whatever the approach, the outcomes need to be recorded.

If you’re using Ardoq, you have a choice in how you conduct and document application assessments, depending on the level of detail you wish to record. This article introduces you to two approaches, that can be used independently or in combination, providing guidance so that you can find the combination that best suits your organization’s governance style. They are:

The Architecture Records solution contains a family of architecture record component types, including Compliance Assessment.

The Compliance Assessment metamodel

This very simple component type is used to document the outcome of a compliance assessment. The result of the assessment is represented with a Yes or No value in the Pass? field, with a supporting explanation contained in Rationale. The Live date range represents the period during which this assessment remains valid. The subjects of the assessment (one assessment might be reviewing more than one application) are the target components of Has Subject references. For most software systems, these will be Application components, but other component types can be the subject of compliance assessments (e.g. Technology Services). For detailed information on how to use Compliance Assessments in your knowledge graph, see Architecture Records: Purpose, Scope and Rationale and Architecture Records: Solution Configuration Guide.

In the context of this article, note that the level of information about the assessment remains very high - a simple Pass or Fail outcome with supporting rationale in text form. This makes the component type highly reusable, suitable for documenting the outcomes of assessments of many different kinds of policy or regulation, as it avoids trying to represent specific details of those policies or regulations. It is a record of the outcome of the assessment rather than the content of the assessment.

For many organizations, this is as much detail as they wish to retain in their architecture repository, providing just enough information to create a suitable audit trail and support governance processes (tracking missing assessments, reporting compliance and non-compliance, triggering renewals). Further details of assessments might be kept in a document repository, and the Architecture Record template makes provision for adding a Document URL field to Architecture Records to facilitate easy access to detailed information held outside Ardoq.

You may wish to include pointers from a Compliance Assessment record to other components in your knowledge graph that support the outcome. Adding such pointers represents a step up in the level of detail you choose to document in the Ardoq platform. It brings the benefit of making more information available to the graph, which is able to contribute to Views, Viewpoints and Explorations, helping you to demonstrate how your use of assessments is contributing positively to the evolution of your IT estate. But, of course, it comes at the cost of more content to maintain - yet another architectural trade-off to consider! This is achieved with the Refers To reference, which can be used to link to other relevant components. Examples that might be used here include:

Whilst the Compliance Assessment component type is used to record the outcome of an assessment, the Solution Health Check is used to record all the details of a review of an Application against a defined set of criteria. And the three Surveys in the Solution Health Check Solution, Select health check criteria, Conduct health check and Submit health check conclusions, provide full support for your architecture review process.

The Solution Health Check metamodel

By default, the criteria against which an Application is judged are drawn from a Quality Model. We recommend using either the Ardoq Quality Model or the quality model that forms part of ISO 25010 - Systems and software Quality Requirements and Evaluation. Both of these are available for import into your Ardoq organization from the Frameworks & resources import page. The Ardoq quality model is shown below:

The Ardoq Quality Model

Fields on the Depends on references that lie between the Solution Health Check component and the selected criteria (Requirement components are used to represent each quality characteristic and sub-characteristic in the Quality Model) represent the scores, comments and recommendations of the review team. The reviewers can give each quality characteristic a score for its relative importance and for their level of concern about how well the application's design satisfies that characteristic. For more details of how to conduct architecture reviews, see Solution Health Check: Purpose, Scope and Rationale.

There may be circumstances in which you wish to use the process of a health check, but use something other than a Quality Model for the criteria. You might, for example, wish to conduct evaluations against a set of architecture principles or against the demands of a particular policy or set of regulations. Provided the criteria have been modeled in the same way (see How to represent Policies, Principles, Standards and Frameworks in Ardoq) then it is easy to create Solution Health Checks that use alternative criteria models (see Changing the Quality Model in Solution Health Check: Configuration Guide). You can also see a real example of this in the way that AI Health Checks have been implemented in the Enterprise AI Governance Solution.

Unlike the Compliance Assessment, the Solution Health Check component type contains enough information with which to conduct a trade-off analysis of a solution’s architecture, and it does not store a simple Pass or Fail conclusion. The two component types complement each other, with the Compliance Assessment containing a simple record of the outcome and a pass or fail decision, and the Solution Health Check containing the detailed content of an architecture review. It is for you to decide when you would use one or other or both in tandem. Your decision may vary according to the size and function of the subject application, and the nature, style and demands of your application governance.

A review activity, such as you are likely to conduct when completing either a compliance assessment or a solution health check, is the perfect opportunity to identify and document technical debt and application risks. The Technical Debt Management and Application Risk Management Solutions add the ability to manage these with components in your knowledge graph. See the corresponding documentation for the solutions for details of how to start using them. The Submit health check conclusions and the Review Compliance Assessment Surveys can easily be extended to enable responders to create new Debt Item or Risk components while they are documenting their assessments or health checks. Formally documenting technical debt and application risk can be seen as a way of creating a backlog of future work that will need funding and resources while creating an audit trail of known risks and issues that can also be used to help justify funding requests.

Both the Compliance Assessment and Solution Health Check components contain the Live date range field. This records the period during which the component remains valid. It is a straightforward task to automate the process to ensure that expiring assessments or health checks are brought to the attention of those responsible for renewing them (e.g. application owners). A Broadcast can be set up to look for components that are approaching their Live end date that will trigger an appropriate call to action to the responsible owners. See How to Create, Launch, and Manage a Broadcast for details of how to set up a Broadcast, or take a look at the Health Check renewal Broadcasts in the Solution Health Check Solution for a real example.

This article has shown how the Architecture Records and Solution Health Check Solutions can support the governance of applications and record assessment activity outcomes with differing levels of detail. The Compliance Assessment component creates a simple, auditable record of an assessment’s outcome, while the Solution Health Check component documents a detailed architecture review. They can be used independently of each other, to suit individual assessment needs, or together to form both a record of compliance and its detailed supporting evidence. Both types can be supported with automated processes and links to other significant records, such as Debt Items and Risks.