Systems design, understood as engaging in substantial questions of the problem and its solution
Project management as the sum of organizational and dispositive measures for planning, guiding, monitoring, and steering a project with regard to content, duration, and costs. Thereby, an important role is played not only by the ever limited available resources, such as manpower, financial, and material means, but also by the connection of the project task to the commissioning group and to the clients and users by the decision-making processes, the questions of collaboration, authority, conflicts and their resolution, etc.
The problem-solving process as an overall term for systems design and project management
Architectural design in terms of developing a fundamental systems architecture (systems architecting) and
Concept development as a concrete embodiment of a selected architecture
An overview of systems architecting will be looked at in Chap. 5.
For the topic of systems design, we once again pick up the building blocks of systems engineering philosophy (systems thinking and the systems engineering process model) that were described theoretically in Part I, Chaps. 1 and 2. Now, we concentrate on aspects of their implementation, and on in-depth and situational considerations.
We have chosen this two-tiered treatment primarily for didactic reasons. On the one hand, we did not want to unnecessarily inflate the treatment of the model. We believe that an earlier treatment of restrictions and directions for implementation would have more likely hindered an understanding of the model. On the other hand, the deliberations that follow presuppose a knowledge of the overall model; thus, background knowledge of the content of the individual components is required.
3.1 On the Application of Systems Thinking
The following sections describe several cases in which systems thinking is applied to the problem-solving process. These thoughts are also taken up again and enlarged upon in other chapters.
3.1.1 Discourse on the Formation of Elements and Relationships
Examples of element and relationship categories. Note: Several of the frequently used combinations are marked. The categories may be further differentiated as required
Thus, one could examine the organizational units of a corporation with respect to its material, information, value, and energy flows. However, one could also examine information flows among functions, positions, tasks or locations.
The actual method of the approach chosen depends on the type of problem to be examined and on considerations regarding appropriateness. There are structures that afford a more in-depth look into the manner of functioning or the way in which problems relate to each other, and others that afford less insight. For example, if there are managerial problems, one examines organizational elements with regard to their relationships with, for example, information flows, work sequences, assignment of tasks, competence, responsibility, etc. But it would also be meaningful to analyze management levels and the existing social and human relationships, behavior, making use of their competences/power, etc.
There is no recipe for the right choice. However, it is known that “one-dimensional” observations yield insufficient insights and that any additionally recognized structure can promote an insight into the relationships and an understanding of a problem.
3.1.2 Problem Area and Solution System
In systems engineering, systems thinking is applied to the problem area and to the solution.
Systems may be designated as problem areas where problem relationships are suspected, and as such should be examined. This is what a situation analysis concentrates on primarily, but in terms of holistic thinking, further areas are usually involved.
Example: if the quality of a product leads to complaints, the corporation, and its quality-related connections would have to be examined as a problem area. The focus would then be on the engineering drawings, on strength calculations, tests, production, the materials and, external parts employed, assembly, the specific application of the product by users, customers, etc.
The solution may lie in design changes to the product, other materials, better instruction and motivation of the production operators, changes in responsibility and/or procedures/processes, remuneration systems, more consistent quality management, etc. Potentially, only simple or selected changes may be necessary, but these would not become apparent without a systematic analysis of the problem area.
Relationship between the problem area system and the solution system
The place between the “problem area” and the “solution system” may be considered to be the “opportunity space.”
The distinction between the result or product (in terms of the system that is to be designed) and the organization (as a designing system) is an interesting one. With the first – corresponding to the systems engineering process model – one has to differentiate between the objectives (requirements) and the solution concepts for the product or object to enable a comparison or an assessment of alternative solutions with regard to the objectives. In this respect, there is an essential difference, regarding the method, depending on whether the cause of a qualitatively substandard product is to be sought in “incorrectly” defined objectives, or if the product was not designed according to (correctly) defined objectives – for whatever reasons (inexpertness, unresolved accountabilities, etc.). This leads to a differentiation between a process system and an activity system that in a broader sense can also be described with a process (project)-based organization or a corporate organization.
3.1.3 Application of Systems Thinking to the Structuring and Analysis of the Problem Area
- 1.
How is the problem area working today, what is happening there?
- 2.
What are the difficulties or the unused chances?
Question 1 can be illustrated by, for example, a flow chart or a process diagram. Process steps would thereby be represented as elements; logical consequences of the steps, information flow, material flow, etc., would be represented as relationships.
Networked thinking – excerpt from the example “warehousing”
3.1.4 Demarcation (Boundary) of the Problem Area
To draw a boundary of the problem area is a significant step in every project. In the example of a quality problem, one could limit the examination to one’s own operation and try to find quality influencing factors in respect of machines or intermediate products. As such, one would accept customer complaints and demands as facts, without first checking. But one could also examine the situation of the customers or suppliers before resorting to expensive measures within one’s own operation. More effective results may be achieved through simple indicators or measures outside of a hastily defined problem area.
If this type of deliberation were carried out, one would extend the system boundary of the problem area. This is not without danger because some people pursue a policy of looking for the causes of problems that principally lay outside of their own field of responsibility. The questions of attitude and expenditure are driven in connection with the problem boundary. (The customer may be delighted to have one of our specialists with whom to discuss the problem).
Within what boundaries should the problem area now be considered? Finding the right system boundary is made more difficult by two opposing tendencies: the more comprehensively the system to be examined is defined, the greater the effort required for the analysis and the search for a solution. The narrower the limits are drawn, the more constrained will be the discovery of further possibilities of a solution or intervention. However, a more comprehensive look at the problem field does not necessarily mean that the solutions themselves have to be of a more comprehensive nature. The knowledge of having many connections and their associated insights only partially under control can actually inspire solutions, albeit in small steps.
A reasonable boundary has to be found by using intuition and experience, coupled with a critical scrutiny and a weighing up of the situation.
3.1.5 Systems Thinking and Solution System
Systems thinking is also important in the working steps that are oriented toward a solution. When applying system-hierarchical thinking, it makes sense, at the beginning of the search for a solution, to look at the solution and the solution building blocks as black boxes and to first define the functions, along with the related inputs and outputs. Subsequently, one models the solution system according to the aspect of the mode of operation and functional relationships at the lower levels, the components/modules/connections (interfaces) between the components, etc., and the allocation of functions to the elements/components (= architecting). Thus, the idea of a system hierarchy is not only applicable to modeling a problem area, but also to the search for a solution, because the solution must of course be successively detailed.
Five General Design Principles
- 1.
Ideality: this is to be understood as the ratio of the sum of all productive functions and the sum of all undesirable functions and effects. It is based on the conviction that an ideal system should consist only of productive functions. This originally derived from the fundamental evolutionary model in the ➔ TRIZ,1 that all systems develop in the direction of an ideal state. For systems design, this means that the complexity of a system should be kept to a minimum. An example would be BMW’s iDrive concept, by which many different comfort functions in the car can be easily operated with a single push–turn knob instead of having to design and operate individual buttons for every function. Another example is the use of touch displays where the view area is also the handling area, using the same interface.
An ideal system also uses pre-existing resources/elements from higher level systems and the system surroundings.
Example: head-up displays in automobiles where the front windshield is used to place information within the driver’s field of vision.
- 2.
Independence: this principle states that the effect of variable design parameters should be reduced as far as possible. This principle is derived from axiomatic design,2 according to which each function of a system or each functional requirement should be fulfilled by an independent design parameter. Here, design parameter can mean a physical principle, a technical parameter, or even a component. The idea is that when it is required to change a parameter or a component, other components and their ability to function should not, as far as possible, be influenced. For example, in certain major software systems, the individual system functions are deliberately implemented in different, distinctly separate software modules.
- 3.Modular construction: this principle signifies that subsystems (system building blocks) should be formed and defined such that they cover functions that are as clearly defined as possible and that are re-useable. Here, one must be careful to draw the boundaries of systems and subsystems in such a way that the interfaces/relationships to the outside are as simple as possible and kept to a minimum (loose coupling) and those directed inward are as strong as possible (strong cohesion). As such, tuning and coordination are simplified. This principle figures in both software and hardware systems. The advantages consist of:
A reduction of complexity because the system becomes more manageable
A greater chance to use modules repeatedly in different solutions
The opportunity to subsequently replace modules with better, that is, more efficient ones
Simpler maintenance
The possibility for more economical production and storage, etc.
4. Piecemeal engineering: this principle (according to K. Popper) states that, particularly with large and complex systems, one should beware of performing major changes in large steps, whereby the effects of those changes are not clear. Here, it is both acceptable and reasonable to broadly define the problem area and to develop a comprehensive solution concept. Its realization, however, should be carried out in smaller steps that can be more easily reversed, should they prove to be inexpedient or even wrong.
5. Minimal prejudice: this principle states that, when in doubt, one should give preference to the solution that presents the most scope for further development and is thus the least prejudicial.
Here, it is important that the solution has a certain robustness in the face of changing conditions and/or contains the appropriate flexibility to accommodate necessary changes/adaptations.
We have limited ourselves to five general design criteria whose application should be fundamentally considered in every search for a solution. Further design criteria are introduced, particularly in Sects. 6.3.2.3 and 6.3.6. References to further literature can also be found there (for example, Altshuller, Baldwin, and Clark, Pahl and Beitz).
Whether the interfaces, i.e., the connections between the solution system and the problem area, have been clearly designed
Whether the solution system, when embedded in the problem area, achieves the changes that were originally intended
Whether undesirable side effects could arise in the problem area that had not been considered up to this point, but that could still be avoided during the design stage
3.1.6 System-Oriented Thinking and Teamwork
Working in a team is of great significance, particularly for problems that cannot be routinely analyzed or processed. It is not only the scope of the work that makes teamwork necessary, it is also the knowledge that familiarity with the situation, expertise, and creativity are required to both determine the problem and find a solution. A team provides better opportunities for a more comprehensive view.
When those persons who have to deal with the real problem can work out the structure of the problem solution within the team – in terms of the systems engineering model introduced in this book – they will always be able to return to this as a basis later on. Experience has shown that in this manner, a better common understanding of the problem and enhanced team spirit develop. This in turn is a prerequisite for good solutions.
In this context, we should point out the usefulness of graphic system diagrams (bubble charts, flip charts or pin boards). This makes it possible to develop descriptive “maps” of the problem area or the solution systems, thus allowing these to be better discussed, analyzed, expanded, or reduced.
3.1.7 Systems Thinking and Project Management
The more extensive an undertaking and the closer it comes to completion, the more important and complicated the institutional allocation of tasks and responsibilities become for its treatment. Subcontracts have to be assigned; tasks have to be outlined. An unclear formulation of tasks leads to overlaps and gaps – if this matter is not sorted out autonomously by the team. Work packages are therefore often defined with the aid of a ➔ work breakdown structure. The work breakdown structure relies in turn on the system approach; thus, it seems reasonable to appoint subproject managers for the design and realization of components (= subsystems). As such, it also makes sense to appoint integrators responsible for the interaction of components, who supervise the cross-functional system aspects.
Examples: in a large company organization project, there are fields of responsibility for functional subsystems such as sales, purchasing, manufacturing, and also for system aspects such as logistics/material flow and information systems. These can be shown clearly in, for example, a matrix organization (see Sect. 4.3.2.3).
Or: the developers of different product parts, components or function groups meet periodically with assembly experts in so-called installation meetings, to evaluate and discuss results – currently only available in digital, virtual form – with regard to their ease of integration.
3.2 On Implementing the Systems Engineering Process Model
In the following, we consider certain aspects of the four modules of our process model that we consider important with respect to implementation.
3.2.1 Implementing the Process Principle “From the General to the Detail”
The basic idea of the process principle from the general to the detail has already been explained in Sect. 2.1.1. It consists of applying this principle to both the problem area and the search for a solution. Before beginning with a detailed analysis of the problem area (the starting situation), one should first structure it by initially posing the questions: what are the important elements of the system for us? What are their mutual relationships? How do they relate to their environment?
Also, in the design of solutions, one should start from general reflections or solution concepts, which are further detailed and substantiated during the process. In this way, complexity can be more easily mastered. From the general to the detail can also be described by other phrases that characterize the same basic idea with varying nuances: “top–down,” “from the rough to the smooth,” “from abstract to concrete,” “from the incomplete to the complete,” “from the framework to the form,” and many more.
This basic principle stimulates a line of thought “from the outside to the inside.” Its usefulness in the new design of solutions or in redesigns on a larger scale cannot be called into question. Modifications and additions to this principle, in terms of the prototyping approach (Sect. 2.2.1.6), an agile process model (Sect. 2.2.2), or the versions concept (Sect. 2.2.1.7), have already been mentioned.
In special situations, such as when it concerns the improvement (melioration) of existing solutions that should not be inherently changed or called into question, the inverse could make sense. The line of thought would then be “from the inside to the outside,” “bottom–up”, or “from detail to an (improved) whole.” In such circumstances a knowledge of details or the improvement and optimizing of portions is of special significance. As a consequence, the whole should be improved.
We return again to certain aspects of this consideration in Sects. 6.3 (Search for Solutions) and 6.5 (Special Cases and Situational Interpretation).
3.2.2 Implementing the Principle of “Variant Creation”
The principle of creating variants has already been indicated as an important component of the systems engineering method in Part I, Sect. 2.1.2. This principle, however, is often contravened when it comes to practical application. This can be outlined using a few typical cases.
Case 1
The chance of an (even) better solution is dispensed with.
One runs the risk of introducing fundamental alternatives to the discussion at a later point, by which time much detailed work would have already been done and when it may be time to begin the realization process. Thus, time pressure is further intensified, and the consequences can be stubbornly clinging to a single solution, uninformed discussions, and finally even postponement of deadlines.
Case 2
The planning group agrees that there is no alternative to the solution presently under discussion. This, however, is seldom the case, for there is rarely only one solution to a problem. Although the solutions may be appropriate or achievable to different degrees, they should at least come under consideration for a time. Such an assumption could also be associated with a “loss of face”: when, for example, a person not belonging to the planning team (client, decision maker, concerned party, other experts, etc.) brings a wholly reasonable alternative to the discussion that had not previously been considered.
Case 3
Apparent variants are created that do not differ in principle but do differ in detail. Or when the favored variant is compared with alternatives that have not been thought through, or are even intentionally inferior. Although the methodology may ostensibly have been applied, it does not actually contribute anything substantial. Here, the same basic risks apply that were mentioned in Cases 1 and 2. Moreover, such a course of action also touches on questions of the credibility, professionalism, and ethics of the planning team.
The cases outlined here are designed to call to mind that, although methodology presents a formal framework, it is the personal potential, contributed by the participants, that yields the benefit. When a colleague presents you with “the best solution,” always inquire what the alternatives were or are – and always be prepared for the same question if you bring up suggestions for a decision. The principle of building variants should cause neither tense situations nor needless delays; rather, it should be an expression of open-mindedness and a lack of bias.
3.2.3 Application of the “Phase Model”
The problem of concept decisions following important phases and the inexorably related cost/benefit considerations
The question of the amounts of expenditure to be allotted to the individual phases
The question of integrating partial solutions within the framework of an overall concept
The dynamics of an overall concept in terms of a timing change
The frequent necessity of an overlapping procedure
The role that could be played by immediate measures
3.2.3.1 Concept Decisions
Phase concept – basic version
The client is required to acknowledge project progress at this point in time and to confront different solution options. In cases in which the client consists of more than one person, they become aware of their differing values and have an opportunity to clarify these and to make them known. Also, the client becomes acquainted with impending changes.
The project group is encouraged, at least during the transition from one phase to the next, to become aware of how the solution appears from the client’s perspective. Details recede into the background for a time, whereas the overall context has to be moved to the forefront. This can benefit the usefulness and acceptance of the solutions. As such, concept decisions offer the group a great chance to highlight its activities from the point of view of project marketing.3
Cost/benefit considerations play a major role in concept decisions alongside considerations of function and fitness for purpose.
The generally nonrecurring costs of development and realization (including expenditure for project management)
Recurring operating expenses comprising, besides allocation for investment costs (via depreciation), personnel costs, materials and energy expenses, etc.
The operating benefits that can be expected when a solution, or even just individual parts of it, are ready for use
The planning benefits that can occasionally arise in terms of an increase in know-how, even if the development is stopped and its realization dispensed with
In many instances, cost can be expressed quantitatively and in monetary terms. In the case of benefit, nonquantifiable qualitative aspects, whose weighting is often a matter of judgment, play a role alongside the quantitative aspects.
Benefits are usually much harder to quantify than costs, especially in a conservative culture. Therefore, trust in benefit is usually much less than trust in cost. This should be taken into account when deciding on the concept. The opposite may also apply: a future solution may be associated with the expectations of benefits that have not been scrutinized.
Each project-oriented decision is characterized by the fact that the expected costs must be offset by a proportionate benefit. A time delay with regard to the availability of information must be accepted as a given in the assessment of cost and benefit: development costs have to be ascertained or budgeted for at the beginning of a development phase (preliminary, main, and detailed studies), whereas the expected benefits can only be estimated when the planning results are available in the form of detailed concept designs – thus, not until toward the end of a phase. (Note: the actual benefit can be determined once the project has been realized or it cannot be reliably determined at all).
It is therefore easy to justify the fitness for purpose of the phase model, with its incremental planning and decision-making process. Owing to the express requirement to consider future costs and benefits at the end of important phases, the chances increase that projects that promise little success can be terminated in a timely fashion, i.e., while the expenditure on development incurred to date is still within tolerable limits. A different approach, and one that would not be recommended, would be to structure the development process without regard to timing, and to make a comparison of cost/benefit considerations not in phases, but only at the end of the development process.
As the development of solutions progresses, it is further significant to note that in general, the increase in relevant knowledge is not linear over the course of a project; rather, it flattens out. This leads to the question of the marginal benefit of developmental costs, as the recommendation to create variants gradually at each system level should not lead to an endless development process. At each level, one must consider whether any additional benefit that might be achieved through further development has not already been overcompensated for by the planning expenditure it entails.
3.2.3.2 The Course of Expenditure During the Different Phases of a Project
Expenditure trends in project phases
The trend of expenditure in the realization phases is significantly influenced by the extent of investments to be made: if, as in the case of software projects, the primary concern is with the employment of labor and the demands placed on IT resources for programming, the expenditure apportioned to the system build will be comparatively low. For a project in the building industry or in machinery or plant engineering it can be very high. This leads to a trend in the curves as shown in Fig. 3.6.
Preliminary and main studies reduce the risk with little expenditure. They should therefore be neither poorly budgeted nor executed in haste.
With projects that involve large and expensive investments in the systems build phase, the proportion of the total that is required for planning and development is comparatively low. For that precise reason, it makes little sense to be overly frugal in the planning stage.
It should be mentioned in passing that reworking, repairing, or servicing solutions in cases of careless or incompetent planning involves a rapid increase in expenditure.
3.2.3.3 Integration of Partial Solutions
The following considerations assume that the detailed concepts developed during the course of detailed studies must fit the overall concept. To check this, they must already be embedded mentally and repeatedly within the framework of the overall concept at the development stage. This can be described as a successive integration process. After all, the demarcation of subsystems, task areas, and system aspects, which was carried out in the main study, had as its chief purpose the creation of manageable and operable units. Therefore, it always had to be clear that the artificial separation of subsystems can only be maintained for a limited time. Special attention had to be given here to the relationships and interfaces with the surrounding system, whereby an effect-oriented approach was notably at the forefront.
In detailed studies, i.e., in the gradual transition to a structure-oriented approach, in terms of an increasingly concrete arrangement of details, the structure and functioning method of detailed solutions becomes clearer and more concrete, along with the type and scope of their relationships with other detailed solutions and with the environment. These results represent additional knowledge, which has to be integrated into the overall concept. Through the integration process, it should be ensured that different detailed concepts do not begin to lead a life of their own, but that they are placed, according to plan, within the framework of an overall concept. This does not rule out that some adjustments to the overall concept may prove necessary.
Existing problems cannot be overcome with a solution based on the original objectives, because essential influencing factors, which were initially not known or simply ignored, have changed in the course of the project.
Interfaces, dependencies, and relationships that were not known or thought of earlier are discovered during the detailed treatment.
The original objectives are basically considered justifiable, but they cannot be successfully realized in view of economic, psychological, technical, political, social, ecological, etc., factors, and must therefore be changed.
Course of knowledge about a system
Here, it should be noted that, on the one hand, knowledge regarding a system is not simply zero at the beginning of a project (the user knows the current situation, the system designer has expertise and a knowledge of methods at his disposal), and on the other, that complete knowledge about an emergent system can never be reached. This is because a system, as a rule, changes, as do the demands put upon it, in a “live,” i.e., a changing environment. In risk assessments of systems, one speaks of a “permissible level” of a lack of knowledge. This never falls to zero, although with particularly safety-relevant systems, the permissible level of lack of knowledge must be relatively low. This is achieved through adequate safety additions (which in essence are in fact “uncertainty additions”), particular analysis efforts (including various simulations), redundancy of system parts, insurance agreements, etc. Thus, one can attempt to reduce the lack of knowledge or, as the case may be, make possible negative effects controllable. However, one cannot entirely eliminate uncertainty when it comes to complex systems.
3.2.3.4 Tendency Toward Decreasing Innovation During the Course of a Project
A component consisting of existing and proven solution elements with known characteristics that are combined into a new type of whole (complete concept).
An innovative component that results from the fact that individual solution elements have to first be newly developed (for example, in additionally required detailed studies).
The greater the second component, the less one can reliably estimate the result that is to be supplied by the working group assigned to the solution search – and the more the difficulties in coordination between the working groups are magnified. Greater attention must therefore be paid to the coordination tools that help to ensure the necessary agreements with respect to objectivity and timing.
It may therefore often make more sense, to the extent that this can be justified from the point of view of the desired overall solution, to rely as much as possible on known and proven solution elements and, when in doubt, to aim for less ambitious solutions. Even so, there are no grounds for thinking it is possible to eliminate all coordination problems entirely, because in practice additional adaptations or expenditure for the development of intermediate links are almost always required.
Or stated differently: if a particular innovation is regarded as an important competitive tool in part of a system, one is neither able to nor wishes to dispense with this innovation. On the whole, however, one should be careful and use predominantly proven solutions for other functions, so that the total complexity remains controllable.
3.2.3.5 Dynamics of the Overall Conception
The following reflection is directly related to the one above. The process of developing complex solutions often does not occur in such a way that the overall concept is “frozen,” and only then are successively detailed concepts developed.
Internal influences, such as a better insight into problem relationships and solution possibilities during the course of developmental activities (arrows from bottom to top).
External influences, i.e., unforeseen developments in the project surroundings, such as new and more efficient technological possibilities, unexpected activities of the competition, changes in the financial and profitability situation; changes in target, procurement, and employment markets; unexpected difficulties with currently employed technologies, new legal regulations, changes in leadership personnel, etc., illustrated as external lightning bolts.
Dynamics of the overall conception (this model has already been illustrated in Fig. 2.20 in connection with the topic “Agility in Systems Engineering”)
Overall concepts are basically at risk of aging. They are based on the level of knowledge current at the time when they were chosen.
The more prolonged the planning, the greater the risk that planning results will be voided by the passage of time (better detailed insights, diverse external changes).
As the project advances, opportunities for the overall concept to exert influence become fewer, because for reasons of efficiency, one has to strive to safeguard the development results achieved (detailed concepts) or the realization steps initiated in the interim; that is, to change them as little as possible (see the next Sect. 3.2.3.6).
Beware of super-integrated solutions that are too large and take several years to carry out, especially when they are located within a dynamic environment and are subject to uncertain conditions. In case of doubt, it is preferable to lean toward smaller solutions that facilitate a quicker benefit.
Implement flexibility in overall concepts, pursue “agile systems” (Sect. 1.3): Keep options open regarding later adaptations, expansions, dismantling, etc. Plan for modular building blocks that can later be replaced with better or more efficient ones. Be open to or plan for opportunities for expansion or reduction.
Consciously plan for flexibility or possibilities of multiple use, even though this may require somewhat increased investment.
Consciously make partial introductions to provide interim benefits.
Dispense with optimizing unproductive details.
Postpone decisions based on uncertain premises for as long as possible − as long as this is compatible with the logical process (agile systems engineering, for example, in accordance with Sect. 2.2.4)
This can ultimately lead one to accept the ideas of the versions concept (Sect. 2.2.1.7), and thus dispense with further improvements of the overall concept or, as the case may be, to defer them until later versions. The project manager will arrive at this point in practically every project. We are convinced that the decision on a certain variant of the overall concept does not necessarily mean that the overall concept is frozen. To benefit from individual and/or collective learning effects, this “concept freeze” should, as far as possible, take place successively and at a later stage within the project.
We believe that these considerations have very much to do with the “agile methods” (see Sect. 2.2.3). Even when using these methods, there is a need for an overall concept as an orientation framework for development. Early sprints should be aimed at developing architectures that make overall contexts clear and allow the steps for the development of the respective detailed concepts to be prioritized – for example, in the form of product backlogs. Also, the configuration and organization of the teams should be allowed to work at various levels of concretization: at the level of the overall concept and at the level where the details are located that determine the overall concept.
3.2.3.6 Temporal Overlapping Procedure
The sequence described in the explanation of the phase concept in Sect. 2.1.3; detailed studies – system build – system implementation, does not have to refer to the overall concept, but can in fact refer to single, partial solutions that are worked out and realized in overlapping stages. This is illustrated on the left-hand side of Fig. 3.5 by means of the slanted lines among system development, realization, and use.
It is therefore quite conceivable that certain partial solutions can be implemented or are already in operation, while others are still in the detailed study phase. However, this overlapping should not go so far that a system build is started before the conclusion of the main study, which in turn would supply the overall concept that determines the functionality and realization principle of the system.
The usually limited capacity of the project group, but also of the later user, to absorb innovations.
Limited budgets that do not allow great advancements for development and realization.
Methodical and logical considerations that result in first defining the particularly important solution components, with which the rest have to be aligned. The conscious limiting of the degrees of freedom in the creation of the remaining solution components can significantly reduce the complexity of the developmental process.
The possibility of obtaining useful interim effects by first putting single solution building blocks (partial solutions) into operation while others are still being worked out in detail.
Of course, this type of approach has repercussions for the considerations posed earlier regarding the dynamics of the overall concept (Fig. 3.8): the more frequently detailed concepts are found at the realization or utilization stage, the fewer the opportunities for any subsequent influence. Although this may be an advantage from the standpoint of labor economics and with regard to the progress of the project, it can also be perceived as a disadvantage in the sense of forfeiting a better solution.
Phase model – modified version (see Fig. 3.5)
3.2.3.7 Immediate Measures
Immediate measures play an important role in many organizational and/or technical projects. Even at an early stage, often during the preliminary study, they represent scope for action and as such opportunities, but also risks.
Opportunities arise particularly when immediate measures can alleviate or even mitigate a problematic situation. This can be an advantage both psychologically and objectively: psychologically, because immediate measures create goodwill and confidence in the efficiency of the project team; and in objective terms, because it may provide the time required for an orderly, i.e., deliberate and systematic handling of the situation.
Possible risks are, for example, that the eventual solution may be unfavorably prejudiced by the immediate measures, in that a course of action would be taken prematurely or by obstructing alternatives. Moreover, the work of implementing immediate measures can hinder or considerably delay the work of the project group. However, one can also imagine situations in which it makes sense to be satisfied with “quick” results and to postpone or even dispense with basic improvements.
- Primarily realize those immediate measures that:
Have little expenditure
Bring as visible and tangible an effect as possible, “quick wins”
Prejudice later solutions as little as possible
Optionally, leave the execution of immediate measures to other people, but remain in contact with them (participate in the interim success, become better acquainted with the operating mechanisms and the reaction of the system, etc.)
3.2.4 Implementation Aspects of the “Problem-Solving Cycle”
The following sections primarily deal with the implementation aspects of the problem-solving cycle (PSC) as a whole and the interaction of the individual partial steps. An in-depth look at the individual steps is given in Chap. 6.
3.2.4.1 Focal Points of the Single Partial Steps of the PSC
- 1.
Current condition with current means or technical procedures (= instrumental, “how” or “with what” level)
- 2.
Current condition, raised to the functional, task-oriented level (“what?) and illustrated functionally. Enables an assessment of condition 1, for example, with regard to the practicality of current working means for current tasks
- 3.
Purpose or justification level for the actual condition. What is the purpose of the current tasks or functions (why)?
- 4.
Purpose or justification level for the target condition.
- 5.
Requirements of the target condition with regard to function. Central point of formulating objectives (forgo or add tasks). Source: actual condition and additional demands.
- 6.
Possible fulfillment (how, with what?) of the desired functions in the target condition.
Different reasoning levels in problem-solving. (a) Assess current means on the basis of current functional demands. (b) Justify current functions. This process is not always very productive, directs attention too much toward the past. (c) Use current functions as a source of future functional requirements, but also consider a possible elimination of functions. (d) Additional functional demands that have nothing to do with the actual condition. (e) Justification of future functions. (f) Fulfil new functions by new means
A situation analysis primarily covers the analysis of the functions of the ACTUAL condition (what?) and, on this basis, the assessment of current aids or instruments (how, with what?) – looking from 2 to 1. In the background and above everything is the use or justification level (why?) – looking from 3 to 2. For the purposes of our problem definition (the difference between ACTUAL and TARGET), the situation analysis does not satisfy itself solely with the ACTUAL condition, but should at least touch upon all three levels of the TARGET condition – steps 3 to 4.
The formulation of objectives must concentrate on the functional level (primarily the TARGET condition) and of course also on the use or justification level, particularly with reference to the TARGET condition – parts of 2 and also of 4 and 5.
The search for solutions (synthesis/analysis) finally comprises the search for instrumental solutions (how, with what?) for defined functions – steps 5 to 6.
The focal points of these reflections on situational analysis, the formulation of objectives, and the search for solutions are illustrated by the bordered fields in Fig. 3.10.
3.2.4.2 Information Flow Between the Partial Steps of the PSC
Information flow among the partial steps of the problem-solving cycle
3.2.4.3 Anticipation or Regress (Repetitive Cycles, Iterations)
The depiction of the problem-solving cycle up to this point may give the misleading impression that it concerns a linear process that would have to be executed exactly according to the stated sequence of steps and would finally lead to an optimal result.
This impression would be neither intended nor realistic, and therefore a few additions and limitations are appropriate. On the one hand, anticipation is necessary and desirable; on the other, a true problem solution in the form of a linear process is not attainable; repetitive cycles, also known as iterations , are often necessary and reasonable.
The problem-solving cycle should therefore neither exactly describe the actual process, nor should it constitute mandatory instructions. It should rather be an aid to orientation and represent a reasonable compromise between an idealized linear sequence (manageable) and a realistic, universal behavioral pattern (complex).
Anticipation
The individual steps of the problem-solving cycle are to be regarded as a series of activities that have different purposes and contents. This is concerned with different individual aspects that, although they may temporarily occupy the foreground, still allow one to aim at the next step and the one after that.
A targeted and adequate situation analysis is only possible, for example, if the planner is aware that he or she must use it to create a basis for the formulation of objectives. Also, he or she must come up with reference points for intervention or opportunities, for solutions, which by rights belong to the synthesis/analysis step of the process.
This pragmatic view should not, however, tempt one to completely skip individual process steps or to grossly neglect them, or indeed to arbitrarily change the sequence.
Regress and Repeat Cycles
Often, one has to return to earlier steps and modify their results. This does not have to be viewed negatively as design processes often take place iteratively and if iterations lead to improvements, they are naturally, in principle, to be welcomed and accepted.
Rough cycles – the step back passes over the individual sections of the search for objectives, the search for solutions, and the selection.
Fine cycles – the cycle transpires within the sections of the search for objectives, the search for solutions, or the selection.
Reversion and repetitive steps in a simplified PSC
Rough Cycles
- 1.
From the search for solutions back to the search for objectives
One or more of the mandatory objectives originally decided upon (for example, performance, costs, deadlines) may prove to be so restrictive that no useful solutions can be found. The requirements have to be revoked wherever this is easiest. Thus, an additional and complementary analysis of the situation may prove necessary.
- 2.
From the selection back to the search for solutions
The evaluation may reveal that solution variants are still insufficiently developed or that they cannot (yet) be assessed with regard to certain criteria. Or: at the decision stage, the client comes up with new requests for the design of variants, which leads, for example, to the creation of new variants by combining elements from available variants.
- 3.
From the selection back to the search for objectives
If at the decision stage, the client is not satisfied with any of the solutions offered or introduces new considerations with regard to system boundary, target definitions, etc., this can lead to a renewed mental run-through of the PSC in which earlier solution suggestions can then be incorporated.
Fine Cycles
- 4.
Within the search for objectives, i.e., between the formulation of objectives and situation analysis.
Newly emerging objectives may make additional situation analyses necessary. The understanding of the problem must be rendered in more detail or improved (a closer look at the actual condition and/or so-called paradigms/good examples).
- 5.
Within the solution search.
An iterative solution search takes place in the alternation of synthesis (constructive step) and analysis (critically checking step) of the concept variants.
- 6.
Within the selection.
During the decision stage there may be repercussions for the evaluation phase, for example, modifications to weighting and criteria, assimilation of new criteria, etc.
The repetitive cycles and mental regress presented here are limited to a certain problem area within a certain project phase and thus to a defined problem-solving cycle. However, there are also cycles of a higher order that point to higher system levels (understood as an adaptation of higher-order concepts) and thus, among other things, to earlier project phases. This has already been referred to in Sects. 3.2.3.3 (Integration) and 3.2.3.5 (Dynamics of the Overall Concept).
3.2.4.4 Expanded Problem-Solving Cycle
Expanded problem-solving cycle
Only those elements of the PSC that are new with respect to Fig. 3.12 are described below.
Client
The client is responsible for the higher-order system level. In respect of very important projects in industry, the management board is the client and the decision-making body for the overall concept, although other types of committees may be responsible for detailed concepts (for instance, the steering committee responsible for the overall concept could be the client and the decision-making body for the development of detailed concepts).
To participate decisively in the demarcation of the problem area and the design area, and in the formulation of objectives
To provide the necessary allocation of resources to the project group
To decide upon the solution variant that is to be selected or to determine an appropriate decision-making body
To create momentum, as required, i.e., to support the project and its proponents.
Difficulties with regard to a rapid execution of the project often arise when the client and the decision-making body are not one and the same, or if the decision-making body is not constituted soon after the beginning of the project, because then the danger exists that at the time of the decision, the decision-making body assumes different notions regarding the appropriate system boundary from other objectives and values.
Such situations are particularly prominent in projects within the public sector. In such cases it is especially important to conduct a careful analysis of the influencing factors as part of the situation analysis and to consider whether the composition of the decision-making body depends on the type of solutions proposed. If this is the case, one should try to bear in mind the potential decision-making body during the synthesis/analysis. This lessens the risk that the reality or the demands of the client and decision-makers are missed in the planning. Nonetheless, a cyclical process sequence, that is to say, a repetition – possibly several times – of single operational steps or their sequences, is sometimes unavoidable. If these steps signify progress, in the sense of ultimately leading to better solutions and not merely resulting in extra costs or needless delays, then this may be accepted as part of a learning process.
Project Group
Find appropriate system boundaries, system objectives, and process objectives in consultation with the client
On this basis, develop functional draft solutions
Analyze these designs to the extent that an evaluation and a rationally justifiable selection are possible
Preliminary Clarifications
Before an assignment (project assignment) can be agreed upon, it is usually necessary to conduct some preliminary clarifications. These serve to elucidate the starting situation, the intentions, and the extent of the problem. They are necessary for estimating the costs of executing the task and for preparing a project assignment. This applies above all to the earlier phases (preliminary study). In later phases, the assignment can usually be derived on the basis of existing information. In that case, preliminary clarifications can be dispensed with or kept brief.
Agreement
This concerns an agreement – preferably written – between the client on the one side and the project group on the other.
The less clear the starting point and the intentions, the more advisable it is to agree upon a project mandate solely for the next phase. Thus, the risk for the client can be reduced.
The further the project has progressed, the more concrete and detailed the project assignment can and must be (for example, an assignment for developing a solution building block within the framework of the overall concept).
Approval
The objectives and criteria underlying the development of the system should be approved by the client, possibly in connection with a rough process plan. This should achieve a mutual matching of objectives and values between the project group and the decision-making body.
However, the objectives and evaluation criteria, declared as valid in this step, should not be regarded as being fixed for all time. The project group and client go through a learning process; they gain a better insight into problem relationships and solution possibilities, which can make it appear necessary to supplement, modify, concretize, and, if need be, even disregard objectives and criteria during the course of the system development. Under no circumstances should changes be made unilaterally, that is, without informing the other participants. Well-functioning communication is therefore an indispensable prerequisite.
The continuous line between commission, situation analysis, formulation of objectives, and approval (Fig. 3.13) represents the process of the search for objectives (or the substantiation of objectives in later phases), in which the project group and the client are equally involved.
Selection
The choice of system, that is, the decision regarding the solution variant to be chosen and potentially further worked on, cannot and should not be the sole responsibility of the project group. If the client leaves the decision and selection to the project group, one has to assume that he or she has succeeded in transmitting his or her perceived objectives, limiting conditions, and subjective standards.
However, with complex systems this prerequisite generally does not happen, and it would be asking too much of the client to expect him or her, in the stage of formulating the objectives, to be capable of formulating the requirements of a solution that is unknown to him, in such a way that another could make the choice for him.
Defines and formulates requirements of the solution in conjunction with the project group
Adjusts his objectives and values during the course of development (learning process) and communicates them to the project group
Selects from a number of concrete solution variants the one that comes closest to his ideas and expectations; therefore, in the decision phase, arguments and perceived values may be taken into account that were not (explicitly) considered during the course of system development – either because they were too difficult to formulate or because they were simply forgotten
The decision-making body often makes its decision such that it is dependent upon measures and process steps that must be triggered in respect of this. In such cases, evaluation results have to be supplemented with specific process plans.
Note: the decision determines and legitimatizes the subsequently worked on variant.
As far as the development of complex systems is concerned, neither the client nor the project group has precise ideas of what the result will look like and how to approach it in detail; both are objectives of a gradual working process.
The client can greatly facilitate development through a balanced collaboration. This should be done when important courses have to be set that do not have to be on a purely objective level. Sensible interim decisions can considerably limit the range of variants and accordingly reduce expenditure on development.
The client needs to be able to make these interim decisions and the selection that follows the evaluation process without being “bulldozed” by the specialists. Also, the client has to continually interact with the emerging solution. This presupposes a mutual exchange of information that should not be limited to a declaration of objectives and to the concluding transmission of planning results.
Reversion and Repetitive Cycles
Cycle (a): objectives emerge from the interplay between a situation analysis and the formulation of objectives.
Cycle (b) expresses the common search for objectives between the project group and the client.
Cycle (c): iteration analysis → synthesis. The process of the solution search, understood as an improvement of solutions as a consequence of the critical analysis.
Cycle (d): ideas for improvement arise from a comparative evaluation.
Cycle (e): agreed targets cannot be met. A return to the formulation of the objectives should be made – with the required approval of the client for a possible modification of the objectives.
Cycle (f): disagreement between the project group and the client regarding the favorite(s). A new evaluation with an altered or newly weighted catalog of criteria possibly needs to be made. The focus is not on the solutions per se (these remain unchanged), but on differences in their assessment.
Cycle (g): new solution (possibly a combination of desirable properties of various solutions). The process begins anew with the synthesis.
Cycle (h): none of the solutions satisfy the client. A return to the search for objectives (as far as a relationship of trust still exists) is made. Possible causes include: the search for objectives not taken seriously enough; misunderstandings between the client and the project group; the client retrospectively changed his expectations, the project group knows nothing about it, as there is insufficient communication.
Reversion and repetitive steps in an expanded PSC
3.3 Model-Based Systems Engineering
Baseline Situation
Systems nowadays become more complex because of customer and market demands; simultaneously, the time to market becomes even shorter, and steadily increasing cost pressure and increasing demands on quality are additional challenges for many product development projects.
There is a long-standing trend to support development processes by using model-based approaches. This was one of the reasons for the establishment of the Object Management Group (OMG) in 1989, which some 100 companies have joined, among them IBM, Apple, Microsoft, etc. The best-known developments of the OMG are Common Object Request Broker Architecture (CORBA) , designed to facilitate the communication of systems that are deployed on diverse platforms (which enables communication between software written in different languages and running on different computers). Another important development in the MBSE context is the Unified Modeling Language (UML), which allows modeling and documentation of object-oriented systems in a standardized syntax.5
This brings us closer to MBSE, which leads away from a documents-based development to a model-based one. The disadvantage of the traditional practice (documents-based development) is that it is accompanied by a large number of describing files (using Word or Excel), which can hardly be kept up to date and joined or integrated with other files. On the other hand, data and models can be maintained consistently when using a model-based development approach. Using models, the system or product to be developed can be better understood, analyzed, detailed, documented, communicated, and transmitted for further processing.
The MBSE approach has been forced and actively pushed by INCOSE (International Council on Systems Engineering) since 2007. The primary goal was increased productivity by minimizing manual interventions for the transmission of concepts, especially when working in different locations.
MBSE Definition
In 2007, the MBSE was defined in the International Council on Systems Engineering (INCOSE) SE Vision 2020 as6 “the formalized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases. MBSE is part of a long-term trend toward model-centric approaches adopted by other engineering disciplines, including mechanical, electrical and software. In particular, MBSE is expected to replace the document-centric approach that has been practiced by systems engineers in the past and to influence the future practice of systems engineering by being fully integrated into the definition of systems engineering processes.”
Furthermore, “Applying MBSE is expected to provide significant benefits over the document-centric approach by enhancing productivity and quality, reducing risk, and providing improved communications among the system development team.”
An MBSE system model comprises all information created in the above-mentioned development steps. It consists of elements that represent requirements, design concepts, test cases, and interdependencies between the elements.
Thus, MBSE may be considered a summarizing name for an interdisciplinary approach that combines best practices of traditional systems engineering with powerful virtual modeling techniques.7
Using our systems engineering concept (Fig. 3.1), we place MBSE into the box Methods and Tools for Systems Design (left foot of the Systems Engineering manakin): it supports systems design (consisting of systems architecting and concept design) and should be inspired by the systems engineering principles, placed at the head of the figure and consisting of systems thinking and the systems engineering process model.
With its methods and tools, MBSE is an indispensable prerequisite for the use of agile concepts (see Sect. 2.4), because working on an “agile” project particularly requires a model-based development environment to be able to integrate and verify products, test results, releases, etc., quickly.
SysML
As mentioned above, the systems modeling language, SysML, was developed from UML as a standardized graphical modeling language (Weilkiens, Tim (2008): Systems Engineering with SysML/UML; Delligatti, Lenny (2013): SysML Distilled). Nowadays, SysML is the modeling language that is most widely used for modeling complex systems in systems engineering. The set of diagrams as defined in SysML consists of a subset of diagrams derived from UML 2 and complemented by SysML-specific diagrams. There are different types of diagrams: the group “structure diagrams” represent the static aspects of a system, whereas the group of “behavioral diagrams” represent dynamic components.
Besides SysML AP233 is another important component of MBSE.8 It is designed as a neutral information model for the exchange of data between systems engineering, systems architecture description and related tools. SysML uses this AP233 data exchange protocol for data exchange between tools such as product data management, computer-aided development, computer-aided systems engineering, and computer-aided software engineering.
SysML supports the requirements for modeling: structure modeling, behavior modeling, and parametrics modeling.9
Miscellaneous
Combination of “top–down” (management aspects) with “bottom–up” (engineering aspects)
Giving all stakeholders access to information on products and their development, and keeping data consistent within complex applications
Facilitating change management, risk, and impact analyses
Allow for early verification, validation or tests
Allow for frontloading approaches with usage contexts, use cases, etc.
Allow for bidirectional traceability of requirements in the process chain
Function-based development instead of component-based
Quality and process support
Facilitation of collaboration and information exchange
Increased speed and efficiency
Support in mastering complexity
Facilitation of the reuse of know-how
3.4 Self-Check of Knowledge and Understanding: Systems Design
- 1.
What is meant by the term systems design?
- 2.
By which categories can we make elements and relations within a system?
- 3.
What do we mean by saying that systems thinking may be applied to a problem and to the solutions?
- 4.
How does the curve of the development expenses ideally run over time? What are the conclusions to be drawn?
- 5.
How does the curve of knowledge of a solution ideally run? How about the curve of admissible ignorance?
- 6.
Do you think it is possible that the knowledge at the beginning of a project may be zero?
- 7.
Do you think it is possible that the admissible ignorance tends toward zero over the course of the project?
- 8.
Is it possible to change/modify the overall concept after the decision at the end of the main study?
- 9.
Are immediate measures in contrast to a systematic systems engineering approach?
- 10.
Explain the different thinking levels of problem-solving with the help of Fig. 3.10.
- 11.
What kind of information is acquired in the single steps of the PSC and is passed over to the next steps?
- 12.
Does the flow of information in the PSC run linear or are there feedback and repetition cycles? If so, which?
- 13.
What is meant by the term MBSE?
- 14.
Which benefits are expected from MBSE? What are the expectations?
- 15.
What is meant by the term SysML? Are there any relations to MBSE?