Systems Architecture

Systems architecture is not the diagrams. ISO/IEC/IEEE 42010, the international standard for architecture description, defines architecture as a property of a system, its fundamental concepts in its environment, and the architecture description as the separate work product used to express that architecture, the same distinction a building architect draws between the design in their head and the blueprints on the table (International Organization for Standardization et al., 2022).

The standard formalizes a specific chain, shown above: a stakeholder has concerns, a viewpoint is a way of describing the architecture that addresses a specific set of concerns for specific stakeholders, and a view is what you get when you actually apply a viewpoint to the system at hand. No single view is "the architecture." The architecture is the whole system's structure; a view is just one lens on it.

Mark Maier, whose work on systems of systems appeared earlier in this series, co-authored the standard reference on the practice of architecting itself, now in its fourth edition. Its central, slightly uncomfortable claim is that requirements are an output of architecting, not just an input: the architect works jointly with the client to define the problem and the solution together, because in a genuinely new system, nobody fully knows what to require until someone has sketched what's possible (Maier & Rechtin, 2025).

The most influential concrete application of this idea is Philippe Kruchten's 4+1 view model, published in 1995 and still the default mental model most architects reach for. Four views, each addressing a different stakeholder's concerns: a logical view for the system's functional structure, a process view for how it behaves at runtime, a development view for how the code and components are actually organized, and a physical view for how it deploys onto real hardware. The "plus one" is a set of use case scenarios that don't describe a new part of the system, they're the thread that shows all four other views are actually consistent with each other (Kruchten, 1995).

Most systems engineering assumes you know what the problem is and are optimizing a solution against it. Maier and Rechtin's whole framing of architecting starts from the opposite premise: architecting is what happens when you don't yet know what the problem is, moving from a vague concept and limited resources toward a feasible system concept in the first place (Maier & Rechtin, 2025).

Their answer isn't more analysis. It's heuristics: rules of thumb abstracted from decades of experience that can't be reduced to an equation, deployed specifically because the problems at this stage are too undefined for equations to apply yet. That's a genuinely different kind of engineering tool than anything else in this series has covered, and it's worth naming as such rather than treating architecture decisions as optimization with extra steps.

Once there are real alternatives on the table, systems engineers usually formalize the choice with a trade study: list the criteria that matter, weight them, score each alternative against each criterion, and let the weighted totals point to a winner. It looks like objective math, and organizations lean on it partly because it looks that way.

Maier and Rechtin's own point cuts directly against that comfort: the political decision-making process is intertwined with the technical one, and is often the deciding factor, regardless of what the trade study's numbers say (Maier & Rechtin, 2025). A weighting scheme is a set of value judgments wearing a spreadsheet's clothes. That doesn't make trade studies useless. It means the honest use of one is to make those value judgments explicit and arguable, not to launder a decision that was already made for other reasons.

An architectural decision is the most expensive kind to get wrong, for the same reason a defect caught early is cheaper than one caught late, covered earlier in this series' MBSE lesson: architecture decisions are the ones everything else gets built on top of. Changing a requirement usually means changing a document. Changing an architecture usually means changing the assumptions half the system's design already depends on.

That asymmetry is why the heuristics-and-trade-study approach from this lesson exists in the first place. Getting the architecture roughly right early is worth more than getting a lower-level design decision precisely right late, because the failure modes aren't the same size.

NASA's own systems engineering community is testing generative AI directly against this problem, on one of its highest-profile future missions. A working group formed for the Habitable Worlds Observatory, NASA's next flagship space telescope, used generative AI to run sensitivity analysis across simulated exoplanet data of varying model complexity, then worked backward from that analysis to the measurement-uncertainty requirements the observatory's instruments would actually need to meet, letting simulated data inform architecture and design requirements before hardware commitments are made (Shabram et al., 2024).

The group's own stated mission for the effort is worth repeating plainly, because it's a fitting note to end this series on: figuring out where the human belongs in the loop as generative AI systems keep getting more powerful and more autonomous, not assuming that question answers itself (Shabram et al., 2024).