Systems of Systems Lecture (9) PDF

Systems of Systems Lecture (9) Dania Mohamed Ahmed Introduction  Software engineering emerged in the 1960s to address the challenges of creating large and complex software systems, which often faced issues like high costs, delays, and unreliability. Despite significant adva...

Systems of Systems Lecture (9) Dania Mohamed Ahmed Introduction  Software engineering emerged in the 1960s to address the challenges of creating large and complex software systems, which often faced issues like high costs, delays, and unreliability. Despite significant advancements in techniques and technologies, project failures persist, especially in large-scale systems like government healthcare implementations.  The core issue remains the increasing complexity and size of systems, which current methods struggle to manage effectively. Today's software systems can be hundreds to thousands of times larger than those in the past, with predictions of systems containing billions of lines of code already becoming a reality. A key factor in managing this complexity is software reuse, allowing developers to integrate existing systems to create large-scale applications.  System of systems  A "system of systems" (SoS) is a collection of two or more independently managed components, distinguishing it from a single system. This sociotechnical perspective highlights that different parts of an SoS are governed by various management policies, which increases overall complexity. While even small systems that incorporate services from different providers qualify as SoS, significant challenges arise with larger constituent systems.  Much of the research in SoS has emerged from the defense sector, where previously independent military systems have been integrated for coordinated operations. The focus here, however, is on software systems, which are formed by integrating separate software applications. Currently, most software SoS involve a limited number of systems, but their complexity is expected to increase as more systems are integrated to leverage their combined capabilities. Examples of systems of systems (SoS)  Examples of systems of systems (SoS) of software systems include: 1. Cloud Management System: Manages local private cloud resources and public cloud servers (e.g., Amazon, Microsoft). 2. Online Banking System: Processes loan requests and connects to credit reference agencies to assess applicants' creditworthiness. 3. Emergency Information System: Integrates data from police, ambulance, fire, and coast guard services to coordinate responses to civil emergencies. 4. Digital Learning Environment (iLearn): Offers learning support by integrating various software systems like Microsoft Office 365, Moodle, and simulation tools, along with content such as newspaper archives. Essential characteristics of systems of systems  Maier identified five essential characteristics of systems of systems (SoS): 1. Operational Independence: Each element can function as a standalone system, evolving independently. 2. Managerial Independence: Different organizations manage the elements, leading to varied rules and policies for their management and evolution. 3. Evolutionary Development: SoS evolve over time rather than being developed as a single project. 4. Emergence: Unique characteristics of the SoS arise only after its creation, highlighting the significance of emergent properties. 5. Geographical Distribution: Elements are often spread across different locations, complicating communication and security management within the SoS. Essential characteristics of systems of systems  In addition to Maier's characteristics, two more are particularly relevant to systems of software systems: 1. Data Intensive: Software SoS typically manage vast amounts of data, often significantly exceeding the size of the constituent systems' code. 2. Heterogeneity: The various systems within a software SoS are likely developed using different programming languages and design methods, reflecting the rapid evolution of software technologies. Over a large SoS's 20-year lifespan, development tools and methods may change multiple times.  System complexity  The complexity inherent in software systems, particularly in systems of systems (SoS). It begins by outlining that all systems consist of parts (elements) and the relationships between these parts, which contribute to overall complexity. For example, in a program, parts may include objects, constants, variables, and methods, with relationships such as "calls," "inherits-from," and "part of."  A system’s complexity is determined by the number and types of these relationships. A simple system may have few relationships, while a more complex system can have many, despite having the same number of elements.  Additionally, relationships are categorized as either static or dynamic. Static relationships, such as "uses," can be analyzed through static models like UML, while dynamic relationships, like "calls," depend on runtime conditions, making them more complex to analyze since they rely on specific inputs and execution states. Simple and complex systems - System (a) is a relatively simple system with only a small number of relationships between its elements. - System (b), with the same number of elements, is a more complex system because it has many more element–element relationships.  Complexity of the processes  The complexity involved not only in software systems themselves but also in the processes for developing and maintaining them. As systems increase in size, their production and management processes become more complex, leading to challenges such as difficulty in understanding, coordination issues, and increased documentation requirements. These complexities often result in projects being delivered late and over budget, making large systems particularly vulnerable to cost and time overruns.  That complexity significantly impacts the understandability and adaptability of a system. Larger systems, with their numerous relationships between elements, are inherently more complex and harder to analyze. As complexity grows, the risk increases that changes in one area could negatively affect other parts of the system. Overall, managing complexity is crucial in software engineering to ensure successful project outcomes. Production and management processes Types of complexity relevant to sociotechnical systems  Three types of complexity relevant to sociotechnical systems: 1. Technical Complexity: This arises from the relationships among the system's various components. It encompasses how these components interact and depend on one another. 2. Managerial Complexity: This is related to the interactions between the system and its managers, including what managers can change within the system. It also involves the relationships among managers overseeing different parts of the system. 3. Governance Complexity: This complexity stems from the interplay of laws, regulations, and policies affecting the system, along with the decision-making processes within the organizations responsible for it. As different components may be governed by various legal frameworks across organizations or countries, this complexity can vary significantly across the system of systems (SoS).  Together, these complexities highlight the multifaceted challenges in managing sociotechnical systems. Governance complexity and managerial complexity  The distinguishes between governance complexity and managerial complexity in sociotechnical systems:  Managerial Complexity: This pertains to operational aspects—specifically, what can be done with the system. It focuses on the practical challenges that managers face in system management.  Governance Complexity: This relates to higher-level decision-making processes that impact the system, influenced by national and international laws and regulations. It involves strategic decisions that shape policies.  The example illustrates how a company's decision to permit employees to use personal mobile devices instead of company-issued laptops constitutes a governance decision that changes company policy. This decision increases managerial complexity, as managers need to ensure proper data security configurations for various devices. Additionally, technical complexity rises because the system must support multiple platforms—laptops, tablets, and phones—likely necessitating software modifications. This highlights how governance decisions can significantly affect both managerial and technical complexities within a system.  SoS characteristics and system complexity  The different SoS characteristics primarily contribute to different types of complexity: 1. Operational Independence: Different policies and rules governing constituent systems lead to governance complexity, while varied management approaches create managerial complexity. 2. Managerial Independence: Different management styles require coordination among systems, increasing managerial complexity. This may necessitate special software for consistent management, adding to technical complexity. 3. Evolutionary Development: The use of different technologies for various system parts increases technical complexity. 4. Emergence: As complexity increases, undesirable emergent properties may arise, leading to additional technical challenges as software must adapt to these properties.  SoS characteristics and system complexity 5. Geographical Distribution: This characteristic heightens all three types of complexity. Technical complexity increases due to the need for coordination of remote systems; managerial complexity rises as coordination among managers from different countries becomes more challenging; and governance complexity is affected by varying laws and regulations across jurisdictions. 6. Data-Intensive Systems: The complexity of relationships among data items increases technical complexity, especially when addressing data errors. Governance complexity may also rise due to different laws related to data usage. 7. Heterogeneity: The presence of diverse technologies complicates technical integration and compatibility, further increasing technical complexity ► Overall, these characteristics illustrate how SoS can lead to significant complexities across different dimensions. ► Large-scale systems of systems are exceedingly complex and cannot be comprehensively understood or analyzed as a whole. Due to the numerous interactions among their components and the dynamic nature of these interactions, traditional engineering approaches are often inadequate. The root cause of challenges in developing large software- intensive systems is complexity itself, rather than poor management or technical issues. SoS characteristics and system complexity SoS characteristic Technical Managerial Governance Complexity Complexity Complexity Operational independence X X Managerial independence X X Evolutionary development X Emergence X Geographical distribution X X X Data-intensive X X Heterogeneity X Systems of systems classification  Maier's classification scheme for systems of systems (SoS) categorizes them based on governance and management complexity: 1. Directed Systems:  Owned and developed by a single organization.  Integrate systems also controlled by that organization.  Features a central governing body that sets priorities and resolves disputes.  Have managerial complexity but no governance complexity.  Example: Military command-and-control system that consolidates information from various sources. 2. Collaborative Systems:  Lack a central authority to set management priorities or resolve disputes.  Owned and governed by different organizations that acknowledge the benefits of joint governance.  Typically have a voluntary governance body for decision-making.  Exhibit both managerial complexity and limited governance complexity.  Example: Integrated public transport information system linking various transport providers. Systems of systems classification 3. Virtual Systems:  Have no central governance, with participants potentially disagreeing on the system's overall purpose.  Systems can enter or exit the SoS, and interoperability is uncertain, depending on changing published interfaces.  Exhibit a high degree of both managerial and governance complexity.  Example: Automated high-speed trading system where different companies buy and sell stocks from each other in fractions of a second.  This classification helps to understand the varying complexities associated with different types of SoS.  Systems of systems classification  The author critiques Maier's classification of systems of systems (SoS), arguing that the names don’t accurately reflect their differences. 1. Collaborative Systems: This term is misleading because there’s always some collaboration in management. 2. Directed Systems: The name suggests strict top-down control, but governance is often based on mutual agreement within organizations. 3. Virtual Systems: While they lack formal collaboration mechanisms, participants usually find mutual benefits and informally work together. The term "virtual" can also be confusing, as it often refers to software implementations.  Overall, the author believes the terms fail to capture the complexities of these systems accurately.  SoS collaboration  The alternative terms for Maier’s types of systems of systems (SoS) and describes their collaboration: 1. Organizational Systems of Systems:  Governed and managed within the same organization, corresponding to Maier's "directed SoS."  Collaboration is managed by the organization, and the system may be geographically distributed, subject to different national laws.  In this case, the governance of Systems 1, 2, and 3 is centralized. 2. Federated Systems:  Governed by a voluntary participative body representing all system owners.  Owners of Systems 1, 2, and 3 collaborate through a single governance body, whose decisions are considered binding.  Individual management policies may vary due to national laws and cultural differences.  SoS collaboration 3. System of System Coalitions:  Lack formal governance mechanisms but involve informal collaboration among organizations to manage their systems collectively.  For example, if one system provides a data feed, its managers will communicate any changes to the data format.  Governance is absent at the organizational level, but informal collaboration exists at the management level.  The governance-based classification scheme helps identify the governance requirements for a system of systems (SoS). By classifying a system, you can assess whether the necessary governance structures are in place and determine if they are suitable. Establishing these structures involves a political process and can be time-consuming, so early understanding of governance issues is crucial. Sometimes, it may be necessary to shift the governance model to simplify the system, which can reduce complexity. SoS collaboration  Reductionism and complex systems  Definition: reductionism is the approach of analyzing complex systems by breaking them down into simpler components to understand their behavior.  Limitations in Complex Systems:  Emergent Properties: In complex systems, behaviors and properties often emerge that cannot be understood by examining components in isolation.  Interdependencies: Components in complex systems interact in non-linear ways, making it difficult to predict outcomes based solely on individual parts.  Challenges:  Oversimplification: Focusing only on parts can lead to overlooking critical interactions and relationships.  Dynamic Behavior: Complex systems often exhibit dynamic and adaptive behaviors that change over time, complicating reductionist analysis. Systems of systems engineering  Systems of systems engineering involves integrating existing systems to create new functionalities and capabilities, rather than designing them from a top-down approach. This process often arises when organizations see the potential for adding value through integration. For example, a city government might combine its traffic management system with national pollution monitoring systems to optimize traffic flow and reduce pollution in specific areas.  Challenges in software systems of systems (SoS) engineering mirror those faced in large-scale application system integration. Key issues include: 1. Limited control over functionality and performance. 2. Incompatible assumptions among system developers. 3. Varied evolution strategies and timelines. 4. Insufficient support from system owners during problem resolution.  Efforts in building software SoS primarily focus on addressing these challenges, which involves defining system architecture, developing compatible software interfaces, and ensuring resilience to unforeseen changes.  An SoS engineering process  Software systems of systems (SoS) are complex entities, and their development processes can vary based on system types, application domains, and organizational needs. Generally, five key activities are involved in SoS development: 1. Conceptual Design: Creating a high-level vision, defining requirements, and identifying constraints, informed by knowledge of existing systems. 2. System Selection: Choosing which existing systems to include, considering not only functionality and cost but also political and governance factors. 3. Architectural Design: Developing an overall architecture for the SoS, ensuring that the individual systems can work together effectively. 4. Interface Development: Creating compatible interfaces that allow different systems to interoperate, including potentially a unified user interface. 5. Integration and Deployment: Making the systems work together and implementing the SoS within the organizations involved. An SoS engineering process Interface Development in Systems of Systems (SoS)  In a SoS, constituent systems are often developed independently for specific purposes, resulting in tailored user interfaces and varying application programming interfaces (APIs). To enable interoperability, new software interfaces must be created to connect these systems.  Key aspects of interface development include: 1. Direct Communication: The goal is for systems to communicate automatically without user intervention. If a system offers a service-based interface, this can facilitate direct communication. 2. Reconciling Differences: Most systems have specialized APIs or rely on user interfaces for functionality access. Developing software that bridges these differences is essential, ideally through service-based interfaces that reflect existing functionalities. 3. Principal System Coordination: One system usually acts as a coordinating hub, managing interactions between constituent systems and directing service calls without each system needing to know others' specifics. Interface Development in Systems of Systems (SoS) 4. User Interface Challenges: Each system will likely have different user interfaces. While a unified UI can reduce user error and ease learning, its development can be costly and time-consuming. Factors influencing the feasibility of a unified UI include:  Interaction models (process-driven vs. user-controlled).  The mode of use (frequent interactions with one system vs. all systems).  The openness of the SoS to new systems or organizations.  Ultimately, budget and time constraints often limit the ability to create a unified user interface, making it one of the most resource-intensive aspects of SoS development. Systems with service interfaces  Integration and deployment  Integration and deployment are typically separate activities, where a system is built from components, tested, and then deployed. However, in a SoS context, many component systems may already be in use, complicating this traditional approach.  In SoS, integration and deployment should be viewed as a unified process. This means that existing deployed systems should be integrated first, allowing for the addition of new systems that enhance overall functionality.  A staged deployment process is often effective, illustrated by the example of the iLearn digital learning environment: Stage 1: Initial deployment includes authentication, basic learning features, and integration with school administration systems. Stage 2: Adds an integrated storage system and specialized tools for subject-specific learning, such as archives for history and simulations for science. Stage 3: Introduces user configuration features and the ability for users to add new systems, allowing customization for different age groups and learning needs. Release sequence For the iLearn SoS Challenging of testing SOS  Testing systems of systems (SoS) is a challenging and costly aspect of large systems engineering projects due to several factors: 1. Lack of Detailed Requirements: SoS often lacks comprehensive requirements specifications, as functionality is determined by the constituent systems rather than a centralized document. 2. Changing Constituent Systems: The systems involved may change during testing, leading to non-repeatable tests. 3. Problem Resolution Challenges: If issues arise, fixing them may require adding intermediate software instead of modifying the constituent systems directly.  To address these challenges, it's beneficial to adopt testing techniques from agile methods: 1. Stakeholder Engagement: Agile approaches do not rely on complete specifications. Instead, stakeholders participate actively in the testing process and decide when the system is acceptable for deployment. 2. Automated Testing: Utilizing automated tests allows for easier re-testing to identify issues caused by unexpected system changes.