Toward an Adequate Definition of Software Architecture: A Meta-Conceptual Framework

1. Introduction

Software architecture occupies a paradoxical position in software engineering. The seminal works that established software architecture as a discipline including Perry and Wolf (1992), Garlan and Shaw (1993), Shaw and Garlan (1996), and Bass, Clements, and Kazman (2021) converge on a widely accepted foundational principle: software architectural design is fundamental to holistic and effective reasoning about, design, construction, and evolution of complex and mission-critical software systems, providing a coherent foundation for their long-term integrity, viability, and sustainability. Yet basic and consequential questions about its own conceptual foundations remain unsettled: What exactly is software architecture? What makes a design concern architectural? Where does architectural design end and other software design begin? And what must architecture encompass to fulfil the purposes expected of it?

Influential answers vary considerably. Software architecture has been conceptualized through elements, form, and rationale (Perry & Wolf, 1992); components, connectors, configurations, and styles (Garlan & Shaw, 1993; Shaw & Garlan, 1996); structures comprising software elements, their externally visible properties, and relationships (Bass et al., 2021; Clements et al., 2011); multiple architectural structures and levels (Soni et al., 1995); fundamental concepts or properties embodied in elements, relationships, and principles (ISO/IEC/IEEE, 2022); and significant architectural decisions and their rationale (Jansen & Bosch, 2005; Kruchten et al., 2006).

This plurality reflects substantial intellectual development. Yet the absence of a sufficiently shared understanding of what software architecture encompasses and where its boundaries lie remains consequential. Different conceptions shape what is recognized as architectural, how the boundary between architectural and non-architectural design is drawn, and what consequently receives architectural attention, scrutiny, documentation, and governance. These differences therefore extend beyond terminology into the actual scope and conduct of software architecture practice.

The practical difficulty is visible in both foundational and empirical research. Baragry and Reed (1998) identified persistent difficulty in determining what constitutes software architecture and distinguishing architectural from other software design. Jansen and Bosch (2005) similarly showed that determining which design decisions are architectural is itself problematic, while Shahbazian et al. (2018) documented continuing difficulty in recovering architectural design decisions from their realization. Empirical studies show that the problem extends into practice. Ozkaya's (2016) survey of 50 practitioners, 39 from industry, found practitioner knowledge of software architecture to be limited despite its perceived importance. A much larger survey of 536 professionals who had worked as software architects found that architects' roles, responsibilities, activities, and tasks remained diffuse and insufficiently shared as common practice in organizations (Oliveira et al., 2019). Ali et al. (2018), interviewing nineteen experienced software engineers, likewise found uneven distribution of architectural knowledge within teams and widespread reliance on informal, often manual and non-holistic practices for maintaining architecture-implementation consistency. These studies do not prove that definitional plurality causes the observed practice problems, but they provide direct evidence that organizations and practitioners struggle to establish and sustain a shared understanding of architectural knowledge, scope, responsibilities, and boundaries.

The practical importance of architectural clarity and conformance is independently reinforced by research on architecture consistency and erosion. Interviews with experienced software engineers found that architecture-consistency practices are often informal and that organizations face barriers to adopting explicit conformance approaches (Ali et al., 2018). A systematic mapping of 73 studies found that architecture erosion manifests through architectural violations and structural problems as well as degradation of software quality and difficulties in software evolution, with both technical and non-technical causes implicated (Li et al., 2022). These findings do not establish definitional plurality as a cause of architecture erosion. Rather, they demonstrate independently why architectural intent, constraints, and conformance matter in practice and why ambiguity about architectural scope and responsibility warrants careful investigation.

The concern is becoming more consequential as software systems grow in scale, distribution, interconnectedness, autonomy, and societal dependence. Architecture is expected to provide a foundation for reasoning about system-wide qualities such as reliability, safety, security, performance, availability, modifiability, and evolvability (Bass et al., 2021; Clements et al., 2011). At the same time, generative AI is increasingly participating in software construction. Systematic reviews of AI-assisted code generation report that generated code can contain security vulnerabilities and therefore requires explicit verification and secure-development controls (Negri-Ribalta et al., 2024). AI does not create the conceptual problem addressed here, but its capacity to accelerate and scale software production raises the cost of leaving consequential design intent implicit. As systems become more complex and software generation becomes increasingly automated, continuing uncertainty over what software architecture encompasses, what it must safeguard, and where its responsibility ends becomes increasingly difficult to treat as a merely terminological problem.

More fundamentally, the enduring disagreement is not merely definitional. Different conceptions embody different underlying beliefs and assumptions concerning the purpose and value of software architecture, what software architecture is and encompasses, and how those positions are explained and justified. They can therefore be understood as alternative software architecture worldviews rather than simply alternative wordings of a definition.

After more than three decades of attempts to characterize software architecture, the persistence of conceptual disagreement alongside practical difficulties suggests that progress requires a more foundational move. Rather than beginning with another proposed definition, a refinement of an existing definition, or advocacy for one established conception, inquiry should first address a logically prior question: what common conceptual dimensions must be considered in order to systematically formulate, reconstruct, describe, understand, compare, and evaluate alternative conceptions of software architecture?

This is the Meta-Architectural Worldview (MAW) question that the present paper seeks to address. It shifts the immediate object of inquiry from what software architecture is to the conceptual space within which competing answers to that question can be expressed, compared, and evaluated on common grounds. Without such a foundation, synthesis risks comparing differently framed conceptions on different conceptual bases, overlooking assumptions left implicit in concise definitions, or prematurely privileging one conception before the dimensions of the definitional problem itself have been established.

Accordingly, this paper develops the Meta-Architectural Worldview (MAW), a first-principles meta-conceptual framework intended to support systematic exploration toward a more unified and holistic definition of software architecture. MAW is operationalized through two complementary frameworks. The Meta-Architectural Descriptive (MAD) Framework establishes the common conceptual dimensions through which alternative software architecture conceptions can be formulated, reconstructed, described, understood, and compared. The Software Architecture Conception Adequacy (SACA) Framework provides the complementary basis for evaluating the adequacy of those conceptions. In developing MAD, the paper additionally introduces the concepts of design span and architectural design span for characterizing the breadth and depth of architectural concern within the wider software-design space. MAW does not propose another definition of software architecture or presuppose which existing conception should prevail. Its contribution is logically prior: to establish a common descriptive and evaluative foundation upon which existing and future conceptions can be examined and from which subsequent synthesis toward a more unified and holistic definition can proceed.

The remainder of the paper establishes the conceptual foundations of MAW, identifies the shared disciplinary purpose of software architecture that provides the reference telos for evaluation, develops MAD and SACA, and discusses the key results, contributions and novelty, validity and credibility, implications, significance, and limitations.

2. Foundational Definitions, Concepts, and Presuppositions

2.1. Worldview

The modern concept of worldview has philosophical roots in Kant's use of Weltanschauung and was subsequently developed more systematically in the German intellectual tradition, particularly by Dilthey, as a way of understanding the underlying orientation through which human beings interpret and engage with the world (Dilthey, 1911/1957; Naugle, 2002).

Contemporary accounts emphasize different aspects of the concept. Sire (2009, p. 20) characterizes a worldview as a fundamental orientation expressed through commitments or presuppositions concerning the basic constitution of reality. Koltko-Rivera (2004) gives the concept of social-scientific formulation, treating worldviews as systems of beliefs and assumptions about reality that encompass, among other dimensions, value, ontological, and epistemological commitments. Naugle (2002) similarly emphasizes the interpretive role of worldview as a conceptual and affective framework through which people understand and engage with the world.

Synthesizing these perspectives, this paper adopts the following working definition:

Definition 1 — Worldview. A worldview is a set of beliefs and assumptions through which an individual or community construes a subject matter, including axiological commitments- concern about what is valued or sought, ontological commitments - what the subject matter is and comprises, and epistemological commitments - how claims about it are explained and justified. These commitments shape and orient subsequent inquiry, knowledge, practice, action, and attitudes concerning that subject matter.

This definition deliberately uses subject matter rather than reality. The nature and meaning of reality are themselves philosophically contested and are unnecessary to the analytical purpose of this paper. A worldview, as used here, may concern reality generally or a particular subject matter, discipline, or domain. Software architecture is one such subject matter.

For analytical purposes, the commitments embodied in a worldview are organized into three broad categories: axiological, ontological, and epistemological commitments. These terms are defined below.

2.2. Axiological Commitments

Axiology concerns value: what is considered valuable, desirable, good, important, or worth pursuing. Koltko-Rivera (2004) associates the axiological dimension of worldview with assumptions concerning what is valuable, good, and right, while Sire (2009) similarly treats questions of value and ultimate concern as integral to worldview.

Definition 2 — Axiological commitments. The axiological commitments of a worldview are its beliefs and assumptions concerning what is valuable, important, desirable, or worth pursuing in relation to its subject matter.

In discipline, these commitments therefore include beliefs about purpose and value: what the subject or discipline is for, what it ought to accomplish, and why accomplishing it matters.

2.3. Ontological Commitments

Ontology concerns what exists and the nature of what exists. Koltko-Rivera (2004) describes ontological commitments in terms of beliefs about the composition and structure of reality, while Naugle (2002) similarly associates ontological presuppositions with beliefs concerning what kinds of things are real and how they relate.

Applied more narrowly to a particular subject matter, ontological commitments concern what that subject is taken to be, what it comprises, and how its constituent elements relate.

Definition 3 — Ontological commitments. The ontological commitments of a worldview are its beliefs and assumptions concerning the nature, constitution, scope, and relationships of the phenomena that comprise its subject matter.

In practical terms, they address questions such as: What is this kind of thing? What does it comprise? What properties or characteristics belong to it? How are its constituent elements related? Where does it begin and end?

This domain-specific interpretation allows ontological analysis to be used without requiring the paper to resolve broader metaphysical questions about reality.

2.4. Epistemological Commitments

Epistemology concerns knowledge and justification. Koltko-Rivera (2004) associates epistemological commitments with assumptions concerning nature, sources, and limits of knowledge. Sire (2009) similarly emphasizes the question of how we know, while Naugle (2002) examines the presuppositions through which claims to knowledge and truth are understood.

The full philosophical scope of epistemology is considerably broader than required for the present analysis. For the specific analytical purposes of this paper, epistemological commitments are operationalized more narrowly as the commitments through which a worldview explains and justifies its axiological and ontological positions.

Definition 4 — Epistemological commitments. The epistemological commitments of a worldview are the assumptions, explanatory claims, justificatory propositions, evidence, analogies, and forms of reasoning advanced in support of its axiological and ontological commitments.

This narrower operationalization is particularly useful for comparing software architecture worldviews. The question is not merely what a worldview claims software architecture to be or to accomplish, but also why should those claims be accepted.

2.5. Meta-Worldview

Different worldviews concerning the same subject matter may hold different axiological, ontological, and epistemological commitments. A higher-order framework is therefore required to describe those commitments on a common basis.

Definition 5 — Meta-Worldview. A meta-worldview is a higher-order conceptual framework that specifies the common dimensions of axiological, ontological, and epistemological commitment along which different worldviews concerning a subject matter can be systematically described and compared.

A meta-worldview does not prescribe the positions a worldview should hold; it specifies the dimensions along which such positions can differ.

2.6. Software Architecture Worldview

Building on Definition 1, the concept of worldview can be applied specifically to software architecture.

Definition 6 — Software Architecture Worldview. A software architecture worldview is a set of beliefs and assumptions through which an individual or community construes software architecture, including its purpose and value, nature and scope, and the grounds on which those positions are explained and justified. These commitments shape and orient subsequent software architecture inquiry, knowledge and theory, education, and practice.

Unless the distinction is material to the context, the shorter expression architecture worldview is used hereafter to mean software architecture worldview.

The central implication is straightforward: conceptions of software architecture do not merely provide different definitions. Explicitly or implicitly, they embody positions concerning what software architecture is for, what it is and encompasses, and why those positions are warranted. Those underlying commitments influence what is subsequently recognized as architectural and how software architecture is researched, taught, and practiced.

For purposes of this paper, a school of thought refers to a recurring and sufficiently coherent software architecture worldview identifiable across related conceptions, definitions, standards, theories, or scholarly positions. The term conception refers more generally to a particular conceptualization of software architecture; related conceptions may therefore express or contribute to the same school of thought.

2.7. Meta-Architectural Worldview

Building on Definitions 5 and 6, the concept of a meta-worldview can be specialized to software architecture. Competing software architecture worldviews may embody different axiological, ontological, and epistemological commitments. Before such worldviews can be systematically compared, evaluated, or potentially reconciled, the common dimensions along which those commitments can differ must first be made explicit.

Definition 7 — Meta-Architectural Worldview. A meta-architectural worldview is a higher-order conceptual system that specifies the common dimensions along which the commitments of alternative software architecture worldviews can be systematically formulated, reconstructed, described, understood, compared, and evaluated.

A meta-architectural worldview itself does not prescribe what software architecture is or which substantive software architecture worldview should prevail. Rather, it establishes a common conceptual space within which alternative worldviews can be made explicit and their adequacy systematically examined.

The corresponding MAW question is therefore: What meta-conceptual framework can provide a common descriptive and evaluative basis for systematically examining alternative software architecture worldviews without presupposing a particular substantive definition of software architecture?2.8 Framework Development Approach

3. The Shared Disciplinary Purpose of Software Architecture

3.1. Motivation and Basis

Although definitions of software architecture differ, foundational and contemporary literature converges substantially on several principal purposes: enabling systematic reasoning about complex software systems, managing consequential design choices and constraints, supporting critical qualities, coordinating realization and evolution, and communicating and governing architectural intent (Perry & Wolf, 1992; Garlan & Shaw, 1993; Clements et al., 2011; Bass et al., 2021; ISO/IEC/IEEE, 2022). This section synthesizes that convergence into the disciplinary reference telos used the SACA framework in section 4.5. It establishes what software architecture is broadly expected to accomplish without presupposing what architecture is or where its boundary must lie.

3.2. Overarching Disciplinary Purpose of Software Architecture

At its broadest level, the purpose of software architecture is to establish and sustain coherent design control over complex software systems so that their realization and evolution can be deliberately directed toward their intended purposes, critical qualities, and governing constraints.

3.3. Supporting Functions of Software Architecture

The overarching purpose is served through several mutually reinforcing functions.

3.3.1. Architecture as a Means for Managing Complexity

Architecture makes complexity tractable. Architectural decomposition, abstraction, separation of concerns, and explicit representation of relationships and dependencies enable complex systems to be understood and reasoned about without requiring simultaneous comprehension of their complete realization (Bass et al., 2021; Garlan & Shaw, 1993; Shaw & Garlan, 1996; Clements et al., 2011). Complexity management is therefore an enabling function: architecture must simplify sufficiently for effective reasoning without suppressing information necessary for consequential design decisions.

3.3.2. Architecture as a Means for Early Design Reasoning, Exploration, and Evaluation

Architecture enables early design reasoning and risk reduction. It permits consequential alternatives, dependencies, constraints, trade-offs, and risks to be examined while significant design freedom remains and before costly commitments become deeply embedded in the realized system (Bass et al., 2021; Garlan & Shaw, 1993; Jansen & Bosch, 2005). Architecture thereby shifts consequential engineering reasoning earlier in the development lifecycle.

3.3.3. Architecture as a Foundation for Long-Term System Integrity, Viability, and Sustainability

Architecture provides a design foundation for achieving and sustaining critical system qualities. Properties such as performance, reliability, availability, security, modifiability, scalability, interoperability, and deployability depend upon interacting design decisions across the system rather than isolated components alone. Architecture provides a principal locus for reasoning about, balancing, and governing such qualities (Bass et al., 2021; Clements et al., 2011).

3.3.4. Architecture as a Means for Communication, Coordination, and Governance

Architecture supports communication, coordination, and governance. Architectural views, models, interfaces, decisions, constraints, and rationale provide shared representations through which stakeholders with different concerns and expertise can communicate, coordinate decisions, allocate responsibilities, and govern consequential technical concerns (Clements et al., 2011; ISO/IEC/IEEE, 2022; Kruchten et al., 2006).

3.3.5. Architecture as a Technical Foundation for Planning and Administration of Software Engineering Work

Architecture provides an important technical foundation for planning and administering software engineering work. By making consequential aspects of the intended solution sufficiently explicit, architecture informs work decomposition, expertise and resource requirements, effort and cost estimation, dependencies and integration planning, procurement and contracting, and technical oversight (Bass et al., 2021; Clements et al., 2011). Architecture is not project management; rather, it helps establish what must technically be realized and the major conditions of its realization, thereby providing information upon which credible planning and administration depend.

These functions are mutually reinforcing rather than independent. Complexity management enables whole-system reasoning; early reasoning exposes consequential choices and risks; architectural design supports critical qualities and system coherence; shared architectural knowledge guides realization and evolution; and architectural representations support coordinated engineering and governance. Collectively, these functions enable coherent and enduring design control over complex software systems in pursuit of their intended purposes, critical qualities, and governing constraints, thereby supporting their long-term integrity, viability, and sustainability.

Disciplinary Reference Telos. On the basis of this synthesis, the study adopts the establishment and sustained exercise of coherent design control over complex software systems - so that their realization and evolution can be deliberately directed toward their intended purposes, critical qualities, and governing constraints - as the disciplinary reference telos of software architecture. This reference telos does not define software architecture or predetermine its scope. Rather, it provides the independent end against which SACA asks whether a particular conception gives software architecture sufficient scope, foundations, and practical capability to fulfil the purpose for which the discipline is broadly valued.

4. Meta-Architectural Worldview (MAW)

4.1. Purpose and Conceptual Structure

The Meta-Architectural Worldview (MAW) is proposed as the overarching answer to the MAW question established in Section 2.7. It provides the higher-order conceptual system within which two logically distinct but complementary tasks can be undertaken: making alternative software architecture conceptions explicit within a common conceptual space, and evaluating whether those conceptions are adequate. MAW is therefore operationalized through the Meta-Architectural Descriptive (MAD) Framework and the Software Architecture Conception Adequacy (SACA) Framework.

MAD addresses the problem prior to definition or evaluation: competing software architecture conceptions cannot be systematically reconstructed and compared unless their underlying commitments can first be expressed within a common conceptual space. This is particularly important because influential definitions are often compact and leave important commitments implicit. A conception may identify architectural objects without specifying how deeply architectural significance extends, identify important qualities without distinguishing their status, or establish an architectural boundary without making explicit the assumptions on which that boundary rests.

Building on Section 2, MAD organizes these commitments into eight interrelated elements: one axiological, six ontological, and one epistemological. The axiological element captures a conception’s position on the purpose and value of software architecture. The six ontological elements characterize what it takes architectural design and its works to encompass—their objects, qualities, forms, depth, context, and boundaries. The epistemological element captures the explanatory and justificatory grounds supporting those positions. MAD does not prescribe what position a conception must take on any element; it makes that position—explicit, implicit, or absent—visible and comparable. Whether those positions are adequate is the separate task of SACA in Section 5.

4.2. Structure of the Meta-Architectural Descriptive (MAD) Framework

Table 2. META-ARCHITECTURAL DESCRIPTIVE (MAD) FRAMEWORK.

Category	Index and MAD Element	Governing Question
Axiological	A1. Purpose and Value	What is software architecture for, and why is it valuable?
Ontological	O1. Architectural Objects	Which fundamental classes of software-system objects can legitimately be subjects of architectural design?
	O2. Architectural Qualities	Which software-system qualities are architecturally essential, desirable, or contingent—and on what basis?
	O3. Architectural Form	Across which fundamental dimensions of software form can architectural reasoning operate?
	O4. Architectural Depth	How deeply into abstraction, decomposition, realization, and detail can architectural significance extend?
	O5. Architectural Context	Which classes of contextual factors can enter architectural determination and reasoning?
	O6. Architectural Boundary	What distinguishes architectural from non-architectural design, and how are they related?
Epistemological (Explanatory)	E1. Explanatory and Justificatory Commitments	What assumptions, knowledge, evidence, analogies, experience, and reasoning explain or justify the worldview's axiological and ontological commitments?

Table 2. META-ARCHITECTURAL DESCRIPTIVE (MAD) FRAMEWORK.

Category	Index and MAD Element	Governing Question
Axiological	A1. Purpose and Value	What is software architecture for, and why is it valuable?
Ontological	O1. Architectural Objects	Which fundamental classes of software-system objects can legitimately be subjects of architectural design?
	O2. Architectural Qualities	Which software-system qualities are architecturally essential, desirable, or contingent—and on what basis?
	O3. Architectural Form	Across which fundamental dimensions of software form can architectural reasoning operate?
	O4. Architectural Depth	How deeply into abstraction, decomposition, realization, and detail can architectural significance extend?
	O5. Architectural Context	Which classes of contextual factors can enter architectural determination and reasoning?
	O6. Architectural Boundary	What distinguishes architectural from non-architectural design, and how are they related?
Epistemological (Explanatory)	E1. Explanatory and Justificatory Commitments	What assumptions, knowledge, evidence, analogies, experience, and reasoning explain or justify the worldview's axiological and ontological commitments?

4.3. The Eight MAD Elements

4.3.1. Purpose and Value

What is software architecture for, and why is it valuable?

Purpose and value constitute the axiological element of MAD. They capture what a particular conception holds software architecture to be for, what it expects architecture to accomplish, and why that contribution is considered valuable. MAD records this position descriptively rather than assuming that every conception expresses the shared disciplinary purpose in the same way. The shared disciplinary purpose established in Section 3 serves a different role: it is the independent reference telos against which SACA subsequently evaluates whether a conception is sufficient for the broader purpose of software architecture.

This distinction is essential because two worldviews may characterize similar architectural phenomena while attributing different purposes or value to them. Conversely, apparently different conceptions may be oriented toward substantially similar purposes. Making the axiological commitment explicit therefore enables each worldview to be reconstructed on its own terms before its adequacy is evaluated through SACA.

4.3.2. Architectural Objects

Which fundamental classes of software-system objects can legitimately be subjects of architectural design?

At the broadest level, a software system is realized through four fundamentals design objects: computation objects, communication objects, data objects, and the computing environment. Computation objects perform processing and behaviour; communication objects enable interaction and information exchange; data objects represent, organize, persist, and convey information; and the computing environment supplies physical and virtual execution, storage, networking, and deployment substrate. These classes deliberately abstract from constructs such as components, services, databases, connectors, processes, nodes, and devices, which can be understood as more specific realizations or combinations of them.

MAD does not assume that all four classes must be architectural. It asks which classes a conception admits, explicitly or implicitly, and the basis on which it does so. This element is fundamental because these objects constitute the substrates through which software form is realized and system qualities are produced. Excluding an object class from architectural concern may therefore leave consequential determinants of system integrity or viability outside architectural design; MAD exposes the position, while SACA evaluates its adequacy.

4.3.3. Architectural Qualities

Which software-system qualities are architecturally essential, which are desirable, and which are contingent—and on what basis?

Software systems exhibit numerous qualities, including reliability, safety, security, performance, availability, scalability, maintainability, modifiability, interoperability, usability, efficiency, testability, and deployability (Bass et al., 2021), (Clements et al., 2011). Many are materially shaped by architectural decisions (Bass et al., 2021). The more fundamental architectural question, however, is not simply which qualities architecture influences, but what architectural status different qualities should have.

MAD therefore distinguishes among essential, desirable, and contingent architectural qualities. Essential qualities are those whose adequate realization is intrinsic to architecture's disciplinary purpose and should therefore be systematically safeguarded rather than treated as optional or wholly negotiable. Desirable qualities improve the resulting system but are not universally constitutive of architectural adequacy and may be pursued to the extent circumstances permit without compromising essential qualities. Contingent qualities become architecturally significant because of the particular system, mission, risks, stakeholders, or context.

The distinction serves two complementary purposes. First, it preserves architectural focus: treating every desirable software quality as intrinsically architectural risks making architectural responsibility conceptually unbounded and practically impossible. Second, it guards against accidental omission and excessive contingency: treating all qualities as stakeholder-selected, context-dependent, or negotiable risks making qualities indispensable to system integrity and viability optional. A conception should therefore provide a principled basis for distinguishing what architecture must safeguard, what it should pursue where feasible, and what becomes architecturally significant only under particular conditions.

Architecture of the built environment provides an instructive precedent, considered here as an instructive precedent. Architectural works may pursue a wide range of important qualities—including affordability, adaptability, sustainability, and energy efficiency—yet classical architectural theory identifies the more fundamental Vitruvian triad of firmitas, utilitas, and venustas, conventionally rendered as firmness, commodity or function, and delight or beauty (Vitruvius, 1914). Contemporary architectural theory and practice continue to foreground closely related concerns with structural integrity, fitness for purpose, and human or aesthetic quality while accommodating additional contextual objectives (Ching, 2023). The point is not that software architecture should inherit the same qualities, but that an architecture discipline can distinguish constitutive qualities from additional qualities whose priority varies with context.

MAD makes a conception's position on this distinction explicit without prescribing its substantive answer. Whether the conception identifies an adequate set of essential qualities, appropriately distinguishes them from desirable and contingent qualities, and thereby supports the disciplinary purpose established in Section 3 is evaluated subsequently through SACA.

4.3.4. Dimensions of Architectural Form

Across which fundamental dimensions of software form can architectural reasoning operate?

Architectural objects identify what is designed; architectural form identifies the fundamental ways in which those objects are configured and manifested as a system. Drawing explicitly on Mulongo's theory of the five fundamental dimensions of software form (Mulongo, 2026), MAD uses structure, space, dynamics, intelligence, and aesthetics as its reference ontology of form. Structure concerns composition, organization, relationships, and part-whole configuration. Space concerns location, distribution, topology, allocation, proximity, and physical or virtual placement. Dynamics concerns behaviour, interaction, state, flow, concurrency, timing, and change. Intelligence concerns sensing, inference, learning, adaptation, autonomy, and decision-making. Aesthetics encompasses the perceptual, interactional, experiential, and expressive form through which people encounter software systems (Mulongo, 2026).

The five dimensions are mutually interacting rather than independent: software qualities emerge from, and are constrained by, their combined configuration (Mulongo, 2026). Architectural reasoning concerned with long-term system integrity, viability, and sustainability must therefore have some position on which dimensions of form fall within its legitimate scope. MAD does not require every conception to classify all five as architectural; it exposes which dimensions are admitted, excluded, or left unspecified. The adequacy of those positions is subsequently evaluated through SACA.

4.3.5. Architectural Depth

How deeply into abstraction, decomposition, realization, and design detail can architectural significance extend?

Software design depth denotes the extent to which software design progresses from abstract or conceptual representations toward increasingly concrete specification and realization. In principle, this continuum extends toward the realized system. Architectural design depth denotes the portion of that continuum that a particular conception recognizes as potentially architecturally significant. It therefore does not presume that architecture terminates at a predetermined “high” level: different conceptions may assign architectural significance to different depths, and potentially to different depths for different objects and dimensions of software form.

Depth is distinct from objects and form. The same software-system object and the same dimension of form may be reasoned about at multiple levels of abstraction, granularity, and realization. This distinction is fundamental because qualities necessary to architecture's purpose may be materially determined at different depths. MAD therefore asks where a conception places the depth boundary, whether that boundary varies across the design space, and what principle justifies it, without presuming that either abstraction or detail is inherently more architectural.

The distinction between breadth and depth permits a broader derived concept: architectural design span. Architectural design breadth is the lateral extent of architectural concern across software-system objects and dimensions of software form; architectural design depth is its extent toward increasingly concrete design and realization. Architectural design span integrates both: it is the total region of software design space that a conception recognizes as architecturally significant across objects, form, and depth.

For conception C, this relationship may be represented abstractly as ADS_C = O_C × F_C × D_C, where O_C denotes admitted architectural objects, F_C the admitted dimensions of software form, and D_C their architectural depth. Because different object-form combinations may extend to different depths, however, architectural design span is more precisely understood as a region or volume within the three-dimensional software design space than as a regular Cartesian volume. The corresponding software design span encompasses the complete design space required to specify and realize the system; hence ADS_C ⊆ SDS. MAD does not prescribe how large this architectural span should be. It makes the span implied by each conception explicit so that its sufficiency

Figure 1. Architectural design breadth, depth, and span illustrated within the software design space.

Figure 1. Architectural design breadth, depth, and span illustrated within the software design space.

The X-axis represents fundamental software-system object classes, the Y-axis the five fundamental dimensions of software form, and the Z-axis design depth from more abstract toward more concrete realization. The high-level/low-level division is illustrative rather than ontological. The shaded regions represent hypothetical conceptions that recognize different portions of the same software design space as architectural; their differing shapes illustrate that architectural significance may vary simultaneously in breadth and depth.

4.3.6. Architectural Context

Which classes of contextual factors can materially influence architectural qualities or design choices across software form?

Software systems are designed, realized, operated, and evolved within environments that constrain feasible form and resulting qualities. Relevant contextual classes may include technological, physical and environmental, economic, organizational, human, social and cultural, legal and regulatory, political and institutional, operational, and historical or legacy factors. These are classes of influence rather than the circumstances of an individual system: a specific budget, regulation, workload, climate, organizational capability, technology platform, or legacy constraint is system-specific, whereas its broader class is conceptually general.

MAD asks which contextual classes a conception admits as architecturally significant. The relevance question is whether variation within a class can materially alter essential architectural qualities, feasible forms, or the design choices required to sustain them. Context is therefore fundamental because architectural adequacy cannot always be determined from properties of the software artifact in isolation; the same form may produce different consequences under different operating, organizational, regulatory, physical, or technological conditions. MAD exposes how broadly or narrowly a conception incorporates these conditions into architectural reasoning.

4.3.7. Architectural Boundary

What distinguishes architectural design from non-architectural design, and how are these domains related?

Architectural boundary is the resulting demarcation of architectural scope: the principle and practical basis by which a conception determines what falls within architectural design and what does not. MAD treats the boundary as derived rather than assumed. Once the defining predicate and the conception's positions on objects, qualities, form, depth, and context are made explicit, their combined implications should make it possible to explain why a concern is architectural or non-architectural.

The distinction need not imply independence. Architectural design, other software-engineering design, and non-engineering design activities involved in software-system realization may remain strongly interdependent. The conceptual requirement is a sufficiently intelligible demarcation that permits architectural scope, responsibility, accountability, governance, and relationships with other design work to be established without defining architecture circularly as whatever an architect happens to do. Because boundary is the practical expression of the preceding conceptual commitments, ambiguity here may reveal ambiguity or inconsistency elsewhere in the conception. can subsequently be examined through SACA.

4.3.8. Explanatory and Justificatory Commitments

What assumptions, knowledge, evidence, analogies, experience, and reasoning explain or justify the worldview's axiological and ontological commitments?

This epistemological element captures the grounds upon which a software architecture worldview's axiological and ontological positions rest. As defined in Section 2, the concern is not epistemology in its entire philosophical scope, but the explanations and justifications advanced for the worldview's claims.

Such grounds may include empirical evidence, established knowledge, conceptual or logical analysis, analogies, values and normative commitments, practical or professional experience, and established disciplinary theories or models. These sources need not be mutually exclusive, and a worldview may rely on several simultaneously.

MAD does not determine whether these grounds are valid or sufficient; it identifies them. Their defensibility is subsequently examined under SACA's explanatory adequacy in Section 5. In short, MAD asks what the grounds are; SACA asks whether those grounds are adequate.

4.4. Integrated MAD Model

Figure 2 presents the integrated structure of MAD. Purpose and Value occupies the axiological center and represents the worldview’s position on what software architecture is for and why it is valuable. The six ontological elements form the middle layer and collectively characterize what the worldview takes architectural design to encompass. The outer epistemological/explanatory layer represents common sources of assumptions, explanations, and justification supporting the axiological and ontological commitments. The layers are interdependent: together, their configuration constitutes the software architecture worldview reconstructed through MAD.

Figure 2. MAD as an interdependent conceptual system anchored on the disciplinary purpose of software architecture. Each outer element contributes to determining the scope through which architecture pursues its purpose; the elements are mutually constraining even though only their common orientation toward purpose is shown for visual simplicity.

Figure 2. MAD as an interdependent conceptual system anchored on the disciplinary purpose of software architecture. Each outer element contributes to determining the scope through which architecture pursues its purpose; the elements are mutually constraining even though only their common orientation toward purpose is shown for visual simplicity.

A synthesized conception or definition of software architecture may consequently be derived from this configuration; it is an outcome of worldview reconstruction rather than an independently presupposed element of MAD.

4.5. Software Architecture Conceptual Adequacy (SACA) Framework

MAD provides a common framework for reconstructing, describing, and comparing software architecture worldviews, but description alone cannot establish whether a worldview is adequate. SACA provides the complementary evaluative framework. The worldviews examined in this paper are therefore treated as theory-like conceptual systems rather than merely as alternative definitions. This treatment is consistent with the theory-theory of concepts, according to which concepts derive part of their coherence and inferential significance from the wider bodies of knowledge, relations, assumptions, and explanatory commitments within which they are embedded (Murphy & Medin, 1985). It is also consistent with broad accounts of theory that recognize analytical, explanatory, predictive, and design-oriented theories rather than restricting theory to causal prediction (Gregor, 2006).

Accordingly, influential software architecture worldviews are evaluated not only through what their formal definitions state, but through the broader descriptive propositions and explicit or implicit justificatory assumptions required to make those definitions intelligible. Whetten distinguishes the theoretical account—its relevant constructs or factors—and the how through which they are related, from the why that supplies the underlying explanatory logic (Whetten, 1989). In SACA, these distinctions broadly motivate descriptive adequacy, concerned with the quality of the worldview's descriptive system, and explanatory adequacy, concerned with the defensibility of the assumptions and justificatory reasoning supporting it.

Because software architecture is an applied design and engineering discipline, conceptual adequacy additionally requires practical relevance. Theory-building literature in professional and applied disciplines emphasizes the relationship between theoretical knowledge and professional practice (Van de Ven, 1989). Gregor recognizes theory for design and action as a legitimate form of theory (Gregor, 2006), while Gregor and Jones show that design theory incorporates purpose and scope, constructing, justifying knowledge, principles of form and function, and implementation-oriented knowledge (Gregor & Jones, 2007). Corley and Gioia likewise identify practical utility alongside scientific utility as an important dimension of theoretical contribution (Corley & Gioia, 2011). SACA therefore incorporates practical adequacy as an additional criterion appropriate to an applied professional discipline.

SACA adds a fourth criterion, teleological adequacy, building particularly on Simon's account of artificial systems and design as inherently purposive (Simon, 1996). Because design is directed toward intended ends, the adequacy of a conception of software architecture cannot be judged solely by whether it is internally coherent or practically usable. It must also be examined against the independently established disciplinary purpose in Section 3. Teleological adequacy therefore asks whether conceiving software architecture in the proposed way gives discipline sufficient scope and design control to fulfil that shared purpose.

Table 3. SOFTWARE ARCHITECTURE CONCEPTION ADEQUACY (SACA) FRAMEWORK.

Dimension	Governing Question	Principal Considerations
Descriptive	Does the worldview adequately specify its conception of software architecture and how its commitments relate?	Completeness; consistency; internal coherence; clarity; precision.
Explanatory	Are the assumptions and justificatory logic supporting the worldview defensible?	Analytic reasoning; epistemic coherence; empirical validity where applicable; analogical validity.
Practical	Does the worldview provide a sufficiently usable basis for architectural practice?	Scope of work; responsibility; accountability; governance; relationships with other design work.
Teleological	Does the conception adequately enable software architecture to fulfil the shared disciplinary purpose?	Disciplinary purpose alignment; coherent design control; long-term integrity, viability, and sustainability.

Table 3. SOFTWARE ARCHITECTURE CONCEPTION ADEQUACY (SACA) FRAMEWORK.

Dimension	Governing Question	Principal Considerations
Descriptive	Does the worldview adequately specify its conception of software architecture and how its commitments relate?	Completeness; consistency; internal coherence; clarity; precision.
Explanatory	Are the assumptions and justificatory logic supporting the worldview defensible?	Analytic reasoning; epistemic coherence; empirical validity where applicable; analogical validity.
Practical	Does the worldview provide a sufficiently usable basis for architectural practice?	Scope of work; responsibility; accountability; governance; relationships with other design work.
Teleological	Does the conception adequately enable software architecture to fulfil the shared disciplinary purpose?	Disciplinary purpose alignment; coherent design control; long-term integrity, viability, and sustainability.

4.5.1. Descriptive Adequacy

Descriptive adequacy asks whether the worldview provides a sufficiently complete, internally consistent, coherent, clear, and precise account of software architecture. MAD supplies the descriptive reference frame: analysis examines whether the worldview establishes intelligible positions across the relevant MAD elements and whether those positions collectively yield a coherent conception and architectural scope. Completeness does not require classifying every concern as architectural; rather, fundamental descriptive questions must be addressed sufficiently for inclusions, exclusions, and relationships to be intelligible. A worldview may therefore be concise yet descriptively adequate, or extensive yet inadequate because important dimensions remain silent, contradictory, ambiguous, or imprecise (Gregor, 2006; Whetten, 1989; Gregor & Jones, 2007).

4.5.2. Explanatory Adequacy

Explanatory adequacy concerns the defensibility of the reasoning supporting a worldview's axiological and ontological positions. MAD identifies these explanatory and justificatory commitments; SACA evaluates their adequacy. It asks why particular objects, qualities, forms, depths, contexts, or boundaries are regarded as architectural and why others are excluded, as well as how the worldview's purpose and value commitments are supported. Their adequacy may be established through logical or analytic reasoning, epistemic coherence with established knowledge, empirical evidence where applicable, and valid analogical reasoning. A worldview may consequently be descriptively precise yet explanatorily weak, while a compelling explanatory insight may remain insufficiently translated into a complete descriptive conception (Whetten, 1989).

4.5.3. Practical Adequacy

Practical adequacy asks whether the worldview provides a sufficiently intelligible and usable basis for professional architectural practice, reflecting the additional expectations placed upon theories and conceptual systems in applied and professional disciplines (Gregor, 2006; Van de Ven, 1989; Gregor & Jones, 2007; Corley & Gioia, 2011). Its scope here is deliberately foundational: whether practitioners and organizations can determine what requires architectural attention, where architectural responsibility and accountability begin and end, how architectural work relates to other software-engineering and design work, and what must consequently be governed, documented, and taught as architecture.

4.5.4. Teleological Adequacy

Teleological adequacy asks how well a conception enables software architecture to fulfil the shared disciplinary purpose established in Section 3. Its reference point is therefore external to the conception being evaluated. The question is not whether a conception is merely consistent with its own stated purpose; such consistency is treated under descriptive adequacy as part of internal coherence. The teleological question is whether the conception's admitted architectural objects, qualities, forms, depth, context, boundary, and explanatory foundations collectively provide an adequate basis for the discipline to establish and sustain coherent design control over complex software systems in pursuit of intended purposes, critical qualities, and governing constraints.

4.5.5. Interdependence of the Four Dimensions

The four dimensions are analytically distinct but intricately coupled. Figure 3 represents descriptive, explanatory, and practical adequacy at the vertices of a triangle and teleological adequacy at its centre. The connecting lines represent coupling rather than one-way causality. A worldview can be descriptively adequate yet teleologically insufficient; explanatorily convincing yet directed toward a scope that inadequately serves the disciplinary purpose; or practically workable yet support outcomes weakly connected to that purpose.

Figure 3. Interdependence of the four SACA dimensions.

Figure 3. Interdependence of the four SACA dimensions.

Dependency also runs in the opposite direction. Adequate teleological judgment is difficult without sufficient descriptive, explanatory, and practical adequacy: ambiguity or silence constrains judgment of purpose-alignment; weak assumptions make apparent alignment unsound; and a worldview that cannot be meaningfully operationalized is limited in its capacity to advance that purpose in an applied discipline. The outer criteria also constrain one another. Poor descriptive adequacy, for example, limits explanatory assessment because omitted or ambiguous propositions obscure the assumptions requiring justification; conversely, strong description does not guarantee strong explanation, and explanatory insight may coexist with descriptive incompleteness.

SACA therefore treats conceptual adequacy as a coupled system rather than four independent tests.

5. Discussion

This study began from a question logically prior to proposing another definition of software architecture: what common conceptual basis is required to systematically formulate, reconstruct, describe, understand, compare, and evaluate alternative conceptions of software architecture before attempting their synthesis into a more unified and holistic conception? The question arises from the persistence of materially different definitions and conceptualizations of architecture and from the practical importance of determining what architectural design encompasses, where its boundaries lie, and what architectural responsibility consequently entails. The discussion considers the results produced by MAW in relation to this question, their relationship to prior knowledge, the validity and credibility of the framework, its implications, and its limitations.

5.1. Key Results

The principal result is that the definitional problem can be productively reframed as a meta-conceptual problem. Before asking which definition should prevail, competing conceptions must be expressible within a common conceptual space and evaluated against explicit criteria. MAW provides this higher-order conceptual structure and is operationalized through two complementary frameworks: MAD for description and comparison, and SACA for evaluation.

MAD identifies eight interrelated elements through which a conception can be reconstructed: purpose and value; architectural objects; architectural qualities; architectural form; architectural depth; architectural context; architectural boundary; and explanatory and justificatory commitments. Treating breadth and depth separately further yields the concepts of design span and architectural design span, allowing architectural scope to be represented as a potentially irregular region of software-design space rather than as a fixed high-level layer.

SACA establishes that adequacy is multidimensional. A conception may be clearly described yet rest on weak justificatory grounds; be theoretically plausible yet provide an insufficient basis for professional practice; or be internally coherent yet delimit architecture in a way that inadequately supports the shared disciplinary purpose. Teleological adequacy is therefore anchored to the independently established disciplinary reference telos in Section 3, while consistency with a conception's own claims is treated as an issue of descriptive coherence.

5.2. Contributions and Novelty

5.2.1. MAW: Moving the Definitional Problem to the Meta-Conceptual Level

Prior software-architecture scholarship has produced influential definitions, structural and view-based models, standards, and decision-centred conceptions (Perry & Wolf, 1992; Garlan & Shaw, 1993; Clements et al., 2011; Jansen & Bosch, 2005; ISO/IEC/IEEE, 2022; Bass et al., 2021). Baragry and Reed (1998) directly exposed the difficulty of obtaining a unified view. These works substantially advance particular accounts of architecture, but they do not by themselves provide a common higher-order framework specifically for reconstructing and evaluating alternative conceptions on the same conceptual basis. MAW addresses that prior-order problem. Its novelty lies not in adding another substantive definition, but in reframing the definitional problem as a meta-conceptual inquiry and integrating systematic description and adequacy evaluation within one higher-order conceptual system. This creates a disciplined basis for synthesis without presupposing its outcome.

5.2.2. MAD: A Common Descriptive Space for Architecture Conceptions

Established architecture-description work already recognizes elements, relationships, properties, stakeholders, concerns, views, viewpoints, context, and design principles (Clements et al., 2011; ISO/IEC/IEEE, 2022). Decision-centred work additionally foregrounds decisions, assumptions, rationale, and consequences (Jansen & Bosch, 2005; Kruchten et al., 2006). MAD does not claim these individual concerns as new. Its contribution is their reorganization at a different analytical level: as common dimensions for making the commitments of competing conceptions explicit. By incorporating axiological, ontological, and explanatory commitments in one descriptive space, MAD permits differently worded conceptions to be compared by what they commit to rather than by terminology alone. Its significance is therefore methodological and conceptual: it provides a repeatable anatomy for reconstructing both explicit claims and material omissions.

5.2.3. Design Span and Architectural Design Span

Software architecture has long relied on abstraction, decomposition, multiple structures, views, and levels to manage complexity (Garlan & Shaw, 1993; Soni et al., 1995; Clements et al., 2011; Bass et al., 2021). MAD's distinction between architectural breadth and architectural depth extends this established body of knowledge by treating scope as a design-space problem. Architectural design span represents the region of software design space that a conception admits as architecturally significant across objects, form, and depth, including the possibility that different object-form combinations extend to different depths. The novelty is therefore not the existence of abstraction or levels, but their integration with breadth and form into an explicit construct for comparing architectural scope and boundary across conceptions.

5.2.4. SACA: From Description to Conception Adequacy

SACA builds on established bodies of theory rather than inventing adequacy criteria without precedent. Descriptive and explanatory adequacy are consistent with theory-building accounts that distinguish constructs, relationships, and justificatory logic (Whetten, 1989; Gregor, 2006). Practical adequacy reflects the expectations placed on theory in applied and design-oriented disciplines (Van de Ven, 1989; Gregor & Jones, 2007; Corley & Gioia, 2011). Teleological adequacy draws on the purposive character of designed artifacts articulated by Simon (1996), but gives it a software-architecture-specific reference through the disciplinary telos established in Section 3. SACA's contribution is the integration and adaptation of these considerations into a framework for evaluating software-architecture conceptions. In particular, teleological adequacy prevents a conception from being treated as adequate merely because it is internally coherent: it must also be capable of enabling software architecture to fulfil the broader purpose for which the discipline is established.

5.3. Validity and Credibility

MAW's present credibility is principally conceptual and theoretical rather than experimental. First, its constructs are grounded across multiple relevant bodies of knowledge: foundational and contemporary software-architecture literature, architecture-description standards, architectural-design-decision research, worldview and concept theory, theory-building scholarship, and design theory. Second, MAW separates description from evaluation through its two constituent frameworks, reducing the risk that MAD silently builds a preferred conception into the descriptive space. Third, teleological evaluation is anchored to a disciplinary purpose synthesized independently from substantial convergence in foundational literature rather than to the preferred purpose of any single conception. Fourth, MAW makes its elements, governing questions, assumptions, and evaluation criteria explicit, allowing them to be challenged, refined, or falsified through subsequent application.

Credibility is also supported by correspondence with documented problems in practice without treating those problems as proof of the framework. Baragry and Reed (1998) identified the longstanding difficulty of establishing a unified understanding of software architecture. Ozkaya's (2016) practitioner survey found limited architecture knowledge despite architecture being regarded as important, while Oliveira et al. (2019) reported that software-architect roles, responsibilities, activities, and tasks remain diffuse in organizations. Ali et al. (2018) found that architecture-consistency practices are often informal and identified barriers to more explicit conformance approaches. Architecture-erosion research independently demonstrates the consequences that can accompany loss of architectural integrity (Li et al., 2022). These studies do not establish that definitional plurality causes poor practice or erosion; rather, they support the practical relevance of making architectural scope, commitments, and boundaries explicit.

5.4. Implications

MAW has three principal implications for how the definitional problem of software architecture should subsequently be approached.

First, the adequacy of a software architecture definition cannot be established by brevity, intuitive appeal, prevalence, institutional authority, or popularity alone. A definition is the concise expression of a broader software architecture worldview whose adequacy depends on the assumptions and positions it embodies. MAW therefore implies that a worldview should first be reconstructed through its commitments across the eight MAD dimensions and those commitments subsequently examined through SACA. The adequacy and suitability of existing or future software architecture worldviews cannot be credibly established merely by comparing their definitional statements; they require systematic meta-conceptual description and evaluation. This shifts the definitional problem from selecting among competing formulations toward examining the conceptual foundations and adequacy of the worldviews from which those formulations arise.

Second, a sufficiently complete and coherent definition of software architecture requires an integrated and coherent set of commitments across the eight MAD dimensions. Defining architecture solely in terms of structures, significant decisions, fundamental properties, abstraction level, or another isolated characteristic leaves other foundational questions implicit or unresolved. A complete conception must therefore establish mutually coherent positions concerning architecture's purpose and value, architectural objects, architectural qualities, architectural form, architectural depth, architectural context, architectural boundary, and the explanatory and justificatory grounds for those positions. The resulting definition need not itself be long; its concision must rest on an explicitly articulated and coherent underlying conception. Definitional completeness is therefore not primarily a property of the number of words in a definition, but of the completeness and coherence of the conceptual system that the definition expresses.

Third, progress toward a unified and holistic definition of software architecture should proceed through systematic synthesis of adequately reconstructed and evaluated worldviews rather than through the proposal of another standalone definition. Existing and future conceptions should first be expressed within a common MAD conceptual space, evaluated through SACA, and examined for genuine convergence, complementarity, incompatibility, and residual inadequacy. A more unified conception can then emerge through principled synthesis of defensible commitments rather than terminological compromise, institutional preference, or selection of a dominant existing definition. Unification, on this view, is not primarily the search for wording on which the field can agree; it is the search for an integrated set of conceptually and teleologically adequate commitments from which an appropriate definition can subsequently be expressed.

5.5. Significance

The significance of MAW lies in providing a disciplined basis for work that has previously been difficult to conduct on common conceptual grounds. For research, it provides a shared analytical space for comparing existing definitions and theories, distinguishing substantive disagreement from terminological variation, identifying genuine convergence and divergence, and constructing future conceptions with explicit commitments. A direct next application is the systematic reconstruction of influential definitions, standards, and foundational perspectives to determine whether recurring configurations of commitments form identifiable schools of thought and how those schools differ when evaluated through SACA.

For practice and governance, MAD provides a vocabulary through which organizations can make explicit the conception of architecture they are actually using: its purpose, admitted objects and qualities, dimensions of form, depth, context, and boundary. SACA provides a complementary basis for examining whether that conception is sufficiently clear, defensible, usable, and capable of supporting the shared disciplinary purpose. MAW does not prescribe a universal organizational architecture scope; it makes the adopted scope, its assumptions, and its rationale inspectable, thereby supporting clearer architectural responsibility, accountability, communication, documentation, and governance.

For education and professional formation, this paper can serve as a useful reference text for graduate education in software engineering, especially, Master of Philosophy (MPhil) and PhD studies. Specifically, it can be a useful reference for understanding as well as critically questioning the philosophical foundations of software architecture

5.6. Limitations

MAW is an a priori meta-conceptual framework and neither MAD nor SACA is claimed to be exhaustive. Rather, they are proposed as comprehensive frameworks grounded in the established bodies of knowledge examined in this study and, to the author's knowledge, constitute the first integrated descriptive and evaluative meta-framework specifically developed for examining software architecture conceptions. They provide a sufficiently comprehensive foundation to initiate systematic reconstruction, comparison, evaluation, and eventual synthesis of competing software architecture worldviews. Nevertheless, the degree of their comprehensiveness and particularly whether additional meta-conceptual dimensions or adequacy criteria are necessary remains open to scholarly scrutiny, refinement, and extension.

6. Conclusion

Progress toward a more unified and holistic definition of software architecture requires more than another competing definition. It requires a common basis for making alternative conceptions explicit and for evaluating whether they are descriptively coherent, explanatorily defensible, practically usable, and capable of enabling software architecture to fulfil its shared disciplinary purpose. This paper has developed the Meta-Architectural Worldview (MAW) for that prior task. MAW is operationalized through the Meta-Architectural Descriptive (MAD) Framework and the Software Architecture Conception Adequacy (SACA) Framework and introduces design span and architectural design span as constructs for making architectural scope explicit.

These constructs provide a disciplined first-principles basis for exploring a more unified and holistic conception without presupposing the outcome. The immediate next step is systematic application of MAW to influential definitions, standards, theories, and foundational perspectives, both to test the framework's analytical usefulness, to determine whether recurring configurations of commitments can be synthesized into coherent schools of thought, and to establish the strengths, and limitations of prevailing schools of thought.