Preprint
Article

This version is not peer-reviewed.

Four Schools of Thought on Software Architecture: Core Characteristics, Merits, Demerits and Practical Consequences

Submitted:

25 September 2026

Posted:

28 September 2026

You are already at the latest version

Abstract
Software architecture remains conceptually fragmented despite decades of influential definitions, standards, and methods. This study synthesizes this plurality into four recurring worldviews: Architectural Abstractionism, Architectural Multi-Levelism, Architectural Fundamentalism, and Architectural Consequentialism. Using an analytic-conceptual methodology, the schools are systematically characterized through the Meta-Architectural Descriptive (MAD) Framework and evaluated through the Software Architecture Conception Adequacy (SACA) Framework for descriptive, explanatory, practical, and teleological adequacy. The analysis finds that all four exhibit mixed adequacy: each contributes important insights but retains material deficiencies, and none is independently adequate or dominant. Their individual and collective inadequacies also have consequential implications for architectural scope, workmanship, governance, architecture-to-realization continuity, and professional formation. The findings support synthesis rather than selection among the schools and establish requirements for a coherent and comprehensive conception of software architecture that integrates their merits while resolving their respective deficiencies.
Keywords: 
;  ;  ;  ;  ;  ;  ;  

1. Introduction

Software architecture occupies a paradoxical position in software engineering. Foundational works converge on its importance for reasoning about, designing, constructing, governing, and evolving complex software systems, yet the discipline still lacks a sufficiently shared answer to basic questions: What makes a design concern architectural? What must software architecture encompass? How deeply does architectural design extend into realization? Where does architectural design end and other software design begin? Perry and Wolf (1992) emphasize elements, form, and rationale; Garlan and Shaw (1993) foreground components, connectors, configurations, and system-level organization; Soni et al. (1995) expose multiple structures and levels; IEEE 1471 and ISO/IEC/IEEE 42010 define architecture through fundamental organization, concepts, or properties in an environment; and decision-centred traditions place architecturally significant decisions and their rationale at the centre (Bosch, 2004; Jansen & Bosch, 2005; Kruchten et al., 2006).
These differences are consequential rather than merely terminological. Different conceptions establish different architectural design spans, assign different statuses to software objects and qualities, recognize different dimensions and depths of architectural form, and draw different boundaries between architectural and non-architectural design. They consequently imply different expectations concerning architectural workmanship, professional jurisdiction, responsibility and accountability, governance, documentation, competencies, and education. They also influence what information is exposed or concealed during architectural reasoning, what design concerns remain subject to architectural scrutiny, and how far architectural intent is traced, constrained, and verified through realization.
The plurality reflects substantial intellectual development in discipline. Abstraction and system-level reasoning have enabled architects to manage complexity and reason about emergent system concerns; multi-level perspectives have exposed architectural organization at different levels of decomposition; standards have associated architecture with the fundamental concepts and properties of an entity in its environment; and decision-centred perspectives have extended architectural knowledge beyond resulting structures to consequential decisions, assumptions, constraints, trade-offs, and rationale. Yet these advances have not converged into a sufficiently unified conception of what makes a design concern architectural or where the boundary of software architecture lies. The result is not simply a large collection of differently worded definitions, but a set of recurring and materially different assumptions about the nature, scope, purpose, and justification of software architecture.
Mulongo (2026a) addressed this synthesis problem by shifting the unit of analysis from individual definitions to recurring configurations of assumptions. The study synthesized influential conceptions into five non-mutually-exclusive schools of thought: Abstractionism, Bi-Level/Macro-Micro, Structuralism, Fundamentality, and Design-Decision Consequentialism. This provided a more tractable account of definitional plurality, but the study was principally classificatory and left systematic evaluation of the schools and refinement of the taxonomy open to subsequent investigation.
A subsequent meta-conceptual study addressed the prior question of how alternative software-architecture conceptions should be reconstructed and evaluated consistently before synthesis toward an adequate definition is attempted (Mulongo, 2026b). It developed the Meta-Architectural Worldview (MAW), comprising the Meta-Architectural Descriptive (MAD) Framework and the Software Architecture Conception Adequacy (SACA) Framework. MAD provides eight common elements through which the commitments of a software-architecture worldview can be reconstructed and compared: purpose and value, architectural objects, architectural qualities, architectural form, architectural depth, architectural context, architectural boundary, and explanatory and justificatory commitments. SACA provides the complementary basis for evaluating descriptive, explanatory, practical, and teleological adequacy.
Application of this stronger meta-conceptual foundation also exposes an analytical asymmetry in the earlier five-school taxonomy. Structuralism identifies an important and pervasive orientation concerning architectural form—particularly the organization and representation of elements and relationships—but does not independently establish why a design concern is architectural. Abstraction or system-levelness, recurrence across levels, fundamentality, and consequence, by contrast, provide distinguishable predicates of architectural significance. The refined taxonomy therefore comprises four non-mutually-exclusive schools: Architectural Abstractionism (AA), Architectural Multi-Levelism (AML), Architectural Fundamentalism (AF), and Architectural Consequentialism (AC). Structuralism remains important within the conceptual landscape but is treated as an orientation of architectural form rather than as a peer-level school defined by an independent predicate of architecturality.
Building on this foundation, the present study synthesizes influential definitions, standards, and foundational perspectives into these four major schools and systematically characterizes each school through MAD. The analysis makes explicit each school’s commitments concerning the purpose and value of software architecture, architectural objects, architectural qualities, architectural form, architectural depth, architectural context, architectural boundary, and its explanatory and justificatory foundations. The latter are reconstructed as explicit propositions so that the reasoning supporting each worldview becomes inspectable and subsequently testable. Where representative foundations establish no position, the corresponding commitment remains unspecified rather than being supplied speculatively.
The reconstructed schools are then subjected to detailed evaluation through SACA. Descriptive adequacy examines their completeness, consistency, coherence, clarity, and precision. Explanatory adequacy examines the defensibility of their assumptions, propositions, evidence, and analogies against relevant theory, established engineering and systems principles, professional bodies of knowledge, and counterexamples. Practical adequacy examines their capacity to provide a usable basis for architectural scope, workmanship, responsibility, governance, specification, construction, and architecture-to-realization continuity. Teleological adequacy examines how effectively each conception enables the shared disciplinary purpose of software architecture: establishing and sustaining coherent design control over complex software systems so that their realization and evolution are deliberately directed toward intended purposes, critical qualities, and governing constraints (Mulongo, 2026b). A summative categorical evaluation subsequently consolidates these findings across the four schools.
Critically, the analysis extends beyond conceptual characterization and evaluation to examine the material and potential practical consequences of the schools and of their individual and collective inadequacies. Differences in architectural boundary and significance affect what architects design and govern, which realization mechanisms remain under architectural scrutiny, what constitutes sufficient architectural documentation, how responsibility is distributed between architects and other software professionals, and what competencies architecture education develops. Where appropriate, documented problems in practice—including architecture–implementation inconsistency, architecture erosion, educational and competency gaps, and material cases in which deeply situated software mechanisms produced system-level consequences—are used to establish why the conceptual issues matter. Such evidence is used with bounded claims: correspondence between a conceptual inadequacy and a documented engineering problem does not, without independent causal evidence, establish that a particular school caused the observed problem.
The study therefore makes four connected contributions. First, it refines and consolidates the plurality of influential software-architecture definitions and perspectives into four major schools of thought organized around distinguishable predicates of architectural significance. Second, it provides a systematic MAD characterization of each school, including its explicit, reasonably inferable, unspecified, and excluded commitments and its principal explanatory and justificatory propositions. Third, it provides a comparative SACA evaluation that identifies and argues for the substantive merits and demerits of each school across descriptive, explanatory, practical, and teleological adequacy. Fourth, it establishes why these conceptual differences and inadequacies matter by examining their material and potential consequences for architectural workmanship, architecture-to-implementation continuity, professional responsibility, governance, documentation, competence, and education. Together, these contributions provide a disciplined basis for identifying what must be preserved, corrected, supplemented, or reconciled in subsequent work toward a more adequate and holistic definition of software architecture.

2. Conceptual Foundations

The four schools of thought presented in section 4 are reconstructed using the MAW framework proposed by Mulongo(2026b). MAW provides the higher-order conceptual basis for examining alternative software-architecture worldviews (Mulongo, 2026b). It is operationalized through MAD and SACA. MAD reconstructs a software-architecture worldview across eight elements: purpose and value; architectural objects; architectural qualities; architectural form; architectural depth; architectural context; architectural boundary; and explanatory and justificatory commitments. Architectural design span denotes the region of software-design space recognized as architecturally significant across objects, form, and depth.
Table 1. The eight MAD elements.
Table 1. The eight MAD elements.
MAD element Governing question
1. Purpose and Value What is software architecture for, and why is it valuable?
2. Architectural Objects Which fundamental classes of software-system objects are legitimate subjects of architectural design?
3. Architectural Qualities Which qualities are architecturally essential, desirable, or contingent—and on what basis?
4. Architectural Form Across which fundamental dimensions of software form does architectural reasoning operate?
5. Architectural Depth How deeply into abstraction, decomposition, realization, and detail does architectural significance extend?
6. Architectural Context Which contextual classes enter architectural determination and reasoning?
7. Architectural Boundary What distinguishes architectural from non-architectural design, and how are they related?
8. Explanatory/Justificatory Commitments What assumptions, knowledge, evidence, analogies, experience, and reasoning justify the worldview?
SACA evaluates the reconstructed worldview through descriptive, explanatory, practical, and teleological adequacy. Descriptive adequacy concerns completeness, consistency, coherence, clarity, and precision. Explanatory adequacy concerns the defensibility of assumptions, reasoning, evidence, and analogies. Practical adequacy concerns whether the worldview provides a usable basis for architectural work, responsibility, accountability, governance, documentation, and relationships with other design work. Teleological adequacy asks whether the worldview supports the disciplinary purpose: establishing and sustaining coherent design control over complex software systems so that realization and evolution are deliberately directed toward intended purposes, critical qualities, and governing constraints (Mulongo, 2026b).

3. Methodology

The study uses an analytic-conceptual comparative design. The unit of analysis is the software-architecture worldview: a recurring and sufficiently coherent configuration of commitments concerning what architecture is, what it encompasses, why it matters, and how architectural significance is justified. Sources are not assigned exclusively to one school; a source contributes evidence to every school proposition it supports.

3.1. Analytical Process

The analysis proceeds in three stages. First, influential definitions and views are synthesized into recurring schools and each school is reconstructed through the eight MAD elements. A commitment is recorded as explicit where directly stated, implicit where it follows reasonably from documented propositions, unspecified where the evidence does not establish a position, and excluded only where exclusion is explicit or follows from the school’s defining boundary.
Second, each reconstructed school is evaluated through SACA across descriptive adequacy (completeness, consistency, coherence, clarity, and precision), explanatory adequacy (defensibility of assumptions, reasoning, evidence, and analogies), practical adequacy (usability for architectural work, responsibility, governance, specification, and realization), and teleological adequacy (capacity to support coherent design control toward intended purposes, critical qualities, and governing constraints).
Third, the detailed SACA findings are summarized categorically as Adequate, Mixed Adequacy, or Completely Inadequate. Adequate denotes substantial adequacy across the major considerations of a dimension with no material inadequacy; Mixed Adequacy denotes material strengths and material deficiencies within the same dimension; Completely Inadequate denotes deficiency across all or virtually all major considerations. The categories summarize qualitative judgments and are not numerical scores or rankings.

3.2. Data Sources

The reconstruction draws principally on influential definitions, standards, books, and foundational papers that materially shaped software-architecture thought, including Perry and Wolf (1992), Garlan and Shaw (1993), Soni et al. (1995), Shaw and Garlan (1996), Medvidovic and Rosenblum (1997), IEEE 1471 (IEEE, 2000), Bachmann et al. (2000), Bosch (2004), Jansen and Bosch (2005), Tyree and Akerman (2005), Kruchten et al. (2006), Clements et al. (2011), Sommerville (2016), Bass et al. (2021), ISO/IEC/IEEE 42010:2022, and Shaw et al. (2025). Evaluation additionally draws on established systems and software-engineering principles, architecture-consistency and erosion research, computer-architecture counterexamples, professional built-environment standards, and documented failure cases where they directly test a proposition.

3.3. Validation Approach

Validity is pursued through source triangulation, proposition-level traceability, and adversarial testing. Each school’s characterization is reconstructed from multiple representative sources where available; non-obvious explanatory claims are tied to explicit source statements or identified as analytical reconstructions. SACA findings are tested against established theory, competing conceptions, professional standards, counterexamples, and documented practice evidence. Characterization is completed before evaluation so that criticism does not determine the reconstructed worldview. Material cases test the generality or practical significance of propositions rather than imply that a worldview caused a specific failure.

3.4. Threats to Validity and Mitigations

Four threats to validity are particularly relevant to the analytic-conceptual methodology employed in this study.
  • Selection bias
The reconstruction could privilege definitions, standards, or perspectives that fit the proposed four-school taxonomy while overlooking conceptions that challenge it. This threat is mitigated in three ways. First, the source base deliberately spans heterogeneous and historically influential forms of evidence, including foundational papers, international standards, major software-architecture textbooks, architecture methods, decision-centered literature, and closely related critiques of established conceptions. Second, sources are examined for their substantive commitments before being associated with a school; authors are not assigned exclusively to predetermined categories, and a source can contribute to more than one school. Third, the four-school taxonomy is advanced as a comprehensive and parsimonious synthesis of the influential conceptions examined, not as an exhaustive closure of software-architecture thought. A recurring conception grounded in a materially distinct predicate of architectural significance therefore remains legitimate evidence for extending the taxonomy
2.
Interpretive bias.
Because a worldview is not always stated explicitly by its proponents, reconstruction could attribute commitments that the underlying literature does not support. This threat is mitigated through an explicit evidentiary discipline in the MAD characterization. Each commitment is treated as explicit, reasonably implicit, unspecified, or excluded. Implicit commitments are attributed only where they follow reasonably from documented propositions, assumptions, inclusions, or exclusions. Where the evidence does not establish a position on a MAD element, that element remains unspecified rather than being completed speculatively; absence of a position is not interpreted as rejection. Explanatory and justificatory commitments are additionally formulated as discrete propositions and tied, where possible, to direct source statements or short quotations, making the reconstruction traceable to its evidentiary basis.
3.
Construct validity: MAD and SACA themselves determine what the analysis observes and how adequacy is evaluated. An incomplete descriptive framework could omit material characteristics of a worldview, while an inadequate evaluative framework could overlook relevant forms of adequacy. This threat cannot be eliminated by application of the frameworks themselves. It is addressed by making both frameworks and their analytical operation explicit and inspectable. MAD exposes characterization across eight stated elements rather than relying on an unstructured interpretation, while SACA separates evaluation into descriptive, explanatory, practical, and teleological adequacy with explicit criteria under each dimension. The analysis is reported at element and criterion level rather than only through aggregate judgments, allowing omitted dimensions, inappropriate criteria, or disputed classifications to be identified and challenged. The study consequently treats MAD and SACA as comprehensive analytical frameworks open to scrutiny, revision, and extension rather than as demonstrably exhaustive constructs.
4.
Confirmation bias.
Because the study refines an earlier taxonomy proposed by the same author, there is a risk that analysis could be directed toward preserving that taxonomy or confirming the subsequent MAW framework. This threat is addressed by permitting the evidence to produce outcomes that contradict the earlier formulation. Most visibly, the analysis does not preserve the original five-school taxonomy: Structuralism is removed as a peer-level school after application of MAD reveals that it describes a dimension of architectural form rather than an independent predicate of architectural significance. The evaluation also tests school propositions against counterexamples, rival interpretations, established principles, professional standards, and documented practice rather than evaluating them only from supporting literature. The resulting four schools are neither treated as mutually exclusive nor presumed individually adequate; extension, consolidation, reinterpretation, or rejection of a reconstructed proposition remains a legitimate analytical outcome.

4. Four Schools of Thought on Software Architecture

The synthesis yields four non-mutually-exclusive schools distinguished principally by the predicate through which architectural significance is established. AA associates architecture with higher-order or system-level design; AML rejects a fixed level and recognizes architectural organization across multiple structures and levels; AF associates architecture with fundamental concepts or properties of an entity in its environment; and AC associates architecture with significant or consequential design decisions and their rationale. Table 2 provides a concise orientation before the detailed MAD characterization and SACA evaluation of each school.

4.1. Architectural Abstractionism

4.1.1. Conception, Origins, and Intellectual Foundations

Architectural Abstractionism denotes the conception that software architecture is principally higher-order, overall, or system-level design: the organization of a software system, its major or coarse-grained elements, externally relevant properties, relationships, interactions, interfaces, configurations, and associated system-level concerns, while progressively finer-grained internal mechanisms belong to detailed design and implementation. Garlan and Shaw (1993) explicitly distinguish a software-architecture level above the algorithms and data structures that had dominated software design. Medvidovic and Rosenblum (1997) describe the corresponding shift from lines of code toward coarser-grained elements and interconnection structures. Sommerville (2016) associates architectural design with the overall structure of a system, while Shaw et al. (2025) continue to characterize architecture through high-level aspects and system-level abstractions.
AA is not synonymous with abstraction. Abstraction is a general engineering mechanism for selectively suppressing information irrelevant to a present concern. AA makes the stronger ontological move: abstraction level becomes a principal determinant of architectural scope. This distinction is decisive because the usefulness of abstraction does not itself establish that architectural significance terminates at an abstraction boundary.

4.1.2. MAD Characterization

1. Purpose and Value.
AA treats architecture as a means of making complex systems tractable, enabling whole-system reasoning, exposing system-wide organization and emergent properties, supporting stakeholder communication, enabling early exploration of alternatives, and coordinating downstream realization. Its implicit axiological commitment is that architecture creates much of its distinctive value by raising reasoning above local computational detail to the level of overall organization and cross-element interaction.
2. Architectural Objects.
AA principally admits major computational and communication objects: components, modules, services, subsystems, connectors, interfaces, configurations, and their relationships. Data and computing-environment objects enter architectural scope when exposed at the architectural abstraction, for example shared stores, major deployment nodes, and externally significant technology choices. Internal algorithms, private data representations, memory-management mechanisms, and component internals are ordinarily assigned to detailed design unless exposed through system-level effects or interfaces.
3. Architectural Qualities.
AA explicitly recognizes performance, reliability, availability, security, modifiability, scalability, interoperability, and related system-wide properties as architectural concerns where they depend upon organization and interaction of major elements. The school does not establish a general distinction among non-contingent essential architectural qualities, desirable qualities, and context-contingent qualities. It instead emphasizes elicitation, prioritization, and trade-off of quality attributes in relation to business drivers and stakeholder concerns.
4. Architectural Form.
Structural form dominates AA: decomposition, components, connectors, configurations, layers, dependencies, interfaces, and views occupy the center of its representational vocabulary. AA also explicitly addresses dynamics through communication, interaction, synchronization, control, concurrency, and runtime structures, and addresses spatial form through distribution, allocation, and deployment. Its foundational literature does not provide a comprehensive ontology encompassing structural, spatial, dynamical, intelligent, and aesthetic/experiential form as coequal dimensions. Silence regarding intelligence or aesthetics is not treated here as explicit exclusion.
5. Architectural Depth.
AA places architecture principally at higher, coarser, overall, or system-wide levels. Progressively internal realization—algorithms, data structures, private representations, component internals, and implementation mechanisms according to this school belongs ordinarily to detailed design and implementation. This commitment creates a comparatively shallow architectural design span in depth.
6. Architectural Context.
AA recognizes business drivers, stakeholders, technologies, organizational conditions, quality requirements, deployment environment, and other constraints as inputs to architectural decisions. It does not establish a distinctive comprehensive taxonomy of contextual classes or a general rule determining when a contextual condition itself enters architectural scope.
7. Architectural Boundary.
AA draws its principal boundary through abstraction depth and visibility: higher-order organization, major elements, and externally relevant properties are architectural; internal realization is detailed design. The school uses terms such as high-level, overall, coarse-grained, major, external, internal, and detail to express this boundary.
8. Explanatory and Justificatory Commitments.
AA’s foundations contain a set of recurrent propositions. These propositions are reconstructed below without evaluating their adequacy.
AA-P1 — Complexity-Abstraction Proposition. Increasing software complexity requires abstraction, decomposition, and selective information hiding to keep design reasoning tractable and communicable. Garlan and Shaw (1993) frame architecture as a distinct ‘level of design’ that emerges as systems grow, while Parnas (1972) grounds modular decomposition in information hiding. The proposition is explicit in AA’s foundational reasoning.
AA-P2 — Holism/Emergence Proposition. System-level properties and behaviours arise from interactions among constituent elements and require reasoning beyond isolated components. Garlan and Shaw (1993, p. 1) state that when systems contain many components, ‘the organization of the overall system’ presents a new set of design problems. This proposition is explicit.
AA-P3 — Scale-Relative-Significance Proposition. As software systems increase in size and complexity, design attention shifts from localized algorithms and data structures toward organization, control, communication, synchronization, distribution, composition, scaling, and performance. Garlan and Shaw (1993, p. 1) state that algorithms and data structures ‘no longer constitute the major design problems’ as system scale increases. The stronger implication that higher-level concerns are therefore more architecturally significant is reconstructed from this framing and evaluated separately under SACA.
AA-P4 — Cognitive-Economy Proposition. Suppressing information irrelevant to a particular concern improves comprehension, communication, and reasoning. Parnas (1972) provides the information-hiding foundation, while architecture views and structures operationalize selective exposure of information (Clements et al., 2011; Bass et al., 2021).
AA-P5 — Specialization Proposition. Complex software engineering distributes design responsibility across teams and specialists; stable abstractions and interfaces permit local autonomy while preserving coordination. This proposition follows from information hiding and modular decomposition (Parnas, 1972) and from architecture’s use of components, connectors, and interfaces to organize large systems (Garlan & Shaw, 1993; Bass et al., 2021).
AA-P6 — Progressive-Refinement Proposition. Higher-order architectural abstractions constrain progressively more concrete design and implementation while preserving design freedom before commitment. The Architecture Based Design Method develops architecture from quality and functional drivers through successive decomposition and design decisions (Bachmann et al., 2000).
AA-P7 — Early-Reasoning Proposition. Architectural abstraction permits alternatives, quality risks, sensitivity points, trade-offs, and constraints to be examined before full realization. ATAM operationalizes this proposition by evaluating architectural approaches against prioritized quality-attribute scenarios and identifying risks and trade-offs (Kazman et al., 1998).
AA-P8 — Built-Environment Analogy Proposition. AA inherits part of its conceptual framing from building architecture. Perry and Wolf (1992, p. 40) state explicitly, ‘By analogy to building architecture, we propose’ their model of software architecture. The analogy supports attention to overall form, major elements, and rationale; the extent to which it justifies a high-level architectural boundary is evaluated under SACA.

4.1.3. SACA Evaluation

1. Descriptive Adequacy.
AA has substantial descriptive assets: it identifies a recognizable locus of architectural work, provides a mature vocabulary of structures and relationships, and distinguishes architectural design from downstream realization. Its deficiencies are nevertheless material.
AA-D1 — Boundary ambiguity and imprecision. The terms that perform most of the boundary work—high-level, system-level, overall, major, coarse-grained, externally visible, internal, and detail—lack a stable threshold. They describe relations rather than intrinsic classes of design concern. The conception therefore states a boundary without specifying a decisive test for locating it.
AA-D2 — Boundary relativism. Software is recursively decomposed. A subsystem is internal to a larger system while simultaneously forming the external architectural environment of its own components. A service is coarse-grained relative to its methods and fine-grained relative to a portfolio. The same concern therefore changes classification when the reference scope changes. AA does not resolve which reference scope determines architectural status.
AA-D3 — Depth incompleteness. AA’s shallow depth excludes from ordinary architectural scope mechanisms that remain causal determinants of system-level qualities. Algorithms, scheduling policies, memory-management strategies, consistency protocols, cryptographic mechanisms, and data representations do not lose their system consequences because they occur inside a component.
AA-D4 — Form incompleteness. AA develops structural form extensively and recognizes important dynamics and deployment/spatial concerns, but its foundational ontology remains substantially structure-centred. It does not systematically articulate the status of intelligent and aesthetic/experiential form and does not comprehensively integrate the five dimensions of software form identified in Mulongo (2026c). This is an incompleteness claim, not an assertion that AA explicitly rejects those dimensions.
AA-D5 — Quality-status incompleteness. AA treats a broad set of quality attributes as architectural drivers and supports their prioritization and trade-off, but it does not establish which qualities constitute non-contingent minimum conditions of architectural adequacy. ATAM, for example, elicits and prioritizes quality goals from business drivers and stakeholders and evaluates risks and trade-offs among them. That is appropriate for context-dependent priorities, but it leaves open a prior question: whether some qualities must be safeguarded regardless of stakeholder ranking. Safety-critical engineering makes this distinction unavoidable; minimum safety is not legitimately traded away merely because another stakeholder preference ranks higher.
3.
Explanatory Adequacy.
AA’s explanatory adequacy is mixed because several propositions are strongly grounded while the inference from those propositions to a high-level architectural boundary is not.
AA-E1 — AA-P1 sounds like a complexity-management proposition. Complex systems exceed the cognitive capacity of individual engineers when treated as undifferentiated detail. Abstraction, decomposition, modularity, and information hiding are therefore indispensable. This proposition justifies architectural abstraction; it does not justify the conclusion that information hidden at one abstraction is non-architectural.
AA-E2 — AA-P2 is strongly grounded in holism and emergence. Interacting components produce properties and behaviours that are not characterized adequately by examining components in isolation. Software architecture therefore requires whole-system reasoning. The proposition establishes a genuine architectural problem at the system level; it does not establish that architectural problems exist only there.
AA-E3 — AA-P3 contains an unsupported stronger inference when interpreted as a significance hierarchy. Increasing scale unquestionably creates additional global concerns, but the emergence of system-level concerns does not make lower-level mechanisms intrinsically less consequential. Higher-order behaviour remains causally dependent on lower-order realization. A severe failure in a deeply situated mechanism propagates upward regardless of its abstraction level.
The Toyota unintended-acceleration litigation provides a concrete counterexample to any general assumption that consequence tracks abstraction level. In Bookout v. Toyota, expert source-code analysis identified defects inside electronic-throttle-control software, including failure mechanisms in the Main CPU; the 2013 jury concluded that flaws in Toyota’s source code caused the accident and death. The case does not establish that AA caused the failure. It establishes that a defect buried in implementation-level software remains capable of producing system-level safety consequences. Barr Group’s later public case study reports simulator and dynamometer analyses linking identified software defects to loss of throttle control.
The Boeing 737 MAX provides a second, independently important counterexample to a simple depth-consequence hierarchy. The FAA-chartered Joint Authorities Technical Review focused on the MCAS function resident in the flight-control computer and on the certification of the flight-control system and its interfaces after two fatal accidents. The lesson relevant here is bounded: a localized control function, sensor assumptions, interface behaviour, and associated safety analysis remain consequential at the aircraft-system level. Consequence therefore does not diminish merely because the mechanism is nested inside a larger architecture.
AA-E4 — AA-P4 and AA-P5 are well grounded as information-management and specialization propositions. Information hiding reduces unnecessary coupling and permits local autonomy. The error arises only when hidden information is equated with non-architectural information. Information hiding governs dependency and visibility; architectural significance concerns whether adequate design control of the whole requires a mechanism to be constrained, coordinated, or verified.
AA-E5 — AA-P8 is an incomplete analogy with building architecture. Professional building architecture certainly uses abstraction and progressive refinement, but architectural work does not terminate at conceptual or high-level form. AIA guidance describes design development as producing fully dimensioned plans, sections, elevations, door and window details, and material specifications; construction documents then add construction details and material specifications sufficient for contractors to price and build the project. AIA quality-control guidance requires dimensions and details to be correct, while RIBA Stage 4 explicitly includes technical design, final specifications, manufacturing information, construction information, and detailed coordination. The built-environment analogy therefore supports progressive abstraction and division of labour, but contradicts a categorical equation of architectural work with high-level design. The distinction between architect, structural engineer, electrical engineer, and other specialists is substantially a distinction of disciplinary scope and design dimension, not a distinction between abstract design and concrete design.
AA-E6 — Computer architecture provides a disciplinary counterexample from computing itself. Computer architecture spans concrete commitments such as instruction-set semantics, registers, address spaces, addressing modes, data types, memory hierarchy, pipelines, coherence, and implementation organization. Minute realization details remain architectural when they define the machine’s externally meaningful behaviour, constraints, performance, or compatibility. The counterexample does not prove that software architecture must copy computer architecture; it defeats the universal inference that architecturality is inherently a function of high abstraction.
4.
Practical Adequacy.
AA again produces mixed results. Its valid abstraction propositions generate substantial practical value, while its boundary assumptions leave unresolved questions and create a risk of architecture-to-realization discontinuity.
AA-PR1 — Communication strength.
Abstraction, information hiding, decomposition, and architectural views let stakeholders reason about relevant concerns without confronting the system’s complete realization. Stable representations support communication among business stakeholders, architects, developers, operators, security specialists, and other disciplines.
AA-PR2 — Exploration and early-risk strength.
High-level models permit alternative structures, allocations, interactions, technologies, and patterns to be compared before expensive realization. ATAM institutionalizes this value by evaluating architecture against competing quality goals, identifying risks, sensitivity points, and trade-offs before full construction.
AA-PR3 — Progressive-refinement strength.
Architectural constraints narrow the design space while leaving legitimate freedom for detailed design. This supports staged commitment, specialization, parallel work, procurement, planning, and technical governance.
AA-PR4 — Governance strength.
High-level views, interfaces, constraints, quality scenarios, and patterns provide stable objects for review and conformance assessment. This makes AA straightforward to institutionalize.
AA-PR5 — Practical boundary uncertainty.
The descriptive ambiguities leave practitioners with unresolved questions: How high is high enough? Which decomposition level owns architecture? When does an internal mechanism become architectural? Who is accountable where a detailed mechanism determines a system-level quality? When must an architect constrain or review specialist design? What evidence demonstrates that implementation preserves architectural intent? AA supplies no general decisive rule for these questions.
AA-PR6 — Constructive under-constraint.
High-level abstraction performs communicative, exploratory, and constraining functions well, but a vague or shallow architectural specification constrains construction only to the extent of what it specifies. Detailed design legitimately refines architecture, yet refinement cannot reliably preserve an architectural intention that was never expressed as a constraint, property, decision, or verification criterion. Where the permitted implementation space contains realizations that violate critical architectural intent, the architecture is under-constraining.
AA-PR7 — Responsibility discontinuity.
Architects are frequently held responsible for system-level qualities while lower-level mechanisms that determine those qualities are assigned categorically to detailed design. Architectural concern and direct authorship are not the same. A specialist can own the detailed design while architecture still identifies, constrains, coordinates, or verifies the consequential aspect. AA’s high-level boundary obscures this distinction.
AA-PR8 — Erosion exposure.
Architecture erosion is the progressive divergence of implementation from intended architectural principles and constraints. Li et al.’s systematic mapping of 73 studies found architectural violations, structural problems, software-quality degradation, and evolution difficulties among its manifestations and consequences. The evidence does not establish AA as a cause of erosion. It does establish why a worldview that weakens visibility and governance below a high-level boundary creates a serious practical problem when architectural intent depends on mechanisms below that boundary: conformance becomes harder to specify, trace, detect, and enforce.
5.
Teleological Adequacy.
AA simultaneously advances and constrains the shared disciplinary purpose. Architecture exists partly because complexity must be conquered systematically; abstraction is therefore indispensable. It makes complexity tractable, supports whole-system reasoning, exposes emergent concerns, enables early exploration, and coordinates distributed construction. These contributions are central to coherent design control.
The teleological limitation arises when abstraction is converted into Abstractionism. Abstraction selectively conceals information irrelevant to the concern being reasoned about. Abstractionism makes the abstraction boundary a principal determinant of architectural significance. The direction of reasoning is thereby inverted. A purpose-driven conception first determines what is architecturally significant and then determines what information is safe to abstract. AA risks allowing the chosen abstraction to determine what is regarded as architecturally significant.
This inversion undermines architecture’s constructive telos where suppressed mechanisms contain costly risks or determinants of critical qualities. Architecture must simplify enough to remain cognitively manageable, yet expose enough complexity to identify costly design and construction risks early, predict critical system behaviour before commitment, explore and optimize consequential alternatives, constrain realization, and verify conformance. Too little abstraction makes architecture unmanageable; excessive abstraction makes it constructively inadequate. AA is therefore highly defensible as a theory of architectural abstraction and whole-system reasoning, but insufficient as a general theory of architectural significance and boundary.

4.2. Architectural Multi-Levelism

4.2.1. Conception, Origins, and Intellectual Foundations

Architectural Multi-Levelism rejects the proposition that architectural significance belongs intrinsically to one privileged system-wide level. Soni, Nord, and Hofmeister (1995) distinguish conceptual, module, execution, and code architectures; the multiple-structure tradition similarly represents systems through structures that recur at different scopes and levels. AML does not classify every fine-grained decision as architectural. It asserts that decomposition depth is not a sufficient reason for exclusion.

4.2.2. MAD Characterization

1. Purpose and Value.
AML inherits architecture’s complexity-management and coordination purposes while adding continuity across recursive levels. Its associated value is preservation of architectural stewardship where architecturally significant concerns recur below the overall-system boundary.
2. Architectural Objects.
AML admits architectural objects at multiple nested scales. Systems, subsystems, modules, runtime units, deployment units, and structures internal to constituent elements enter architectural reasoning at the scope where architectural significance is established. AML does not independently prescribe a complete ontology of object classes.
3. Architectural Qualities.
AML treats qualities as architecturally relevant at the level or levels where their determinants reside. It does not establish an independent essential/desirable/contingent quality classification.
4
Architectural Form.
AML explicitly supports recurring structural, runtime, behavioural, and deployment forms. It does not establish a complete ontology across every dimension of software form. Unspecified dimensions remain unspecified.
6.
Architectural Depth.
This is AML’s defining ontological commitment. Architectural depth is variable. A component at one level exposes another organization at the next, and architectural significance extends deeper where the relevant concern recurs.
7.
Architectural Context.
AML recognizes that scale, risk, technology, deployment, organizational decomposition, and other contextual conditions alter the level at which a concern becomes architecturally salient. It does not supply a comprehensive context taxonomy.
8.
Architectural Boundary.
AML rejects a single privileged depth boundary. Level alone does not distinguish architectural from non-architectural design. The school does not independently supply a complete positive discriminator of architecturality.
9.
Explanatory and Justificatory Commitments.
AML is justified principally through the following propositions.
AML-P1 — Multi-Structure Proposition.
Software systems possess multiple architectural structures rather than a single privileged representation. Soni et al. (1995, p. 196) identify conceptual, module-interconnection, code, and execution architectures, each addressing different engineering concerns. This proposition is explicit.
AML-P2 — Level-Independence Proposition.
Architectural organization is not confined to one decomposition level. Soni et al.’s (1995) inclusion of code and execution architectures alongside conceptual architecture, together with multi-structure treatments in Clements et al. (2011), supports the inference that depth alone does not determine architecturality. This proposition is an analytical reconstruction from those documented inclusions rather than a verbatim claim by the authors.
AML-P3 — Cross-Structure Propagation Proposition.
Architectural concerns and relationships cross structural and decomposition boundaries. Soni et al. (1995, p. 196) explicitly emphasize relationships ‘within and between structures’; the proposition that mechanisms at one level affect higher-level qualities and constraints is reconstructed from this cross-structure dependence and evaluated under SACA.
AML-P4 — Multi-Level Coordination Proposition. Where architectural structures exist at multiple levels, coherent architectural reasoning must coordinate the relationships among those levels. This proposition is implicit in Soni et al.’s (1995) treatment of multiple interacting structures and in Clements et al.’s (2011) use of multiple architectural structures; it is not attributed as an explicit claim about organizational ownership.

4.2.3. SACA Evaluation

  • Descriptive Adequacy.
AML corrects AA’s fixed-depth assumption and describes recursive architecture more faithfully. Its principal deficiency is incompleteness of positive discrimination. AML states where architecture is not prohibited but does not state sufficiently what makes architectural concern. This gap propagates into objects, qualities, form, context, and boundary. The worldview is therefore precise about variable depth and comparatively under-specified about selection within that depth.
2.
Explanatory Adequacy.
AML-P1, AML-P2, and AML-P3 align with recursive system structure and causal propagation across levels. A nested mechanism retains system significance where its effects propagate. The propositions defeat the inference that low-level necessarily means non-architectural. The explanatory gap is different: disproving level as a sufficient discriminator does not establish an alternative discriminator. AML therefore supplies a sound correction but an incomplete theory of architectural significance.
3.
Practical Adequacy.
AML strengthens architecture-to-realization continuity. It supports subsystem architecture, platform architecture, distributed architecture ownership, recursive documentation, and governance that follows concerns into deeper realization. This is particularly relevant to product lines, platforms, systems-of-systems, embedded systems, and large modular systems. Its practical deficiency is jurisdictional indeterminacy. Without a positive significance rule, teams still lack a decisive answer to when architectural review should descend, who assumes responsibility, and where architectural stewardship stops. AML solves premature termination but risks unbounded escalation.
4.
Teleological Adequacy.
AML advances coherent design control by allowing architecture to reach determinants of critical qualities wherever they reside. It therefore removes a major teleological restriction imposed by fixed-depth Abstractionism. Its insufficiency is selection: coherent control requires neither stopping arbitrarily high nor treating every design decision as architecture. AML establishes that architectural depth is variable; it does not independently establish the rule governing that variability.

4.3. Architectural Fundamentalism

4.3.1. Conception, Origins, and Intellectual Foundations

Architectural Fundamentalism associates architecturality with what is fundamental to an entity in its environment rather than with a predetermined level, object type, or representation. IEEE Std 1471-2000 defined architecture through the fundamental organization of a system embodied in components, relationships, environment, and principles guiding design and evolution. ISO/IEC/IEEE 42010:2022 broadens this formulation to the fundamental concepts or properties of an entity in its environment, embodied in elements, relationships, and principles of design and evolution. The shift from ‘fundamental organization’ to ‘fundamental concepts or properties’ materially broadens the possible architectural span.

4.3.2. MAD Characterization

1. Purpose and Value.
AF connects architecture to stakeholder concerns, environment, and principles of design and evolution. Its implicit purpose is to identify and preserve the fundamental concepts and properties that define, constrain, and sustain the entity through realization and evolution. The standards do not prescribe a single hierarchy of architectural purposes.
2. Architectural Objects.
Elements, relationships, and principles that embody fundamental concepts or properties are architectural. ‘Elements’ is deliberately general and therefore admits computational, communication, data, and computing-environment objects where fundamental.
3. Architectural Qualities.
Qualities are architectural where fundamental to the entity in its environment. AF does not prescribe a universal list and does not independently operationalize essential, desirable, and contingent quality classes.
4. Architectural Form.
AF is not structurally closed. It implies any dimensions of software form that are fundamental to the system are architectural. Therefore, while it does not provide explicit prescription of the universe of such essential dimensions, it does not preclude the essential dimensions of form proposed by Mulongo (2026a)- structural, spatial, dynamical, intelligent, aesthetics and human experience. Its weakness is therefore lack of clarity on the dimensions. That silence provides design freedom but it also leaves room for different interpretation of what fundamental dimensions of software form are.
5.
Architectural Depth.
By implication, depth too follows fundamentality. Hence, a deeply realized concern remains architectural where it embodies or materially determines a fundamental concept or property.
6.
Architectural Context.
Context is intrinsic rather than ancillary. Architecture is architecture of an entity in its environment; stakeholder concerns, mission, external constraints, and environmental influences therefore participate in determining fundamentality.
7.
Architectural Boundary.
The boundary is fundamental versus non-fundamental. The standards do not provide a universally decisive operational test for fundamentality.
8.
Explanatory and Justificatory Commitments.
AF’s justificatory structure is less extensively developed than its descriptive formulation, but several propositions are explicit or reasonably reconstructed.
AF-P1 — Fundamentality Proposition. Architecture concerns fundamental concepts or properties rather than every property or design decision. IEEE 1471 defines architecture through the ‘fundamental organization of a system’ (IEEE, 2000), while ISO/IEC/IEEE 42010:2022 generalizes the predicate to ‘fundamental concepts or properties’ of an entity in its environment (ISO/IEC/IEEE, 2022). This proposition is explicit.
AF-P2 — Entity-in-Environment Proposition. Fundamentality is determined in relation to the entity and its environment. Both IEEE 1471 and ISO/IEC/IEEE 42010 embed the environment in the architecture definition, and ISO/IEC/IEEE 42010 organizes architecture descriptions around stakeholders and concerns (IEEE, 2000; ISO/IEC/IEEE, 2022).
AF-P3 — Representation-Distinction Proposition. Architecture is distinct from its architecture description. IEEE 1471 defines an architectural description as a collection of products used to document an architecture (IEEE, 2000); views and models therefore represent architecture rather than constitute it. This proposition is explicit in the standards’ conceptual model.
AF-P4 — Evolution-Principle Proposition. Architecture includes principles governing design and evolution. The phrase ‘principles guiding its design and evolution’ is part of the IEEE 1471 definition and is retained in the standards lineage (IEEE, 2000; ISO/IEC/IEEE, 2022). This proposition is explicit.

4.3.3. SACA Evaluation

1. Descriptive Adequacy
. AF supplies a positive predicate that is independent of abstraction depth and representation and explicitly integrates context. It also distinguishes architecture from its descriptions. Its central descriptive deficiency is ambiguity concentrated in the word ‘fundamental’. Because that term performs most boundary work, its under-specification propagates into objects, qualities, form, depth, and professional scope. A concise definition therefore achieves breadth at the cost of operational precision.
A second descriptive gap concerns quality status. ‘Fundamental properties’ provides a route to identifying non-contingent qualities, but the standards do not operationalize how a practitioner distinguishes a fundamental quality from a highly desirable or merely context-prioritized one. The conception consequently identifies the category without supplying the classification procedure.
2. Explanatory Adequacy.
AF-P2 aligns with purposive systems and design reasoning: the significance of a designed artifact depends upon its intended purpose and environment. AF-P3 is also conceptually strong because it avoids conflating architecture with diagrams or documents. The main explanatory deficiency concerns AF-P1. The standards assert fundamentality as the predicate but provide limited independent justification for why fundamentality is sufficient to distinguish architecture from other design. If ‘fundamental’ is interpreted merely as ‘architecturally important’, the account becomes circular. A defensible AF therefore requires independent criteria of fundamentality tied to mission, viability, critical qualities, governing constraints, irreversibility, or other warranted bases.
3. Practical Adequacy.
AF gives architects legitimate reach across levels and forms without classifying all design as architectural. It supports mission analysis, stakeholder analysis, environmental reasoning, views and viewpoints, and context-sensitive scope. Its practical weakness is governance consistency. Different architects and organizations reach different judgments about what is fundamental unless the determination is made explicit, evidence-based, reviewable, and contestable. The worldview therefore needs operational decision rules or governance procedures that convert fundamentality from professional intuition into inspectable engineering judgment.
4
Teleological Adequacy.
AF aligns closely with coherent design control because architecture should encompass whatever is genuinely fundamental to intended purpose, critical qualities, and governing constraints. It avoids AA’s depth ceiling and AML’s purely negative discriminator. Its teleological weakness lies in identification rather than scope: a fundamental concern omitted or misclassified remains outside control. AF therefore supplies a strong candidate predicate but not a complete method for discovering and verifying the set of fundamental concerns.

4.4. Architectural Consequentialism

4.4.1. Conception, Origins, and Intellectual Foundations

Architectural Consequentialism associates architecturality principally with significant or consequential design decisions, their rationale, trade-offs, dependencies, constraints, and effects rather than with their location in a decomposition hierarchy. Bosch (2004) argues for moving beyond architecture understood principally as structure. Jansen and Bosch (2005) make architectural design decisions first-class architectural entities; Kruchten et al. (2006) broaden architectural knowledge to decisions, assumptions, context, and rationale; Tyree and Akerman (2005) operationalize decisions through records of issues, alternatives, assumptions, constraints, implications, and status.

4.4.2. MAD Characterization

1. Purpose and Value.
AC treats architecture as a means of identifying, reasoning about, preserving, governing, and revisiting decisions whose consequences materially shape the system. It emphasizes trade-off reasoning, preservation of architectural knowledge, and coherent evolution.
2. Architectural Objects.
AC is object-neutral. Components, interfaces, data models, deployment topologies, consistency mechanisms, algorithms, security controls, and technology choices enter architectural scope where consequential decisions affect them.
3. Architectural Qualities.
Qualities enter architecture where consequential decisions materially affect them. AC does not independently classify essential, desirable, and contingent qualities.
4.
Architectural Form.
AC complements structural and behavioural representations with decision knowledge: assumptions, alternatives, constraints, rationale, trade-offs, dependencies, and implications. Any form dimension enters architectural scope where consequential decisions shape it. AC does not itself supply a complete form ontology.
5.
Architectural Depth.
Depth follows consequence rather than level. A deeply realized mechanism is architectural where its effects materially shape system qualities, risk, cost of change, evolution, or future design freedom.
6.
Architectural Context.
Context is central because significance is relational. Mission, stakeholders, regulation, scale, technology, lifecycle, organizational conditions, and risk tolerance alter the consequences of a decision.
7.
Architectural Boundary.
The boundary is consequential versus routine decision-making. The school does not establish a universal threshold for significance.
8.
Explanatory and Justificatory Commitments.
AC rests on a set of propositions that is explicit in substantial part in the decision-centred literature.
AC-P1 — Structure-Insufficiency Proposition.
Structural descriptions alone do not preserve the knowledge explaining why architecture has its form. Kruchten et al. (2006, p. 43) define architectural knowledge as including design decisions, assumptions, context, and other factors in addition to architecture design. This proposition is explicit.
AC-P2 — Knowledge-Vaporization Proposition.
Architectural knowledge is lost when decisions remain implicit in resulting structures. Jansen and Bosch (2005, p. 109) state that design-decision knowledge is ‘implicitly embedded in the architecture’ and lacks first-class representation, leading to knowledge vaporization. This proposition is explicit.
AC-P3 — Consequence-Over-Location Proposition.
Architectural significance follows consequential design decisions rather than decomposition location alone. Jansen and Bosch (2005) explicitly reconceive software architecture as a composition of explicit architectural design decisions; Tyree and Akerman (2005) similarly centre architectural documentation on major architecture decisions. The level-neutral consequence criterion is reconstructed from this decision-centred framing.
AC-P4 — Change-Constraint Proposition.
Architectural decisions create durable constraints, dependencies, trade-offs, costs, and restrictions on future design freedom. Jansen and Bosch (2005) motivate explicit decisions partly from architecture’s high cost of change and erosion during evolution; Tyree and Akerman (2005) document assumptions, constraints, alternatives, and implications as properties of architecture decisions.
AC-P5 — Rationale-Preservation Proposition.
Preserving assumptions and rationale supports coherent evolution because future engineers can distinguish enduring constraints from decisions whose premises have changed. Kruchten et al. (2006, p. 43) state that architectural knowledge includes the factors that determine ‘why a particular solution is the way it is’; Tyree and Akerman (2005) argue that explicit decisions clarify architectural rationale for stakeholders.

4.4.3. SACA Evaluation

1. Descriptive Adequacy.
AC substantially improves description by making decisions and rationale first-class and by remaining neutral to object type and depth. Its central deficiency is significance ambiguity. Every design decision has consequences; ‘architecturally significant’ therefore cannot function as a complete discriminator unless significance is independently defined. The school also leaves the mandatory architectural form and quality coverage under-specified: architecture risks becoming a collection of decisions already recognized as significant rather than a systematic search across the design space.
2. Explanatory Adequacy.
AC-P1, AC-P2, AC-P4, and AC-P5 are strongly supported by the realities of software evolution: structures do not explain themselves, constraints persist, assumptions expire, and undocumented rationale impairs later reasoning. AC-P3 also corrects AA’s depth bias. The explanatory deficiency is threshold multidimensionality. Consequence concerns safety, security, reliability, performance, cost, reversibility, organizational impact, legal exposure, temporal duration, and future design freedom. AC does not establish which dimensions are constitutive, how they interact, what time horizon applies, or how much consequence is enough.
3. Practical Adequacy.
AC maps directly to architectural decision records, trade-off analysis, rationale capture, traceability, review, and evolution. It strengthens continuity from intent to implementation by requiring decisions to be preserved rather than inferred retrospectively from structure. Its practical weakness is classification and documentation overload. Without disciplined thresholds, locally important decisions accumulate as ‘architectural’, diluting attention and making governance expensive. Practical adequacy therefore depends on explicit significance criteria and traceability from decisions to requirements, qualities, structures, constraints, and realized code.
4. Teleological Adequacy.
AC aligns strongly with coherent design control because it follows commitments that constrain realization and evolution and preserves why those constraints exist. Its limitation is coverage. A purely decision-centred process is reactive if it records only decisions already noticed. Coherent design control requires systematic discovery of consequential concerns across objects, qualities, form, depth, and context. AC therefore provides a strong predicate and knowledge model but requires a complementary design-space ontology and purpose-driven search mechanism.

4.5. Summative SACA Evaluation of the Four Schools

The preceding evaluations are summarized using three categorical states. Adequate denotes full or substantial adequacy across the major considerations of a SACA dimension, with no material inadequacy. Mixed Adequacy denotes material adequacy in one or more major respects together with material inadequacy in one or more other major respects. Completely Inadequate denotes deficiency across all or virtually all major considerations of the dimension, without a material basis for adequacy. These categories summarize the preceding qualitative analysis; they are neither numerical scores nor rankings.
Table 3. SACA Evaluation Summary.
Table 3. SACA Evaluation Summary.
SACA Dimension Architectural Abstractionism (AA) Architectural Multi-Levelism (AML) Architectural Fundamentalism (AF) Architectural Consequentialism (AC)
Descriptive Adequacy Mixed Adequacy
Mature description of higher-level structures, relationships, and qualities; material boundary ambiguity/relativism and depth, form, and quality-status incompleteness.
Mixed Adequacy
Architectural recurrence and variable depth clearly articulated; positive discriminator of architecturality and several other MAD commitments remain under-specified.
Mixed Adequacy
Broad, context-sensitive conception spanning objects, forms, and depths; ‘fundamental’ remains insufficiently precise and operationalized as the principal boundary criterion.
Mixed Adequacy
Decisions, rationale, assumptions, and consequences explicitly represented; ‘architectural significance’ remains insufficiently delimited and mandatory coverage of form and qualities under-specified.
Explanatory Adequacy Mixed Adequacy
Abstraction, emergence, information hiding, specialization, and early reasoning are well founded; inference from abstraction level to architectural significance is inadequately supported and parts of the built-environment analogy fail scrutiny.
Mixed Adequacy
Recursive decomposition, level-independence, and cross-level propagation are well founded; rejecting level as the discriminator does not supply a complete positive theory of architectural significance.
Mixed Adequacy
Entity-in-environment reasoning and the architecture/description distinction are defensible; fundamentality remains insufficiently independently grounded and risks circularity if interpreted merely as ‘architecturally important.’
Mixed Adequacy
Rationale preservation, evolution, durable constraints, and consequence-over-location are well founded; dimensions and threshold of architectural consequence remain theoretically under-specified.
Practical Adequacy Mixed Adequacy
Strong communication, design-space exploration, specialization, progressive refinement, and governance benefits coexist with boundary uncertainty, constructive under-constraint, responsibility discontinuity, and architecture-realization gaps.
Mixed Adequacy
Supports recursive architectural stewardship and stronger architecture-realization continuity, but leaves practitioners without a sufficiently determinate jurisdictional and stopping rule.
Mixed Adequacy
Supports flexible, mission- and context-sensitive architectural scope, but inconsistent determination of what is fundamental weakens repeatability and governance consistency.
Mixed Adequacy
Supports decision governance, trade-off reasoning, rationale preservation, and traceability, but unresolved significance thresholds create classification inconsistency and documentation-overload risks.
Teleological Adequacy Mixed Adequacy
Abstraction substantially advances complexity management, whole-system reasoning, and early design, but Abstractionism constrains architecture’s constructive reach where consequential mechanisms lie below the selected abstraction boundary.
Mixed Adequacy
Removes the fixed-depth restriction and allows architectural control to reach deeper determinants of system outcomes, but lacks a sufficient rule for selecting which concerns architecture must follow.
Mixed Adequacy
Allows architecture to follow fundamental concerns irrespective of object type, form, or depth, but incomplete criteria for identifying fundamentality threaten systematic coverage and control.
Mixed Adequacy
Follows consequential commitments and preserves rationale necessary for coherent evolution, but lacks sufficiently systematic discovery and a determinate threshold for architectural significance.
Overall Status Mixed Adequacy Mixed Adequacy Mixed Adequacy Mixed Adequacy

5. Material and Potential Consequences of the Four Schools

The differences among the four schools and, more importantly, the individual and collective inadequacies identified through the preceding SACA evaluations have profound practical consequences for software architecture and software engineering practice. These worldviews shape what practitioners recognize as architectural, what receives architectural scrutiny, how deeply architectural reasoning extends into realization, which qualities and constraints receive explicit architectural protection, what constitutes sufficient architectural specification and documentation, and where professional responsibility and accountability begin and end. Their inadequacies therefore do not remain at the level of conceptual imprecision: they propagate into architectural workmanship, architecture-to-implementation continuity, governance, professional jurisdiction, education, and ultimately the ability of architecture to exercise coherent design control over complex software systems.
The consequences are both individual and collective. Individually, AA risks premature termination of architectural concern at an abstraction boundary; AML removes that fixed boundary but leaves practitioners without a sufficiently determinate positive rule for deciding how far architectural concern should extend; AF replaces level with fundamentality but leaves the determination of what is fundamental insufficiently operationalized; and AC follows consequential decisions but leaves the dimensions and threshold of architectural significance incompletely specified. Collectively, these differences leave the discipline without a sufficiently shared basis for determining what is architectural, how architectural significance should be established, and what constitutes adequate architectural workmanship.
The discussion below distinguishes consequences that follow logically from a school’s commitments, risks that plausibly arise from inadequacies identified through SACA, and materialized problems documented in software-engineering practice that correspond to those risks. Material cases demonstrate why a conceptual deficiency matters or challenge the universality of an assumption; they do not, without independent evidence, establish that adherence to a particular school caused the observed outcome.

5.1. Fragmented Architectural Scope and Professional Jurisdiction

The most immediate consequence is that competent practitioners working from established literature reach materially different conclusions about the scope of software architecture. AA concentrates architectural significance around higher-order organization and externally relevant properties. AML rejects a fixed depth boundary and permits architectural concern to recur within subsystems and nested structures. AF follows what is fundamental to the entity in its environment. AC follows consequential design decisions irrespective of their position in a decomposition hierarchy. The question “Is this an architectural concern?” therefore has no stable answer across the four schools.
This plurality creates professional-jurisdiction ambiguity. Organizations must decide how deeply architects reason, which decisions require architectural review, what developers decide autonomously, when specialist designs require architectural scrutiny, and what constitutes sufficient architectural workmanship. Yet the inherited literature supplies different legitimate answers. The problem is therefore not simply practitioner misunderstanding; the discipline itself contains competing conceptions of its professional boundary.
The consequence becomes sharper when architectural responsibility is conflated with technical authorship. A concern need not be personally designed by an architect to remain architecturally significant. Specialists legitimately author detailed designs; the unresolved question is whether architectural responsibility ceases when authorship passes to another specialist. Where organizations do not distinguish authorship from architectural significance, responsibility for system-level outcomes becomes disconnected from authority over the mechanisms that produce those outcomes.

5.2. Architecture–Implementation Discontinuity and Architectural Erosion

The schools imply different relationships between architecture and implementation. This is especially consequential for AA because its high-level/detail boundary creates the strongest conceptual separation between architectural design and realization. The separation supports specialization and preserves design freedom, but becomes problematic where architectural intent depends upon mechanisms beneath the adopted abstraction boundary.
Architecture-consistency research demonstrates that maintaining alignment between intended architecture and realized software is already an industrial problem. Ali et al. (2018), interviewing 19 experienced software engineers, found that many practitioners relied on informal consistency approaches. Reported barriers included difficulty quantifying inconsistency effects, the near invisibility of inconsistency to customers, reluctance to correct inconsistencies, and the effort required to map implementation to architecture. These findings do not implicate a particular school, but they demonstrate that architecture-to-realization continuity is materially difficult in practice.
Architecture erosion provides stronger evidence of the stakes. Li et al. (2022), in a systematic mapping of 73 studies, found that erosion manifests through architectural violations and structural problems as well as degraded software quality and difficulties in software evolution. The evidence does not establish AA as a cause of erosion. It establishes why a worldview that leaves consequential realization mechanisms outside architectural specification, traceability, or verification faces a serious governance problem: divergence between architectural intent and implementation becomes harder to specify, detect, and correct.
AML, AF, and AC respond differently. AML permits architectural stewardship to descend into realization but does not independently determine when it should descend. AF follows fundamental concerns downward but leaves practitioners to operationalize fundamentality. AC follows consequential decisions and strengthens rationale and traceability, but requires a threshold for architectural significance. The four schools therefore expose different versions of the same unresolved problem: how architecture remains connected to construction without expanding until architecture becomes indistinguishable from all software design.

5.3. Uneven Architectural Workmanship and the Constructive Gap

A further consequence is variation in what constitutes complete architectural workmanship. AA encourages high-level decomposition, interface specification, architectural views, patterns, quality scenarios, and system-wide reasoning. AC emphasizes decisions, rationale, alternatives, constraints, trade-offs, and traceability. AF directs attention toward mission, environment, stakeholders, and fundamental properties. AML encourages recursive architectural reasoning across nested levels. Each orientation strengthens particular aspects of architectural work while leaving others comparatively underdeveloped.
AA illustrates the constructive problem most sharply. Its abstractions are highly effective for communication, exploration, coordination, and early constraint of the solution space. Their constructive adequacy is weaker where architectural intent must govern mechanisms below the chosen abstraction. A high-level architecture constrains a family of possible detailed designs. That flexibility remains beneficial only while the permitted family remains consistent with architectural intent. Where an omitted mechanism determines a critical quality, multiple implementations can conform to the same high-level structure while producing materially different reliability, safety, security, performance, or evolvability outcomes.
The proposition that detailed design subsequently refines architecture only partly resolves this problem. Refinement preserves an architectural intention where the relevant intention has been expressed with sufficient precision to constrain refinement. Detailed design cannot reliably preserve a constraint that the architectural specification never made explicit. A vaguely specified architecture therefore constrains construction only to the extent of what it actually specifies.
Professional building architecture provides a useful counterpoint to the assumption that architecture is intrinsically high-level. The American Institute of Architects describes design development as progressing to fully dimensioned plans, sections and elevations, door and window details, and material specifications; construction documents then contain the information required for contractors to price and build the project (American Institute of Architects [AIA], 2023). The RIBA Plan of Work similarly defines Stage 4 Technical Design as the stage in which the design information required to manufacture and construct the project is completed, including final specifications and coordinated technical information (Royal Institute of British Architects [RIBA], 2020). The analogy therefore supports progressive abstraction and specialization, but not a categorical equation of architecture with permanently high-level design.
The corresponding implication for software architecture is not that architects specify every line of code. It is that architectural specification must become as precise as necessary to preserve architectural intent through construction. The appropriate stopping point follows architectural significance rather than an a priori preference for abstraction.

5.4. Concealed Low-Level Risk and Materialized System Consequences

The practical stakes become clearest when consequential behaviour originates below conventional high-level architectural boundaries. The Toyota unintended-acceleration litigation provides a software example. Barr (2026), summarizing the public regulatory and court record, reports that expert analysis in Bookout v. Toyota examined defects inside electronic-throttle-control software and that the 2013 Oklahoma jury concluded that a software flaw caused the fatal crash. The case does not establish that AA caused the failure. It establishes the narrower proposition relevant here: implementation depth does not bound consequence. A defect buried inside source code remains capable of determining a safety-critical system outcome.
The Boeing 737 MAX provides a complementary example. The Joint Authorities Technical Review found that assumptions made during requirements definition directly influenced the design and certification of the Maneuvering Characteristics Augmentation System (MCAS), and that the complex operational environment and flight-crew workload encountered in the accident sequences had not been adequately anticipated in certification (Federal Aviation Administration [FAA], 2019). Again, the case does not establish that an architectural school caused the accidents. It demonstrates that localized control functions, sensor assumptions, interfaces, and human-system interaction mechanisms remain consequential at the system level.
These cases challenge any general hierarchy in which higher-level concerns are presumed inherently more consequential than deeply situated mechanisms. System consequences follow causal dependencies rather than abstraction hierarchies. An architecture discipline responsible for critical qualities therefore requires a mechanism for following architectural significance into realization where necessary.
The examples also expose the central danger of over-abstraction. Abstraction suppresses complexity to enable reasoning, but some complexity is precisely where risk resides. The architectural task is therefore not to hide as much complexity as possible; it is to distinguish irrelevant complexity, which should be abstracted, from consequential complexity, which must remain sufficiently visible to be reasoned about, constrained, or verified.

5.5. Fragmented Architectural Documentation and Governance

The four schools produce different answers to another practical question: What constitutes sufficient architectural evidence? Under AA, architectural workmanship naturally centres on system-level views, components, connectors, interfaces, deployment models, quality scenarios, and architectural constraints. AML requires recursive or layered descriptions where architectural significance reappears within subsystems. AF requires descriptions that expose fundamental concepts, properties, environment, stakeholder concerns, and principles governing design and evolution. AC requires preservation of decisions, alternatives, assumptions, rationale, dependencies, constraints, implications, and traceability.
These are not interchangeable artifacts. An architecture board grounded implicitly in AA can regard a set of high-level views as substantially complete. An AC-oriented reviewer can regard the same documentation as incomplete because it does not preserve the decisions and rationale that produced those structures. An AF-oriented reviewer can ask whether the description exposes the fundamental properties of the system in its environment. AML can ask whether architectural description terminates prematurely at the system boundary.
The result is governance heterogeneity. Architecture review boards, procurement processes, outsourcing contracts, design-assurance procedures, and conformance assessments can apply materially different standards while all claiming to assess software architecture. The empirical architecture-consistency difficulties reported by Ali et al. (2018) illustrate the practical cost of this gap: mapping realized systems to intended architectures is sufficiently difficult that many practitioners fall back on informal mechanisms.
The problem becomes more consequential as software construction becomes increasingly automated. Generated implementation cannot be meaningfully constrained or verified against architectural intent that exists only as broad diagrams and informal assumptions. Architecture therefore requires sufficiently precise, traceable, and machine-verifiable constraints wherever implementation choices materially determine architectural outcomes.

5.6. Fragmentation of Architectural Competence, Education, and Professional Identity

The schools ultimately shape software architects themselves. What counts as architectural determines what an architect is expected to know. AA privileges abstraction, decomposition, patterns, components, interfaces, quality-attribute reasoning, system-level trade-offs, views, and stakeholder communication. AML additionally requires recursive reasoning and understanding of cross-level propagation. AF requires mission, environmental, stakeholder, and systems reasoning capable of establishing what is fundamental. AC requires consequence analysis, risk reasoning, rationale preservation, decision traceability, and understanding of how commitments constrain future evolution.
A curriculum constructed predominantly from one worldview therefore produces a different conception of architectural competence from a curriculum constructed from another. Evidence of a broader education-practice mismatch is already substantial. Kassab and Petrillo (2026) compared 658 software-architect job postings from 38 countries with 588 software-architecture courses from leading computing institutions. Industry emphasized cloud, DevOps, containers, microservices, and stakeholder engagement, whereas curricula emphasized structural concepts and technical foundations and gave substantially less coverage to lifecycle practices, operational tasks, and soft skills. Pantoja Yépez et al. (2024), reviewing 56 studies of software-architecture education, likewise found continuing challenges associated with the abstract and ambiguous nature of software architecture, practical complexity, and alignment with industry needs.
These studies do not attribute the education gap to the four schools. They establish that what software architects should know and how architecture should be taught are already unsettled in practice. The present analysis supplies a conceptual explanation for part of that instability: different worldviews imply different professional scopes and therefore different competency requirements.
The educational danger of unexamined AA is especially clear. Students can absorb the maxim that architecture is high-level design without learning the qualification that architecture must sometimes follow consequential mechanisms into detailed realization. The result is a risk of architects who are skilled at abstraction, diagrams, communication, and pattern selection but insufficiently prepared to reason about the mechanisms through which critical qualities are realized. The opposite extreme is equally undesirable: without abstraction discipline, architectural education collapses into indiscriminate technical detail. The appropriate response is therefore to teach the schools, their assumptions, strengths, limitations, and the architectural-boundary problem itself.

5.7. The Central Consequence: Intellectual Enrichment Accompanied by Professional Fragmentation

In the final analysis, the consequences are paradoxical. The plurality of schools has enriched software architecture. AA contributed abstraction, whole-system reasoning, separation of concerns, communication, and early exploration. AML challenged a rigid depth boundary. AF connected architecture to fundamental properties, mission, stakeholders, and environment. AC restored decisions, rationale, consequence, and evolution to architectural knowledge. Yet the same plurality has left the discipline without a sufficiently shared basis for determining architectural significance.
The result is fragmentation in scope, professional jurisdiction, documentation, governance, competency, education, and architecture-to-realization continuity. The practical problem is not plurality itself; multiple perspectives are intellectually productive. The problem arises when different worldviews silently govern practice while their incompatible assumptions remain unexamined. Architects, developers, specialists, educators, and architecture boards can use the same vocabulary while reasoning from different boundaries of responsibility.
This is why the search for an adequate conception of software architecture is not terminological housekeeping. Architectural scope determines what engineers reason about before construction, what risks are exposed early, what design intent is specified, what specialists are constrained to preserve, what implementation is verified against, what architects are accountable for, and ultimately which determinants of system integrity remain under deliberate engineering control.

7. DISCUSSION

7.1. Key Results

The results are synthesized according to the study’s three objectives: (1) synthesis and MAD characterization of the major schools of thought, (2) SACA evaluation of their merits and demerits, and (3) examination of their material and potential practical consequences.

7.1.1. Objective 1: Synthesis and MAD Characterization of the Major Schools

The analysis synthesizes the examined software-architecture definitions, standards, and foundational perspectives into four non-mutually-exclusive schools: Architectural Abstractionism (AA), Architectural Multi-Levelism (AML), Architectural Fundamentalism (AF), and Architectural Consequentialism (AC). Their principal distinction lies in the predicate through which each establishes architectural significance: AA emphasizes higher-order or system-level design; AML recognizes architectural significance across multiple levels; AF associates architecturality with what is fundamental to an entity in its environment; and AC associates it with consequential design decisions and their rationale.
Structuralism emerges as a pervasive orientation of architectural form rather than an independent predicate of architecturality. Structure remains central to software architecture, but structural organization alone does not establish why a design concern is architectural.
MAD further reveals that the schools are unevenly developed across the eight meta-conceptual elements. Each provides comparatively developed positions on some elements while leaving others unspecified or insufficiently articulated. The schools consequently overlap without being interchangeable and imply materially different architectural design spans and boundaries. The apparent plurality of software-architecture definitions therefore resolves, to a substantial extent, into a smaller number of recurring worldview-level positions distinguished principally by how architectural significance is determined.

7.1.2. Objective 2: SACA Evaluation of the Merits and Demerits

The SACA evaluation finds mixed adequacy across all four schools. Each contains substantial merits together with material inadequacies, but the nature of those merits and inadequacies differs.
AA provides strong foundations in abstraction, whole-system reasoning, complexity management, information hiding, specialization, and early design reasoning, but does not provide an adequate general basis for determining architectural significance and boundary. AML corrects the fixed-depth restriction by recognizing architectural significance across levels, but does not supply a complete positive discriminator for determining what becomes architectural at those levels. AF provides a positive, context-sensitive predicate through fundamentality, but does not sufficiently operationalize how fundamentality is determined. AC captures consequential decisions, rationale, constraints, and evolution, but leaves the dimensions and threshold of architectural significance insufficiently specified.
A further result is the interdependence of the SACA dimensions. Descriptive ambiguity, incompleteness, or imprecision weakens explanatory adequacy; explanatory deficiencies propagate into practical uncertainty or discontinuity; and practical inadequacies ultimately constrain teleological adequacy.
Most importantly, none of the four schools is independently adequate, and no school emerges as dominant in overall adequacy. All four receive an overall status of Mixed Adequacy. This common status does not imply equivalence: their respective merits, demerits, and sources of inadequacy differ materially. Equally, none is completely inadequate. Each preserves substantive architectural insights that contribute to understanding the architectural problem.
The comparative result therefore supports principled synthesis rather than selection. No single school provides a sufficient standalone conception of software architecture, while none can be discarded without losing important architectural insights.

7.1.3. Objective 3: Material and Potential Practical Consequences

The analysis finds that the differences among the four schools and particularly their individual and collective inadequacies—extend beyond conceptual disagreement into software-architecture practice.
First, the schools produce different architectural scopes and professional jurisdictions. They imply different answers concerning what architects should design, how deeply architectural reasoning should extend, which concerns require architectural governance, and where responsibility passes to other software professionals.
Second, these differences affect architecture-to-realization continuity and architectural workmanship. Different conceptions establish different expectations concerning the extent to which architectural intent should constrain, trace into, and remain verifiable within detailed realization.
Third, the schools imply different standards of architectural documentation and governance. What constitutes sufficient architectural evidence varies according to whether emphasis is placed on high-level structures and views, recursive architectural organization, fundamental concepts and properties, or consequential decisions and rationale.
Fourth, the schools imply different competency and educational requirements. Their respective architectural scopes demand different combinations of abstraction, whole-system reasoning, multi-level reasoning, contextual and fundamental analysis, consequence analysis, rationale preservation, and realization-level traceability.
Collectively, the findings expose a central tension: the plurality of schools has enriched software architecture intellectually while contributing to fragmentation of its professional scope, workmanship, governance, and formation. Their practical consequences reinforce the SACA result: the discipline requires neither wholesale adoption nor rejection of any single school, but a more adequate conception capable of preserving their complementary merits while resolving their material inadequacies.

7.2. Validity and Credibility

The claims are conceptual and classificatory rather than statistical. Credibility rests on five controls: reconstruction from primary or influential sources; explicit separation of documented, inferred, unspecified, and excluded commitments; separation of characterization from evaluation; proposition-level testing rather than school-level rhetoric; and bounded use of counterexamples. Toyota and the 737 MAX, for example, are not presented as failures caused by AA. They falsify a stronger general assumption that lower-level mechanisms are inherently less consequential than system-level design concerns.
The analysis also distinguishes absence from rejection. Where a school does not articulate intelligence, aesthetics, essential-quality classes, or a context ontology, the paper reports incompleteness or silence rather than attributing an exclusion. This preserves fidelity to the source conceptions and makes the taxonomy open to revision as additional evidence emerges.

7.3. Contributions and Novelty

The study makes three principal contributions corresponding to its three analytical objectives.
First, it provides a refined synthesis and systematic characterization of the major schools of thought on software architecture. The study consolidates the examined definitions, standards, and foundational perspectives into four peer-level schools—Architectural Abstractionism, Architectural Multi-Levelism, Architectural Fundamentalism, and Architectural Consequentialism distinguished by their respective predicates of architectural significance. It then reconstructs each school systematically across the eight MAD elements, preserving explicit, reasonably implicit, unspecified, and excluded commitments rather than imposing artificial completeness. The explanatory and justificatory foundations of each school are additionally reconstructed as source-grounded propositions, making the assumptions and reasoning underlying the schools explicit and inspectable.
Second, the study provides a systematic comparative adequacy evaluation of the four schools. SACA moves the analysis beyond classification and characterization by evaluating each school across descriptive, explanatory, practical, and teleological adequacy. The evaluation identifies specific merits and deficiencies including ambiguity, relativism, incompleteness, imprecision, unsupported inference, problematic analogy, operational indeterminacy, and teleological insufficiency and tests material explanatory claims against relevant theory, engineering principles, professional standards, counterexamples, and empirical evidence. The resulting cross-school evaluation establishes the important comparative finding that none of the four schools is independently adequate, none dominates in overall adequacy, and none is completely inadequate. This provides a reasoned basis for synthesis rather than selection among the schools.
Third, the study connects conceptual adequacy to its material and potential consequences for software-architecture practice. It shows how differences and inadequacies in architectural worldviews propagate into architectural scope and professional jurisdiction, architecture-to-realization continuity, architectural workmanship, documentation and governance, and professional competence and education. This extends the definitional problem beyond conceptual disagreement by demonstrating why the underlying assumptions about architectural significance and boundary matter to the practice and professional formation of software architecture.
These contributions materially extend the two preceding studies. Relative to Mulongo (2026a), the present study does more than reduce the earlier five-school taxonomy to four. It strengthens the analytical basis of the taxonomy by distinguishing peer-level predicates of architectural significance from dimensions of architectural form, reconstructs the resulting schools systematically through MAD, and advances from descriptive clustering to proposition-level reconstruction and comparative adequacy evaluation. Relative to Mulongo (2026b), which established MAW, MAD, and SACA as the meta-conceptual basis for examining software-architecture conceptions, the present study demonstrates their analytical utility through systematic application: MAD exposes the commitments, differences, and absences underlying the four schools; SACA establishes the merits and demerits of those commitments; and the consequences analysis demonstrates how conceptual adequacy propagates into architectural practice.
In conclusion, the novelty of the paper lies in establishing an integrated analytical progression from worldview synthesis and characterization, through proposition-level reconstruction and adequacy evaluation, to practical consequences. This progression provides a grounded basis for determining what a subsequent adequate conception of software architecture must preserve, resolve, or reconcile.

7.4. Significance

The significance of this study lies first in making the conceptual plurality of software architecture more tractable. By reducing a fragmented definitional landscape to four recurring worldviews and reconstructing their commitments and explanatory propositions systematically, the study provides researchers with a common analytical basis for examining where influential conceptions genuinely converge, where they diverge, and why. The finding that none of the four schools is independently adequate, none dominates in overall adequacy, and none is completely inadequate further reframes the definitional problem from one of choosing among established conceptions to one of principled synthesis.
For software-architecture practice, the study establishes that definitional and conceptual differences are not merely theoretical. Different predicates of architectural significance produce different architectural boundaries, design spans, expectations of workmanship, professional jurisdictions, documentation requirements, and approaches to architecture-to-realization continuity. Making these differences and their underlying assumptions explicit provides a basis for organizations and practitioners to examine more critically what they designate as architectural, what remains under architectural governance, and whether their adopted conception provides sufficient design control over consequential aspects of realization.
For education and professional formation, the study provides a more complete basis for teaching software architecture than presenting a single inherited conception as settled doctrine. The four-school synthesis exposes students and practitioners to the complementary roles of abstraction and whole-system reasoning, multi-level architectural reasoning, fundamentality and context, and consequential decisions and rationale, while also making their respective limitations explicit. This supports a conception of architectural competence that extends beyond familiarity with structures, views, patterns, and technologies to include critical reasoning about architectural significance, scope, boundary, responsibility, and realization.
More broadly, the study establishes a reasoned foundation for subsequent synthesis toward a more adequate conception of software architecture. Rather than adding another definition to an already crowded definitional landscape, it identifies what the existing schools contribute, where each remains inadequate, and which conceptual problems a more adequate conception must resolve. Its significance therefore lies both in clarifying the present intellectual and professional landscape and in providing an analytically grounded starting point for advancing beyond it.

7.5. Implications

The principal implication is the need to move beyond the continued coexistence of individually incomplete conceptions toward a coherent and comprehensive conception of software architecture. The findings show that the established schools contain substantial and complementary intellectual resources, yet none is independently adequate and their coexistence does not, by itself, resolve their respective deficiencies. Progress therefore requires principled synthesis: preserving their demonstrated merits, resolving their contradictions and ambiguities, and filling the conceptual gaps exposed through MAD and SACA. Such a conception must achieve sufficient descriptive, explanatory, practical, and teleological adequacy rather than merely introduce another concise definition or combine existing definitions terminologically.
This has an immediate implication for software-architecture theory and research. The priority should shift from proposing or defending isolated definitions toward establishing a coherent conception that explicitly accounts for the purpose, objects, qualities, form, depth, context, boundary, and justificatory foundations of software architecture and provides a defensible basis for determining architectural significance. The present findings provide a compelling case that the existing schools, considered individually and collectively, do not yet supply that foundation.
The corresponding implication for practice is the need to strengthen continuity between architectural intent and realization. Architectural scope, responsibility, governance, specification, and verification should follow architecturally significant concerns sufficiently far into realization to preserve intended qualities and constraints, without expanding architecture indiscriminately to encompass all software design. This requires clearer architectural boundaries, more precise specification of consequential design intent, and stronger traceability between architecture and constructed software.
Finally, professional and educational practice should reflect the breadth of architectural reasoning revealed by the analysis. Architecture should not be taught or institutionalized through any one school as though it represented settled disciplinary doctrine. Professional formation should instead develop the complementary capabilities required for whole-system abstraction, multi-level reasoning, identification of fundamental concerns, consequence and trade-off analysis, and architecture-to-realization continuity. The broader implication is a transition from fragmented inherited conceptions toward a more coherent disciplinary foundation for software architecture.

7.6. Limitations

The four schools are proposed as a comprehensive and parsimonious synthesis of influential conceptions, not an exhaustive closure of software-architecture thought. Their comprehensiveness remains open to scrutiny, revision, and extension. The evaluation is conceptual and qualitative; SACA does not convert adequacy into a numerical score. Counterexamples demonstrate limits of general propositions but do not establish causal responsibility of a worldview for an incident. The professional-architecture analogy is likewise used only where the compared proposition is structurally relevant; differences between software and buildings remain material.

8. Conclusion

Software architecture’s definitional plurality becomes more tractable when analysis shifts from individual formulations to recurring worldviews and those worldviews are systematically characterized and evaluated. The resulting four schools—Architectural Abstractionism, Architectural Multi-Levelism, Architectural Fundamentalism, and Architectural Consequentialism embody distinct predicates of architectural significance and exhibit distinct merits and demerits.
AA contributes indispensable abstraction, emergence-aware whole-system reasoning, communication, specialization, and early design, but high-levelness is an ambiguous, relative, and insufficient boundary criterion. AML establishes variable architectural depth but lacks a complete positive discriminator. AF provides the context-sensitive predicate of fundamentality but leaves its operational determination under-specified. AC preserves consequential decisions, constraints, rationale, and evolutionary knowledge but leaves the dimensions and threshold of architectural significance unresolved. None of the four is independently adequate or dominant in overall adequacy, yet none is devoid of substantial merit.
The resulting imperative is synthesis rather than selection. An adequate conception must preserve abstraction without equating it with architectural significance; accommodate variable depth without absorbing all design; establish independent and operational criteria for architectural significance; preserve consequential decisions and rationale; distinguish non-contingent architectural obligations from context-dependent priorities; and maintain traceable continuity from architectural intent through realization and verification. These requirements establish a foundation for constructing and defending a more adequate conception of software architecture.

References

  1. AIA. Best practices for enhancing drawings & specifications; American Institute of Architects, 2023. [Google Scholar]
  2. AIA. Quality control: Preparation of working drawings; American Institute of Architects, 2023. [Google Scholar]
  3. Bachmann, F.; Bass, L.; Chastek, G.; Donohoe, P.; Peruzzi, F. CMU/SEI-2000-TR-001; The Architecture Based Design Method. Software Engineering Institute, 2000.
  4. Baragry, J.; Reed, K. Why is it so hard to define software architecture? In Proceedings of the Asia-Pacific Software Engineering Conference, 1998; pp. 28–36. [Google Scholar] [CrossRef]
  5. Bass, L.; Clements, P.; Kazman, R. Software architecture in practice, 4th ed.; Addison-Wesley, 2021. [Google Scholar]
  6. Bosch, J. Software architecture: The next step; Springer, 2004; Volume Software Architecture (LNCS 3047, pp. 194–199. [Google Scholar] [CrossRef]
  7. Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; Ivers, J.; Little, R.; Merson, P.; Nord, R.; Stafford, J. Documenting software architectures: Views and beyond, 2nd ed.; Addison-Wesley, 2011. [Google Scholar]
  8. Garlan, D.; Shaw, M. An introduction to software architecture. In Advances in software engineering and knowledge engineering; World Scientific, 1993; Vol. 2, pp. 1–39. [Google Scholar]
  9. IEEE. IEEE Std 1471-2000; IEEE recommended practice for architectural description of software-intensive systems. 2000.
  10. ISO/IEC/IEEE. ISO/IEC/IEEE 42010:2022; Software, systems and enterprise—Architecture description. 2022.
  11. Jansen, A.; Bosch, J. Software architecture as a set of architectural design decisions. Proc. WICSA 2005, 109–118. [Google Scholar] [CrossRef]
  12. Kazman, R.; Klein, M.; Barbacci, M.; Longstaff, T.; Lipson, H.; Carriere, J. CMU/SEI-98-TR-008; The Architecture Tradeoff Analysis Method. Software Engineering Institute, 1998.
  13. Kruchten, P.; Lago, P.; van Vliet, H. Building up and reasoning about architectural knowledge. In Quality of Software Architectures; Springer, 2006; Volume LNCS 4214, pp. 43–58. [Google Scholar] [CrossRef]
  14. Li, R.; Liang, P.; Soliman, M.; Avgeriou, P. Understanding software architecture erosion: A systematic mapping study. J. Softw. Evol. Process 2022, 34(3), e2423. [Google Scholar] [CrossRef]
  15. Medvidovic, N.; Rosenblum, D. S. Domains of concern in software architectures and architecture description languages. Proc. DSL ‘97 1997, 199–212. [Google Scholar]
  16. Mulongo, A. Five schools of thought on software architecture; SSRN, 2026a. [Google Scholar] [CrossRef]
  17. Mulongo, A. Toward an adequate definition of software architecture: A meta-conceptual framework. SSRN 2026b. [Google Scholar] [CrossRef]
  18. Mulongo, A. The five fundamental dimensions of software form: Structure, space, dynamics, intelligence and aesthetics. Comput. Sci. Inf. Technol. 2026c, 14(2), 19–36. [Google Scholar] [CrossRef]
  19. Parnas, D. L. On the criteria to be used in decomposing systems into modules. Commun. ACM 1972, 15(12), 1053–1058. [Google Scholar] [CrossRef]
  20. Perry, D. E.; Wolf, A. L. Foundations for the study of software architecture. ACM SIGSOFT Softw. Eng. Notes 1992, 17(4), 40–52. [Google Scholar] [CrossRef]
  21. Shaw, M.; Garlan, D. Software architecture: Perspectives on an emerging discipline; Prentice Hall, 1996. [Google Scholar]
  22. Shaw, M.; Klein, D. V.; Ross, T. L. Revisiting abstractions for software architecture and tools to support them. IEEE Trans. Softw. Eng. 2025, 51(3), 768–773. [Google Scholar] [CrossRef]
  23. Sommerville, I. Software engineering, 10th ed.; Pearson, 2016. [Google Scholar]
  24. Soni, D.; Nord, R. L.; Hofmeister, C. Software architecture in industrial applications. Proc. ICSE 1995, 196–207. [Google Scholar] [CrossRef]
  25. Tyree, J.; Akerman, A. Architecture decisions: Demystifying architecture. IEEE Softw. 2005, 22(2), 19–27. [Google Scholar] [CrossRef]
  26. Ali, N.; Baker, S.; O’Crowley, R.; Herold, S.; Buckley, J. Architecture consistency: State of the practice, challenges and requirements. Empir. Softw. Eng. 2018, 23(1), 224–258. [Google Scholar] [CrossRef]
  27. American Institute of Architects. Defining the architect’s basic services. 2023. Available online: https://www.aia.org/resource-center/defining-the-architects-basic-services.
  28. Barr, M. Toyota unintended acceleration: What the software really did. Barr Group. 11 July 2026. Available online: https://info.barrgroup.com/software-expert-witness/articles/toyota-unintended-acceleration.
  29. Federal Aviation Administration. Boeing 737 MAX flight control system: Joint Authorities Technical Review. 2019. [Google Scholar] [PubMed]
  30. Kassab, M.; Petrillo, F. Architects in demand, curricula behind: A gap analysis of software architecture training. In Proceedings of the 2026 IEEE 23rd International Conference on Software Architecture; IEEE, 2026; pp. 110–120. [Google Scholar] [CrossRef]
  31. Pantoja Yépez, W. L.; Hurtado Alegría, J. A.; Bandi, A.; Kiwelekar, A. W. Training software architects suiting software industry needs: A literature review. Educ. Inf. Technol. 2024, 29, 10931–10994. [Google Scholar] [CrossRef]
  32. Royal Institute of British Architects. RIBA Plan of Work 2020 overview; RIBA, 2020. [Google Scholar]
  33. Baragry, J.; Reed, K. Why we need a different view of software architecture. In Proceedings of the Working IEEE/IFIP Conference on Software Architecture; IEEE, 2001; pp. 125–134. [Google Scholar] [CrossRef]
  34. Software Engineering Institute. What is your definition of software architecture? Carnegie Mellon University. 31 December 2010. Available online: https://insights.sei.cmu.edu/library/what-is-your-definition-of-software-architecture/.
  35. Solms, F. What is software architecture? In Proceedings of the South African Institute for Computer Scientists and Information Technologists Conference, 2012; ACM; pp. 363–373. [Google Scholar] [CrossRef]
Table 2. Overview of the four schools of thought.
Table 2. Overview of the four schools of thought.
School of Thought Main Ideas Key Proponents / Representative Sources
Architectural Abstractionism (AA) Architecture is principally higher-order/system-level design concerned with overall organization, major elements, interactions, externally relevant properties, and system-wide qualities. Perry & Wolf (1992); Garlan & Shaw (1993); Shaw & Garlan (1996); Bass et al. (2021); Shaw et al. (2025)
Architectural Multi-Levelism (AML) Architectural organization and significance recur across conceptual, module, execution, code, subsystem, and other nested levels; decomposition depth alone does not determine architecturality. Soni et al. (1995); Clements et al. (2011)
Architectural Fundamentalism (AF) Architecture concerns the fundamental organization, concepts, or properties of an entity in its environment and the principles governing its design and evolution. IEEE 1471 (IEEE, 2000); ISO/IEC/IEEE 42010:2022
Architectural Consequentialism (AC) Architecture is constituted or substantially characterized by significant design decisions, assumptions, constraints, rationale, and consequences that shape realization and evolution. Bosch (2004); Jansen & Bosch (2005); Tyree & Akerman (2005); Kruchten et al. (2006)
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.
Copyright: This open access article is published under a Creative Commons CC BY 4.0 license, which permit the free download, distribution, and reuse, provided that the author and preprint are cited in any reuse.