- Information
- AI Chat
Systems of systems architecture
Software Engineering (CSPC 111)
STI West Negros University
Preview text
Systems of systems architecture
Perhaps the most crucial activity of the systems of systems engineering process is architectural design. Architectural design involves selecting the systems to be included in the SoS, assessing how these systems will interoperate, and designing mechanisms that facilitate interaction. Key decisions on data management, redundancy, and communications are made. In essence, the SoS architect is responsible for realizing the vision set out in the conceptual design of the system. For organizational and federated systems, in particular, decisions made at this stage are crucial to the performance, resilience, and maintainability of the system of systems.
Maier (Maier 1998) discusses four general principles for the architecting of complex systems of systems:
Design systems so that they can deliver value if they are incomplete. Where a system is composed of several other systems, it should not just be useful if all of its components are working properly. Rather, there should be several “stable intermediate forms” so that a partial system works and can do useful things.
Be realistic about what can be controlled. The best performance from a SoS may be achieved when an individual or group exerts control over the overall system and its constituents. If there is no control, then delivering value from the SoS is difficult. However, attempts to overcontrol the SoS are likely to lead to resistance from the individual system owners and consequent delays in system deployment and evolution.
Focus on the system interfaces. To build a successful system of systems, you have to design interfaces so that the system elements can interoperate. It is
important that these interfaces are not too restrictive so that the system elements can evolve and continue to be useful participants in the SoS.
- Provide collaboration incentives. When the system elements are independently owned and managed, it is important each system owner have incentives to continue to participate in the system. These may be financial incentives (pay per use or reduced operational costs), access incentives (you share your data and I’ll share mine), or community incentives (participate in a SoS and you get a say in the community).
Sillitto (Sillitto 2010) has added to these principles and suggests additional important design guidelines. These include the following:
Design a SoS as node and web architecture. Nodes are sociotechnical systems that include data, software, hardware, infrastructure (technical components), and organizational policies, people, processes, and training (sociotechnical). The web is not just the communications infrastructure between nodes, but it also provides a mechanism for informal and formal social communications between the people managing and running the systems at each node.
Specify behavior as services exchanged between nodes. The development of service-oriented architectures now provides a standard mechanism for system operability. If a system does not already provide a service interface, then this interface should be implemented as part of the SoS development process.
phases. These are shown in Figure 20, taken from the TOGAF reference documentation (Open Group 2011).
All architectural frameworks involve the production and management of a large set of architectural models. Each of the activities shown in Figure 20 leads to the production of system models. However, this is problematic for two reasons:
Initial model development takes a long time and involves extensive negotiations between system stakeholders. This slows the development of the overall system.
It is time-consuming and expensive to maintain model consistency as changes are made to the organization and the constituent systems in a SoS.
Architecture frameworks are fundamentally reductionist, and they largely ignore sociotechnical and political issues. While they do recognize that problems are difficult to define and are open-ended, they assume a degree of control and governance that is impossible to achieve in many systems of systems. They are a useful checklist to remind architects of things to think about in the architectural design process. However, I think that the overhead involved in model management and the reductionist approach taken by frameworks limits their usefulness in SoS architectural design.
Systems of systems architecture
Course: Software Engineering (CSPC 111)
University: STI West Negros University
