© Springer Nature Switzerland AG 2019
Reinhard Haberfellner, Olivier de Weck, Ernst Fricke and Siegfried VössnerSystems Engineeringhttps://doi.org/10.1007/978-3-030-13431-0_5

5. Systems Architecting

Reinhard Haberfellner1 , Olivier de Weck2, Ernst Fricke3 and Siegfried Vössner4
(1)
Institute of General Management and Organization, Graz University of Technology, Graz, Austria
(2)
Engineering Systems Division, MIT, Cambridge, MA, USA
(3)
BMW AG, Munich, Germany
(4)
Engineering and Business Informatics, Graz University of Technology, Graz, Austria
 

As in our earlier treatment, we divide systems design into systems architecting and concept development (Fig. 5.1).

The terms architecture and systems architecting are used in many disciplines. Thus, one speaks of vehicle, IT, hardware or software architectures. Hence, the content of the terms often remains unclear, either because it has not been defined at all, or because it is a synonym of the term structure. (Note: for structure as an arrangement of elements and their relationships to one another, see Sect. 1.​1.​2.​3). However in the latter case, one has to ask oneself why architecture is needed as an additional term.

The term architecture denotes something that goes beyond the term structure; namely, the allocation of functions to the elements of a structure. Thus, the architecture of a system can be seen as a kind of solution principle ; it is distinct from other solution principles, has important advantages and disadvantages, and focuses on the process of systems creation. For example, the architecture of a product or a product family is considered to be good when the products are expandable, adaptable, and robust.

Here, the reflections of Ed Crawley (professor at MIT in Cambridge, MA, USA) and his group are very useful (see in detail in Crawley et al. 2016). We adopt his approaches to the extent that they are required to understand the systems engineering concept.

Based on the work of Ed Crawley1 and other authors, for example, Ulrich (1995) and Rechtin (1991), we define architecture as:

  • The allocation of functions to elements

  • The arrangement of these elements in a structure

  • The definition of the interfaces between these elements and with the system environment

  • Creation of a defined value

5.1 Examples of Architecture Variants of Systems

The following historical example of the Apollo Moon Landing Mission from the 1960s reveals quite clearly what the term architecture means; it shows that the correct architectural decision was intrinsic to its success. At the time, there were three architectural variants:
  1. (a)

    Direct ascent : direct transfer from the Earth to the Moon with an extremely powerful, as yet to-be-developed rocket (Nova), direct landing, and return to Earth.

     
  2. (b)

    Earth orbit rendezvous : two modules were to be sent into the earth’s orbit and assembled there, to then fly directly to the Moon. The existing rocket technology and the Saturn V under development could have accomplished the goal. This variant would have required the landing of an enormous space ship on the moon.

     
  3. (c)

    Lunar orbit rendezvous : with this variant, the spaceship was to be sent into the Moon’s orbit, the command module was to remain in the Moon’s orbit, whereas the two-stage lunar landing module was to land on the Moon. The lower stage of the lunar landing module was to remain on the Moon and only the upper stage was to lift off from the Moon to dock with the command module in orbit and from there begin its return to Earth.

     

The third variant initially had very little support at NASA. However, it was selected because it showed crucial advantages: no new, more powerful rocket had to be built, whose development would have been time-consuming and would have presented technical problems, and a much lower weight was required to land on the moon, meaning that a lower weight had to be transported off the Moon again. As such, the total fuel consumption of the mission could also be reduced.

This decision made it possible to concentrate on further technological development activities: not a new launcher, but rather a new, important, and critical architectural element that allowed the execution of the docking maneuver in lunar orbit.

Another example is automotive drive train architecture. A front-wheel drive car has a different architecture from a rear-wheel drive car. Even though both drives, having four wheels, front and rear axles, transmission, etc., have the same basic structure, their architecture is different.

With front-wheel drive cars the function of propulsion is allocated to the front wheels, whereas with a rear-wheel drive it is allocated to the rear wheels. This results in different driving performance. Thus, rear-wheel drive is used particularly for sporty cars, as the decoupling of the functions of steering (front wheels) and propulsion (rear wheels) leads to, among other things, more precise steering and better driving dynamics.

The combination of front engine plus rear-wheel drive makes for an almost ideal 50:50 weight distribution between the front and the rear axle, as vehicle parts that are not dependent on their location within the vehicle, (e.g., the battery) can be optimally positioned. In contrast, the architecture of a front-wheel drive car with front engine leads to a front-heavy weight distribution and thus to unfavorable driving dynamics and, when the motor is installed longitudinally, a longer front overhang.

Systems architecting is the first step in the process of systems creation, in which the basic architecture of a system/product is established in terms of a given solution principle. A more detailed concept design, along with its individual subsystems and components, can then be built on this. The architecture of a system, however, not only determines the essential components of a system, but also their structural and functional relationships. It is only an understanding of these relationships that enables effective and efficient management of complex development projects.

The selection of an architecture pre-defines important properties of a system/product, such as the extent of functional performance, changeability, possible derivatives, component standardization, the ideal developmental organization, and much more.

In the case studies presented in Chaps. 8 and 9 (home construction and airport planning) we emphasize those definitions that can be designated as architectural decisions.

5.2 Relationship of Function and Form to Architecture

Function and form are fundamentally different from one other:

  • Function refers to what a system does and thus to the benefit or the value2 that a solution or a solution approach should bring.

  • Form is in a sense the actual carrier of the function.

  • The elements and their mutual arrangement (structure) represent the form.

Often, when concentrating on the form, which is seen as what is concrete and tangible (elements and structure), one may neglect its actual connection to value creation, that is, function. The functional view of a system is therefore the central starting point of systems architecting; it determines the system’s purpose and value.

  • A function cannot be implemented without form.

  • A form without function creates no value.

Function – usually in an abstract formulation – is what the system does or should do to fulfill objectives, and it must be conceived and worked out by the architect (Crawley). It should initially be conceived independently from a possible later design, and as such be neutral with respect to a solution. It is then the form that determines the way in which the function(s) is/are realized. Form is a product or system property that is actively designed by the architect to enable function. Form is what is implemented (built, written, programmed, produced etc.) (Table 5.1).
Table 5.1

Distinction between form and function

Function

Form (elements and structure)

What a system does/could do

What a system is/could be

Creates behavior

Is aggregated and decomposed

Is a source of benefit/value

Is a source of costs

Requires form

Enables function

Source: E. Crawley, MIT Course Material

An architecture can and must be observed from different perspectives (architectural views). Thus, one can speak of different views of an architecture, but also of its functions and form.

In automotive engineering, for example, one differentiates among a geometric, a functional, and an informational view of the architecture:

Thus, the geometric view of the electrical system of an automobile (data bus system, cables, steering devices, etc.), shows mostly the spatial allocation of the constituent components: how are cables routed, that is, laid out? An informational view, for example, the depiction of data flows, would express a different perspective and other attributes. But in each case, it concerns the same system. Therefore, it is important not to confuse the view of an architecture with the architecture itself.

Software development distinguishes, for example, among four views (logic, process, physical, and developmental view) of an architecture (Kruchten 1995).

The same reflection forms the basis of the idea of system aspects (looking at something through a different pair of eyes), which was treated in Sect. 1.​1.​2.​9.

5.3 Task and Meaning of Systems Architecting

Within the framework of the problem-solving process, systems architecting is the first step toward translating the defined requirements, needs, and objectives, as derived from a problem, into a rough sketch of a solution. In Sect. 2.​1.​5, Fig. 2.​7, we called this a decision for a particular solution principle.

Architecting can be repeated at every level of the product hierarchy, because with subsystems, too, their architecture must first be designed or determined before they can be developed in detail.

Example: in addition to the previously mentioned overall architecture of an automobile, architectural concepts can of course also be found at each subsequent level of decomposition: the architecture of an engine, a drive train, an all-wheel drive, etc.

Another example would be the avionics3 of an airplane. This too has its own architecture, but is still a part of the overall architecture of the aircraft. Systems architecting can thus be run iteratively – across the decomposition of a product or the detailed concepts, across different developmental phases and problem-solving cycles (system – subsystem – components).

The basic principle of how architectural design could be systematically derived on the basis of customer requirements harks back to the architect C. Alexander, among others. He recognized that the systems to be developed became increasingly complex and that a responsible designer could no longer approach a problem merely intuitively (Alexander 1964). From this, he deduced the necessity of a methodical process that would enable architectures to be designed to satisfy customer needs in a sustainable fashion. The goal should be to establish the “goodness of fit” between the system to be developed and its environment (context).

The objective of systems architecting is therefore to develop an architecture that fulfills a previously defined value or purpose/objective (Crawley 2009; Rechtin and Maier 1997). Thereby, the useful function that a system carries out or should carry out in the context of its environment can be described as its purpose. Whether or not the purpose was assigned to the system deliberately has no bearing on this concept. An architecture can later prove to be very good or very bad, even if no conscious architectural decision was made.

Example: city planning in Vienna. The partial removal of fortifications had the aim of creating grand boulevards for the monarchy, such as the Ringstrasse.4 Thus, in terms of systems architecting, one element (Ringstrasse) is allocated a certain function (to become a grand boulevard). This function is no longer required today; the architecture is nonetheless useful because the broad Ringstrasse nowadays serves as an important traffic carrier.

A further thought: systems architecting, in terms of the systematic process “from the general to the detail,” is the process in which the solution space is constrained for the first time by an architectural decision; this process can and should enable, by way of feedback, a comparison between solution concepts and objectives and demands. Such a formal development of an architecture is especially worth striving for with complex, novel, or highly interconnected systems. Thus, the architecture is seldom based on a fixed, consistent set of objectives but rather on the fundamental benefit/value it is meant to create (for example, performance, scalability, stability, versatility, and much more). In systems architecting, the customer or contracting authority and the systems designer/architect should discuss, substantiate, and come to a binding agreement on these goals to generate the maximum value.

The creation of an architecture is subject to the basic principles, that is, the fundamental approaches of the systems engineering problem-solving process that have already been described in Sect. 3.​2. It can be seen as the result of certain phases in the system development models introduced here. Thus, systems architecting is initially independent of the process model selected for the development of a system.

The question of whether the system should be further developed later on, whether parts/subsystems of the system should be re-used, or whether the architecture should be the basis for a whole product family, or even over several generations, assumes an important role in systems architecting. Should a defect already be present in the development of an architecture, one that limits flexibility or quality or results in a cost-intensive structure, then this not only negatively influences the expenditure and time required for the development of a single product, but it can also have a lasting effect on the competitiveness of a whole product family.

Moreover, an architecture also significantly influences later opportunities for re-using components (commonality), for allocating development tasks, for limiting sub- or pre-assemblies, for the sequence, and thus also the standardization of integration processes, in addition to the ability to update products. In particular, the architecture predetermines a large portion of the costs.

5.4 Characteristics of Good Architectures

When is an architecture a good architecture? This can really only be answered in the context of the defined objectives. A good architecture is one that meets the required objectives. This entails meeting the needs of customers and users. Beyond that, one can broadly say that for a good architecture – the basis of later products – it is important that:

  • It enables competitive products

  • It takes into account the fulfillment of strategic business objectives

  • It ensures compliance with present and future laws and regulations

  • It can be operated and serviced efficiently and is sustainable

  • It is scalable and adaptable with little effort

  • Further products can be developed from it within given schedules and resources

  • It is “elegant”

The property stated last may sound somewhat strange; however, the experience of many product and systems architects – including the authors – has shown that an architecture that at first glance appears inconsistent and, precisely as said, not “elegant,” will also lead to later errors, problems or unnecessarily complex products.5

The above list also shows that architectures must be aligned to the future. This may be because more products or derivatives of a product family will be derived from this architecture, because it has to comply with future legal requirements, or simply because it requires high initial investments. Different authors have described this aspect using the term changeability (e.g., Fricke and Schulz 2005; Ross et al. 2008). It requires – in addition to the five general design principles already named in Sect. 3.​1.​5 – three additional important principles that should be take into consideration:

Integrability

Integrability means that allowance should be made for aspects of compatibility or inter-operability of components and subsystems and, with this, the use of open, standardized, or common interfaces. This enables, with little effort, the exchange of components or technologies of an architecture during the course of its life cycle; it also enables the distributed development of individual subsystems of an architecture – that is, by several contractors. This characteristic is especially important in the context of a “System of Systems” (Sect. 1.​1.​2.​6), where one’s own product/system has a common operational connection with systems of other manufacturers. One example is the universal serial bus, which standardizes the integration with external peripherals and the related data-exchange; another is Bluetooth.

Scalability

The scalability of an architecture means that the scope of a function and/or the performance of a system/product can be expanded or possibly even reduced. This can be achieved by connecting several identical elements of an architecture with each other, or supplementing them, to scale performance properties or functions. A single element of an architecture can also be scaled by expanding or reducing its characteristic properties.

A good example is Ariane 4, the European launcher whose payload capacity was expandable with additional booster rockets according to customer demand – in contrast to Ariane 5, for which this is not possible and whose maximum payload capacity is always available, even when not required, resulting in unnecessary higher costs.

Another example would be batteries, e.g., those for hybrid or electric vehicles, whose performance can be expanded by adding cells and thus be scaled according to the desired driving range of such a vehicle.

Decentralization

It is characteristic of a decentralized architecture that certain functions, including control or information processing, are not assigned to a central element; rather, they are distributed over several elements. As such, necessary decisions can be taken during the operation of a system at the point of the best information or the greatest knowledge. For example, for time and safety critical functions, decisions concerning systems behavior must be made without long delays via data buses or gateways, but rather directly at the actuator level (e.g., actuator in the control loop that opens or closes a valve).

Another example is current fly-by-wire flight control systems, in which rudders or elevators are not controlled by the mechanical transfer of the pilot’s lever movements (by steel cables, push rods, or hydraulic systems), but by actuators locally mounted on the respective rudder and activated by centrally controlled electrical signals.

The advantages that a decentralized architecture may offer are speed, security against outages or malfunctioning, easy changeability, etc.

The opposite of decentralization is centralization, which could also be useful, for example, when it saves resources.

5.5 Architecture and Innovation

Particularly with regard to economics, it is important to ask how long an architecture can be in use and when the change to another one becomes necessary. Major technological innovations usually entail a change in the systems architecture. Henderson and Clark (1990) differentiate among “radical,” “incremental,” “modular,” and “architectural innovation.”

Architectural innovation can be seen as the reconfiguration of an existing system. This pertains to both function and form; the new product is developed on the basis of a new architecture and the change does not necessarily need to be triggered by technological developments.

Incremental innovation refers to the further development of a product with the same architecture, but the focus is on single, better performing subsystems, for example, in connection with the use of new technologies.

Modular innovation means that only the technical concepts of a module change, whereas the actual architecture or the relationships among the elements remains the same. Simply put, one technical module is exchanged for another. This was the case, for example, in the change from analog to digital telephones.

Radical innovation is a far-reaching architectural innovation, most often prompted by advances in the underlying technologies.

Architectural innovation can be a crucial core competence of a company6: when new products, because of a new architecture, require a different allocation of functions to components and a different arrangement of components, or when new architectures on the market enable completely new product functions and there is a risk that competitors will quickly and successfully implement them. In that case, the existing knowledge of a company may rapidly become worthless.

The basic messages of the Henderson/Clark model (Fig. 5.2) are:

  • The distinction between incremental and radical innovation says something about the extent of the innovative step.

  • Those innovations between architectural and modular identify the levels at which this innovation takes place: the level of the overall architecture or the component level.

../images/460299_1_En_5_Chapter/460299_1_En_5_Fig2_HTML.png
Fig. 5.2

Architectural innovation in context with other innovations (according to Henderson and Clark (1990): Architectural Innovation)

It is not easy to decide the right time to introduce a product onto the market on the basis of a new architecture. It requires a systematic evaluation of opportunities and risks, based on good access to customer requirements.

Maintaining the existing architecture makes it possible to continue to make use of investments that have already been made. A new architecture can develop new functions and potential customers.

Changing too rapidly to a new architecture can be just as detrimental as waiting too long. The market may not yet be ready for innovations; and may not (yet) appreciate them. The products based on the old architecture could still be salable for a long time. On the other hand, a protracted development based on existing architectures can lead to the loss of the competitive edge. Thus, innovation capability and competitiveness depend to a great extent on the skills of those involved in the architectural development and on the right architectural decisions.

Figure 5.3 shows the functionality of technologies, over time and effort, in an S-curve. At the beginning of a technological development cycle, one is usually glad to be able to master to a certain extent the basic functionality and it is not expected to develop quickly. As things progress – also through increased application and experience – significant functionality improvements can often be achieved. Toward the end of the S-curve, increased functionality is not really possible, regardless of the level of expenditure. This is the latest point in time when a decision with regard to technology has to be made.
../images/460299_1_En_5_Chapter/460299_1_En_5_Fig3_HTML.png
Fig. 5.3

Development of drive train architectures in automotive engineering. Architectural S-curve based on Gorbea et al. (2008)

The architecture of the automotive drive train also traverses such an S-curve, which necessitates the changeover to new architectures, such as electrical propulsion. By around 1920, the internal combustion engine format of the drive train architecture had prevailed over the steam engine and electrical drive architecture.

5.6 The Role of Systems Architects

If systems architecting has the above-stated significance for successful systems design, it is logical to think about the particular role of those persons who create or make decisions regarding architectures. Here, the function of the architect is not necessarily tied to a single, specific person who is seconded as an addition to the project group. It is rather that this function is tied to an intellectual approach, to a role that involves making deliberate reflections regarding architecture and maintaining a view on them – a role carried out either by an experienced member of the project team or by a small team.7 However, some companies assign specific architectural tasks to designated persons.

It is the task of systems architects to understand the objectives of a system in terms of functions that bring value for customers, to define these functions, to evaluate the benefits of a system, and to determine the boundaries of a systems approach. Their task requires them to work closely with customers and clients, market researchers, etc., or – depending on the nature of the project – they may be required to discern, discuss, understand, and stipulate the objectives and demands of a corporate strategy.

During this phase, there is usually a great deal of uncertainty with regard to information. Therefore, architects must be in a position to interpret corporate and marketing strategies, regulatory constraints and competition analyses, and to enter into a dialogue with customers or their representatives. They will neither demand nor stipulate a fixed set of requirements – as is generally the case with many of those engaged at the start of a project. Rather, they will try to develop a common understanding with their partners before moving on to the development of a concept.8

Thus, along with objectives and functions, architects also develop concepts that translate functions into a form, that is, they assign certain functionalities to the elements, define the interfaces among the elements and their arrangement, etc.

Therefore, it is also important to understand that architects, on the basis of the required technical expertise, not only have to be generalists looking at the bigger picture, but also specialists in reducing complexity, resolving uncertainties, and focusing the creativity of the developers and project members (Crawley).

5.7 Self-Check of Knowledge and Understanding: Systems Architecture

  1. 1.

    How would you define the term “structure” of a system?

     
  2. 2.

    How would you define the term “architecture”?

     
  3. 3.

    Give your own examples of architectural variants

     
  4. 4.

    Differentiate between the terms “form” and “function.”

     
  5. 5.

    At which level of a product hierarchy should an architecture be developed?

     
  6. 6.

    Give a few examples of principles of good design characteristics for good architectures.

     
  7. 7.

    Sketch the Henderson/Clark model for architectural innovations in the context of other innovations.

     
  8. 8.

    What is the objective of architectural design?