Systems of Systems Engineering

A system of systems is not just a big or complicated system. It's a specific category with its own engineering problems, and the paper that gave the category its modern definition even admitted the name itself doesn't quite fit. Mark Maier's 1998 paper, still the most cited definition in the field, suggests the grouping might be better termed "collaborative systems," since "system of systems" doesn't really describe what makes the category distinct (Maier, 1998).

What does make it distinct is five characteristics, all of which have to hold at once. Operational independence: each constituent system can do something useful entirely on its own, it doesn't need the rest of the SoS to function. Managerial independence: each constituent has its own owner, budget, and priorities, and nobody outside that constituent can simply order a change to it. Evolutionary development: the SoS is never finished, it's fielded incrementally and keeps changing as its constituents change on their own schedules. Emergent behavior: the SoS produces capabilities that don't exist in any single constituent, only in how they interact. Geographic distribution: the constituents are spread out enough that how they exchange information matters as much as what any one of them does (Maier, 1998).

Air travel is a working example most people have some intuition for. Air traffic control, airlines, airports, weather services, and the maintenance and ground operations that keep aircraft moving are each independently operated and independently managed, air traffic control doesn't own the airlines, and the airlines don't own the airports. Put them together and you get something none of them provides alone: a national air transportation system that's safe and, most of the time, on schedule.

Maier's original paper proposed a taxonomy based on how much central authority exists over the constituents: directed, collaborative, and virtual. Judith Dahmann and Kristen Baldwin's 2008 study of US defense systems of systems added a fourth, acknowledged, to describe a common case Maier's original three didn't quite capture: an SoS with a real, designated manager and its own recognized objectives, whose constituent systems still keep their own funding, ownership, and development schedules (Dahmann & Baldwin, 2008). The four types now form the standard taxonomy, later folded into ISO/IEC/IEEE's own standards for systems of systems (International Organization for Standardization et al., 2019).

Every one of the other four characteristics is a management and organizational problem. Emergent behavior is the one that's actually an engineering problem, and it's the reason SoSE exists as its own discipline rather than just being systems engineering at a larger scale (Nielsen et al., 2015).

A capability that emerges from the interaction of independent constituents can't be fully verified by testing any constituent on its own, and often can't be fully verified by testing the whole SoS either, because the SoS keeps changing as its constituents evolve independently of each other. That's a genuinely different problem than verifying a single system against a fixed specification. The specification itself doesn't hold still.

Traditional systems engineering assumes something SoSE can't: a single authority who can set requirements, freeze a baseline, and hold every part of the system accountable to it. An SoS has neither a fixed baseline nor a single authority, by definition, since managerial independence is one of its defining characteristics. Every practice that depends on central control, requirements flow-down, configuration freezes, a single integrated master schedule, has to be rethought rather than just scaled up.

A 2024 retrospective examining 57 papers across eleven years of the field's own dedicated workshop found the research community still treating most of its hardest problems, verification of emergent behavior, engineering for continuous evolution, cross-organizational governance, as open rather than solved (Cavalcante et al., 2024). This isn't a niche research gap. It's the actual state of a field that's been working on these exact problems for over a decade.

MBSE, covered earlier in this series, is arguably most valuable exactly where central authority is weakest. If no single organization can mandate a shared model, a common, machine-readable representation that different constituent-system teams can each connect to is one of the few practical ways to keep an evolving SoS even partially coherent. One study specifically measuring MBSE's return on investment in the evolutionary development of complex systems of systems found it delivers a real, positive return, not just a theoretical one (Rogers & Mitchell, 2021).

That's a meaningfully different claim than the general MBSE value question raised earlier in this series, where the evidence turned out to be thinner than the hype: two thirds of claimed MBSE benefits in the wider literature are only "perceived," not measured (Henderson & Salado, 2021). SoS is a case where the argument for MBSE doesn't rest on convenience. It rests on the fact that there's often no other way to maintain a shared picture at all.

Multi-agent AI systems, covered earlier in this series, run into the exact same typology Maier described for physical systems, just faster.

Google announced Agent2Agent in April 2025 with backing from more than fifty technology partners, aimed squarely at that hardest case: agents built by completely different vendors discovering each other and coordinating with no central authority (Google, 2025). It's a live test of Maier's oldest point. Getting managerially independent parties to actually adopt a shared coordination standard is a social and organizational problem before it's a technical one. Compared to the rapid, broad adoption the Model Context Protocol saw across the industry, Agent2Agent's uptake has looked more mixed since, even with major vendor backing and a later move to the Linux Foundation. The protocol being technically sound was never the hard part.