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
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.
What is a systems methodology? Arthur D. Hall III, a founding father of modern systems engineering, put it like this:
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:
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:
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
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...
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 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 whirled and the ideal world to conceive change agenda. The GPSP emphasizes the Problem
At center 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.
At right, 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.
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).
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.
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,
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.
Step 3 uses the the TRIAD Building System Methodology.
It is possible, but unenlightening, to continue this detailed process. Instead, let us look at other ways of presenting and explaining the SM.
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.
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:
The seven steps of the original behavior diagram at Level 1 are elaborated and interconnected to present a continuous process of activities.
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 to dissolve 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:
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
July 2007