Architect for Quality


A lot of new initiatives around quality are introduced these days not least Cognitive QA. It is all very good, but I am missing something.

Quality Assurance (QA) and Quality Control (QC) is about providing confidence that a product or service will fulfill requirements. Some say that QA is about processes and QC is about product, but others use the terms interchangeably.

Testing is defined as the process of executing a system with the intent of finding defects. With this definition, testing is definitely QC.

One definition of quality is: “the totality of features and characteristics of a product or service that bears its ability to satisfy stated or implied needs”. I think that J.M. Juran’s[i] split into two distinct definitions is a very good start of a discussion about “Good Quality”. The two definitions are:

  1. the presence of features that create customer satisfaction
  2. the reliability of those features

QA and QC is all about the second part of the definition.

Quality by Design

The first part of the definition is about designing for quality which is where architecture come into play.

Architecture is all about ensuring the right features get into the product in a sustainable way.

Sound principles are at the heart of architecture. Principles, that are derived from business strategy. Principles, that guide all decisions in development (not necessarily IT‑development).

Based on the requirements and the principles (and probably many more artefacts) you architect the solution.

The architecture governance process can be seen as the software QA-process defined in the first part of the above definition.

So, reducing the focus on architecture in the development process would be the same as reducing the quality of the product!

A side comment

For the class of computing problems where you can create a formal definition of requirements, you can completely avoid testing. Instead, you gradually refine your requirements using a formal development methodology like VDM. Using VDM you continuously create mathematical proof that your refinement is correct and thus that the program is correctly fulfilling the requirements.

[i] J.M. Juran: ”Juran on Planning for Quality”, The Free Press, 1988, ISBN 0-02-916681-0

Erik Haahr


Erik Haahr has been a Managing Consultant at Capgemini Sogeti Denmark since 2015. In this role, he is improving local service offering descriptions, participating in pre-sales activities, mentoring graduates, and consulting with customers.

More on Erik Haahr.

Related Posts

Your email address will not be published. Required fields are marked *