Introduction
INTRODUCTION
Before delving into the specifics, it's worth first discussing software architecture qualities. These qualities are the technical characteristics used to describe software and systems.
A mastery of software architectural qualities solidifies an understanding of why specific software-related decisions and rationalizations are made and - more importantly - help to characterize the overall architectural impact that each decision has on a solution, or business.
A BALANCING ACT
Software architecture qualities don't always fit well together. Achieving one quality often affects (sometimes negatively) other qualities. The architect's job then, is to make the correct quality tradeoffs (by balancing their benefits and drawbacks), to achieve the best solution, given a set of constraints.
SOFTWARE ARCHITECTURE & DESIGN
Architecting and designing software is hard. Building an optimal solution to satisfy a wide and diverse range of stakeholders involves making many difficult decisions, often with little appreciation from others around you, who may only see a decision's first-order consequences.
To me, ensuring a solution's architectural integrity transcends any design decision. Designing a solution which subsequently breaks an important architectural quality creates future problems that may be difficult to understand at the time, are not (necessarily) immediately identifiable on project completion, but inevitably directly affect multiple stakeholders at later stages in the product life-cycle.
Intentionally breaking an architectural constraint once (for whatever reason) tempts others to do the same: "they did it, so why can't we?" leading to many more “faulty” implementations that make future rectification harder. This eventually causes Change Friction - a change becomes too risky, or costs too much, and stakeholders confidence expires with the product.
DEGREES OF IMPORTANCE
Every organisation (or project) places varying degrees of importance on each architectural quality. For example, air-traffic control software typically requires a stricter level of security, availability, and redundancy than a blogging website. Additionally, in the air-traffic control scenario, there is likely a standardised (or governing) body overseeing quality.
Yet, this is not true for all software. If there is no standardised quality overseer, the enterprise decides what's important, sometimes with disastrous results. This is yet another reason to truly, deeply, understand architectural qualities.
WHY UNDERSTAND SOFTWARE ARCHITECTURE?
Many enterprises begin life with a heavy focus on “functional” requirements. Business representatives have ideas that they want brought to life into some tangible form (i.e. software). Yet, often, the solution's “technical” aspects are ignored (or deprioritised) as seemingly irrelevant.
This approach may gain traction; feature after feature is built with little consideration to the technical ramifications, and over time, there comes a sudden realisation that building software isn’t solely about building features. The constant chants of time-to-market are slowly but inevitably drowned out by the equally just reply of technical debt from engineers.
For example, if a system suffers from poor maintainability, then each change takes significantly longer, and causes more brittleness. This may affect the business in the form of poor TTM, ROI, and Reputation. Or consider the situation where an enterprise suddenly realises that many customers like their product; yet they have neglected scalability, cannot take advantage of the situation, and potentially lose the competitive advantage due to poor technical leadership.
Business and technology are interlinked. You can't affect one without affecting the other. If we understand those links, then we can use them to make better decisions.
QUALITY CATEGORISATION
Architectural qualities can be categorised into runtime and non-runtime qualities. Purely runtime qualities are marked below (with a RT definition), and tend to be more quantifiable than their counterparts. For example, Scalability or Availability can be measured, whilst Evolvability, or Usability is more subjective, but no less important.
THE LISTED QUALITIES
Numerous architectural qualities have been documented in other works. For brevity’s sake, I only discuss (in my view) the most important qualities here.
The architectural qualities discussed here are: