Model assisted problem solving in multi-actor environments

Building further on one of my previous blogs on model-based enterprise engineering I came to the conclusion that model-based enterprise engineering really is an application of what I would like to call "model assisted problem solving in multi-actor environments". This may sound as an over-the-top generalisation, but it think it also signifies the core competency of enterprise engineers and enterprise architects. And at a time of crises I think it is wise to better understand the core competency of our profession.

Note that the word "problem" should be interpreted in a broad sense. Moving from e.g. a formulated business strategy to a plan for its actual execution can be regarded as a "problem".

When moving from a "problem" to a "solution", one will go through the earlier discussed assess/aim/act processes:

1. During the assess process, models are used to capture knowledge about the problem, its context, and what should be done about it. This requires more than modelling skills alone. It also requires elicitation techniques, as well as strategies to get multiple people (multi-actor environments!) to agree on a shared understanding of the problem.
   
2. In the aim process, models are used to evaluate alternatives and make explicit what the chosen solution will be. Again, this requires more than modelling skils. Agreement on, and more importantly, lasting commitment for, the chosen solution in a multi-actor environment certainly is no trivial task. In terms of the models formal analysis can be made wrt different properties of a desired solution.
   
3. During the act process, the models serve as a base to guide the implementation/execution of the chosen solution and/or for compliance testing. Again, the multi-actor environment is likely to produce additional challenges.
   

During the act process we may end up in a "recursion" in the sense that it needs to the need to solve several smaller problems. For example, the creation of a highway connection between two cities first requires a high level analysis of the problem it would aim to solve, followed by a design of the actual highway in terms of the path it will follow, overpasses needed, junctions needed, etc. Once this has been established, the act process involves several smaller projects e.g. focusing on the creation of a specific bridge. The same aplies to enterprise transformations. It starts at the portfolio level dealing with the general directions. This leads to a number of programs executing different parts of the transformations needed. Each program will comprise of more manageable chunks of work in terms of projects.

Clearly, this cycle of problem solving using models does not only apply to the architecting or engineering of enterprises, or aspects thereof (such as its IT). In that sense I would like to argue that we (as architects) need to take a closer look at more general theories on problem solving. See for example a survey included in the WikiPedia.

When dealing with model assisted problem solving in multi-actor environments, we are typically confronted with situations of a high social complexity. In other words multiple actors with multiple, contradicting, stakes in the problem and its solution. What makes matters worse is the fact that the problems themselves tend to have a messy or wicked nature. Authors like Horst, Rittel and Conklin, a summary of which can be found on the WikiPedia, typically characterise wicked problems as:

1. There is no definitive formulation of a wicked problem.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not true-or-false, but better or worse.
4. There is no immediate and no ultimate test of a solution to a wicked problem.
5. Every solution to a wicked problem is a "one-shot operation"; because there is no opportunity to learn by trial-and-error, every attempt counts significantly.
6. Wicked problems do not have an enumerable (or an exhaustively describable) set of potential solutions, nor is there a well-described set of permissible operations that may be incorporated into the plan.
7. Every wicked problem is essentially unique.
8. Every wicked problem can be considered to be a symptom of another problem.
9. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution.
10. The planner has no right to be wrong (planners are liable for the consequences of the actions they generate).

which are indeed rather challenging indeed.

In solving such problems, models can play very important roles:

1. Models may provide insight. Either directly or indirectly by deriving views from the models that answer/focus on specific questions/issues. This insight might be needed towards an informing purpose, a decision making purpose, analytical purpose, resolving of disputes between stakeholders, etc.
   
2. Models may provide guidance towards the execution of work. This could be design activities, the operational execution of work, etc.
   
3. Models can be used as a means to share knowledge about the problem and the selected (and not selected!) solutions.
4. Models can be used to explicitly represent the state of a problem solving process. In other words, the understanding of the problem/solution at some point in time.
   
5. Models can act as a formal a steering/regulation instrument.
   
6. They can act as a common frame of reference, i.e. an ontology.
   
7. They can be directly executable or at least formally interpretable (MDS and MDA!).

In further evolving the idea of model assisted problem solving in multi-actor environments, we can make a distinction between the different domains in which problems are solved (medical diagnosing, enterprise engineering, software engineering, ...) as well as the wickedness of the problem itself in terms of social complexity and cognitive complexity.

Having said this, it is probably interesting to see how the ADM (architecture development method) of TOGAF relates to general problem solving approaches.