Uncertainty, uncertainty everywhere

You know what's the most common error people make when trying to embrace DDD? They tend to focus on DDD's specific DSL (terminology, composition) - entities, boundaries, aggregate roots, etc. because they think that this particular modeling model (OMG, recurrence detected, stack overflow comin' ...) is a game changer. But it isn't.

It's useful (it's an ubiquitous language for modelers :)) & makes co-operation easier, but what's really important is joint domain crunching between domain experts ("business") & modelers ("IT") TOGETHER. Even having DDD tools in your hand you still can't assume that domain expert(s) will provide you all the necessary data pre-processed & well thought-through, you'll just classify it as entities or value objects & bammm, you're done.

Learning, understanding and making sense of the domain (initially unknown or barely known) is still the biggest challenge to beat (with a shared responsibility for).

Uncertainty, here we come then, but sadly not all problems are alike & there are various ways to approach different types of unknowns to be crunched. That's what Cynefin aims to help with.

What's Cynefin?

Cynefin is a conceptual model for crunching uncertainty - or in other words: classifying problems / jobs / tasks that need processing. It's being strongly evangelized by Dave Snowden (who, as far as I remember is an author of the model) & Liz Keogh - who has had a great presentation about Cynefin at BuildStuff 2015.

Do we need a model for that?

To be honest, until recently, I didn't feel that urge :) Problem is just a problem -> you approach it & use full power of your smarts to head over it: analyze, identify & evaluate options, document learnings, validate whether problem is solved in the end, etc. Not a big deal - standard way of doing stuff.

That's all truth, but past experience has taught me to approach intuitively (or "automatically") different kinds of uncertainty in a different way ... It's really important because attacking a problem in a wrong way, with wrong assumptions (for example: trying to analyze chaos or confusing complex problems with complicated problems) may not only not bring any valuable outcome, but also be a source of major frustration & disappointment. I find Cynefin a good "ubiquitous mini-language" to describe categories of problems to people I collaborate with - it seems to simplify things a lot & save a lot of explanations (just like GoF Design Patterns do for low-level code engineering or EAI Patterns for high-level systems architecture).

Let's give it a look.

Cynefin 101

Here comes a visual map (src.: Liz Keogh), to help you get through category descriptions:

Obvious obviousness

In some cases the work / job / task you're approaching is something you find very similar or analogous to what you've done in the past. You already know what has to be done, what are the major risks, how to decompose & approach work, what to track & how to measure outcome. There's barely anything that could surprise you, so you can easily plan & execute work activities. No risk, no-brainer - but also no fun, no challenge, no learning & most likely not much to be gained (if there was, why wasn't it gained earlier?).

That's the area of OBVIOUS problems.

Crunch through like you mean it

But not all problems are that obvious - sometimes you approach a problem with more unknowns, but based on brief overview you already know that it can be solved in a way of straightforward decomposition & analysis. It's comprehensible. It has a lot of causality & ordered logic within - that may not be fully understood & clear now, but it's just the matter of time & effort - a capable person(s) can crunch through it.

That's the area of COMPLICATED problems.

When Shit meets Vent

For some 'old-school' people all problems seem like two categories above. Well, if the only tool you have is a hammer, suddenly all problems look like nails, right? :P Anyway, (un)fortunately reality is not that simple & once in a while you approach a huge pile of ... something that's just too:

huge
tangled / coupled (with too many, strict dependencies)
overgrown with out-of-core-domain abstracts
etc.

to just analyze through (& understand as a whole). There's hard to find any 'loose knots' to start with. There's hard to chunk whole stuff into smaller, separate problems. Instead of typical analysis what you should do is to run some punctual experiments & learn what you can from them.

That's the area of COMPLEX problems.

Chaotic Evil

And there's another category of uncertainty to make whole picture (almost: there will be a twist) complete - problems you can't make any sense of at all (at the 1st & 2nd glance), where you don't find any causality, that seem unstable and illogical. If any kind of analysis you try does not lead to sensible findings (because, i.e. you get non-idempotent results), you're facing CHAOS problem(s).

When in chaos, you don't analyze, you don't overthink, you act immediately (& still learn from observations).

When in doubt, who do you call?!

But life's a bitc... I mean - life's life & sometimes there's a lot of uncertainty about uncertainty, so ... sometimes you may have insufficient (or contradictory) signals to clearly determine which area your problem belongs to. In such case - welcome to DISORDER - dangerous limbo hung up between categorized problem areas.

And that's basically Cynefin -> classify your uncertainty & adjust your approach to area it belongs to. Keep in mind that approach always involves "a learning element".

Where can I learn more?

There are plenty of resources available on-line:

Still warm (I'm writing this on 25th Nov 2015) Cynefin mini-book: http://www.infoq.com/minibooks/cynefin-mini-book
Good introduction on InfoQ: http://www.infoq.com/articles/cynefin-introduction
Cognitive Edge (Dave Snowden's company) website: http://cognitive-edge.com/
Intro on Youtube: https://www.youtube.com/watch?v=N7oz366X0-8
Of course there's also Wiki page: https://en.wikipedia.org/wiki/Cynefin

Embracing uncertainty with Cynefin