Loading field map
Every large engineered system—a satellite, a military command network, a hospital information system—must be given a shape before its components are designed in detail. That early shaping is the work of systems architecture: deciding what the major parts are, how they interact, and which principles will guide their evolution. Since the 1970s, practitioners have developed six major frameworks for doing this work, each responding to a different kind of pressure. The earliest frameworks assumed that a system's structure could be derived from its functions through rigorous top-down decomposition. Later frameworks recognized that many systems are too novel, too uncertain, or too distributed for that assumption to hold. The result is a subfield that today contains several coexisting traditions, each best suited to a different class of problem.
The first systematic approach to systems architecture grew out of the structured analysis movement in software engineering. Structured Functional Architecting (SFA) treats architecture as a hierarchy of functions: the analyst decomposes the system's top-level purpose into subfunctions, then into sub-subfunctions, until each leaf function can be assigned to a physical component. The most influential notation was SADT (Structured Analysis and Design Technique), later standardized as IDEF0. SFA gave engineers a repeatable, auditable method for producing function-flow diagrams and data dictionaries. Its strength was traceability: every requirement could be linked to a function, and every function to a component. Its weakness was that it assumed the system's behavior could be fully specified in advance. For systems with emergent properties, novel technologies, or shifting stakeholder needs, the functional hierarchy often had to be rebuilt from scratch. SFA remains in use today in regulated domains—defense, aerospace, nuclear—where contractual traceability is mandatory, but it has been largely superseded for early-concept work.
By the early 1990s, architects working on unprecedented systems—the first GPS constellation, the International Space Station—found that functional decomposition could not capture the qualitative judgments that actually drove their decisions. Eberhardt Rechtin and Mark Maier articulated an alternative: Heuristic Systems Architecting (HSA). Instead of a formal decomposition method, HSA offers a collection of experience-based heuristics ("simplify, then add complexity later", "the system is the solution to a problem that may change") and a process of iterative negotiation among stakeholders. HSA does not reject SFA's tools; it subordinates them to a broader, more interpretive practice. The architect's primary skill, in this view, is not modeling but judgment. HSA is still widely taught and practiced, especially in the early phases of large government programs, because it acknowledges that the most important architectural decisions are made under conditions that no functional decomposition can resolve.
A third tradition emerged from the recognition that documents—SFA's function-flow diagrams, HSA's heuristic lists—are poor vehicles for analyzing dynamic behavior. Model-Based Systems Architecture (MBSA) replaces documents with an integrated, executable model of the system. The model is the single source of truth; every view (functional, physical, behavioral) is a projection from it. The intellectual foundation was laid by Wayne Wymore's work on mathematical systems theory and A. Wayne Wymore's 1993 book Model-Based Systems Engineering. The practical enablers came later: the Object-Process Methodology (OPM), which unifies structure and behavior in a single diagrammatic language, and the Systems Modeling Language (SysML), a UML profile tailored for systems engineering. MBSA does not replace SFA or HSA so much as absorb them: a SysML model can contain functional decompositions and can be used to test heuristics, but it adds the ability to simulate, verify consistency, and propagate changes automatically. Today, MBSA is the dominant framework in aerospace and defense, mandated by NASA and the U.S. Department of Defense for major programs.
As systems grew more complex, a different problem emerged: different stakeholders—acquirers, developers, operators, maintainers—needed different views of the same architecture, but there was no standard way to define those views or relate them to each other. Architecture Description Frameworks (ADFs) address this problem at the meta-level. The landmark standard was IEEE 1471-2000 (later ISO/IEC/IEEE 42010), which introduced the concepts of architecture viewpoint, view, and stakeholder concern. An ADF does not prescribe a modeling language; it prescribes a structure for organizing architectural descriptions. The U.S. Department of Defense Architecture Framework (DoDAF) and the UK Ministry of Defence Architecture Framework (MODAF) are prominent instantiations. ADFs are complementary to MBSA: a SysML model can be used to populate the views required by DoDAF. In practice, ADFs have been partially absorbed into MBSA toolchains, but they retain an independent identity because they address a problem—stakeholder communication—that MBSA alone does not solve.
Not all systems are monolithic. A system-of-systems (SoS) is an assemblage of independently governed, operationally independent systems that cooperate to produce capabilities none could achieve alone. Examples include air traffic management, disaster response networks, and military coalitions. System-of-Systems Architecting (SoSA) emerged as a distinct framework because the classical assumptions of SFA and MBSA—a single authority, a fixed boundary, a stable set of requirements—do not hold. SoSA focuses on interfaces, interoperability, and evolutionary governance rather than on internal decomposition. It draws on HSA's heuristics for managing uncertainty and on MBSA's modeling tools for interface specification, but it adds principles specific to distributed authority, such as Maier's "keep the interfaces simple and stable" and "design for evolution." SoSA is not a replacement for MBSA; it is a specialization for a class of problems that MBSA alone cannot address.
The most recent framework, Tradespace Exploration (TSE), shifts the architect's focus from defining a single architecture to exploring a space of possible architectures. TSE treats requirements not as fixed constraints but as variables whose values can be traded against each other. The architect generates a large set of candidate architectures, evaluates each against multiple attributes (cost, performance, risk, schedule), and visualizes the resulting tradespace to identify Pareto-optimal designs. TSE is value-centric: it asks not "does this architecture meet the requirements?" but "which architecture delivers the most value across the range of plausible futures?" TSE relies on MBSA models to generate and evaluate candidates, but it adds a quantitative decision-making layer that neither MBSA nor HSA provides. HSA and TSE both address uncertainty, but through fundamentally different mechanisms: HSA uses qualitative heuristics derived from experience, while TSE uses quantitative exploration of a modeled tradespace. TSE is now a leading framework in space systems architecture and is increasingly applied in defense and infrastructure.
No single framework has displaced the others. Today, MBSA, SoSA, and TSE are the most active research and practice traditions, but each occupies a distinct niche. MBSA is the workhorse for large, well-funded programs where a single authority can enforce model-based practices. SoSA is the framework of choice for distributed, evolving systems-of-systems. TSE is the leading approach for early-concept exploration under deep uncertainty. ADFs provide the meta-level structure for stakeholder communication and are often implemented inside MBSA tools. HSA remains influential as a source of architectural judgment and as a corrective to over-formalization. SFA persists in regulated domains where traceability is a contractual requirement.
The frameworks agree on several points: architecture matters, early decisions have outsized consequences, and no single view of a system is sufficient. They disagree on how to handle uncertainty—whether through heuristics, executable models, or quantitative exploration—and on the role of formal methods versus human judgment. The most productive tension today is between MBSA's drive toward comprehensive, integrated models and TSE's insistence that the most important architectural work happens before the model is fixed. That tension is unlikely to be resolved; it is more likely to generate hybrid practices that combine the strengths of both.