At the heart of Ward Cunningham’s original concept of technical debt [1] lies the notion that the development and deployment of a new software solution often involves decisions to cut corners to get the project completed and the new solution launched. Many organizations conduct some form of Architecture Review immediately prior to “go live” to validate the solution as implemented against the approved solution architecture. This review is a great opportunity to identify and record technical debt. Using Ardoq’s Technical Debt Solution to create Debt Items as they are discovered during the Review ensures that debt is not forgotten and left to acquire serious consequences (“interest”).

Many organizations also conduct periodic reviews of their most critical business systems. These may take the form of a relatively lightweight “Health Check”, examining the system from different quality perspectives and reviewing compliance with architecture guiding principles, to a full-blown architecture evaluation, often involving a detailed trade-off analysis examining how the solution satisfies a set of quality requirements. Technical debt is not just something that can be created during the initial development and deployment of a system. For example, deciding not to upgrade components, and failing to keep documentation updated with recent changes, are two ways debt may be incurred during the lifetime of a system. Sometimes, the business environment has changed, creating a gap between quality requirements and the application’s behavior.

In some organizations, the scope of such reviews goes beyond the software solution or business system to cover the service that uses the systems. Like systems, services have architectures, and their designs can also be subjected to analysis against a quality model. The concepts of technical debt have been applied beyond technology, for example, to describe process debt [2] [3] and organizational debt [4]. An advantage of taking in this wider scope is that it considers the “system” as an integrated whole: people, process, information and technology.

All of these Architecture Reviews, large or small, pre-launch or in-flight, focused on systems or more widely on services, are opportunities to identify and document technical debt. Use the following guidance to establish your own Architecture Review process.

Adopt and promote a standard quality model across your organization. A quality model is a set of quality characteristics that may be further decomposed into sub-characteristics used to define the quality requirements of a software system or service. It is also sometimes referred to as the set of “quality attributes” that make up the “non-functional requirements” of a system [5].

It can quickly become a widely spoken and understood language, not just among architects, but with business analysts, product managers, project managers, business sponsors and system users. It promotes understanding and consideration of all quality characteristics (functional and non-functional), and encourages different stakeholders to see requirements from each other's perspectives. You might choose to license an international standard quality model, like ISO 25010 [6] (or ISO 25011 for IT services [7]), or use the Ardoq Quality Model that is provided with the Technical Debt Management Solution.

The Ardoq Quality Model

You can also choose to develop your own Quality Model that reflects the language and culture of your organization. It gives you a language to classify technical debt. It can also be applied when discussing system or service requirements and behaviors, so it is worth putting in effort to arrive at a language that can become universally understood and adopted across your organization. Create clear and meaningful definitions for each quality characteristic and sub-characteristic.

Start your review by considering each quality characteristic in your Quality Model (and sub-characteristic if you have a richer, tiered model) in the context of the system. Agree a level of importance for each characteristic. It will likely vary from system to system: for some business systems, security is paramount; for others, usability might be especially important. Rather than invent a new language to describe this, you might consider reusing the Impact scale of your corporate risk model, asking the question:

Now you have a running order for your review: start with the most important/impacted quality characteristic and examine the solution architecture from that perspective. How is that quality characteristic managed in the solution? Does it satisfy the quality requirements associated with this characteristic or sub-characteristic? Identified gaps are evidence of technical debt, so when these are identified, use the survey in the Ardoq Technical Debt Management Solution to create a new Debt Item and initiate your technical debt management process. This forces the review team to give a more detailed description and quantify the debt in terms of its impact and remediation. Beware that the debt item might relate to a dependent technology rather than the system or application under review. For example, the technical debt might relate to a Technology Service which provides supporting services to the application (and perhaps other applications too). Make sure you connect the Debt Item to the right asset(s) and, of course, to the quality characteristic under discussion. See below for an example of two debt items that might be identified during a review of an Application, but that directly impact supporting components of that Application (the system’s database and its application server).

You could develop a check-list of potential technical debt to consider for each quality characteristic. Different organizations will have their own criteria, but here are a few examples:

This will give your reviews consistency, and ensure that key questions are always asked. But at each stage, think of the role of the system in the context of the quality characteristic that is currently in the spotlight: there are likely to be questions beyond your standard list that should be asked for a particular system.

This type of review is also an opportunity to test a system’s compliance with architecture guiding principles and agreed corporate standards. You might consider failure to comply to represent technical debt, and wish to record it alongside other Debt Items. As part of your review, you could choose to have a separate agenda item that considers compliance with the relevant principles and policies, or associate individual principles and policies with quality characteristics and add their consideration to your check-list. You may notice that the last Quality Characteristic in the Ardoq Quality Model is called Compliance, and it has a sub-characteristic called Principles. So with this model, your Architecture Guiding Principles are brought into the scope of your Quality Model.

This article has described a relatively light-weight “health check” style of architecture review. Depending on the scale and scope of the system under review, it can typically be conducted in one day. A more in-depth review involves conducting a trade-off analysis that looks in greater detail at the solution and how it meets a defined set of requirements or scenarios from the different perspectives of a quality model. These are beyond the scope of this article, but they have a place in the armoury of the Enterprise Architect, for example when comparing alternative proposals for a new system, or when embarking on major changes. Architecture Tradeoff Analysis Method (ATAM) [8] and Solution Architecture Review Method (SARM) [9] are examples of this.

An Introduction to Technical Debt

Technical Debt Management: Purpose Scope and Rationale

Technical Debt Management: Metamodel

Process Playbook: Technical Debt Management

How to represent Policies, Principles, Standards and Frameworks in Ardoq

[1] W. Cunningham, “The WyCash portfolio management system,” ACM SIGPLAN OOPS Messenger, vol. 4, no. 2, pp. 29–30, Dec. 1992, doi: 10.1145/157710.157715.

[2] A. Martini, V. Stray, T. Besker, N. Brede Moe, and J. Bosch, “Process Debt: Definition, Risks and Management.” Rochester, NY, Jan. 18, 2023. doi: 10.2139/ssrn.4328073.

[3] “Process Debt: Invisible debt you weren’t aware of,” Softchoice. Accessed: Apr. 25, 2024. [Online]. Available: https://www.softchoice.com/blogs/digital-transformation-and-innovation/process-debt-tackling-the-invisible-debt-you-didn-t-know-you-were-in

[4] S. Blank, “Organizational Debt Is Like Technical Debt -- But Worse,” Forbes. Accessed: Apr. 25, 2024. [Online]. Available: https://www.forbes.com/sites/steveblank/2015/05/18/organizational-debt-is-like-technical-debt-but-worse-2/

[5] Wikipedia.org, “Non-functional requirement - Wikipedia, the free encyclopedia.” Accessed: Apr. 04, 2009. [Online]. Available: http://en.wikipedia.org/wiki/Non-functional_requirements

[6] 14:00-17:00, “ISO/IEC 25010:2023,” ISO. Accessed: Feb. 11, 2024. [Online]. Available: https://www.iso.org/standard/78176.html

[7] 14:00-17:00, “ISO/IEC TS 25011:2017,” ISO. Accessed: Feb. 12, 2024. [Online]. Available: https://www.iso.org/standard/35735.html

[8] R. Kazman, M. Klein, and P. Clements, “ATAM: Method for Architecture Evaluation,” Software Engineering Institute, Carnegie Mellon University, Technical Report CMU/SEI-2000-TR-004, Aug. 2000.

[9] S. Field, “SARM,” SARM: A site devoted to the Solution Architecture Review Method. Accessed: Feb. 14, 2024. [Online]. Available: https://sarm.org.uk/welcome/