Robert Cloutier

Exploring the Impact of Systems Architecture and Systems Requirements on Systems Integration Complexity

The need to perform faster systems integration of complex systems require the architect and design team to understand how the selected architecture and design components will impact the systems integration processes complexity (or difficulty). Systems integration process complexity is an outcome of the interaction between degree of feasibility and level of effort required to understand, describe, implement, manage, and document the systems integration process for a given system development and operational environment. This paper analyzes the cause-and-effect relationships between the system requirements, architecture and the systems integration processes complexity. In order to address systems integration issues upfront in the design phase it is necessary to determine if the architecture and design of components, subsystems, processes, and interfaces impacts (and to what extent) systems integration process complexity. This paper also defines and analyzes the impact of the different system architecture and requirements factors on systems integration process complexity. A research framework is developed to understand the cause-and-effect relationships between system requirements, architecture, and integration process. Finally, the paper proposes recommendations based on the causality results. These conclusions are based on research undertaken by the authors on eight development projects in the government sector.

Developing a stakeholder-assisted agile CONOPS development process

Concepts of Operations (CONOPS) are documents describing the characteristics and intended usage of proposed and existing systems. They provide information about the requirements and future desired states the project aims to achieve. We reviewed 22 recent CONOPS from government and private sector institutions to ascertain the current approach to CONOPS development. Based on the CONOPS review and research literature, we highlight three key areas, stakeholder involvement, shared mental models, and visualization, through which the development process may be improved. Moreover, we suggest that the development process itself may be transformed into an agile process that addresses current shortcomings in the key areas. To do so, we propose an agile CONOPS development process conducted through three iteration-driven phases and present corresponding research and commercial tools that may be leveraged at each phase. As such, putting this agile process into effect may reduce development time, improve effectiveness, and change the perception of the CONOPS from a burdensome documentation procedure to an invaluable resource throughout the system lifecycle.

Applying Object Oriented Systems Engineering to Complex Systems

Analyzing systems using functional analysis has been the mainstream for systems engineering for five decades. With the advent of object oriented software methods and the object management groups (OMG) Unified Modeling LanguageTM (UML), a number of systems engineers working on software intensive systems began to apply use cases and object oriented analysis and design (OOAD) methods to large scale, complex systems. While the use of these OO methods is still controversial within the systems engineering community, many systems engineers that apply OO methods effectively have used functional analysis and understand the strengths of both methods. FireSAT is a well known fictitious system of systems space mission to provide a space based approach to wildfire detection, monitor and control. This paper will explore the use of OOAD methods to FireSAT for problem definition, concept development, and system architecture development. Using the OMGs recently adopted System Modeling LanguageTM (SysML) and more traditional Systems engineering modeling techniques, this paper will compare and contrast some of the differences between OO and functional methods, showing diagrams from each approach.

Transitioning Systems Thinking to Model-Based Systems Engineering: Systemigrams to SysML Models

A fundamental challenge for system engineers is to capture a problem with an effective model or framework and then facilitate transferring the information of that captured problem to practical systems engineering tools and methods. The early problem definition phase requires an application of systems thinking with adequate modeling tools and methods. Then, the later problem definition phase and early system architecting phase requires transferring the captured problem to systems engineering tools and methods through emerging techniques such as model-based systems engineering (MBSE) using SysML (MBSE is the practice of using a modeling tools to capture systems engineering diagrams). This paper presents a method for capturing a problem through systemigrams and the Boardman soft systems methodology and then directly translating the systemigrams into SysML diagrams. With MBSE increasing in usage, this method could provide a time savings opportunity during model development along with the possibility of lowering information distortion or loss that can occur during transformation of systems thinking to systems engineering activities. This paper includes a case study which demonstrates how the proposed approach was applied on a problem being considered by the U.S. Army-Contingency Basing for Small Combat Units. Finally, this paper will provide the conclusion on the development of the method and describe future research directions that can allow systems thinking and MBSE to function in a congruent methodology.

Applying Frameworks to Manage SoS Architecture

Abstract: As systems become more complex, managing the development of these systems becomes more challenging. Additionally the integration of multiple independent systems increases the management challenge. A System of Systems (SoS) has unique attributes which bring about unique management challenges. Architecture frameworks exist to organize and manage information about an architecture, and can be used to manage SoS architecture. One proposed approach was a framework that spans from component to enterprise, where enterprise is a SoS. A potential problem for this approach is that the lower half of the framework (from system down), is constructed using a reductionist approach while the upper part of the framework is constructed using a composition approach—that is, it is constructed by combining systems to make the broader enterprise system or SoS. So, does it stand to reason that the management approach for systems development should be the same as for SoS development? This article addresses some of the reasons why they should be managed differently, and offers a methodology for implementing the widely accepted Zachman Framework to facilitate the managing of SoS architectures.

Performance-based logistics and technology refreshment programs: Bridging the operational-life performance capability gap in the Spanish F-100 frigates

Many large and complex systems have extended operational lives. Examples of such systems include the oil and gas drilling systems, defense systems, and air traffic control systems. A growing concern for many users is the difference between actual and intended system performance during the operational life. An understanding of the root causes of that gap, known as performance capability gap, is required if appropriate measures are to be taken. This paper explores the main reasons for the existence of the performance capability gap and suggests the combination of performance-based logistics and technology refreshment programs as a very effective and efficient remedial strategy. The paper examines the Spanish F-100 frigate to illustrate actual application of these strategies.

An Introduction to the JET Special Issue of Journal of Enterprise Transformation: Enterprise Modeling

I teach an advanced systems engineering course on system and system of system architecture and modeling. One of the objectives of the course is to transform students’ thinking from drawings that contain no consistent syntax or semantics to the more formal approach found in modeling languages such as the Unified Modeling Language used by software engineers, the System Modeling Language used by systems engineers, and the Business Process Modeling Language used by process engineers, among others. My mantra for the course is, “We model to reason about the problem and to communicate with others.” The goal of modeling enterprises is the same—reasoning about the enterprise and communicating about the enterprise with others. Recently, I added the notion of simplifying complexity to the goal of modeling. I have been influenced by IBM Fellow Grady Booch who often states that a software engineer’s responsibility is to “engineer the illusion of simplicity in the face of essential complexity.” To model the enterprise, one must first understand who the stakeholders are, what their values and motivations are, and their relative levels of influence. Stakeholders take on many identities. They may be individuals, groups of individuals, organizations, agencies, or even other systems. One also needs to understand the interactions between stakeholders. The challenge is that the space of possible stakeholders can continue to expand and be influenced by business rules and objectives, the business environment, and the extent of the enterprise. An important question is, “Where does the enterprise boundary end?” Understanding the boundary of the enterprise or system becomes critical as one understands who the stakeholders are and where their interests in the system/enterprise lie (Valerdi, Nightingale, and Blackburn, 2008). It is also critical to understanding the capabilities or functions to be provided and what must be exchanged across the interfaces that exist between the constituents of the enterprise. As most systems engineers have experienced,

Concept of system architecture database analysis

Every company stores more and more product data. Most of the data are not analyzed and possible findings cannot be used. But the utilization of existing knowledge can make the system development process more efficient. Therefore, this paper focuses on the data analysis of system architectures. It develops a concept to identify patterns between system architectures of different products in a database. The concept combines the knowledge discovery process of databases (KDD) and analyzing methods of product architectures. The so identified patterns of system architectures support the usage and fostering of synergies between different products.

The Design for Tractable Analysis (DTA) Framework: A Methodology for the Analysis and Simulation of Complex Systems

The Design for Tractable Analysis (DTA) framework was developed to address the analysis of complex systems and so-called “wicked problems.†DTA is distinctive because it treats analytic processes as key artifacts that can be created and improved through formal design processes. Systems (or enterprises) are analyzed as a whole, in conjunction with decomposing them into constituent elements for domain-specific analyses that are informed by the whole. After using the Systems Modeling Language (SysML) to frame the problem in the context of stakeholder needs, DTA harnesses the Design Structure Matrix (DSM) to structure the analysis of the system and address questions about the emergent properties of the system. The novel use of DSM to “design the analysis†makes DTA particularly suitable for addressing the interdependent nature of complex systems. The use of DTA is demonstrated by a case study of sensor grid placement decisions to secure assets at a fixed site.

Applying Composable Architectures to the Design and Development of a Product Line of Complex Systems

This paper investigates a composable design methodology leveraging SysML to manage mission flexible product lines, and reviews the application of this methodology to a spacecraft product line. This methodology extends the SysML language with a mathematical and Boolean constraint language allowing for the capture of product line rules as an alternative to a more traditional variation tree. Finally, this paper reviews future work underway to extend this methodology.