The following topic describes the development and features of the Systems Methodology.
To see the SM at work, go to Land Force 2010
Contents
The Systems Methodology (SM)
Problem-solving Paradigms
What should a Systems Methodology (SM) look like?
SM Level 2 Step 1 - Using the Rigorous Soft Method
SM Level 2 Step 2 - Exploring the Solution Space
SM Level 2 Step 3 - Focusing on Purpose, Using the TRIAD Building System
SM Level 2, Step 4. Developing the Overarching Concept of Operations
The Systems Methodology Outline Process Model
The Systems Methodology - Overall Process Model
A Conceptual Overview of the SM - with the GRM as Keystone
Background
The need for a Systems Methodology was perceived in the second half of the 20th Century, to show how and why systems engineering worked and was so effective.
Systems engineering was seen as a powerful method for solving complex problems, particularly in respect of major projects in the space program and the defense industry. These early successes were based on systems science and system methods that were themselves relatively new, having emerged in response to perceived limitations in the hard sciences, notably their inability to explain life and the counterintuitive behavior of wholes, or gestalt
Systems methods concerned themselves with the synthesis of whole open systems and with emergence, the latter caused by interactions between the parts within a system. Such methods, although effective, seemed alien and arcane to engineers concerned with methods, based on Cartesian reduction, for creating tangible and material end products.
The need was perceived for a systems methodology, one that was accessible to engineers along with other disciplines from the applied and life sciences, so that the whole process, from addressing the problem to creating the optimum solution, could be understood and pursued.
That need is even greater today, as our world continues to become more complex as predicted by the Second Law of Thermodynamics.
The Systems Methodology (SM)
What is a systems methodology? Arthur D. Hall III, a founding father of modern systems engineering, put it like this:
"Has mankind evolved to a point that there exists, or that with creative additions and re-combinations of modest proportions, there can be shown to be available, a common systems methodology, in terms of which we can conceive of, plan, design, construct, and use systems (procedures, machines, teams of people) of any arbitrary type in the service of mankind, and with low rates of failure?"
Hall was convinced that such a generic, problem-solving systems methodology was, indeed, within our grasp. And he was right.
A methodology, or praxeology, consists of a process, executed by skilled people using methods and supported by tools. A systems methodology, then, is fundamentally a process incorporating system-scientific methods, supported by system thinking and simulation tools, undertaken by people with suitable systems and applied science and engineering skills.
If we define systems engineering, not unreasonably, as follows, then systems methodology becomes the how of systems engineering:
Systems engineering is the art and science of creating optimal system solutions to complex issues and problems.
This is not the only definition, of course. Definitions of systems engineering abound, although they mostly identify how the originator thinks systems engineering should be done, than define the term. There is an INCOSE Fellows Consensus - that states as follows:
"Systems Engineering is an engineering discipline whose responsibility is creating and executing an interdisciplinary process to ensure that the customer and stakeholder's needs are satisfied in a high quality, trustworthy, cost efficient and schedule compliant manner throughout a system's entire life cycle. This process is usually comprised of the following seven tasks:
- State the problem,
- Investigate alternatives,
- Model the system,
- Integrate,
- Launch the system,
- Assess performance, and
- Reevaluate.
This list seems reasonable. However, it does not really state the "how." Moreover, it starts with a statement, not of the problem, but of the problem solution - often the hardest thing to achieve - without explaining how the problem was solved, resolved or dissolved in the first place - so, it implicitly assumes that someone else is the problem solver, as follows
i.e., The problem statement starts with a description of the top-level functions that the system must perform: this might be in the form of a mission statement, a concept of operations or a description of the deficiency that must be ameliorated.
This is a serious issue - if someone else, some customer presumably - has already decided what they believe they want, in order to solve some problem, then the systems engineer would be foolish indeed to underwrite the customer's decision by guaranteeing that the solution system was fit for purpose. For example, if the customer has decided that the solution to their problem is a computer giving some results in near real time, and the systems engineer builds and supplies it - well, the customer had better be right. And if he is not, and the system does not solve the problem, guess who gets the blame. Not the customer, you can be sure. And that is a sure way to discredit systems engineering...
- The Fellows definition presumes that SE is an engineering discipline. There must be a whole host of operations analysts, management scientists, systems analysts, policy researchers, value engineers, cyberneticians, mathematicians, psychologists, physicists, architects, managers, economists, ecologists, etc., etc., who would disagree.
- It therefore tends to situate and confine both the problem space and, especially, the solution space to the domains of engineering - surely an unnecessary and unreasonable restriction, particularly since elsewhere the INCOSE fellows state that: "...The elements, or parts, can include people, hardware, software, facilities, policies, and documents... " It is well established that engineering skills and pratices are inappropriatee to the creation and organization of human activities/systems. See Checkland, P. B., Systems Thinking, Systems Practice, John Wiley, Chichester, 1981
- Further, the mention of customers and stakeholders situates SE somewhere in the commercial / industrial world, which may often be true, but is surely not inevitable.
- Interestingly, the definition of stakeholders seems to have been modified in recent times.
- It used to be: "those who have something to gain, and particularly those who have something to lose, from the successful outcome of a project or enterprise."
- These days, the italicized clause is omitted, which may be seen as seriously diminishing the concept of stakeholder.
- And, most importantly, there is no mention of system design, or design optimization, - cornerstones of systems engineering since the pyramids(!)
Problem-solving Paradigms
SE is about problem solving. There are several problem-solving paradigms in the literature that have been proved useful.
The three diagrams show how the initial task of addressing the issue or problem might be approached. At top left is the General Problem-solving Paradigm, or GPSP. It uses the problem components, or symptoms, to explore the problem space, and to create a model of an Ideal World, in which the problem symptoms would not arise. It then uses perceived differences between the real world and the ideal world to conceive a change agenda. The GPSP emphasizes the Problem
At top right is the Systems Engineering Problem-solving Paradigm, or SEPP. This is a well-known and widely used method of seeking some optimum solution to a problem. It is to be found at the core of most SE processes, either explicitly or implicitly. The SEPP emphasizes the solution.
Immediately above, the previous two paradigms have been welded together, so that the composite paradigm emphasizes the path from Exploration and Enlightenment to tangible solution. The ideas and concepts implicit in this composite paradigm have been used as a basis for developing a systems methodology.
What should a Systems Methodology (SM) look like?
By definition, if it is a methodology, it is context free - it can be used for any kind of problem and to create any kind of systems solution - provided one exists. (In the real world, every problem need not have a solution).
- So, it must also be scale independent and type independent.
- And, paradoxically, perhaps, it must be solution independent, i.e., it must not presume any particular kind of system solution.
- This is important - if a methodology is to have integrity, it must make no assumptions, it must contain no prejudices, implicit or explicit.
- For a start, then, it must not contain any implicit assumptions that a solution will be e.g., a regiment of soldiers, a manned aircraft, an electronic device, or indeed any artifact or technology.
- On the other hand, an SM has to be useful.
- It must enable the practitioners, those applying the SM in order to solve some problem, not only to derive an optimum solution, but also to prove that they have done so.
- Indeed, it should be possible not only to create the right solution, but also to avoid creating the wrong solution.
- So, where a solution has a technological component, users of the SM should be able to guide the choice of fit, form, function and technology as appropriate.
- The SM must not be a straitjacket - the SM should encourage creativity and innovation, while at the same time addressing risks and threats.
The figure, a so-called Behavior Diagram, shows the Systems Methodology at high level - Level 1. It can be elaborated to show higher levels of detail, and in so doing will reveal the processes implied by the built-in methodologies, including the Rigorous Soft Method and the TRIAD Building System. It will also incorporate the application of the Generic Reference Model, which is a tool for systems thinking, in that it represents the "internals" of any system.
The seven steps in the Systems Methodology may be compared with the seven steps in the INCOSE approach mentioned above. They clearly differ significantly.
SM Level 2 Step 1 - Using the Rigorous Soft Method
The SM may be elaborated in several ways. First, each step can be elaborated as a more explicit Behavior Diagram:
Level 1, Step 1 describes the Rigorous Soft Methodology,
SM Level 2 Step 2 - Exploring the Solution Space
Step 2 situates the conceptual remedy (remedial systems solution) in the future solution space, to ensure compatibility, interaction, interoperability, etc., to establish higher levels of purpose and objective, and to anticipate potential resource shortfalls when the systems solution is introduced.
SM Level 2 Step 3 - Focusing on Purpose, Using the TRIAD Building System
Step 3 uses the the TRIAD Building System Methodology.
SM Level 2, Step 4. Developing the Overarching Concept of Operations
It is possible, but unenlightening, to continue this detailed process. Instead, let us look at other ways of presenting and explaining the SM.
The Systems Methodology Outline Process Model
This figure shows the overall process, and what is happening at each stage. Unlike the behavior diagrams above, it does not indicate how these activities are undertaken, but nonetheless gives an insight into the underlying strategy and tactics of the SM.
- problem inspired
- optimal solution driven
- concept before detail
- purpose before function
- functional before physical
The Systems Methodology - Overall Process Model
The following version of the Systems Methodology has been trialed and proved effective. However, its application, operation and success depend to a major extent on the employment of skilled practitioners and domain knowledge of both the problem domain and the solution domain. This is because the methodology is, per se, devoid of such particular knowledge. Instead of providing a solution by "handle-turning," practitioners are required to think, to research, to develop stores of information for later steps, and so on. It is possible to create a different kind of model, in which "pigeonholes" are defined, into which data and information are inserted as the project proceeds. This information-driven viewpoint can complement the process view but, as will be seen, the methodologies on which the the SM is founded generate copious amounts of data in any event.
Notes:
- In the following figure, the process has been presented in 2 columns, to aid reading. Step 5 has been split into two parts, one at the bottom of the left-hand column, the other at the top of the right. These two parts are, however, contiguous.
- You may compare this figure usefully with the original paradigms at the top of the page, to confirm that the SM does, indeed, satisfy its original goals.
- Activities in Steps 5 and 7 are shown with multiple boxes, indicating options.
- Note Step 5/12 - this indicates recursion, in that Steps 2 to 5/7 may be repeated for each physical partition of the overall SoS
- This should be no surprise.
- If a solution system turned out to be a full space mission, then the overall system, the SoS might consist of many interlocking parts
- There could be a lifter/launcher, a crew capsule, a lander/rover, and so on.
- Each of these would be needed to achieve the overall CONOPS
- Each would be a full system in its own right, with its own CONOPS contributing to the overall (see CONOPS (5/13)
- So each would be subject to the careful, logical, rational processes that governed the conception and design of the SoS
- Note Step 6 - it has an interesting approach to design optimization
- Step 7 does not assume a technological solution, although it is compatible with one should it arise.
- Instead, the SM identifies objectively what should be created, what its specification should be, and moreover...
- Proves it.
The seven steps of the original behavior diagram at Level 1 are elaborated and interconnected to present a continuous process of activities.
A Conceptual Overview of the SM - with the GRM as Keystone
An alternative view of the Systems Methodology is shown below:
The SM is more, much more, than process and product. It is a meta-system in its own right, incorporating skilled people, organization, tools, methods, techniques, etc. The SM is for individuals, teams and teams of teams, and can address problems from the small to the global, from the technological to the social and international. It can be used to solve problems, to resolve problems (find a solution that is good enough) and todissolve problems (to so change the situation/move the goalpost that the problem disappears). It encompasses both soft and hard systems methods and ideas, and can afford soft solutions as well as hard onse, and mixed soft/hard solutions. It also employs the scientic method, to ensure integrity. All, provided that the systems practitioners who employ/apply/participate in the SM are sufficiently skilled and aware of the domains in which they operate.
The SM 'bridges' from Problem Space to Solution Space. This notional bridge has a number of blocks, as shown in the figure, with the Generic Reference Model serving as the keystone, holding the whole span together.
From this viewpoint:the GRM is instantiated with:
- features derived from the problem space to achieve missions, and...
- features derived from the solution space, notably to accommodate constraints, threats and opportunities that may be anticipated in the operational environment.
- connections, interactions and 'orchestrations' of these various features to generate synergy and emergent properties, capabilities and behaviors of the whole solution system
Note that the Systems Methodology encompasses a full range of aspects, some of which - such as Process, Tools and Methods - are context independent systems methods, while others, notably Domain Knowledge and Organization, may be situation specific. Domain Knowledge is essential to apply the generic systems methodology to the specific problem or issue...and the systems practitioners select tools and methods appropriate to the particular problem and domain, much as a surgeon selects the particular scalpel appropriate to an operation.
Now go to Land Force 2010 to see the Systems Methodology at work