No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
5.6.5 Advancing Systems Engineering for Systems‐Of‐Systems Challenges
Abstract
Engineering activities in future organization development, including various information-based systems, vary, but all result in evolutions of an organization, its capabilities and systems. These evolutions occur in a context of Systems-of-Systems (SoS) where the organization must maintain a sustained, sustainable, and controlled SoS evolution as a whole. This paper presents an understanding of SoS challenges to the application of Systems Engineering (SE) in organizational evolutionary development and discusses the difference between “developing a SoS” and “developing systems in a SoS context” from an SE management perspective. A new approach to SE process organization and management is presented in order to help an organization cope with the high complexity of SoS evolutions and improve its architecture practice. Philosophically different from many SoS SE studies that consider mainly how to develop a SoS, the new approach is to add a dimension or components of SE practice at the organization level that is aimed at creating a better engineering environment to enable effective applications of traditional SE practice in implementing SoS evolutions. © 2003 Wiley Periodicals, Inc. Syst Eng 6: 170–183, 2003
... In order to achieve the goals of digital preservation, repositories must "protect" digital objects against several threats that can affect their future interpretation. Actually, protecting digital objects against threats is equivalent to reduce the risk of those threats, which is the main goal of the broad area of Risk Management [10], which is also a challenge of System of Systems Engineering [18] [19], due to the system evolutions in the System of Systems context [20]. ...
... From a technical point of view, System of Systems Engineering raises several challenges, especially in the scope of interoperability, information technology and technical integration [20]. ...
... Actually, Enterprise Architecture can be seen as a methodology that may help in the engineering of solutions for System of Systems, dealing with the complexity of such kind of systems. In [20], the authors propose a combination of Enterprise Architecture initiatives with strategic planning, engineering the business and systems as a whole for an Enterprise Systems Engineering, to be able to deal with the complexity of System of Systems Engineering and respect strong non-functional requirements. As a consequence, there is a strong connection between System of Systems Engineering and Enterprise Architecture Frameworks. ...
Digital preservation aims at maintaining digital objects accessible over long periods of time, ensuring the authenticity and integrity of these digital objects. In this paper, we propose three different approaches to address the digital preservation problem. First, we survey the main requirements specific to the preservation arena. Next, we show how digital preservation can be approached as a specific case of System of Systems Engineering. Then, we introduce Enterprise Architecture as a framework which is regularly used to assist information systems design and maintenance, but can also be applied to System of Systems and consequently to digital preservation. Finally, in such complex environments, Risk Management is a key factor to assure the normal behavior of systems along time. Thus, we propose a Risk Management based approach to design and assess digital preservation environments, enclosing the definition of context and requirements, and the identification of threats and vulnerabilities, to be used as the basis of the definition of actions to deal with the risks associated with those threats and vulnerabilities. We generalize and survey the threats, vulnerabilities and techniques that can be applied in the scope of digital preservation.
... With a focus on education Lukasik [1998] describes an SoS as a self-organizing system assembled from multiple distributed individual systems, and assembly that has not been directly designed; instead it follows from the evolution of the integration of constituents. Chen and Clothier [2003] focuses on systems engineering practice, but attempts to improve and adapt traditional methods by focusing on the design of the environment in which the SoS constituents reside. Keating et al. [2003] provide a perspective in which an SoS is described as a metasystem of interrelated complex subsystems, constructed out of systems that integrate in order to reach a high goal, despite the individual parts being unlike in technology, geography and operation. ...
... Historical overview of publications defining SoS SoS as a defining factor in future battlefield scenarios 2.4Carlock et al. 2001 Enterprise Systems Engineering point of view 2.4Sage et al. 2001 Use of the strategy "new federalism" for organisational structuring 2.7Chen et al. 2003 Focus on the SoS environment with a core in architecture interoperability and dynamic behaviourBoardman et al. 2006 The alphabet characteristics: autonomy, belonging, connectivity, diversity and emerging An SoS may not be as much about the system mission, but about the architecture of the selected solutionDOD-SoS Engineering 2008SoS is an arrangement of independent and useful systems that integrate to delivers unique capabilities ...
The term 'System of Systems' (SoS) has been used since the 1950s to describe systems that are composed of independent constituent systems, which act jointly towards a common goal through the synergism between them. Examples of SoS arise in areas such as power grid technology, transport, production and military enterprises. SoS engineering is challenged by the independence, heterogeneity, evolution and emergence properties found in SoS. This paper focuses on the role of model-based techniques within the SoS engineering field. A review of existing attempts to define and classify SoS is used to identify several dimensions that characterise SoS applications. The SoS field is exemplified by a series of representative systems selected from the literature on SoS applications. Within the area of model-based techniques the survey specifically reviews the state of the art for SoS modelling, architectural description, simulation, verification and testing. Finally, the identified dimensions of SoS characteristics are used to identify research challenges and future research areas of model-based SoS Engineering.
... Depending on the system characteristics, systems can be classified as monolithic systems, complex adaptive systems, and systems of systems (SoS). A complex system is a whole consisting of many interacting subsystems that interact to make the system emerge with new functions that are not available in an individual subsystem [17,20,60]. Megaprojects, as complex systems, consist of multiple interacting hard and soft subsystems such as organization, technology, goals, resources, and products. ...
The increasing complexity of megaprojects has brought severe challenges to traditional theories and methods of project management. Traditional evaluation models fail to support managers in properly allocating scarce resources based on project complexity levels because of their inability to capture the relationships between indicators. Therefore, this study aims to develop a complexity evaluation model of megaprojects that integrates a two-dimensional indicator framework and the DEMATEL-ANP method, and test the feasibility and applicability of this model using the Shapingba Railway Hub Project (SRHP). The results indicate that resources, technology and products are controlled and managed by environment, organization, institution and goal subsystems of SRHP, the overall complexity level of SRHP is high, and environmental complexity affects the complexity of SRHP most significantly. Furthermore, the model proves feasible and applicable and can be applied to evaluate the complexity of other megaprojects with minor adjustments following systems thinking and practical conditions.
... Carlock and Fenton (Carlock and Fenton, 2001) suggested that the engineering of systems of systems should couple traditional systems engineering activities with enterprise activities of strategic planning and investment analysis, and be called "Enterprise Systems of Systems Engineering. " Chen and Clothier (Chen and Clothier, 2003) suggested considering the "organizational contexts" of systems-of-systems. Keating et al. (Keating et al., 2003) suggested system-of-systems research and practice should develop understanding, methodologies, processes, and techniques in four major areas: new system design, existing system transformation, operation and maintenance, and evaluation and evolution. ...
The growing complexity in the technological products and systems that we design, manage and operate may limit the future potential for component and architecture innovation. In the meantime, systems-of-systems are emerging. System-of-systems innovation may bypass the complexity within an existing system, and synthesize it with other systems and technologies to improve their utilities or derive novel functionalities from the new whole. Despite the increasing attention to systems-of-systems as ex post phenomena, the proactive pursuits for system-of-systems innovation opportunities remain unguided. In this article, we first elucidate the theoretical foundations, including expansionism, synthesis and complementarity, of system-of-systems innovations with various examples. We propose a methodology of using a technology map to aid in the search for technologies and the conception of new system-of-systems concepts. Further, we also discuss and prescribe a few actionable approaches and strategies to conquer the challenges in implementing new system of systems concepts and capture the potential values created from system-of-systems innovations.
... It must be realized that architecture interfaces for legacy systems are usually unavailable or not accessible in a satisfied and consistent manner. There may be a need for additional engineering efforts to construct architecture interfaces not only for legacy systems but also for those under development and to be developed [30]. ...
... This is often called System of Systems (SoS) Integration. In other countries, defence capability integration is being achieved through the application of systems engineering tailored to reflect the SoS context: there usually is no single owner of a SoS and independent, concurrent management and funding at both the constituent system level and at the SoS level is the norm (Maier, 1998;Chen and Clothier, 2003;Valerdi et al., 2008;OSD 2008;Lalancette et al., 2008;Camm & Fitchett, 2011;Anteroinen, 2012;Norman and Kuras, 2006). In order to achieve effective SoS integration it becomes necessary for key players to influence other parties (in particular independent project offices) on the basis of perspective, breadth of knowledge, and analysis rather than from a position of authority (Oxenham and Swales, 2010). ...
The Australian Defence Organisation is undergoing the most significant change in 40 years to deliver a more effective and agile defence force. One of the key changes is the introduction of a new capability life cycle that seeks to take a more holistic perspective on defence capability. This has included the introduction of Programs that are to be managed in a coordinated way to optimize capability outcomes across a group of Products and Projects. The paper opens by discussing the context in which Programs will be implemented and identifies the needs for their management and systems engineering. The needs analysis concluded that a system-of-systems engineering (SoSE) approach is needed and that this should be tested and refined using an initial test case. Building on recent review material of SoSE approaches, a modified wave model was selected for the test case as the preferred approach for Program SoSE. The paper concludes with a set of recommendations on how the initial test case should be implemented to provide a foundation for broader implementation across Programs.
... Consequently, local behaviours of parts of a CAS influence or inhibit the local behaviour from other parts, and conjointly few predictable (by traditional study methods) behaviour are generated. This CAS description is also supported currently by the concept of system of systems (SoS) in other literatures [e.g., systems engineering (Carlock and Fenton, 2001;Chen and Clothier, 2003)]. ...
The process of business-information technology strategic alignment (BITSA) has been consistently ranked as a top priority by chief information officers (CIOs) and extensively studied for over three decades. Constructs on the BITSA process, frameworks for understanding its main components, models for predicting its successful occurrence, and methods for guiding toward a successful BITSA process have been reported. However, the BITSA literature appears as contrasted and fragmented for researchers, and copious and ambiguous for CIOs. Thus, in this paper we conduct a selective yet intensive literature review on the BITSA process with the aim to provide a summary of core concepts, an evolution model, and an account of theoretical and practical implications. Through this literature review, a four-stage evolution model of BITSA emerges and an updated view of the BITSA process as a complex adaptive system is supported.
... Carlock and Fenton (Carlock and Fenton, 2001) suggested that the engineering of systems of systems should couple traditional systems engineering activities with enterprise activities of strategic planning and investment analysis, and be called "Enterprise Systems of Systems Engineering. " Chen and Clothier (Chen and Clothier, 2003) suggested considering the "organizational contexts" of systems-of-systems. Keating et al. (Keating et al., 2003) suggested system-of-systems research and practice should develop understanding, methodologies, processes, and techniques in four major areas: new system design, existing system transformation, operation and maintenance, and evaluation and evolution. ...
... Carlock and Fenton (Carlock and Fenton, 2001) suggested that the engineering of systems of systems should couple traditional systems engineering activities with enterprise activities of strategic planning and investment analysis, and be called "Enterprise Systems of Systems Engineering. " Chen and Clothier (Chen and Clothier, 2003) suggested considering the "organizational contexts" of systems-of-systems. Keating et al. (Keating et al., 2003) suggested system-of-systems research and practice should develop understanding, methodologies, processes, and techniques in four major areas: new system design, existing system transformation, operation and maintenance, and evaluation and evolution. ...
Facing the growing complexity within technological products and systems, traditional reductionism-based design approaches, which focus on decomposing and optimizing subsystems, components, and their interrelationships, will face greater difficulties in the search for future innovation. In such cases, expansionism-based design will be particularly effective because it reduces the need to deal with the superior internal complexity of existing systems and primarily explores design opportunities by integrating and synthesizing previously unrelated independent systems into a new system of systems. The system of systems that results from expansionism-based design may improve the functionalities and performances of the prior systems, or obtain novel functionalities of the system of systems from the synthesis. In this paper, we identify the system theory roots of design expansionism, and elaborate the value of expansionism-based design and how it enables design opportunities for systems-of-systems. We also preliminarily discuss potential concept generation methods to aid in expansionism-based design and the analytics of collective dynamics and emergent behaviors of the resulting system of systems in order to effectively architect and manage them.
... Maier (1996) assumes that systems of systems with similar complexity and extent should not be regarded as equivalent; and based on managerial control, he suggests three types of SoS: Directed, Collaborative and Virtual. Moreover, from system architecture point of view, Chen and Clothier (2003) classify SoS into two types: Dedicated and Virtual. Recently, Dahmann and Baldwin (2008) have introduced a new type of SoS, Acknowledged SoS, which is mostly growing in military context. ...
This chapter expresses three cognitive genres: descriptive genre, normative/prescriptive genre, and know-how genre. The descriptive genre introduces and discusses on the following disciplines: the core concepts of complexity, complex adaptive system (CAS) of systems (CASoS), the application domains of human-automation interaction (HAI) and adaptive autonomy (AA), especially in Smart Grid, and two implementation ideas of expert systems and Petri nets. The chapter describes the automation related notions, that is, automation and HAI, followed by the investigation of HAI models' evolution from the perspectives of dimensions and dynamism. The idea of AA is then introduced as a dynamic HAI scheme, followed by the classification of AA implementation methods. Petri nets are introduced as powerful tools for modeling complex systems (CxS). Finally, Petri net realization of the adaptive autonomy expert system (AAES) is presented, followed by a performance evaluation study.
... SoS requires new thinking in terms of acquisition methodologies. Chen and Clothier (2003) provided some evolution scenarios for SoS (joint evolution, emergent evolution, and self-evolution). Each scenario requires different engineering environments. ...
The problems stemming from increasing complexity, and its associated phenomena, continue to confound our capabilities to deal with systems. In response, many large organizations seek to integrate their existing systems (or external systems) to work together to accomplish capabilities or behaviors that cannot be achieved by the constituent (individual) systems. The integration and coordination of these systems is often referred to as a system of systems (SoS). While much has been written about SoS and their associated phenomena, we have not found sufficient exploration to answer some of our most basic questions: where did this concept came from? and when, or has, the peak of the SoS development movement been reached? To answer these questions, this paper has constructed a histogram analysis to trace the history of SoS from 1926-2011. Five hundred different sources have been included in the analysis in an attempt to give a glimpse into the development of the SoS field through the frequency of publications. Three main time period intervals have been identified to trace the history of SoS. The three primary objectives of the histogram analysis are to: 1) obtain quantitative information about the shape of distribution for the SoS developmental history as evidenced by publication frequency; 2) gain a better understanding about several related terms used to describe SoS; and 3) present the main contributions from the literature that have contributed most significantly to the body of SoS. This paper provides an invitation to consider the historical progress of the SoS field and the potential implications of this history for the future of the field.
... Kaplan [2005] pointed out that setting and coordinating mission and system requirements and resources across spheres of influence is a challenge in SoSs. Chen and Clothier [2003] concluded that handling SoS challenges requires managing systems engineering activities across projects and system domains. Toward this end of enhancing the SE discipline in the SoS preacquisition and acquisition phases, there are two possible approaches. ...
Acquisition of a system-of-systems can be an all new acquisition of multiple systems that are intended to operate together as a system-of-systems. Much more common in the U.S. Department of Defense (DoD) is acquisition of one or more new systems that are intended to interoperate with existing systems as a system of systems (SoS) with new capabilities. In either case, successful SoS acquisition necessarily depends on effective contracting structures and processes for SoS acquisition. In this paper, a set of issues that need to be addressed in SoS acquisition are identified, and the current findings discussed. The findings suggest maintaining an extensive systems engineering effort within the SoS acquisition and changes to the existing contracting processes, structures, and organizational structures to maximize the probability of SoS acquisition success. The resulting changes are recommended to current and future DoD SoS acquisitions. ©2012 Wiley Periodicals, Inc. Syst Eng 15
... Most, if not all, systems of systems engineering projects involve thousands or even hundreds of thousands of stakeholders, with different stakeholders having different levels of influence in the project [4]. As a result, in addition to identifying stakeholders, a crucial step in stakeholder analysis involves prioritizing stakeholders based on their influence in the project so as to focus efforts on highinfluence stakeholders while still being aware of lowinfluence ones. ...
In system of systems engineering, stakeholders are individuals, groups or organizations that stand to gain or lose from the success or failure of a system of systems. Systems of systems pose unique problems for stakeholder analysis due to their evolutionary nature, emergent behavior, operational independence, managerial independence, and geographical distribution of their constituent systems. This paper proposes the use of social networks and crowdsourcing to identify and prioritize the stakeholders for system of systems projects. The proposed method crowdsources the stakeholders to recommend other stakeholders, builds a social network of stakeholders, and prioritizes stakeholders using social network measures. The paper describes the method, and discusses the strengths and limitations of applying the method in system of systems projects.
... Their continued efforts are expressed (DoD, 2006) and reinforced in an updated version of the Systems Engineering Guide for Systems of Systems (DoD, 2008). In titling the updated version of the guide, the perspective suggesting SoSE as the extension of SE perspective is evident (Chen and Clothier, 2003). To capsule the military perspective, we provide some definitions associated with the military perspective of SoS and SoSE; ...
System of systems engineering (SoSE) is a field that remains in the embryonic stages of development. The work presented in this volume provides a methodological approach, grounded in foundations of systems theory, to perform SoSE. However, further development of the field must be predicated on understanding critical distinctions emerging and bring focus to the challenges and prospects for further development. The purpose of this paper is to develop a perspective of the state of the SoSE field and identify challenges for future evolution. To achieve this purpose, the paper is organised to explore four primary areas. First, the literature is reviewed to provide an account of the current state of the field. Second, an organising framework is presented to structure understanding of field development. Third, a set of challenges to forward movement of the field is offered. Fourth, the paper concludes with reflections on the SoSE methodology presented in this volume and implications for further development of the SoSE field.
... Context plays an important role in complex systems problems (Keating et al., 2003;Chen and Clothier, 2003;Ackoff, 1971;Maier, 1998;. We affirm that risk managers should understand the context in which the problems occur by 1 choosing the pertinent contextual issues that impact the decision making process in addressing human risk 2 selecting technique(s) appropriate to the problem domain and context. ...
Although there are various techniques such as cost-benefit analysis
that risk managers can use to place a monetary value on human life, these
techniques have met with only varying levels of success even when applied to
problems that have direct relationships among entities. Furthermore, these
techniques have not enjoyed even this level of success when applied to
problems that have ambiguous, uncertain and dynamic relationships among the
entities. This paper proposes a three-phased framework that will attempt to
guide decision makers beyond traditional thinking toward a more systemic
(holistic) perspective to addressing human risk. The correct implementation of
this emerging framework can help risk managers to: 1) better understand the
nature of complex systems problems; 2) gain additional knowledge with which
to assess human risks; 3) shift away from the traditional way of thinking and
toward applying a holistic perspective based on systems theory in conjunction
with systems thinking.
... For instance, Chen and Clothier [9] point out that the high-level engineering complexity (as discussed further by [32,7]) raise great challenges in evolutionary development of SoS and indicates a need for considering different SE strategies at a level above individual projects. ...
In this position paper (1) we discuss two particular aspects of Systems of
Systems, i.e., variability and evolution. (2) We argue that concepts from
Product Line Engineering and Software Evolution are relevant to Systems of
Systems Engineering. (3) Conversely, concepts from Systems of Systems
Engineering can be helpful in Product Line Engineering and Software Evolution.
Hence, we argue that an exchange of concepts between the disciplines would be
beneficial.
... Beginning with Maier's work on architecting SoS [4] which continues to be foundational after more than a decade, this literature reflects a continued interest in definitions of SoS and SoS characteristics. Key articles include Maier's taxonomy of SoS [4], Sauser and Boardman's "Systems of Systems -The Meaning of It [5] and others [6,7]. Literature has focused on SoS level considerations in policy and on management of SoS [8,9,10], in approaches to analysis and architecting of SoS [11], and in the form and handling of SoS in sectors beyond defense [12]. ...
Over the past ten years there has been a steady growth in attention to issues related to systems of systems (SoS) and systems engineering, particularly in Defense in the United States. This attention has focused on how to apply SE principles and practices to SoS, considering the differences between systems and SoS. For many organizations, however, despite recognition of SoS considerations, the focus of investment and development continues to be on individual systems. This paper looks at SoS and SE from the perspective of constituent systems and examines impacts on systems engineering of systems in light of the increased prevalence of SoS. The paper addresses these issues based on the experience and viewpoint of the U.S. Department of Defense and identifies areas for further attention in systems engineering research and practice.
... The first path engages SOSE from a technically dominated perspective (e.g. interoperability, information technology, net-centricity, technical integration) (Chen and Clothier, 2003). The primary focus is on SOSE as producing an 'integrated product'. ...
In this paper, we present System of Systems Engineering (SOSE) as a developing multidiscipline, spanning across and drawing from a variety of disciplines to address complex situations; situations are characterised by ambiguity, high uncertainty and emergence. This paper is organised to: (1) provide an assessment of the current state of SOSE field development, (2) suggest the nature of complex issues for which traditional approaches are falling short to include the corresponding challenges facing SOSE development, (3) describe two perspectives of the SOSE response to complex situations and (4) establish an emerging paradigm for SOSE as a multidiscipline based on current research. This paper concludes with the implications for further development of research and practice for SOSE.
... New needs cannot be supported without cooperative efforts of multiple systems [2]. Alternatively, a system of systems (SOS) may be created to address the challenges which the traditional SE has to face [3][4][5][6][7][8][9]. ...
The definition, characteristics, classifications, development are summarized first in this paper. Then, compare system with system of systems (SOS) is followed with the problems during the development of SOS. From what is discussed above, the basic knowledge of SOS can be derived. Further, we can safely come to the conclusion that SOS can more effectively meet the challenge of complex giant systems. At last, applying SOS, current support systems are considered.
In response to the increasing complexity of aviation equipment systems, the increasing urgency of the equipment pre-research process and the urgent need for rapid iterative optimization during the aircraft development process, this paper proposed a kind of model-based process for aviation equipment requirement demonstration. Starting from the operational concept, the requirement demonstration process for aircraft equipment is established from system of system layer to equipment layer, then to system layer, then to subsystem layer by modelling and simulation based on MBSE theory. The methods for each layer are proposed to support the agile requirement generation of aviation equipment from mission and task requirements to performance indicators. Through concept confirmation, logic verification and principle verification, the forward design of aircraft equipment complex system is practiced. Finally, this paper verifies the rationality of this method through a case, so as to provide a reference of requirement demonstration for aviation equipment in other scenarios.
Developing large-scale complex information systems, such as the Smart Court system-of-systems (SoSs) of China, is a worldwide engineering challenge. This paper, from a methodological perspective, aims to expound the theoretical construction and practical progress of Smart Court system-of-systems engineering (SoSE) of China. The concept and key task requirements of SoSE are explored, technical difficulties faced by the Smart Court SoSE are analyzed, and a “two-track parallel, six-ring linkage” pattern framework is proposed for the progressive collaboration SoSE of large-scale autonomous information systems. Based on the theories including a universal information model, information metric system, and dynamic configurations of information systems, a key evaluation indicator system for an information SoSs is proposed. To satisfy the SoSE design requirements, an overall design method based on information relationships and its enabling tool are proposed, and a reference model of the Smart Court SoSs is designed to provide a top-level reference for the system development and integration of the Smart Court. Moreover, the development and collaborative integration of the autonomous and backbone systems in the Smart Court SoSE are presented in a comprehensive manner. The nationwide application and promotion of the Smart Court SoSs support the upgrade and transformation of the conventional judicial operation pattern of people's courts in China. Through continuous analyses of the quality and effectiveness of the Smart Court based on the key evaluation indicators, targeted improvement can be conducted to further enhance the SoSs capabilities, thereby contributing to the progress of judicial civilization in the information age.
For the last four decades, the alignment of strategy and digital technology has persisted as one of the most critical and bothersome issues for senior government executives. Against this backdrop and drawing on the fruits of an extended program of collaborative research between 1995 and 2020, this chapter draws attention to how government organizations foster effective alignment and how this is achieved through four distinct cycles of alignment work. Considering that this work is heavily people-and organization-centric, the chapter calls for greater involvement of organization development and change scholars and practitioners in this important area of organizational life and work.
The Australian Department of Defence is actively pursuing initiatives to improve the integration and interoperability of the defence force and this paper reports on research findings produced in support of this effort. The paper opens with a description of the Australian Defence capability development context together with recent initiatives to provide greater military capability for the available budget. Within this context, the problem the researchers set out to address is how best to co‐ordinate the ongoing force Integration and Interoperability (I2) activities that evolve and deliver defence capabilities so that these capabilities can be integrated together at short notice and deployed. System of Systems Engineering (SoSE) approaches have been found to be effective for this class of problem and the paper provides a short review of the most promising candidates. The methodology needs analysis that follows concludes that a range of different SoS approaches will be needed to cover the different stages of the capability lifecycle and the paper then proceeds to describe an initial framework that provides a new way of looking at the defence Integrated Capability Realisation (ICR) SoSE challenge across two dimensions. The first dimension is the time horizon of the planned capability increment: from the present to around four years; four to eight years; eight to twelve years; and longer than twelve years. The second dimension covers the types of activities that are traditionally performed to evolve defence forces such as future force planning, program co‐ordination and planning, project capability definition, acquisition, and force generation. The paper describes how this framework provides a simple method to identify which SoSE approaches are the most applicable to given ICR subtasks and also proposes an overall approach to self‐organise overall Defence ICR efforts
The concept of technological ecosystems has been increasingly applied across different domains but rarely in the area of capability development. This paper contributes to addressing this knowledge gap by demonstrating the potential value of applying the technological ecosystems perspective to support technology investment decisions. We present a practical step‐by‐step approach to show how this approach can be used in practice and illustrate it using two case studies in the military domain. Case A looks at emerging technologies in health support; and Case B is concerned with driverless vehicles in dangerous environments. In both instances, the concepts are developed via facilitated workshops and the technological ecosystem maps are derived by analyzing the enabling technological elements and the relationships between them. Subsequent analysis shows how the technological ecosystem framing assists in gaining a holistic picture of the potential impacts of technology adoption and how it can be used to reframe capability options in terms of technology groupings. Technological ecosystem analysis across the two cases is used to identify common capability enablers and multidomain capability enhancing elements. We discuss the types of components within the generated technological ecosystem maps and point to directions for future work enabled by technological ecosystem mapping in capability development.
A historical classification shall provide a better understanding and explain the fundamentals of modern complexity management. Thinking about the phenomenon of complexity and dealing with this challenge can be traced back to ancient Greece. From the seventeenth century on, exceptional mathematicians like Isaac Newton and in the nineteenth century philosophers like Emanuel Kant were dealing with complexity and changed the view of the world. And scientific and methodical knowledge about modern complexity management has been aggregated over a time span of approximately 70 years. Significant challenges like those presented by the Second World War, the Cold War and the beginning of astronautics acted as catalysts for developments on complexity management. Thus, complexity management is not an invention made at the end of the twentieth century. It is based on long-term developments originating from different disciplines. This chapter will give a deeper insight into the historical development.
Simulation based training means using simulated environment to create training lessons, more focused towards interactive learning by simulating real world scenarios. Simulation based training has been used extensively in the field of aviation for many years. Flight simulator as a product is quite complex and all the lifecycle phases such as requirements, analysis, design, development, integration, verification and validation are not very well interconnected or centralized, which adds to complexity in producing an artefact in a complex system of systems environment. Moreover, the lack of integrated method for ensuring the traceability of requirements and customization, acquisition of knowledge and data, integration and changes in hardware, and the design and testing of software creates massive challenges for simulation companies developing system of systems products. The current paper provides insights into such challenges that typically exist in the Flight Simulation industry. Methods and techniques inspired from the Knowledge Based Engineering (KBE) and Model Based Systems Engineering (MBSE) aspects of Systems Engineering are proposed to evolve existing Systems Engineering practices for more efficient Requirements Management, Interface & Change propagation management and Hardware and Software integration solutions. Towards the end, results of an industry-wide survey have been summarized, which was initiated to gather feedback from industry experts on various systems engineering practices challenges.
Complexity, tremendous and interactivity are main characters of system of systems (SoSs). A requirement analysis of SoSs faces some questions, such as great uncertainties and huge space of solutions. The heuristic algorithm could settle some NP-hard problems, but efficiency of heuristic algorithm is lower when the complexity of the problem becomes higher. Capabilities solutions of SoSs have their own traits. Each heuristic algorithm is expert in computing different kinds of capabilities solution. This article proposes an algorithm based on intelligent agent by choosing a 3-dimension probabilities matrix. Using the self-learning of agent, the method stores the history experience which is applied to solve such kind of SoSs requirement solutions. The history experience of Agents could be stored in the 3-dimension matrix. When dealing with huge complex SoSs requirement solutions, the Agent can choose the most efficient algorithm to solve the proper problem. This is illustrated with a case study of military SoSs, and the result shows greatly robust and efficient advantages under this context.
The current paper summarizes the Capability Engineering Process (CEP) being developed to help decision making on strategic investments and divestments for the Canadian Forces and Department of National Defence. This effort is part of a technology demonstration effort called the Collaborative, Capability, Definition, Engineering and Management (CapDEM). The CEP introduces ways to increase strategic agility capability management in a world in constant evolution. A CEP application provides a set of options addressing a given capability gap. Among benefits, this process: (1) provides decision makers with timely strategic information through an iterative and incremental approach; (2) reduces time spent on unrealistic options by continuously pruning the solution space as early as possible; (3) provides operationally acceptable strategic options with direct involvement of the operational community into the solution development; and (4) provides feasible options by ensuring commitment and participation in developing solutions involving all of the organization's functional components: Personnel, R&D, Infrastructure, Concept development, Information management, and Equipment (known as PRICIE components in Canada).
Some managerial and technical problems related to the transition of the Canadian military acquisition from the Threat-Based Planning to the Capability-Based Planning are identified in this paper. A simplified example of military acquisition illustrates recommendations that were made in the Collaborative Capability Definition Engineering and Management (CapDEM) project to guide the work surrounding the conception of a new Capability Engineering Process. Some elements of solution for the support of such a process are also presented.
Traditional systems engineering (SE) is performed on a development project with only one or a few related systems being developed. Enterprise SE, on the other hand, must deal with deciding among many enterprise opportunities that the enterprise projects will work on. This entails several processes that are not provided for in traditional SE practice. An Enterprise SE Framework was developed to characterize the full scope of SE at the enterprise level.1 This framework was used to evaluate several case studies as part of my doctoral dissertation. This evaluation focused on how they used knowledge modeling techniques identified in my dissertation for development of an enterprise architecture.2
This paper describes how combining certain aspects of systems re-engineering with intelligence analysis creates a hybrid methodology resulting in a major transformation of the intelligence analysis discipline. The world and technology have changed over the years and now actionable intelligence must be provided in a collaborative environment prior to and during crises. Analysis of today's intelligence complexities demands a move away from analytic thinking to systems thinking. By introducing the concept of a “system” into the process of intelligence analysis, analysts are empowered to create and use systems models. These system models comprise all of the systems necessary for world-class intelligence analysis – to include systems-of-systems of target, customer, and analyst. To the degree that these models are sufficiently accurate, the analyst can apply logic and judgment to produce projections of the future. Therefore, a continuing close customer-analyst collaborative relationship enables professional determination of the most likely consequences of alternative customer operations.
Systems-of-Systems (SoS) engineering for modern complex systems is one of the most difficult challenges facing today's engineer. This paper provides a detailed case study of architecting for a major modern SoS: the US Ballistic Missile Defense System (BMDS). The BMDS is a massive SoS that encompasses several existing and new missile defense programs on a variety of platforms covering most of the world. This paper includes a review of currently defined practices for architecting SoS, a discussion of how the BMDS was architected, and then suggestions for architecting future additions to the program.
The Predator‐Prey ecosystem of the African savannahs provides a real‐world abstraction of network centric warfare (NCW). Prides of vultures scan the skies looking for dead or dying prey while packs of hyenas and lions fight it out on the ground to either track and kill their next meal or steal downed prey from their natural adversaries. Constantly observing and spying on each other, these incessant adversaries are always seeking a competitive advantage.
When one of the circling vultures sights either downed prey or possible scraps from a ground‐based struggle, it signals others to descend. By doing so, they inadvertently share their intelligence with other predators on the ground. Based on distance to the prey, number of other predators in the area, and ratio of adversaries to allies, the race to the kill‐site is swift and the outcome means the difference between survival to fight again and starvation.
Starting with the assumption that the Predator‐Prey ecosystem of the African savannah would be a real‐world abstraction of NCW, a study of the interactions between three representative species (lions, hyenas, and vultures) was initiated. Behavior, especially in regard to interactions with other species, pride or pack size, average ground or air speed, and territory size were investigated. During the investigation, it became clear that the interactions between the species could be clearly viewed as an analogy to a set of mobile combatants seeking to overthrow their adversaries; in this case the goal is food (i.e., survival) rather than social power, money, or property.
A portion of this work analyzes the behavioral characteristics of each species much like war fighters dissect the capabilities of their adversaries. These species‐based parameters were used to analyze how different distributions of prey, in relation to predator territories, influence which predator species gets to the prey first in sufficient numbers to get the majority of the food. The analysis was performed using a simple Monte Carlo discrete event simulation model and considered the nominal, aggregated behavior of each pack or pride as a single unit, not the behavior of individual pack members. Using these aggregated characteristics of speed and the ability to sense downed prey at a distance, a clear parallel could be drawn to the groups of armed forces in war zones relative to available surveillance and tracking systems. Albeit, the struggle in the African savannah is an on‐going, zero‐sum war game.
Significant changes in the nature of military systems and the military environment require improvements of the current military systems acquisition process. The Capability Engineering Process (CEP), to be delivered through the CapDEM project, aims at improving military capabilities acquisition in the Department of National Defence and the Canadian Forces (DND/CF). However, opportunities to improve capability acquisition are too numerous to implement all of them within the CEP. This paper presents a structured approach to better orient the development of a CEP.© 2005 by F. Bernier, M. Mokhtari, M. Couture, M. Lizotte, F. Lemieux, S. Lam, C. Lalancette and G. Dussault. Published and used by INCOSE with permission.
This paper discusses the use of the system-of-systems (SoS) methodology and SoS engineering (SoSE) to the challenge of the design and operation of a CubeSat-class spacecraft. It considers this in the context of one critical component system, the electrical power system (EPS) which interacts with virtually all other systems onboard the spacecraft. The spacecraft is also considered in the context of being a system-component of a larger mission system-of-systems. The efficacy of SoSE use for this endeavor is considered and recommendations are made for the use of SoS and SoSE by other small spacecraft and, more broadly, spacecraft developers.
Acquisition of a system of systems can be an all new acquisition of multiple systems that are intended to operate together as a system-of-systems. Much more common in the DoD is acquisition of one or more new systems that are intended to interoperate with existing systems as a system of systems with new capabilities. In either case, successful acquisition of systems-of-systems (SoS) necessarily depends on effective contracting structures and processes for systems-of-systems acquisition. In this paper, a set of system-of-systems issues that need to be addressed in SoS acquisition are identified and the current findings in this on-going research are discussed. The findings suggest sustainment of extensive systems engineering effort within the SoS acquisition and change to the existing contracting structures and process and organizational structures to maximize the probability of SoS acquisition success. The resulting changes will be applied to current and future DoD SoS acquisitions.
Composability focuses on combining heterogeneous independent simulation systems into one larger simulation system. This chapter covers some key concepts used to successfully combine simulations into an System of Systems (SoS) simulation. It provides motivation for the remainder of the chapter by reviewing Maier's attributes of an SoS and the implication of these attributes on the work of the simulation engineers supporting the development of an SoS. The chapter clearly defines composability and contrasts it with similar concepts such as interoperability and integratability. It introduces the Levels of Conceptual Interoperability Model (LCIM). LCIM provides a common lens to view composability as well as a metric for quantifying the success of composability efforts. The chapter further explores some of the areas of current research, including recent work on ontologies and semantic modeling as well as agent-based simulation.
The INCOSE SoS Working Group (SoSWG) identified the need to understand the SoS issues of importance to the systems engineering community as an initial SoSWG activity at their meeting in January 2012 in Jacksonville, Florida. The results of the survey and follow-up interaction with SoSWG members, identified seven areas of challenge or SoS Pain Points. This paper summarizes the survey and working group feedback and describes the pain points along with the questions they pose for the systems engineering community. The work described in this paper is the product of the INCOSE Systems of Systems Working Group, and acknowledges the contributions of working group members, including Alan Harding, Scott Workinger, Kelly Griendling, Eric Honour, Claire Ingram, Michael Henshaw, Bryan Herdlick, and others who responded to the survey and participated in the formulation and discussions of these SoS pain points.
This paper highlights the use of active learning in a capstone engineering design track to create a distributed learning environment where students apply their knowledge of Systems Engineering fundamentals to complete a design project for a real-world customer. An organizational structure consisting of students at Missouri University of Science and Technology and distance education students across the country was developed for the use in two courses, mirroring current industry practices. Six student design teams were formed at the beginning of the first course; with each team assigned a graduate student facilitator, a faculty mentor, and a professional practitioner acting as an industry mentor to provide additional guidance, structure, and support. The capstone project was to implement systems engineering fundamentals and principles to design, specify, and construct a wireless vest for the use in immersive training, satisfying a documented need statement provided by United States of America"s Department of Defense representatives. This paper highlights the implementation of this pedagogy within a distance education environment. Further, this paper highlights the development and use of this new pedagogy and elaborates on the details of the implementation. The paper provides a thorough synopsis of the courses" structure, an elaboration on shortcomings, a discussion of survey results provided as student feedback, and a description of the students" perception of learning.
Single systems and systems of systems, alike, demand management approaches focused on performance; but system of systems management can only responsibly address performance if it accounts for characteristics such as the presence of distinct subsystems pursuing possibly disparate purposes, a characteristic by definition of no concern to single system management. By extension then, with to manage in many ways to measure, systems of systems demand performance measurement schemes that accommodate the traits that set them apart from individual systems. Enterprise AID represents a means for measuring and hence managing the current or future performance of systems of systems. Enterprise AID - or simply AID, for assessment, improvement, and design - is a methodology for the design and use of performance measurement systems able to uniformly address problems encountered with extant or envisioned, single system or system of systems type enterprises. This paper describes advantages held by the AID methodology for system of systems performance measurement, and it does so within a context set by appropriate definitions, selected methodology elements, and an application example focused on the selected elements. This paper concludes with a recognition of performance related issues attendant to system of systems improvement or design.
Overall performance of a peer-to-peer system can be highly variable and unpredictable as there is no central authority to set and coordinate the amount of resource contributions made by constituent peers. In this paper, we address the problem of optimal cooperation policy setting for individual peers by taking into account their rationality, and with respect to a set of overall constraints imposed by resource-driven requirements of the system. We formalize distributed cooperation policy setting as an asynchronous distributed decision making (ADDM) process and represent an integrated design for this process in two top-down and bottom-up phases. In top-down design, we specify the overall objective and constraints and in line with them, we synthesize the local objectives of individual peers. We show that the rational peers should continuously adapt their cooperation policies asynchronously and autonomously according to the policies of the other participants in order to maximize their local objectives. To this end, we devise a self-organizing interaction mechanism in the bottom-up phase and demonstrate that it coordinates asynchronous distributed decisions of individual peers with respect to the overall objective and constraints through local interactions. ©2012 Wiley Periodicals, Inc. Syst Eng 16
According to the design requirements of complex system-of-systems, an agent based Evolutionary System-of-Systems Integration Realization environment is presented. Based on some industry standards such as XML, SOAP and WSDL, this environment is designed with peer- to-peer communication between different agents, characterized with standardization of the interfaces, flexibility of the architecture and compatibility with other standard web services frameworks. Such an adaptable framework can effectively support the distributed collaborative design and hence promote the evolutionary integration of complex system-of-systems.
Purpose
– The purpose of this paper is to draw a metaphorical parallel between a pilot in the cockpit of the latest, ultra‐modern US fighter F22 and that of a chief executive officer (CEO) managing his corporation in responding to global competitive challenges.
Design/methodology/approach
– This paper is inspired by the embedded, “system of systems (SoS) thinking” in the text of the very ancient Chinese Art of War by Sun Tzu. The approach here is to illustrate how such a 2,500‐year‐old thinking may be applied through the emerging discipline of SoS. For designing a CEO‐responsive, informative system, the innovations in designing the cockpit for a pilot in the latest US fighter jet, F22, is utilized.
Findings
– Today's corporate world management has, in the past, drawn heavily from the military (for example, operations research). Whilst there is a vast difference between the pilot's cockpit in an F22 and the lap‐top of the CEO, the need for deadly accurate, often reflexive decisions is the same. It is becoming a fact of business life that speed of deadly accurate responses is necessary to ensure the survival of corporations, especially for firms operating in rapidly changing technologies, or top executives who have to cope effectively with informatively intensive yet fast changing environments, such as in the financial markets.
Originality/value
– This paper illustrates how it is still possible for managers to draw inspirations in designing corporate systems through examples taken from the military. Sun Tzu drew inspirations on organizing for flexibility by observing and thus grasping the essential nature of water. Similarly, it may be useful to draw parallels in innovative design of an F22 pilot's cockpit for the CEO or managers having to make fast yet deadly responses.
Performance of systems engineering tasks requires appropriate skills and methods often surmised from marketing and advertisement pieces. What is the correlation between the 'required' skill set and the individual's experience? We observe that skills seem to vest with time and that the systems engineer likewise becomes more proficient in those traits that improve project performance. Can these proficiencies be tied to time or years of experience? We apply a time-based exponential learning curve to data collected from three sources: classified job advertisements, surveys of practicing systems engineers, and pertinent literature. From a triangulation methodology we investigate the relationship between the number of years of experience and the breadth and depth of knowledge expected in the workplace. We then relate the contribution to work made by systems engineers to the number of their years of their experience. For the processes of requirement's analysis and project management skills, systems engineers with 15 years of experience are twice as effective as those with 10 years of experience (with a 3.6 year error).
The C4ISR Architecture Framework document issued by the Department of Defense specifies three views of an information architecture and defines a set of products that describe each view. These architecture views are to serve as the basis for C4ISR system development and acquisition. The Framework does not provide a process for architecture design. In this paper, information architectures are described in the context of Structured Analysis, and then the architecture views of the Framework and the related products are interpreted in that context. A methodology for architecture design is developed that is then implemented using Structured Analysis and object orientation in two companion papers. © 2000 John Wiley & Sons, Inc. Syst Eng 3: 225–247, 2000
While there is growing recognition of the importance of “Systems-of-systems,” there is little agreement on just what they are or on by what principles they should be constructed. This paper proposes a taxonomy of these super-systems and exhibits a basic set of architecting principles to assist in their design. While several heuristics are particularly applicable to systems-of-systems, the key insight is the central role played by communication standards. The enabling architecture of systems-of-systems is non-physical, it is set of standards that allow meaningful communication among the components. This is illustrated through existing and proposed systems.
True systems-of-systems are one of the toughest challenges for system engineers. They face the problem to balance complexity of design and project structure against the product's cost during its lifecycle. The main cost driver is undesired redundancy in the product and/or the development process. Here we present a method that enables system engineers to shape the architecture of the system to the needs of the users and the development organisation. First we will give our definition of a system-of-systems, show why they are so important, and what makes them so demanding for the system engineer. After a look at the conventional way to solve the complexity problem and a discussion of its disadvantages we will present our method. We will give an impression how we derived it, and of the variants in applying it.
In this paper we examine the term “Systems of Systems” (SoS) and form a distinction between them and large monolithic systems based on system attributes and acquisition approaches. Importantly, for this paper, one of the distinguishing attributes is that SoS are formed from component systems that are acquired using multiple asynchronous projects. We raise the issue that the current stovepiped, project-centric, prescriptive acquisition paradigm is not well suited to the acquisition of component systems for military systems of systems. The paper proceeds to identify more detailed issues that need to be addressed to improve acquisition outcomes and provides some mitigation strategies. The major recommendations are to increase the influence of top-down, force-structure planning, move away from project-centric capability development and acquisition to broad, force-area development, and to raise the importance of systems characteristics that will enhance their ability to be integrated into systems of systems, such as, adaptability, flexibility, and open interfaces.
The challenge of Systems of Systems has particular significance in the acquisition, deployment and operation of defence equipment. In the UK, MOD sees that a major part of the solution to the effective creation, use and evolution of defence SoS lies in particular improvements in organisational structure, in project responsibilities and in the definition and application of systems engineering processes. These three areas of change are providing a framework for tackling SoS issues. MOD's Smart Acquisition initiative is leading to management structures and responsibilities, at the executive and project levels, and to technical processes that more effectively meet the SoS challenges.
While the phrase “system-of-systems” is commonly seen, there is less agreement on what they are, how they may be distinguished from “conventional” systems, or how their development differs from other systems. This paper proposes a definition, a limited taxonomy, and a basic set of architecting principles to assist in their design. As it turns out, the term system-of-systems is infelicitous for the taxonomic grouping. The grouping might be better termed “collaborative systems.” The paper also discusses the value of recognizing the classification in system design, and some of the problems induced by misclassification. One consequence of the classification is the identification of principal structuring heuristics for system-of-systems. Another is an understanding that, in most cases, the architecture of a system-of-systems is communications. The architecture is nonphysical, it is the set of standards that allow meaningful communication among the components. This is illustrated through existing and proposed systems. © 1999 John Wiley & Sons, Inc. Syst Eng 1: 267–284, 1998
This book provides a basic, conceptual level description of engineering management disciplines that relate to the development and life cycle management of a system. For the non-engineer it provides an overview of how a system is developed. For the engineer and project manager it provides a basic framework for planning and assessing system development.
This paper is concerned with the engineering of systems that are themselves comprised of other component systems, and where each of the component systems serves organizational and human purposes.ï¾ ï¾ These component purposes may be locally managed and optimized independently, or nearly so, of the objectives to be met by the composite system.ï¾ ï¾ There are a number of inherent characteristics of these systems, and such related terms as systems of systems (SOS) or federations of systems (FOS) or federated systems of systems (F-SOS) are often used to characterize them.ï¾ ï¾ It is asserted that the resultant systems generally possess the characteristics of complex adaptive systems.ï¾ ï¾ We provide an overview of the literature describing these engineering efforts and provide plausible strategies for systems engineering and management of SOS and FOS that are based on the principles of a 'new federalism'.ï¾ ï¾ Finally, the implications of these plausible SOS and FOS systems engineering and management concepts are discussed with emphasis on evolutionary acquisition in the style of DoD and Intelligence Community related programs.
This article describes the emerging roles of the systems engineering (SE) function in supporting enterprise management in information-intensive organizations. “Enterprise Systems Engineering” (ESE) comprises three major roles or “levels” of systems engineering for successful and efficient development or procurement of large complex systems of systems (SoS). While the authors' experience focuses predominantly on government organizations acting as their own SoS integrators, the SoS ESE concept has generic applicability for any organization, public or private, seeking to attain competitive advantage through leveraging of information technology resources and systems. The processes and tools described here have been developed and successfully employed to facilitate government project management and investment decisions and control. [Carlock and Decker, 1998] This paper describes a formal three-level SoS ESE process that, at the top level, organizes and maintains all of the details of the enterprise-wide SoS architecture and strategic development plan in a flexible framework that accommodates the changes expected over a long SoS evolution. The information maintained in this framework allows the organization to know where it is going, how and when it is going to get there, the required capabilities and interfaces of each SoS component, and the impact of changes to system requirements, budgets, schedules, etc., on the overall SoS. The middle level processes allow the organization to perform trade studies among alternative solutions to implement required capabilities based on what is best for the enterprise-wide SoS rather than just local considerations. The end result of the middle level processes is a selected and approved solution and its associated cost, schedule, benefits, and technical baselines. The third level processes implement the approved solutions in accordance with the approved baselines. © 2001 John Wiley & Sons, Inc. Syst Eng 4: 242–261, 2001
The evolution of system-of-systems (SOS) is an emerging challenge and requires systematic architecture capabilities and support. This paper discusses the features of SOS evolution and introduces a key concept, Architecture Evolution Environment, to facilitate the evolution. We argue that an architecture solution for specific evolution requirements can be reached only when its evolution environment is addressed.
The main deliverable of Phase One of the Architecture Practice Study task is a technical report consisting of two parts. The first part is represented by this report, whereas the second part discusses specifically the requirements of IT development capability for the Australian Defence Organisation (ADO) and how the architecture practice introduced in the first part can support improvement of this capability. This report captures research findings concerning the concept of architecture in IT, and its roles in large organisations. These roles of architecture include providing a sound foundation on which quality information-intensive systems are developed or evolved, capturing the necessary architectural descriptions to facilitate understanding about these systems, and guiding the development of enterprise infrastructure to support the creation of such descriptions. This report concludes that large organisations, including the Australian Defence organisation (ADO), must commit themselves to establishing and managing architecture as an inseparable practice embedded within their overall ITmanagement and practice. Such recommendation, once implemented, will ensure that the identified roles of architecture are performed, sustained and continually improved. The report highlights significant problems, more or less, common to current IT practice in large organisations. These include the high cost of acquiring and maintaining software (US DoD spends an estimated amount of US 19.8 Billion is spent on software maintenance activities), the longer time to acquire and maintain software, inconsistent quality characteristics of acquired software (quality characteristics mean different things to different people in large organisations), and high turnover of IT professionals. The possible causes of these problems have been traced and analysed. The analysis discovered that IT practices in large organisations have disintegrated and immature capabilities preventing the effective generation, representation, preservation and retrieval of architectural descriptions in a consistent manner across the enterprise. A broad consensus exists among IT/IS practitioners and researchers that architecture, despite its diverse definitions and meanings, is crucial to resolving these problems. Recognised and influential architecture-based frameworks of both industry and government organisations have been selected and studied. The study covers Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance - Architecture Framework (C4ISR AF), Microsoft Solutions Framework (MSF), Zachman Framework, Meta Groups Enterprise Architecture Strategies (EAS), The Open Group Architectural Framework (TOGAF), and Product Line Practice (PLP). The selected frameworks represent just a sample of the many attempts to eliminate these problems. In all the selected frameworks, architecture has been central in their design. In order to be able to provide a proper basis for reaching a better understanding of architectures and architecture frameworks or approaches, the report uses the whole architecture practice as the context to investigate different scenarios of architecture production and use, interrelationships and connections among various architectures and frameworks, and complexity of architecture practice in large organisations. Based on such a context, architecture practice is studied as a community practice in which professionals can communicate their architecture issues and products with less confusion and misunderstanding, and the value of each architecture product can be maximally realised. In the efforts to address architecture issues that are important for an emerging discipline but not addressed by most architecture frameworks, the report focuses on attributes of architecture and the knowledge value chain in architecture practice. The study of the selected frameworks has shown strengths as well as weaknesses inherent in each of them. The main strength is found to be their ability to acknowledge the value of architecture for individual systems as well as for the enterprise as a whole, and to apply architecture thinking to manage architecture in their own environment as in the case of C4ISR AF. On the weakness side, two main limitations are common to each of these frameworks. The first limitation is in the missing link between the process of developing/evolving architectures for information-intensive systems and the enterprise architectural infrastructure. This missing link results in spreading incomplete and inconsistent architectural descriptions across the enterprise, thus causing unreliable systems and islands of information to flourish. The second limitation is in the absence of a process for codifying architecture descriptions prior to preserving them in an enterprise repository. This absence limits the use and reuse of architectural descriptions to specific areas in the organisation, thus preventing the benefits of these descriptions being shared by all areas of the enterprise. The encountered limitations serve to demonstrate that none of the selected frameworks is capable, on its own, of providing a total solution to manage architecture in large organisations, including the ADO. A total solution here refers to an integrated solution that provides large organisations with the necessary capabilities to generate, represent, preserve and present architectural descriptions about information-intensive systems in a consistent manner across the enterprise with less time, cost and effort. Such capabilities have the potential to resolve IT practices main problems and also overcome limitations described above. This report introduces a new definition for architecture. It defines architecture of a system as knowledge regarding that system; the knowledge is described and represented by a set of interrelated views (models), which collectively reflect the concerns and requirements of the stakeholders of that system. Also, the report describes an "Architecture Practice Conceptual Model (APCM)", which addresses the limitations of existing architecture frameworks and paves the way towards establishing an architecture practice. The model is based on an integrated solution with the capabilities to generate, describe, represent and present architectural descriptions of information-intensive systems in a timely and consistent manner enterprise-wide. The APCM consists of four integrated components. The "System Architecture Construction/Evolution Process (SACP)" implements the generation/evolution of architectural descriptions of information-intensive systems. The "Systems Architecture Acquisition Process (SAAP)" is a necessary process for codifying the graphical architectural representations generated by SACP prior to preserving it in an "Enterprise Architecture Repository (EAR)". The "Enterprise Supporting Elements (ESE)" provide the essential services as required by SACP in its capacity to guide the construction or evolution of new or existing architectures. The report communicates to large organisations that one of the main objectives of establishing an architecture practice, as an emerging discipline, is the cycling and recycling of the architectural knowledge of systems within the enterprise, thus avoiding leakage of knowledge that can be essential to the survival of such organisations. The report also introduces and explains two assessment models, which have been designed to allow large organisations including the ADO, using the proposed architecture practice, to assess the level of the architectural knowledge sustained by the practice. Architecture practice improvement guidance is also provided should organisations seek to further improve the level of their architecture practice. The two models are "Component Improvemevnt Model (CIM)" and "Knowledge Acquisition Improvement Model (KAIM) ". The main purpose of CIM is to assess the improvement level of each of the four components of APCM, based on five specified improvement levels. KAIM is designed to assess the sophistication of the architectural knowledge produced by the practice as a whole; it has four improvement levels and is based on how well the four main components of APCM are integrated and managed within the practice. Finally, the report identifies critical success and failure factors in the pursuit of guiding large organisations into what to adhere to and what to avoid as they embark on developing and implementing the proposed architecture practice. The main critical success factors include commitment by higher management to adopting and establishing such a practice and continued involvement and dedication by the practice's stakeholders to keep business and technology aligned. On the other hand, the critical failure factors include allowing vendors to take full responsibility for developing and implementing this practice, and lack of coordination in developing and supporting the practices four main components. In conclusion, this report lays the foundations for large organisations including the ADO to establish an architecture practice, as an inseparable part of IT management, based on developing and integrating the capabilities of the four components of the architecture practice conceptual model. The challenge will be to test this model in the ADO by engaging stakeholders concerned with the proposed architecture practice. It is through such a practice that the ADO can develop or evolve its information-based systems with reliability, adaptability and interoperability, thereby enabling the ADO to better develop new and evolve existing capabilities. Large organisations are becoming increasingly dependent on the reliability, adaptability and interoperability of information-intensive systems to conduct their business operations successfully and profitably. These qualities are now prequisite for organistions' survival in the everchanging national and international markets. For the last two decades, architecture, despite its diverse definitions, has been considered by Information Technology (IT) practitioners and researchers, as playing critical roles during the life cycle of systems and their infrastructure. The roles include, firstly, providing a sound foundation on which quality information-intensive systems are developed or evolved, secondly, capturing the necessary knowledge to aid in the understanding about these systems, and thirdly, guiding the development of enterprise infrastructure needed to support the creation of such knowledge. This concludes concludes that large organisations, including the Australian Defence Organisation (ADO), must commit themselves to establishing and managing architecture as an inseparable practice embedded within their overall IT management and practice. Such recommendation, once implemented, will ensure that the identified roles of architecture are performed, sustained and continually improved. To pave the way towards this objective, a conceptual model is introduced to help in the planning and guidance of the development and incorporation of acrhitecture practice within ADO. DGC3ID
Context analysis and principles study of architecture practice, DSTO Technical Report, DSTO-CT-0151, Department of Defence, Canberra, Aus-tralia, 2000. P. Chen and A. Pozgay, Architecture practice: A fundamental discipline for information systems
- P Chen
- A El-Sakka
P. Chen and A. El-Sakka., Context analysis and principles study of architecture practice, DSTO Technical Report, DSTO-CT-0151, Department of Defence, Canberra, Aus-tralia, 2000. P. Chen and A. Pozgay, Architecture practice: A fundamental discipline for information systems, Australasian Conf Inf Syst (ACIS), December 2002, pp. 441–451.
On the acquisition of Systems of Systems Coalition collaborative engineering environment
- S C Cook
S.C. Cook, On the acquisition of Systems of Systems, Proc 11th Annu Symp INCOSE, 2001. H.E. Crisp and P. Chen, Coalition collaborative engineering environment, INCOSE Insight 5(3) (October 2002), pp. 13–15.
System engineering management C4ISR Architecture Working Group, Levels of information systems interoperability System-of-Systems (SoS) enterprise systems engineering for information-intensive organizations
- B S Blanchard
B.S. Blanchard, System engineering management, 2nd edi-tion, Wiley, New York, 1998. C4ISR Architecture Working Group, Levels of information systems interoperability, U.S. Department of Defense, Washington, DC, 1998. P.G. Carlock and R.E. Fenton, System-of-Systems (SoS) enterprise systems engineering for information-intensive organizations, Sys Eng 4(4) 2001, 242–261.
A map of systems and systems engineering
- Lawson
- Levis
Systems engineering fundamentals Defence Systems Management College Press December1999
- J Leonard
Han Facilitating Systems-of-Systems evolution with architecture support Proc Int Workshop Principles Software Evolution (IWPSE) Vienna Austria
- P Chenandj
Using architecture analysis for mission capability acquisition Proceedings of the International Command and Control Research and Technology Symposium (ICCRT)
- C Dickerson