KEY CONCEPTS
Architecting
Systems
Utility
Conceptual integrity
Over a decade ago when the systems engineering community was rethinking its concepts and practices, an expansive advancement of systems engineering tools and languages began picking up momentum. Dating further back to the mid-1990s, the influence of information technology (IT) has become increasingly significant. Object-oriented languages and tools from the IT community were developed and integrated with systems processes and methods. Over the past decade, this integration has been associated with what is broadly referred to as model-based systems engineering (MBSE). Amongst other things, this was fuelled by and supported the development of large-scale information systems in aerospace and defence such as theatre level mission planning systems in which software, hardware, databases, system operators, and increasingly autonomous vehicles are integrated. The role of system architecting became more central and the need for more formal approaches to system specification, analysis, design, and assurance became central to MBSE. This was echoed in the INCOSE Systems Engineering Vision 2020 expressed in 2007 as noted in the INCOSE Systems Engineering Handbook (INCOSE 2015).
Many of the tools and modelling languages of MBSE have been standardised by the Object Management Group (OMG). The established object-oriented language for software development, the Unified Model Language (UML), was adapted and has evolved into the Systems Modeling Language (SysML). Concurrently the standards for software and systems engineering continued to evolve. The need for agreed-upon language is a part of these standards. In the case of the term system architecture, driven by the need for agreement, new standards for terminology and concepts were initiated. Given the extent and breadth of activity in the systems engineering community over the past decade, it is important to step back and look at architecting and the engineering of systems in the context of the first two decades of the twenty-first century.
This chapter provides âbrief historiesâ that serve to distil some of the key activities and concepts and speak to some of the key issues. These derive from the INCOSE Systems Engineering Handbook (INCOSE 2015), especially the contribution by Estefan (2007); work that includes a critical analysis of MBSE (Dickerson and Mavris 2013), and summative research for using mathematical model theory in architecture definition and design (Dickerson et al. 2021). One purpose of the summative research was to offer definitions of architecture and system that are complemented by a mathematical interpretation that can be: (i) used for specification of a technical process for architecture definition and (ii) exploited in engineering practice and relevant standards. The details of the process and mathematically based methods for its implementation are subjects of Chapters 3 and 4 of this book.
What should be clear from the history that follows is that MBSE is far from being in a final stage of maturity. Amongst the areas of work to be finished include a formal basis for MBSE (both logical and scientific) and a stronger synthesis between systems and software engineering.
1.1 A BRIEF HISTORY OF ARCHITECTURE
Architecture is key to the modern practice of engineering. The term would be understood by a general audience as a property of buildings or large-scale structures. In civil engineering, it relates a building's purpose (function), form (how its spaces are organised to achieve the purpose), and construction (what it is built from and how it is built). Although understanding architecture in this way is intuitive and useful, it lacks the precision needed for application to engineering problems. Beyond the design and construction of buildings, architectural ideas are also prevalent in disciplines such as software and systems engineering, management science, and biology.
Despite an extensive common ground, there has been no consensus on the terminology or meaning of architecture across the disciplines. In many ways, a precise practical definition has been elusive. Achieving a precise agreed-upon definition by means of a formal approach could bring unity. The International Organisation of Standards (ISO) established the working group JTC1/SC7/WG42 on System Architecture for this purpose. In the standard for Architecture Description, ISO/IEC/IEEE 42010:2011, a definition was adopted that has been subsumed into later standards (ISO 2011). In 2018, the working group began a routine review of the standard, which is still ongoing at the time of writing of this book. In a shift from a narrow system orientation, recent efforts within have also applied the term architecture to entities not normally considered to be systems.
The early attempts to standardise ideas about the meaning of architecture within systems engineering were in connection with the lifecycle processes standard, ISO/IEC 15288. The first published version (ISO 2002) was influenced by legacy software engineering standards, which conditioned the way in which architecture was conceived. It also combined architecture with design into a single process called Architectural Design. This was separated into two processes in the 2015 update, ISO/IEC/IEEE 15288:2015 (ISO 2015), which is generally accepted as the de facto standard for system life cycle development. It has also sought to incorporate the influences and standards from software engineering.
As noted by Wilkinson in Dickerson et al. (2021), the influences of the software discipline date back to the early 1990s, when the IEEE considered architecture to be âthe organizational structure of a system or componentâ. This provided a formulation for architecture as a system property, described in terms of static structure (elements and their relations). In 1996, with the aim of using an architectural metaphor as a foundation for systems engineering, Hilliard, Rice and Schwarm (1996) defined architecture as âthe highest level conception of a system in its environmentâ. This has several important ideas: architecture is âhigh levelâ, includes an âexternal focusâ, and is a âconceptionâ in the imagination. The ideas described by Hilliard et al. were carried over into the definitions used in IEEE 1471:2000 (IEEE 2000), which defined architecture as âthe fundamental organization of a system embodied in its components, their relationships to each other, and to the environment and the principles guiding its design and evolutionâ. The same wording was used in the 2008 issue of ISO/IEC/IEEE 15288. The idea that architecture is subjective is fully embraced in these standards, which introduce architectural descriptions (i.e., models of architecture) as the vehicle for conveying information about the subjective conception of architecture. However, the role of models of architecture for communication has caused a widespread perception that architecture and model are equivalent: Wasson (2005), for example, considers architecture as a graphical model (or representation). By contrast, the popular term âarchitecture descriptionâ can be understood as referring to a description of a system, just as the term âblueprintâ in civil engineering refers to a blueprint of a building and not of the architecture.
Over the same two-decade period, the Object Management Group⢠(OMGâ˘) has used architecture in standards for software development. For example, the Model Driven ArchitectureÂŽ (MDAÂŽ) is an approach to software design, development, and implementation. MDA p...