Complexity of services has to be explored and can be exploited. In the very begining we need to understand how complex the system is and place it in the continuum from ordered to unordered state. Cynefin is the framework that helps to do that.
Cynefin framework “can be used to provide different views on an issue, to make sense of diverse problems by positioning them in appropriate domains and then to identify suitable methods for dealing with those problems. Cynefin can also be used to understand how issues and problems evolve, either of their own accord or as the result of deliberate planning, through different domains as they, and their context, change over time.” (Hasan & Kazlauskas, 2009)
The framework is divided into 5 general contexts, or domains, reflecting a degree of order as well as relationships between cause and effect. Each domain implies the need for a different form of management and a leadership style with the adoption of corresponding tools, practices, and conceptual understanding. These domains are:
“Simple and Complicated domains assume an ordered universe, where cause-and-effect relationships are perceptible, and right answers can be determined based on facts. Complex and Chaotic domains are unordered, meaning that there is no apparent relationship between cause and effect. This doesn’t mean that this is no cause-and-effect, just that it’s not apparent or obvious. While the ordered part of the continuum (simple and complicated) can be managed based on facts, the unordered part requires intuition and recognition of patterns. Consequently, the tools and methods that work well in the simple and complicated domains tend to be less effective (or completely ineffective) in the complex and chaotic domains.” (Dettmer, 2011)
|How to identify?|
|Characteristics||Ordered, stable, repeatable||Ordered, stable, discoverable||Un-ordered, fluid, unpredictable||Un-ordered, turbulent, intense|
|Cause and effect||Clear cause-effect relationships evident to everyone||Cause-effect relationships discoverable but not immediately obvious to everyone||Cause-effect relationships can only be perceived in retrospect||No clear cause-effect relationships|
|Questions||Asked and answered||Asked but not answered||Not asked, but we can get required information then decide what to ask||Not asked, not answered|
|Answers||Right answer exists||More than one right answer possible||No right answers, but many competing ideas||No point in looking for right answer, many decisions to make and no time to think|
“The fifth central domain is Disorder, which is the destructive state of not knowing what type of causality exists and thus not knowing which way of working is best. While problems may legitimately be allowed to exist in the other four domains if approached with suitable solutions, those in states of disorder are normally harmful and should be guided into one of the other domains.” (Hasan & Kazlauskas, 2009) Usually, Disorder state can be resolved or at least explained on the higher level of view. For example disorder on the level of a private soldier can be the part of the considered military operation on the level of commander.
“Most matrices imply some value judgment about which cell it’s better to be in. The Cynefin framework makes no such assumption, other than that disorder should be avoided. Instead, it merely describes domains.“ (Dettmer, 2011)
Different people can interpret the same situation in perspective of various domains. “The stronger the importance of the issue, the more people seem to pull it towards the domain where they feel most empowered by their individual capabilities and perspectives.” (Kurtz & Snowden, 2003)
How to use Cynefin?
Every domain has its most effective way to be managed and delivers services. Quality and success expectation also vary in case of ordered and unordered domains. Brief recommendations how to use Cynefin are given in the Table below.
|How to manage?|
|Technics||Standard operating procedures||Scenario planning||Complex adaptive systems thinking||Crisis management|
|Expertise||Low or medium level of expertise required||High level of expertise required||Expertise important but with balance with creativity||Expertise important to enforce a power|
|Communication||Provide clear, direct communication||Listen to conflicting advice||Open up discussion||Provide clear, direct communication|
|Network||Strong connection between the center and components, weak connection between individual components||Strong connection between the center and components, strong connection between individual components||Weak connection between the center and components, strong connection between individual and components||Weak connection between the center and components, no connection between individual components|
|How to deliver service?|
|Main focus||Efficiency||Expertise||Creativeness||Rapid response|
|Practices||Apply best practices||Apply good practices||Allow emergent practice||Discover novel practice|
|Principal actions||Ensure that proper processes are in place||Create panels of experts||Make experiments, simulate, create prototypes, use methods that can help to generate ideas||Take immediate command and control actions to reestablish an order, look for what works instead of seeking right answers|
|Optimal processing||Assess facts -> Categorize them -> Follow established procedures||Assess facts -> Analyze them -> Choose any of possible solutions||Experiment -> Assess results -> Choose solution based on observations||Act on intuition -> Observe the immediate effects -> Decide to follow the direction if the action effective, or rapidly respond with another option if it doesn’t|
|What to expect?|
|Quality||Good results every time||High certainty of quality of results||Low certainty of quality of results||Uncertainty of quality of results|
|Success||Easy replication of successful projects||Every successful project increase like hood of success of next||Success in one project provides experience but don’t increase like hood of success of next||Success in project does not depend on success or failure of others|
Let’s consider a couple of the examples of how to use Cynefin. In the context of every domain, the same problem can be resolved by different ways. The direction how to solve the problem became clearer when current domain state is identified.
Example 1 – resolve problem with enterprise application performance.
- After analysis of symptoms, problem was classified as common. Administrator knows the procedure to follow. So that is the Simple domain. Resolution is straightforward – according to administrator guide, the specific configuration option has to be changed.
- After analysis of log files, vendor’s experts detected that the problem is in the Input / Output subsystem. They developed two alternative options with similar effects that could help. That is the Complicated domain. The resolution is to choose one of the good practices to optimize data volumes on the disk array and follow it.
- Symptoms did not point to the source of the issue. The administrator has no idea what resolves the problem. That is the Complex domain. Direction for resolution is to do some experiments and choose a solution based on observations. So administrator is going to use trial and error method. The first try is to add indexes to the database. The second one is to optimize access to the data volume where DB tablespace is located. In parallel administrator opens the service request for vendor support.
- The problem with performance appeared suddenly at the end of the quarter when an application is needed for the whole company success. The problem must be resolved urgently. Administrators are under huge pressure. They do not know what the source of the problem is and just panic. Problem-solving became Chaotic. The ways out is to select from administrators a potential leader and give him corresponding authorities. The first task is to move from Chaos to Complex domain. A leader should intuitively define most probable causes of the problem and begin the trial and error experiments as in the Complex domain. Another way is to start with potential solutions that are easy and quick to check. That allows making as many “cheap” mistakes on early stage with high probability to find the right solution as possible.
- A senior administrator is on vacation. Junior Administrator received complaints about low application performance. Because of small experience, he even doesn’t understand the problem. Under a pressure of users, a junior administrator is scared and totally paralyzed. That is typical Disorder. The problem cannot be resolved on the current level. The only way is to ask experienced senior administrator or external expert to analyze the situation and find corresponding solution in any of the other four Cynefin domains.
Example 2 – Virtual Machine provisioning.
- Provisioning of VM with standard characteristics. That is the Simple domain. A virtual machine has to be deployed as self-service from the Service Catalog.
- Provisioning of VM with non-standard features which is out of Service Catalog. That is the Complicated domain. An administrator or another expert has to be involved to get this job done.
- The actual task is to develop Service Catalog for VM provisioning. What VMs should be added or removed from the catalog in perspective of needs of the next year? The task is vague enough, so that is the creative Complex domain. A methodology that allows collecting and analyzing future needs has to be created and tested. Service Catalog has to be redesigned following findings.
How resistant are the boundaries between domains?
“The boundaries between each domain are deliberately fuzzy, indicating that there are transitional zones between them. Typically [but not always], a particular system in question will reside primarily in one domain, though it may occupy a position that puts it at least partially in another zone”. (Dettmer, 2011) “In that sense, the boundaries we consider are more like phase changes than physical boundaries”. (Kurtz & Snowden, 2003)
Vertical transitions across ordered or un-ordered domains usually don’t get much resistance from fluid Simple<->Complicated and Complex<->Chaotic boundaries. Systems move back and forth across these boundaries quite often. Traffic is manageable enough. Complicated<->Complex boundary separates ordered and un-ordered domains so it is less penetrable and requires some force to be crossed. Simple<->Chaotic is the strongest of the four. It is very dangerous but the most powerful if used wisely.
Boundaries might resist differently in one direction or the other. For example movement from the Complex to the Complicated domain can be much easier than the opposite way. Boundaries might also have various forms in a different context or for different people.
To explain different behavior of boundaries (Kurtz & Snowden, 2003) use set of metaphors. In some cases boundary is like “the shallow river [that] can be crossed by anyone at any place, and thus control over crossing is difficult to achieve. However, it is easy to tell when one has crossed it … because one’s feet get wet.”
There are contexts when boundary is “the high plateau … because you may not be aware that you have crossed the boundary until it is too late and you drop off the other side. The worst place to get lost was on a plateau – there are often heavy mists on high plateaus, and people lose their sense of direction and head directly off a cliff.”
How dynamic is the Cynefin framework?
A system can stay stable in one domain for a long time. However, sometimes there are reasons to move it into another domain. Decision makers can do this intentionally or “changes in external conditions or internal system modifications may push a given system from one domain to another without leaders being aware of it, if they aren’t paying attention.” (Dettmer, 2011)
Rotating along the counter-clockwise cycle from Simple toward Chaotic domain decreases the order of the system. In contrast, clockwise movement decreases complexity as well as increases system’s stability and predictability.
Processes and Technologies play fundamental roles in the Simple domain. Moving counter-clockwise Processes and Technologies became less and less important. At the same time role of People dimension significantly increases. Tasks and problems in the Complex and especially in the Chaotic domains can be resolved by People only.
Let’s consider individual characteristics of inter-domain movements.
- Simple -> Chaotic. Every system naturally degrades with time. When decision makers ignore this fact and don’t look after the system, at some point it goes down into Chaos. That is a harmful process.
An example of such movement is when nobody looks for available space in the storage array and free space suddenly ends. When applications stop, administrators who are used to work under strict and linear procedures of a Simple domain, can’t find the right solution and panic.
- Chaotic -> Simple. Usually, Chaotic situation is so catastrophic that decision makers can accept solutions that would have previously been unacceptable as a price of order. For example, a situation with out of space in a storage array can be cardinally resolved by deletion of less valuable data to resume mission-critical applications. When situation stabilized and additional disk space acquired, deleted data can be restored from the last backup according to proven procedures of the Simple domain.
- Simple <-> Complicated. Movement from restricted Simple to less ordered Complicated domain allows us to find good practices to resolve problems or ways to provide new services. Implementation of new knowledge and experience into procedures returns us back to the Simple domain. Such periodic movements develop the system adopting it to dynamic changes of the world. The relative size of such improvements can be small or medium. For example, backup practices should be regularly reconsidered by experts and after some enhancements employed in updated procedures.
- Complicated -> Complex. Sometimes experts in the Complicated domain cannot resolve tricky problem or vise verse are overconfident in their solutions. Movement from the Complicated to the Complex domain allows generating new creative ideas and approaches not limited by a preconceived or outdated opinion of experts. Trial and error method of problem solving is a good example of Complicated to Complex boundary crossing. Tasks like a big data analysis can also be performed only in a Complicated domain.
- Complex -> Complicated. In the Complex domain, many competing ideas are generated. To be exploited, they need to be refined in perspective of balance between their benefits and disadvantages. This kind of movement is the process that consists of a selection of the most stable and feasible patterns to transfer them to the Complicated domain for ordered representation. Let’s consider the example when IT architects during the Complex phase of a project developed 5 alternatives of architecture. After Complex to Complicated refinement, only 2 architectures with different characteristics but similar value and cost remain. Experts within Complicated domain make selection between last 2.
- Complex <-> Chaotic. Movement from Complex to Chaotic domain usually caused by wrong management and/or unexpected circumstances like a change of project scope or loss of key resources. This movement is not so harmful as Simple to Chaotic boundary cross but still requires transition back as soon as possible. That needs robust and intelligent management. Somebody has to make a decision and check if it helps to stabilize the situation. Sometimes the first try is unsuccessful, and several Complex to Chaotic and back iterations with different decision patterns are required. A resistance of vertical fluid boundary is not so strong as horizontal, so such iterations are less painful as Chaotic to Simple stabilization. Small and medium size open communities are more resilient to such movements than large bureaucratic ones. Let’s consider the example when a group of solution developers moved from Complex domain to Chaos because of shift of deadline on early dates. One of the ways to stabilize the situation is to prioritize and focus on most critical and easy to implement functionality and postpone other features for future releases.
There are several other types of domain-to-domain movement. Some of them are just a combination of basic ones. Others are less obvious jumps over boundaries like direct Simple to Complex movements. To offload our document of boring details, such transitions remain out of our consideration.