All of the Problems! How I Stay Centered

Most of my job as an architect in the early days of a product being developed lives in the realm of disorder. You're in the process of really getting to the heart of the problem that you're working to solve and as you define that, I need to analyse the options of how we can technically create these solutions. As I work through the problem, the picture becomes clearer and gradually, I'll get to the point where I have a solid plan and code is starting to be written to implement it. Sometimes other problems will get thrown up along the way. When that happens, I need to figure out where the new problems sit on the scale of "WTF?!" to "oh yeah no problem".

A few years ago I was shown the Cynefin Framework. The Cynefin Framework was developed in the early 2000's at IBM as a sense making device. As a side note, it's nice to see a Welsh word in tech language (cynefin is Welsh for habitat). For the non-Welsh speakers reading this, it's pronounced kun-ev-in. Anyway, I probably picture this diagram in my head on a daily basis at the moment. Whenever I'm considering a problem or when a new problem gets raised, I think about where it sits on this diagram.

Link to original file

My thought process tends to go clockwise, starting at chaotic. The first step is, we have a problem. We discuss it, we make sense of it, define it and eventually begin to come up with an idea of how we think we could solve it with the software we're building.

I then enter the complex domain. I have an idea of an end solution to the problem. I have to think about how we can technically solve that problem in the larger context of our entire system. This domain for me will usually involve some proof of concept work and eventually I'll come up with a plan for a technical implementation to help us get to our end solution.

The next domain is complicated. For me this is where I actually start putting some high level work into our architecture, making sense of how this implementation actually fits in. I see this step as the part where it goes from being an idea in my head or on paper, to being an implementation. This part can be slow and a bit frustrating for me personally, but when the solution is taking shape, it becomes a very rewarding part of the process!

Eventually you get to the simple domain. The architecture is now in place so here we're fleshing out the details and putting all the implementations in place using well known solutions and techniques that I've used lots of times before.

Problems don't always need to start in the chaotic domain.

A problem can start in any domain. Sometimes a problem will come up that will go straight into the simple domain, probably because you've already gone through the other three domains while working through a similar problem. It may just be something you've solved a hundred times before in your development career.

I personally think the framework can be useful in lots of applications. It's definitely not just useful for new startups or new projects. It could be helpful even in well established software projects. I don't believe it's usefulness is limited to the technical world either.

So using this framework is how I stay calm in a world of disorder. I don't panic, I categorise the problem and that helps me stay calm. When I look at a problem and have no idea how to solve it, I know it's fine because it's not in the simple domain yet. I just need to work on it until it gets there.