Don't Panic

Janne J. Korhonen has written a nice and worth to read blog post: There is not a simple solution to every problem, in which he was bringing me Cynefin back to my mind:

• Simple Problems can best be solved via Sense-Categorize-Respond (Best Practice).
• Complicated Problems can best be solved via Sense-Analyze-Respond (Good Practice).
• Complex Problems can best be solved via Probe-Sense-Respond (Emergent Practice).
• Chaotic Problems can best be solved via Act-Sense-Respond (Novel).

Tom Graves has created his useful SCAN framework and compares SCAN here with Cynefin. SCAN divides the sense-making and decision-making also in 4 different buckets:

• Simple and Straightforward
• Complicated but Controllable
• Ambiguous but Actionable
• Not-known, None-of-the-above

As I have written in People in GLUE the difference between success and failure lies in the success of failure of a person, because a person can make the difference. The key reason why in the GLUE Framework the focus is on people.

"Don't Panic",

Douglas Adams (1952 - 2001)

"Don't Panic" is the cover of "The Hitchhiker's Guide to the Galaxy" and in the novel it is explained that the title has two reasons. The first reason is, because the device looks insanely complicated and the second reason is to keep intergalactic travelers from panicking. I personally believe that most Enterprise Architecture frameworks could use a title like "Don't Panic", because the Frameworks look insanely complicated and to prevent those who travel through Enterprise Architecture either by applying or consuming it to panic.

In my GLUE approach I use the concept of the GLUE Decks to tackle complexity. As a reminder there is always a one-to-many relationship between the decks:

While I observe and support the GLUE Journeys through the GLUE Space I match the complexity of the solution to four levels:

1. Re-Use of an already existing solution without changing the solution itself. Most likely high potential to automate or already automated.
2. Re-Use of an existing Architecture (GLUE Discipline Design) so that real changes happen only in build and therefore potentially also on a lower Deck. Off-the-shelf and cloud solutions belong into this category.
3. Change of the Architecture by adding elements which are not existing at the moment.
4. No Idea how to solve the problem

Important aspect here is that the complexity level on the different decks can vary quite dramatic. Therefore to find out the complexity of a potential solution I apply a simple max() function on all Decks and elements in one Deck. The highest complexity decides about the complexity of the overall solution.

In most cases there is a fairly simple answer (Good or Emerging Practice) to most Desire, which is transforming into an existing standard off-the-shelf solution. That transformation is in most cases as an initial starting point not acceptable ("we are special", "we do not accept that our process is dictated by a software supplier" or "change the process without changing the IT solution and get all imaginable benefits"). Reality is that in most cases an adaption to an existing off-the-shelf-solution is a good fit-to-purpose and fairly easy (complicated, complicated but controllable, Re-Use Architecture) to use solution.

The typical conclusion for me is to go to the persons and work close with them. Helping them in seing the potential of a solution even if it means to give up some of the Intentions and Requirements. Interesting enough this is usually not achieveble by pure facts but requires a quite intense person to person work. So Don't Panic, work with the persons. People are relevant, the problem and the solution is only interesting.