When dealing with problems, we not always know if these problems were complex. And if they are complex, how complex? Is there a tool for measuring complexity? If there is, it would be beneficial to measure or at least categorize the problem complexity before starting to solve it. Such measurement would help to regulate the solution complexity as well, since complex problems also demand complex solution, with rare exclusions from this rule. If you disagree, we will be getting deeper into this topic in the next section.

In 2007, Dave Snowden and Mary Boone published a paper A Leader's Framework for Decision Making in Harvard Business Review 2007. This paper won the Outstanding Practitioner-Oriented Publication in OB award from the Academy of Management's Organizational Behavior division. What is so unique about it and which framework we describe there?

The framework is Cynefin. This word is Walsh for something like habitat, accustomed, familiar. Snowden started to work on it back in 1999 when he worked in IBM. The work was so valuable that IBM has established the Cynefin Centre for Organizational Complexity and Dave Snowden was its founder and director.

Cynefin divides all problems into five categories or complexity domains. By describing properties of problems that fall to each domain, it gives the sense of place for any given problem. After the problem is categorized as one of the domains, Cynefin then also offers some practical approaches to deal with this kind of problem:

These five domains have specific characteristics, and the framework provides both attributes for identifying to which domain your problem belong, and how the problem needs to be addressed.

The first domain is Simple, or obvious. There you have problems, which can be described as known knowns, where best practices and an established set of rules are available, and there is a direct link between a cause and a consequence. The sequence of actions for this domain is sense-categorize-response. Establishing facts (sense), identify processes and rules (categorize) and execute them (response).

Snowden, however, warns about the tendency for people wrongly classify problems as simple. He identifies three cases for this:

• Oversimplification: This reason correlates with some of the cognitive biases described in the next section.
• Entrained thinking: When people blindly use the skills and experiences they obtained in the past and therefore become blinded to new ways of thinking.
• Complacency: When things go well people tend to relax and overestimate their abilities to react to the changing world. The danger of this case is because from being classified as simple, such problems quickly escalate to chaotic domain due to a failure of people to adequately assess the risks.

For this book it is important to remember two main things:

• If you identify the problem as obvious—you probably don't want to set up a complex solution and perhaps would even consider buying some off-the-shelf software to solve the problem, if any software required at all.
• Beware, however, of wrongly classifying more complex problems in this domain to avoid applying wrong best practices instead of doing more thorough exploration and research.

The second domain is Complicated. There you find problems, where expertise and skills are required to find the relation between cause and effect since there is no single answer to such a problem. These are known unknowns. The sequence of actions in this domain would be sense-analyze-respond. As we can see, analyze replaced categorize because there is no clear categorization of facts in this domain. Proper analysis needs to be done to identify, which good practice to apply. The classification can be used here too, but it requires to go through more choices and also some analysis of consequences needs to be done as well. That is where previous experience is needed. Engineering problems are typically in this category when clearly understood problem requires the more sophisticated technical solution.

In this domain, assigning qualified people to do some design up front and then perform the implementation makes perfect sense. When a thorough analysis is done, the risk of implementation failure is low. Here it makes sense to apply DDD patterns for both strategic and tactical design, and to the implementation, but you probably could avoid more advanced exploratory techniques like event-sourcing. Also, you might spend less time on knowledge crunching, if the problem is thoroughly understood.

The Complex is the third complexity domain in Cynefin. Here we encounter something that no one has done before. Making an estimate, an even rough estimate is impossible. It is hard or impossible to predict the reaction in response to our action, and we can only find out about the impact that we have made in retrospect. The sequence of actions in the complex domain is probe-sense-respond. There are no right answers here and no practices to rely upon the previous experience might not be helping. These are unknown unknowns, and this is a place where all innovation happens. Here we find our Core Domain, the concept, which we will get to later in the book.

The course of actions for the complex domain is lead by experiments and spikes. There is very little sense to make a big design upfront since we have no idea, how stuff will work and how the world would react to what we are doing. Work here needs to be done in small iterations with continuous and intensive feedback.

Advanced modeling and implementation techniques that are lean enough to allow to respond to changes quickly are the perfect fit in this domain. In particular, modeling using EventStorming and implementation using event-sourcing are very much at home in the complex area. The thorough strategic design is necessary but some tactical patterns of DDD can be safely ignored when doing spikes and prototypes, to save time. However, again, event-sourcing could be your best friend. Both EventStorming and event-sourcing are described later in the book.

Fourth domain is Chaotic. Here is where hellfire burns and the Earth spins faster than it should. No one wants to be in here. Appropriate actions here would be act-sense-respond since there is no time for spikes. It is probably not the best place for DDD since there is no time and fiscal budget for any sort of design available at this stage. 

The Disorder is the fifth and final domain, right in the middle. It is where the transition to chaos usually happens from any stage. Underestimated complex problems with unrealistic deadlines bring teams to stress, leading to disorder at the later project stages, from where all slips to chaos.

Here we only have a brief overview of the complexity classification. There is more to it, but for this book, the most important outcome is that DDD can be applied almost everywhere but is virtually of no use in obvious and chaotic domains. EventStorming as a design technique for complex systems would be useful for both complicated and complex domains, along with event-sourcing, which suits the complex domain best.