A Problem-Solving Process for Modern Cloud
With the Modern Cloud, solving problems is not a “one-size-fits-all” process. Your actions depend on the situation, and you make better decisions by adapting your approach to changing circumstances.
But how do you know which approach to use in a particular situation? And how can you avoid making the wrong decision?
In this article, we’ll look at the Cynefin framework, a tool that helps you make better decisions by assessing your situation.
The five domains of the Cynefin Framework
The Cynefin framework is an exciting model. We discovered it around ten years ago. Dave Snowden created the Cynefin framework. Cynefin, pronounced “ku-nev-in,” is a Welsh word that translates as “place” or “habitat.” However, you can use it to describe the elements of your situation and personal history that influence your thoughts and decisions in ways you don’t understand. It’s pitched as a sense-making framework. Now, like any framework, don’t apply it to a whole company by writing it up on the walls. As architects, the Cynefin framework is a good thinking model.
Sometimes, at the back of your mind, you know something’s happening, and you cannot put things in place. The Cynefin framework has four domains and a fifth disorder domain. The first four domains are:
- Clear, when something is well understood,
- Complicated, it’s understood by few,
- Complex, where there are a lot of unknowns.
- Chaos when you don’t know what’s happening.
There’s a domain in the middle called Confused.
So, if you understand which domain you’re in, you can assess where you’re at, and if you need to be made aware of where you are, you need clarification.
How to apply the Cynefin Framework to the Modern Cloud
When you deal with situations and teams, seeing the problem is sometimes easy. It falls under one of the domains. There are a bunch of practices to apply. When something’s well understood and clear, the practices are different than for something complex. There are various ways for you to handle situations. And if you’re a manager, there are other ways to manage. A chaotic project needs different practices to a project you know well and know what to do.
It’s a valuable thinking tool if you’re going into a new area team or for anything new or novel. The assess/respond piece is useful. If you are looking for feedback or to gain situational awareness, one way is by doing something, sensing what happens and responding appropriately. Once you get a feel for it, you understand what’s happening and can move towards the Complex domain. You’re unsure how things go, so you’re sending out probes. You’re trying to sense what’s happening and then responding.
Complicated is where you understand the rules and what needs to happen, but it is complicated. There might be multiple steps or things to achieve an outcome. So you’re sensing the context and analysing to respond appropriately. A best practice is sensing the category or domain that applies and responding.
Different teams for each Cynefin Framework Domain
How do you model complex? We’ve all found ourselves in chaotic situations. You may be going into an area where something’s happened, and there are no logs or instrumentation, or it’s an old application. You have to take steps to build up awareness and move out of that chaotic situation. And begin to move from Chaotic to Complex. It’s evolutionary to go from high-intensity to a manageable problem.
In software, different types of teams are comfortable working in the grey in situations where nobody is telling them the answer. They’re applying what they know to build awareness and take action to create outcomes they can sense and respond to. They are, typically, your empowered squads or your experienced teams. Nobody is comfortable working in Chaotic, but they’ve built up experience. You may have teams that are good at working in Complex. You can organise your teams around the different domains.
To simplify this, let’s give quick examples of each domain in software development. We had a session with Liz Keogh, an Agile Leader. She had a great talk on using Cynefin with agile teams – you should google it.
Cynefin Framework Examples in Modern Cloud Software
1. Clear
We need Clear examples that have best practices, like maintenance or monthly releases. They are within software and are an understood area. There are fixed constraints around time, budget and performance. You know how to do it well. You can sense what’s happening categorise it, because you’ve seen it before, and you can respond quickly. They are ‘known-knowns’ and are predictable, like traditional delivery methods.
We’ve all done long stints at monthly release and maintenance. It’s a great place to learn important work. They will never go away. And they are critical to earning your stripes as software engineers.There are standard documentation and run books to follow the process. Follow the docs and steps, and you will be fine.
2. Complicated
Complicated can be described as building a new component in an existing system. It’s your known unknowns. You might design a database but not know the structure of the DB or the data model. So you need skills to work it out.
You have not done it before, but a person can help you. You know roughly what to do, but you may need an expert to level you up. They have done it before, but you have not done it personally. It’s an excellent example of something complicated, but it’s a solved problem. A new database table or component is a good example.
3. Complex
A lot of people need clarification on complicated and complex domains. Complex is when you’re working on a new project that the organisation has yet to do, And you’re not even sure if it’s possible. You don’t know good practices because you don’t know what you’re dealing with. So that’s when you bring in the probe idea. We’ve done this multiple times in our careers. Let’s probe and see what happens to learn what this is. We remember doing this and the probe failed, so we did not proceed. You need to bring something from Complex back to Complicated.
And feel safe to fail. You don’t know what you don’t know, and you’re trying things to work it out. It’s very exploratory. It is evolutionary architecture. We’re working towards something, but we have enabling constraints. You must have some constraints so you don’t hit the wall.
We talk about this with the well-architected framework and using cloud tools for feedback and responses so you know you’re on the right track. And you are secure, performant, reliable and cost-optimised. If you’re doing something novel or new, constraints will give you feedback and guidance on where to go next. You must bring Complex over to Complicated and then Complicated to Clear.
4. Chaotic
Chaotic is when you don’t have production support figured out. We’ve all been in production incidents before when something happens, and it’s chaos. It’s all hands on deck. There’s no logic in Chaotic. You can’t predict anything; you must get on with it because you need more information, and doing something gives you more clarity. You realise there’s a memory leak, etc. If everyone’s running around not knowing what’s happening, then doing something is sometimes your only option.
We’ve all been on bridge lines, where you’re probing to build understanding. You need your technical leaders to step in and drive. Context is vital because what may seem chaotic to you and your team may be resolvable by another team you were unaware of. Some companies will be good at production support with mature SRE practices. So, a production incident is manageable and apparent with best practices controlled with operational excellence.
Lead with context and understand the context. You’re applying your context; this may look different from one team to another in your organisation.
5. Confused
Confused could be a new hire who’s joined the team and needs to know what’s happening. If you’ve been there for a couple of years and need clarification, that’s not a good place to be.
You can experience all the domains in a short space of time.
How does the Cynefin Framework apply to Cloud Modernisation?
If a team has been on-prem in a data centre for many years, they know everything and have documented it well. They have constraints, best practices, and it’s an understood area. It’s an excellent steady state before cloud migration.
When a company first moves to the Cloud, it’s very new. There are good practices, but you haven’t done them yet. You will learn from your cloud vendor or consultant that there are different governing constraints for security, reliability, cost, etc., And you must understand what they are. It’s not your environment, so you can’t just call someone to switch on a machine; you don’t own the hardware.
It is Complicated, but it’s an understood problem. Companies that go through migration are in that complicated space. It’s complex because you’re starting to break your extensive system. It’s different for brand-new companies building on a greenfield. There are a lot of unknown unknowns. You try to go towards modern application architecture when breaking up your monolith. There’s lots to examine and line up, and the environment around it is an unknown unknown.
Bring complex over to complicated
Sometimes, you’re working on a system that was well designed ten years ago and is a solid monolith that runs well and makes money, but the people who wrote it have moved on. And you’re looking after the system. You understand it but don’t know what will happen when you start to crack it apart. Because there may be hidden dependencies in the tech stack, so it’s always a challenge. To modernise, you’re bringing the complex over to complicated. You may need to learn modern toolsets for serverless or containers.
There are known unknowns with on-prem, and you build your org, teams and skill sets around that. With cloud modernisation, you must acknowledge you are in a complex scenario, and you need teams that are comfortable with unknown unknowns. You must tailor your work practices, methods and approaches.
Who needs hero engineers?
It’s like the Pioneers, Settlers and Town Planners Model. You want Town Planners with Clear and best practices to keep everything moving. Your Pioneers do Complex stuff because they are fearless of not knowing the answers but are prepared to probe, try and figure things out. There are many models around for those three phases.
Would you want your hero engineers in the chaotic? We don’t want hero engineers at all! We like the Cynefin framework because it uses sense-making. You don’t know what you’re dealing with, a lot of the time.
If things aren’t making sense, maybe you’ve moved across one of these boundaries without realising it. What you thought was Clear with best practices applied suddenly becomes Chaos. Or you’ve gone from Complicated to Complex, and you have yet to realise that techniques, processes and practices that worked yesterday won’t work today. Sometimes, a technical leader thinks they are clear, with best practices and fixed constraints, but the situation is complex. And they’re applying good techniques in the wrong section or sector, with disastrous outcomes.
Cynefin is excellent for modelling complexity and thinking about how to organise around it. It is a great way for you to shape conversations and drive outcomes.
Serverless Craic from The Serverless Edge
Check out our book The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
Subscribe on YouTube and Spotify
1 thought on “The Cynefin Framework”