The concept of Reference Architectures is novel in the business world. However, many architects active in the creation of complex systems frequently use the term Reference Architecture. Yet, these experienced architects do not collectively have a consistent notion of what constitutes a Reference Architecture, what is the value of maintaining the Reference Architecture, what is the best approach to visualizing a Reference Architecture, what is the most appropriate level of abstraction, and how should an architect make use of the Reference Architecture in their work? This paper examines current Reference Architectures and the driving forces behind development of them to come to a collective conclusion on what a Reference Architecture should truly be. It will be shown that a Reference Architecture captures the accumulated architectural knowledge of thousands man-years of work. This knowledge ranges from why (market segmentation, value chain, customer key drivers, application), what (systems, key performance parameters, system interfaces, functionality, variability), to how (design views and diagrams, essential design patterns, main concepts). The purpose of the Reference Architecture is to provide guidance for future developments. The Reference Architecture incorporates the vision and strategy for the future. The Reference Architecture is a reference for the hundreds of teams related to ongoing developments. By providing this reference all these teams have a shared baseline of why, what and how. It is the authors' goal that this paper will facilitate further research in the concepts and ideas presented herein.

While much has been written about patterns in software engineering, little has been written about their application to systems architecting. This paper provides a discussion of patterns and their potential applicability to complex system architecting. A historical introduction to the concept of patterns is provided along with their evolution from the domain of civil architecture to other engineering disciplines and domains. The relevance and applicability of patterns to systems architecting is then examined. Research with regard to developing a pattern form for documenting patterns for systems architecting is presented, and this is demonstrated on a command and control pattern, using both IDEF0 and UML. The application of this pattern within a functional architecture is then explored. Finally, recommendations for the development and management of a systems architecting and architecting pattern repository are offered. © 2007 Wiley Periodiocals, Inc. Syst Eng 10: 138– 154, 2007

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.Index Terms-Model-based systems engineering (MBSE), SysML, systemigram, systems thinking.

No abstract

In military, civil, and commercial systems there exists a need to affordably manage the operational effectiveness of the system of interest through the acquisition and operational stages of its life cycle. Once a system design is baselined and instantiated, then the challenge during development, production, and utilization life cycle stages is to maintain the currency of the physical system baseline to facilitate affordable system support. In essence, the system must adapt to potentially frequent asynchronous obsolescence of its constituent elements, requirements growth (driven by the operational environmental and external constraints such as funding, schedule or risk), and external environment changes. This paper specifically addresses the impact that system element obsolescence has on a system baseline during the various system life cycle phases and provides a framework for affordable system evolution. Literature search and consolidation has articulated six integral components that comprise a comprehensive evolution framework through bottoms‐up obsolescence management of constituent system elements. Each of the obsolescence management components is tangibly addressed in terms of each system life cycle phase and the available tools and methods. Additionally, each of the obsolescence management framework components is analyzed for life cycle phase applicability and then extended further with the criticality and type of analysis to be done for that life cycle phase. In this way, a project can determine which studies to perform, while in a specific life cycle phase, that maximizes the insight of impending obsolescence for a particular system. © 2008 Wiley Periodicals, Inc. Syst Eng