CFOs are accountable for finance, COOs for operations, this is all quite clear.
For Enterprise Architecture, the CEOs is usually the ultimate responsible outside formal Chief Architect roles.
But who’s clearly responsible for your overall quality architecture?
“Architecture” is transversally present leading to regular confusion: are we talking about enterprise, functional or technical architecture?
Creating software is supported by a system referred as SDLC – Software Development Life Cycle – that is architectured, intentionally or not.
Software quality architecture is usually diluted through the organizations in different functions, resulting in a poor and inconsistent inclusion.
In fact, where is your quality architect ensuring a holistic approach?
Traditional architects are pivot with a global view within organizations
Architects usually come with their aura of mystery, what are they doing in reality?
In pivot between Business and IT, they usually have to articulate divergent and transversal perspectives.
Key differentiators are to identify structuring functional and non-functional requirements, that else would have been missed.
This involves architects to be cross-functional and multi-disciplinary in their interactions and perspectives.
They are not necessarily experts in various fields, but they need to have the capacity to pro-actively include different visions.
In initial interactions, they need to be real sponge able to make pertinent questions.
The architecture of quality is usually lost in the organization
Depending on their scope, architects can more or less interact with software quality.
A real difficulty lies in the positioning within organizations, that by design is not as clear as a CFO, as overlapping depending on the enterprise context.
Your CFO owns finance, but who owns your software quality?
Antoine Craske
Adding to this complex setup of architects, software quality is it itself not sufficiently understood, missing the link to business objectives within the organizations.
Leaving apart the recent dialog between developers and operations known as DevOps, quality teams did not jump quickly on the band-wagon of DevQAOps.
I personally think that we end up in confused organizations, with unknown responsibilities, unclearly defined, leading to a poor performance.
Different type of architects resides in organizations
The traditional architect’s roles can be differentiated in the following, inspired from The Practice of Enterprise Architecture of Svyatoslav Kotusev.
Enterprise architects are usually pivots between the CEO, boards of directors and the overall organization structure, strategy and evolution.
Moving to the operational unit, we can find the Business Unit Architects and Domain Architects, ensuring the ecosystem within their perimeter.
They can be then completed by narrowed positions such as Solution Architect, Technical Architect, Cloud Architects depending on the organizations.
The setups depend on the company maturity, capacity and requirements in terms of architecture. In a small structure one architect can be a one-size-fit all role.
Software Quality is a system that requires Architecture
Producing software involves a complete and complex system.
From ideation, design, implementation, operations and maintenance, various actors are involved in its value chain.
We usually recall the process as the software development life cycle (SDLC), at least for the core development of the software.
Complementary processes must be included from the strategic prioritization of the initiative up to the technology governance instance, pro-actively providing the necessary foundations.
But what happens to quality in those various processes?
Software quality can be assessed in the various steps and processes involved.
We will assume the “Why” for the software is making sense for the organization, transitioning to the “What” and “How”.
A qualitative architecture starts with well defined requirements
From its ideation, the software product quality attributes must be identified, mentioning the functional and non-functional requirements.
Being able to identify them clearly is already a quality challenge of communication, formalization and prioritization.
Here are some functional attributes that should be considered from the ISO/IEC FCD 25010 : completeness, correctness, appropriateness.
We can go a long way with the rest of the list : performance, efficiency, compatibility, usability, reliability, security, maintainability, portability.
Software quality attributes are lost in translations of siloed organizations.
Antoine Craske
Going back to our problem: how can you guarantee that those requirements are identified?
It can be a painful process if the domain architect must work on some of them, leaving the rest to be sorted by the others roles.
It is not rare to see a vague affectation of other requirements between a technical architect, devops engineer, qa automation and engineering manager, that rarely synchronize together.
Without a clear organization, the various requirements end up lost in the various silos.
A transversal perspective is required to build a performant system
This is where I think that someone in charge of the quality architecture can make a difference.
It can be responsibilities and functions affected to an existing role within the organization, a QA lead or a Tech Lead for instance.
The perspective of the system can affect its overall development.
“The perspective of the software quality system affects its overall development.”
Antoine Craske
The ants are a very profound example of system dynamic. They will work in sync to optimize the system they are involved in.
The day their niche starts to expand with another one, whatever their initial affectation, their coordination will expand to the overall system optimization.
We must learn from other performant systems.
Organizations are systems that will be optimized depending on their perspective
Coming back to the business world, this is what tends to happen in organizations.
A local CEO is a decentralized organization that will optimize its local results, based on its objectives and incentives.
Positive cases can lead to benefits for both the local and global organization, but this is not guaranteed.
If the local CEO must improve its cash-flow, he could just pre-order more items in the central warehouse, resulting in an overall poor cash-flow for the company with over stock.
The day this subsidiary is incorporated in a larger group, or moving to a centralized management, its optimization perspective will be quite different.
The key is that a system can be improved taking into consideration its global perimeter, interfaces, objectives, actors and dynamic.
Local optimizations are dangerous in their local quality evaluation
We all know pitfalls and anti-patterns of local optimizations that do apply in the software industry.
“Local pre-optimization is one of the major reasons for waste in software quality.”
Antoine Craske
A QA team can, from their point of view, invest in an automated test campaign with a high coverage of 80%, showing results to the other teams.
In the meanwhile, the developers will ensure their unit tests are covering the full use-cases, adding integration tests to secure their development.
In the end, both teams probably have overlapped work in terms of coverage and testing, resulting in higher delay, implementation and maintenance costs.
The team could have saved 50% of their time by having a jointed approach.
The quality architect must be guardian of the global system quality
The software quality architects must act like architects in its roots, focusing on a transversal perspective of quality.
Ensuring the fit of the product within the organization’s goals and customers needs is the first step.
Its next task is to ensure the various attributes of the requirements, being functional and non-functional.
“The software quality architect must own the transversal perspective of quality.”
Antoine Craske
His work is not necessarily to be responsible for each of the areas, but to ensure their completeness, being accountable overall.
Designing the end-to-end system for a structural software quality is his next task.
He’s the one who should have the global perspective overall all local interests, taking into account the overall system constraints.
The quality architect must be a “doer” involved with the team
Like any architects, he should stay far from ivory towers, being participative and collaborative.
Moving from requirements to operations of the software requires a real involvement of the team to the defined architecture.
This is why the quality architects must interact with the rest of the team to transform the architecture into reality.
He can for example help structuring the test matrix, test strategy and test automation platform that should be used through the implementation.
Complementary, being transversal, he can work with the engineering, qa and platform teams to define a structurally performant CI/CD architecture.
A combined view leads more easily to transversal practices such as quality gates, monitoring, feature flag.
When we have the transversal view, we think more globally and on the final outcome.
The quality architect must be continuously present
Software is a living product evolving over time.
An actor only temporarily involved in a system will tend to optimize its goals on its short-sight participation.
Like in many subjects, achieving a balance is key.
Taking the country president, in some countries they are there for about 4 to 5 years and can be reelected twice.
It is not perfect, but it favours the actors to produce results at various terms to be liked today, reelected tomorrow and ensuring its future afterwards.
Even if software is not that long-lived today, they are not short-lived either.
This is why some key actors must be continuously present in the software system development.
The quality architect must obtain the product feedback loop
This is the case of the software quality architect.
The need to close the feedback loop until the customer experience.
Is the product meeting its original functional and non-functional requirements?
How the various software attributes were translated and are they satisfactory?
What should be changed to improve the software product quality while reducing its architectural debt over-time?
Getting the feedback loop is what will enable a structural performance and adaptation.
We, humans, are not designed to produce with delayed feedback loops (e.g. see all the literature on losing weight).
Clarify who is the software quality architect in your organization
Software quality architecture responsibilities must be clearly assigned, as for the CEO, CFO, and COO.
There are common parts and reuse from traditional architectural works, but in connecting the dots and the holistic perspective of quality is the difference.
With the evolution, complexity and distribution of the team I won’t be surprised to see quality architects appearing soon.
Where is your software quality architect?
Antoine Craske
Until then, it needs a clarity of responsibility within the organization : Domain Architect, Head of QA, Quality Lead, Lead Developer?
The choice is all yours, it should be clear and for a holistic software quality.
What do you think about quality architects becoming a function by itself?