Systems architecting creates the opportunity for capturing, analyzing, and understanding the stakeholder needs and understanding the problem domain, the most important point of which is to capture the underlying needs. These needs are very important because stakeholders cannot express most needs, with text or speak about the problem in a clear way, proposing solutions (tradeoffs), deriving requirements to be addressed by the system architecture and to meet the purpose or stakeholders’ purposes of the system. Figure 8.1 illustrates the architecting process from the initial idea to the final realization. The primary product of the architecting process is the system architecture, both physical and functional and the relationships among the architectural components. Architecting applies at both the aircraft level and at the subsystem level.
Abstract principles form the basis for action, such as design, in many fields, such as architecture. According to Clinical Architecture (2019), the Roman architect Vitruvius articulated the following three principles of architecture:
- • Firmatis (Durability). It should stand up robustly and remain in good condition.
- • Utilitas (Utility). It should be useful and function well for the people using it.
- • Venustatis (Beauty). It should delight people and raise their spirits.
None of these principles describes the exact design of any product such as an aircraft. That lack of detail is what makes them abstract. These three principles are aspects of the whole but are not parts of the whole.
The basic definition of architecting is the arrangement of the parts of a system. This arrangement can be either physical or functional. The physical arrangement pertains to, for example, the configuration of the wings and empennage. Functional arrangement pertains to, for example, how auxiliary power is provided. When these architectural decisions are made, then the systems engineering processes are used to determine such quantities as power, lift, and control. Systems engineering is dependent on the architectural arrangement. Systems engineering and systems architecting are inseparable. One cannot exist without the other.
As illustrated above, one of the methods employed by architecting is abstraction. According to Locke (1999), an abstraction is a description of the “essence” of an entity. For example, physical redundancy is the abstract description of any entity consisting of two identical branches. If an aircraft contains two identical control systems, then the abstract principle of physical redundancy will apply.
The abstract view is very important and helps to simplify the architecture by considering the essential aspects in the right moment of the process and architecting activities. Another method is the use of heuristics; it is an intuitive aspect based on
FIGURE 8.1 Architecting.
lessons learned from experience (e.g., on the job training, other development experiences and issues, etc.). The use of physical redundancy can also be considered a heuristic. Physical redundancy is but one of a set of 14 heuristics identified by Jackson and Ferris (2013).
There are different methods to use for different phases of the development process in the early phases in which the structure of information and the needs or wishes of the stakeholders are poor. At this point in the development process, the time is optimum for the architecting perspective. Following this phase, it is time to integrate the detailed information using rational and normative methods described by Maier and Rechtin (2009, p. 169). The use of abstractions and heuristics are appropriate for the early phases of concept development.
- • Art: Participate (Stakeholder Based) and Heuristic (Lessons Learned).
- • Normative Method: The normative method is solution based; it is more science and analytical viewpoint about the strategy solution, examples build codes (Mark Maier and Eberhardt Rechtin).
- • Rational Method: The rational method is a science and analytical viewpoint about the strategy solution, example systems analysis (Mark Maier and Eberhardt Rechtin).
Art, normative, and rational methods are essential to the classic architecting approach and very useful to the original equipment manufacturer (OEM). Art is the most appropriate for systems architecting. Because of the quantitative nature, the normative and rational methods serve to introduce the systems engineering phase of development.
So, it is fair to ask if both the rational method of architecting and systems engineering are based on the principles of mathematics and science (see rational method in Maier and Rechtin (2009, p. 425)), where does architecting ends and systems engineering begins? Maier and Rechtin (2009, p. 426) answer this question by pointing out that in systems engineering decisions are based on the system as a whole. So it can be concluded that architecting is used for determining the features of a system, while systems engineering is used to specify the performance of the entire system.
Finally, systems architecting is a process driven by a client’s purpose or purposes. Clearly, if a system is to succeed, it must satisfy a useful purpose at an affordable cost for an acceptable period. According to Maier and Rechtin (2009, p. 260), “success is defined by the beholder, not the architect.”
In the INCOSE references, ISO/IEC/IEEE 42010 Systems and Software Engineering, Architecture description (ISO 2011) provides a useful description of the architecture considering the stakeholder concerns, architecture viewpoints, architecture views, architecture models, architecture descriptions, and architecting throughout the life cycle (BKCASE Editorial Board 2016).
The life cycle process is very useful in the commercial aircraft domain in which the aircraft is considered as a system, how this objective and the title of this book, a lot of consideration of the architecting process and activities need to be addressed to help understanding the cost and the correct context and environment of the whole solution are.
The architecting process applies to all levels of the aircraft hierarchy as illustrated in Figure 4.1. It is therefore integral to the systems view of an aircraft. Architecting receives the most attention at the top of the aircraft hierarchy, defining the relations among the fuselage, wings, engines, and the empennage. However, aircraft contain within their boundaries many distributed subsystems. These include the control system. the hydraulic system, the environmental control system (ECS), the fuel system, and the power system. All of these subsystems are subject to the architecting process. In short, the architecting process covers the entire aircraft.
As an example of architecting at the subsystem level, take the ECS for example. This subsystem consists of many sensors scattered throughout the aircraft. The location of the individual sensors is the subject of systems architecting at the subsystem level.
Systems Architecting and Systems Engineering
Figure 2.4 shows that both systems architecting and systems engineering are subordinate disciplines to the systems approach, which is the subject of this book. So, if this true, what are the differences and how do they interact?
The general view is that systems architecting is more of an art as explained by Maier and Rechtin (2009, p. 169). On the other hand, systems engineering is regarded as more of a quantitative science. Hence, systems engineering is more of a left- brain discipline, while systems architecting is more of a right-brain discipline. For, example, systems architecting is the discipline responsible for concept development, which according to Maier and Rechtin is an artistic endeavor. On the other hand, systems engineering is responsible for the achievement of system performance, a right-brain activity.
According to Britannica (2019), the idea that people are either right-brained or left-brained is untrue and a total myth. Hence, anyone can be right-brained or left- brained and hence either a systems engineer or a systems architect, or both. People who are both analytic and artistic are sometimes called whole-brained.
In other words, the idea that systems architecting and systems engineering have to be performed by different people has no support in the literature. They can be performed by the same person, which is an advantage in itself.
Furthermore, in order to define and develop a whole system, both systems architecting and systems engineering must be employed. And if this can be done by a single person, it is much better.
According to BKCASE Editorial Board (2016) (Applying the Systems Approach), both systems engineering and systems architecting are two of the processes required to define a system through the systems approach among other processes.
Systems Architecting in the Aircraft Life Cycle
The INCOSE (2015, p. 29) describes the aircraft development phase from the point of view of the “typical high-tech commercial systems integrator,” which is normally the OEM. The initial study period is divided into three phases: The first is the "user requirements definition phase,” which is often called the “user needs” phase. This phase does not determine the design of the aircraft.
The second phase is the concept definition phase. This is the phase in which systems architecting is the dominant activity. Not all architecting occurs at the aircraft level. The major subsystems have their own architectures that have to be determined in the proper phase, normally following the aircraft-level architecting.
The third phase is the Aircraft-Level Requirements phase. In this phase the requirements for the specific aircraft systems are specified.
These three phases are not necessarily chronological since architecting occurs at all levels. Furthermore, these phases are intermingled with the aircraft hierarchy itself that was described in Chapter 4. This is all in agreement with the systems principle of hierarchy.
Figure 8.2 illustrates the interrelation between the systems architecting and systems engineering in the concept development phase of a program.
User Requirements Definition Phase. In the first phase the role of the architect is to reduce ambiguity and to elicit needs and try to keep the architecture as solution neutral as possible. This phase is often called the “User Needs phase.” This name emphasizes the fact that the requirements identified in this phase are not design requirements prioritizing high-level requirements that result from the goals; the requirement is more related to what my system will do to meet the user need. The needs of the stakeholders and beneficiaries guide the entire process; every decision should be traced back to them. The requirements identified in this phase are trade- able throughout the development process. So what is more important to the user.
range or speed? The answer to this question, and many others, will have a strong influence on the aircraft concept.
Aircraft-Level Architecting Phase. In INCOSE (2015, p. 29), this phase is called the Concept Definition Phase. However, Aircraft-Level Architecting is a more exact description of what happens in this phase. For example, the role of the architect is to come up with a set of possible concepts and develop some of them. So, this phase includes the development of the highest level of the architecture, encompassing the system in its surrounding context within a broader system. This phase may also include a few trade-studies to assist in the definition.
Aircraft-Level Requirements Phase. INCOSE (2015, p. 29) refers to this phase as the System Definition phase. In this phase the aircraft architecture is decomposed to the aircraft elements (avionics, propulsion, and so forth) specifying them both in form and function. In terms of requirements, the functional description of the architecture will be completed when we specify the functions and allocate the requirements, proceed with a functional analysis. Also it will be remembered that the individual aircraft systems will have architectures of their own, for example, the fuel system architecture. Hence, at the end of phase 3 both the aircraft architecture and element requirements will be defined.
The purpose of the above discussion was to show how the aircraft and element architectures are developed using both systems architecting and systems engineering throughout the development phase of the aircraft. In addition, it showed how two subordinate disciplines of systems science enable this development.
An Architecting Tool: The Rich Picture
A tool used in the architecting process is the “rich picture” as shown in Figure 8.3. This tool is a method of seeing in a very informal way the relation between the parts of the system, their function, and the options available to the architect.
FIGURE 8.3 The rich picture.
The rich picture is suggested by Checkland (1999, p. 317) who says that it is “an expression of the problem situation compiled by an investigator, often by examining elements of the structure, elements of process, and situation climate” [italics as quoted].
Architecting: An Overview
For a more comprehensive view of the architecting process, an overview tasks below guides the reader on the perception about the knowledge that involved on this process.
Task 1: Solution definition. This task should include an analysis of mission objectives, market objectives, and customer objectives (same place in the process, three different contexts).
Task 2: Life cycle process analysis. This task includes the identification and analysis of all system life cycle processes.
Task 3: Stakeholder analysis. This task includes the identification of stakeholders and stakeholder concerns.
Task 4: Functional analysis and architectural design. This task establishes the role of functional analysis in design.
Task 5: Functional design. This task performs functional decomposition aiming at allocable functions.
Task 6: Architectural design. This task performs functional and performance allocation. This task requires both systems engineering and systems architecting.
Task 7: Trade-off and selection. This task performs technical evaluation of alternatives. This is primarily a systems engineering task.
Task 8: Interface design. This task determines interface types. This is primarily a systems architecting task.
Task 9: Detailed design. This task performs a full characterization of each system element. This is a design task using the results of previously performed systems architecting and systems engineering tasks.
The above tasks illustrate the interrelationship between systems architecting and systems engineering. This interrelationship is the core of the systems approach.
BKCASE Editorial Board. 2016. “Systems Engineering Body of Knowledge (SEBoK).” Accessed 14 April. http://sebokwiki.org/wiki/Guide_to_the_Systems_ Engineering_Body_of_Knowledge_(SEBoK).
Britannica, Encyclopedia. 2019. “Are There Really Right-Brained and Left-Brained People?” Encyclopedia Britannica, accessed 11 October.
Checkland. Peter. 1999. Systems Thinking, Systems Practice. New York: John Wiley & Sons. Clinical Architecture. 2019. “Three Principles of Good Architecture.” Accessed 27 April.
INCOSE. 2015. Systems Engineering Handbook, edited by SE Handbook Working Group. Seattle, CA: International Council on Systems Engineering.
Jackson, Scott, and Timothy Ferris. 2013. “Resilience Principles for Engineered Systems.” Systems Engineering 16(2):152—164.
Locke. John. 1999. “An Essay Concerning Human Understanding.” Pennsylvania State University, accessed 8 February, ftp://ftp.dca.fee.unicamp.br/pub/docs/gudwin/ia005/ humanund.pdf.
Maier. Mark W.. and Eberhardt Rechtin. 2009. The Art of Systems Architecting. Third ed. Boca Raton, FL: CRC Press. Original edition. 1991.