What Architecture Is

Software architecture is usually defined in one of three ways: by activity, where an architectdraws diagrams, attends meetings, reviews code, and makes decisions; by significance, wherearchitecture is “about the important stuff, whatever that is,” in Johnson’s phrase quoted byFowler; or by cost of change, where architecture is the set of decisions that are hard to changelater. Each style of definition describes the occupation rather than the discipline, and eachfails the same test: given a concrete question the design must answer, none supplies a criterion,independent of the fact to be explained, that says whether the question is architectural. This article proposes a definition built on a single criterion: derivability. A questionthe design must answer is architectural exactly when the domain’s causal knowledge, theknowledge required to realize the system’s purpose within the obligations its governingartifacts impose, bears on the answer by restricting which answers the system may take. Thecriterion rests on a distinction that the existing styles obscure: the domain’s obligations area fact about the domain, over which the architect has no authority, while the architect’sderivation is a fallible estimate of that fact. Machine and cost knowledge are not secondsources of authority; they enter the derivation only through the obligations that depend onthem. The criterion is decidable within a stated scope. The governing artifacts are identifiable,their obligations are expressed, and the required knowledge is available, so that a derivationcan be checked by someone other than the architect. Within the feasible region, judgmentoperates, and must be presented as judgment: reasoned, challengeable, never dressed up asnecessity. Where the knowledge is incomplete, the question is provisional and the gap is adefect to repair, not a preference to push through quietly. Where the obligations themselvescannot be jointly satisfied, the system is infeasible: no realizable design exists, and theremedy is a governing act on the artifacts rather than a design choice. The duty to enable every role follows from the criterion: a system that leaves a roleunable to do the work its obligations require does not satisfy those obligations, so whoever isaccountable that the system embodies the derivation faithfully is accountable for enablement.One organizational premise remains, which the article states explicitly rather than leavinghidden: that this accountability is held by a single role. Four duties discharge it: derive,document, validate, re-examine. Validation must be able to attribute a failure to thederivation, not only to the builders. The article then states three failure modes, each acheckable predicate with an observable condition, and closes with the limits of the definition.