Architecting Approaches for Systems of Systems

Lead Authors: Judith Dahmann, Mike Henshaw

Essentially, the role of the Systems Engineer with respect to system of systemssystem of systems SoS is to compose the constituent systems to meet the goals and needs of the SoS. In practice, this will largely require management of interfaces between constituent systems and leveraging the existing functionality of the constituent systems. However, it may also include changing the functionality of some constituent systems, the performance of interfaces, or the introduction of additional capability the purpose of which is solely to facilitate SoS operation.

Systems architectures and the process of architecting is covered by the ISO/IEC/IEEE 42000 series of standards and is overviewed by System Architecture Design Definition. In this article, we are concerned with the specific concerns related to architecting SoS.

ISO/IEC/IEEE 42010 (2022) defines architecting as ‘conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout the life cycle of an entity of interest’. For a SoS, the level of control varies according to its type; for a directed SoS, the owner, as architect, may be able to treat it as a monolithic system, whereas for a collaborative or virtual SoS, the architect may have little knowledge of many of the constituent systems. Furthermore, the notion of lifecycle is somewhat different because of the manner in which SoS evolve. Some may evolve over long periods of time and be reasonably stable, whereas others may be assembled transiently to achieve a specific purpose and then disassembled. The architectural approaches may need to be different accordingly.

(Wilkinson et al., 2010) analyzed different belief systems in systems architecting and highlighted two important differences pertinent to the approach to architecting and the contrast between a monolithic system and a SoS. Firstly, they determined that whereas some architects through the purpose of architecting is to ‘enable the building of better systems’, i.e. a design approach which they termed Forward Architecting, others regarded its purpose as ‘architecting is to understand existing parts of the environment as systems’, referred to as Reverse Architecting. Secondly, they contrasted the view of Maier & Rectin (2009) of the purpose to be to deliver maximum value to the client (monolithic system) with MODAF (2008) that sought coherence across the capability of the SoS. MODAF, a contemporary architecture framework (now withdrawn) that has been described by Hause (2010).

The key themes for architecting SoS are interoperability and the management of interfaces, design for evolution and reconfiguration, and increasingly the role of MBSE and simulation within an architectural context.

The Role of System of Systems Architecting

In a SoS, the architecturearchitecture is the technical framework for the systems comprising the SoS which designates how the systems will be employed by the users in an operational setting (sometimes called the concept of operationsconcept of operations (CONOPs), the internal and external relationships and dependencies among the constituent systems and their functions and, finally, the end-to-end functionality and data flow as well as communications among the systems.

The management and/or operational independence of the constituent systems drive the special considerations for architecting a SoS. (Maier, 1998) has provided four principles for architecting SoS, motivated by these characteristics:

The architect must pay attention to intermediate steps in a planned evolution of the SoS. This is realized in in the Wave Model [ref], which employs stable intermediate steps. This principle seems appropriate to the directed and acknowledged types of SoS, but is unlikely to be possible with the other types.
Application of standards and protocols through, what Maier terms, policy triage. This recognizes that the opportunities to influence the constituent system design are limited and that the points of influence must be chosen carefully.
As noted above, architecting of SoS largely focuses on the interfaces, this means that the architect must leverage the interfaces to realize the capability that the SoS is assembled to deliver. Agreement on interface definition is essential and the use of standards and, in particular, Open Systems Standards, is a means through which competent composition and flexible evolution may be achieved. It is worth noting that the inclusion of COTS (Commercial Off-The- Shelf) systems within the SoS relies on compliance with standards both during configuration of the SoS and the design of constituent systems. COTS, and MOTS (Modified Off-The-Shelf) are frequently used to reduce cost and risk in systems development.
Ensuring cooperation. Maier observes that collaboration between independent systems is only possible if the systems owners choose to collaborate. Thus, incentivizing collaboration, which requires an appreciation of motivations and non-technical aspects of assembly (such as commercial benefits and protection of IP) must be considered.

SoS are generally characterized by complexity and their assembly requires a mindset that thinks of design not as defined by an endpoint but by continual change and adaptation. The INCOSE Complexity Primer for Systems Engineers [INCOSE, 2021] articulates this well as ‘Think like a gardener, not a watchmaker’. This is the mindset that the SoS architect must adopt.

Interoperability as a Key Feature of Architecting for SoS

Interoperability within a SoS implies that each system can interact with appropriate other members of the SoS to enable higher level functions unachievable by the single systems, regardless of their hardware and software characteristics or nature. This implies that each constituent member (and potential new members) of a SoS should be able to exchange data/information with others without compatibility issues in the operating systems, communication hardware, and so on. In general, interoperability focuses on data and information, although physical interoperability may sometimes be needed.

Data exchange patterns are comprised of three elements: an architectural pattern, a data format, a communication protocol (Charest et al., 2020). There are many common languages for exchange of information and data, with XML (eXtensible Markup Language) being a popular choice.

However, interoperability must be achieved at many levels and not just at the data/network level. There are a number of frameworks that describe the levels of interoperability. From military applications, the NCOIC (Network Centric Operations Industry Consortium) Interoperability Framework (Osvalds, 2009) covers three broad levels of interoperability, subdivided into further layers as indicated below:

Network Transport:
- Physical Interoperability and
- Connectivity and Network Interoperability;
Information Services:
- Data/Object Model Interoperability,
- Semantic/Information Interoperability, and
- Knowledge/Awareness of Actions Interoperability; and
People, Processes and Applications:
- Aligned Procedures,
- Aligned Operations,
- Harmonized Strategy/Doctrine, and
- Political or Business Objectives.

This spectrum of interoperability layers requires appropriate coherence at each layer consistent with the SoS shared goals. Indeed, the vertical consideration of the framework is essential because, for example, agreement about the data/object model interoperability level requires alignment of business objectives through collaborative or cooperative engagement.

There exist interoperability frameworks in other fields of activity. An example is the European Interoperability Framework (European Commission 2017), which focuses on enabling business (particularly e-business) interoperability and has six levels within a political context

Interoperability Governance

Integrated Public Service governance

Legal Interoperability,

Organizational Interoperability,

Semantic Interoperability, and

Technical Interoperability.

The interoperability between the component systems of a SoS is a fundamental design consideration for SoS that may be managed through the application of standards.

Challenges in Architecting SoS

It is rare that architecting a SoS can begin unencumbered by extant designs and legacy systems or infrastructure. In general, the SoS must be composed with extant constituent systems, perhaps designed to different standards and for different purposes. Moreover, the architect’s knowledge of existing systems or those managed by alternative organizations, even competitors, is constrained. Thus, a mixed black-box, white-box approach to architecture definition may be needed. Even if the interfaces are well-defined, hidden functionality could potentially lead to undesirable emergent behavior.

The independence of the constituent systems means that these systems are typically designed to optimize system behavior, which may be at the expense of optimization for the SoS objectives. Indeed, it could be the case that the architect requires a constituent system to operate sub-optimally at the system level in order to achieve overall SoS effectiveness. (Rebovich 2009) has articulated this difficulty as a fundamental problem of SoS:

From the single-system community's perspective, its part of the SoS capability represents additional obligations, constraints and complexities. Rarely is participation in an (sic) SoS seen as a net gain from the viewpoint of single-system stakeholders.

The development and implementation of a SoS architecture may be significantly constrained by a reluctance to make changes or invest in the constituent systems, which could be very mature (e.g. in sustainment) or currently productively supporting other uses. In this case, approaches such as gateways and wrapping may be used to incorporate these systems into the SoS without making significant changes in the other systems.

The co-simulation community seek to integrate different types of models within an overall framework, e.g. Gomes et al, 2018. This can be extended to consider models of different constituent systems using an MBSE approach. This has been demonstrated by (Dahmann et al., 2017) in which a SoS architecture built with SysML includes executable models of the platforms, weapons, communications and data links.

(Maier, 1998) third principle, concerning leveraging the interfaces in SoS architecting and assembly is illustrated by (Shames, Sarrel and Friedenthal, 2016) using the example of a space data system. They highlight the role of standards in modelling the SoS interfaces using SysML defining the Interface Modelling Method that employs a black-box / white-box approach and the final step of which is to specify the standards that define interface compliance. The Object Management Group (OMG) are active in the development of standards to support interface design, as described by (Fosse and Delp, 2013).

Open Systems Architecture (OSA)

Open Systems Architectures is a particular approach to standards that seeks to enable commercial, technological, and operational agility (Henshaw et al., 2011) by publishing standards enabling competition amongst suppliers and opportunities to rapidly deploy new systems (or sub-systems) within a SoS. It should be emphasized that Open Systems Architectures refers to an approach to the use of standards within acquisition and procurement, rather than to a particular class of architecture. Typically, government or tier 1 integrators may see benefits by enabling greater competition within the supply chain, and lower tier organisations may see benefits due to reduced barriers to entry. (Henshaw et al., 2011) define an open architecture as: ‘An Open (Systems) Architecture applies to a system in which the architecture is published in sufficient detail to enable change and subsequent evolution through the introduction or replacement of modules and/or components from any supplier’, whereas the Defense Acquisition Glossary uses the definition: ‘A technical architecture that adopts open standards supporting a modular, loosely coupled and highly cohesive system structure that includes publishing of key interfaces within the system and full design disclosure’ [DAU, n.d.], whereas Radoman et al [2025] has provided a systemigram description of Open Systems Architecture, combining many different views and presenting an in depth analysis of benefits and actions to implement the approach.

OSA are used across several domains and, typically, open architecture standards are domain specific. Perhaps the broadest applicability is the MOSA (Modular Open Systems Approach), https://www.cto.mil/sea/mosa that integrates business and technical strategy across the US DoD. Within the automotive industry, AUOTSAR, is an industry developed set of standards adopted by major automotive manufacturers as an effective supply chain management approach focusing on software. However, this might be regarded as an approach for complicated software-driven systems rather than SoS.

(Radoman et al., 2023) has reviewed more than 80 open Architecture Standards in the military domain and provided a detailed database of her review.

References

Works Cited

Cláudio Gomes, Casper Thule, David Broman, Peter Gorm Larsen, and Hans Vangheluwe. 2018. Co-Simulation: A Survey. ACM Comput. Surv. 51, 3, Article 49 (May 2019), 33 pages. https://doi.org/10.1145/3179993

Charest, G. et al. (2020) Advisory note: Data Exchange Methods and Considerations. Available at: https://enterprisearchitecture.harvard.edu/sites/hwpi.harvard.edu/files/enterprise/files/data_exchange_advisory_v1_final.pdf?m=1581437469.

Dahmann, J. et al. (2017) ‘SysML Executable Systems of System Architecture Definition: A Working Example’, in 2017 Annual IEEE International Systems Conference (SysCon). Montreal, CA: IEEE.

Defense Acquisition University, Glossary, Fort Belvoir, VA, https://www.dau.edu/glossary/open-systems-architecture, accessed 03/25/25

The European Interoperability Framework in Detail, 2017, https://interoperable-europe.ec.europa.eu/collection/nifo-national-interoperability-framework-observatory/european-interoperability-framework-detail,

Fosse, E. and Delp, C.L. (2013) ‘Systems Engineering Interfaces: A Model Based Approach’, in 2012 IEEE Aerospace Conference. Pasedena: IEEE. Available at: https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6497322 (Accessed: 30 January 2025).

M. Hause, "The Unified Profile for DoDAF/MODAF (UPDM) enabling systems of systems on many levels," 2010 IEEE International Systems Conference, San Diego, CA, USA, 2010, pp. 426-431, doi: 10.1109/SYSTEMS.2010.5482450.

Henshaw, M. et al. (2011) Assessment of Open Architectures within Defence Procurement, Crown owned copyright [2011]. Available at: https://dspace.lboro.ac.uk/dspace-jspui/handle/2134/8828.

INCOSE (2021) "A Complexity Primer for Systems Engineers, Revision 1"

Maier, M.W. (1998) ‘Architecting principles for systems-of-systems’, Systems Engineering, 1(4), pp. 267–284. Available at: https://doi.org/10.1002/(SICI)1520-6858(1998)1:4<267::AID-SYS3>3.0.CO;2-D.

Osvalds, G., Grumman, N., Yanosy, J., Collins, R., Robert, L. S.-S., & Lebas -Thales, P.-S. F.-X. (2009). NIF WG NIF Solution Document Reference Manual NSD-RM. https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=df42971f88001761b69a0da3fea763a85bbf8b59

Radoman, R.L.V. et al. (2023) ‘Mapping of Open Architectures Applied to Military Systems’, 2023 18th Annual System of Systems Engineering Conference, SoSe 2023, pp. 1–8. Available at: https://doi.org/10.1109/SoSE59841.2023.10178668.

Radoman, Raquel Lampaça Vieira; Henshaw, Michael; King, Melanie; Rabbets, Tim (2023). Mapping of Open Architecture Standards Applied to Military Systems (dataset). Loughborough University. Dataset. https://doi.org/10.17028/rd.lboro.22241656.v2.

Radoman, R.L.V.; Henshaw, M.; King, M.; Rabbets, T. Enabling Open Architecture in Military Systems: A Systemic and Holistic Analysis. Systems 2025, 13, 207. https://doi.org/10.3390/systems13030207

Shames, P.M., Sarrel, M.A. and Friedenthal, S.A. (2016) ‘Modeling systems-of-systems interfaces with SysML’, in 14th International Conference on Space Operations, 2016. American Institute of Aeronautics and Astronautics Inc, AIAA. Available at: https://doi.org/10.2514/6.2016-2500.

Wilkinson, M. et al. (2010) ‘Belief systems in systems architecting: Method and preliminary applications’, 2010 5th International Conference on System of Systems Engineering, SoSE 2010, pp. 1–7. Available at: https://doi.org/10.1109/SYSOSE.2010.5544095.

Primary References

None

Additional References