Tom Graves / Tetradian

Another follow-on to the earlier post ‘Helping others make sense of my work‘, just a quick note to let you know about two current book-projects.

The first has a working-title of The enterprise as story: the role of narrative in enterprise-architecture. This has been a major theme on this blog for the past couple of years or so: more than 40 posts here on various aspects since ‘The enterprise is the story‘. And as in the post ‘The no-plan Plan: architecture as story‘, it’s one of the five key-themes in my ‘no-plan plan‘ for my current and future work-direction. So it’s something I need to get down on paper, in more direct, usable form.

There’s a definite deadline of end of February for this one, because I’ll need it available in time for my presentation ‘The enterprise is a story: a narrative approach to enterprise-architecture‘ at the Integrated EA conference in London on 6-7 March 2012.

The second has a working-title of The business-anarchist: enterprise-architectures for the edge of chaos. This has perhaps been a less prominent theme on the blog, but it’s turned up quite a few times, such as in the post ‘Analyst, anarchist, architect‘. In essence, it’s about being deliberate and responsible about working with disruption in the business-context, preferably before that disruption is thrust upon us – a concern which is rapidly becoming more and more important almost by the day.

I’ve been nibbling at this one since mid-2009, and even wrote a fair chunk of it at various points last year, but didn’t finish it then, in part because it didn’t feel like the right time. Now, post-Occupy and suchlike, it does feel more like the right time, so I need to get it done. It’ll have to come after The enterprise as story, but with luck and lack-of-distraction it should be ready somewhen in April.

There’s also another enterprise-architecture book I’ve been working on for quite a while now with a colleague in Guatemala, Michael Smith. We don’t have a working-title for this one yet, and it’s rather further away in time – somewhen mid to late next year, probably – but it’s probably worth mentioning at this point. It’ll focus on the Five Elements theme that comes up in quite a few places in my work – for example, the structure of the effectiveness model used in SCORE strategy-assessment and the book Real Enterprise-Architecture, and the core of the market-cycle that’s used in conjunction with Enterprise Canvas.

Will let you know when any of the books become ready and available, but thought I’d keep you up to date with this part of work-in-progress, anyway.

Yeah, right. ‘SCAN’. Yet another pretty acronym. What’s the point? What’s the use? Gimme some real examples, huh?

This one’s a follow-up to the previous post “Let’s do a quick SCAN on this”, in which I introduced the SCAN frame for sensemaking at business-speed:

(The above is the updated core-graphic – see ‘SCAN – an Ambiguous correction‘.)

So: some real examples. Let’s get started.

Requirements definition

Let’s say we’re looking at requirements for a new IT-system, and we need to clarify the difference between ‘shall’ and ‘should’ in the requirements-specification.

As soon as we say it’s ‘new’, that tells us that there are unknowns. In SCAN terms, we start from Not-known. And we start pulling outward from Not-known, into the other spaces.

What is there that’s certain, that we know is Simple and straightforward? For example, what rules and regulations and standards must apply to this? In requirements terms, that’s mandatory: that’s going to be a ‘shall’. We can say that straight away: we don’t have to think about it.

What is there that, however Complicated it might be to do it, the system still has to deliver against that requirement? That’s probably going to be a ‘shall’ as well, because it’s over on the same side of the ‘controllable’ fence as the Simple. But we might have to spend a bit more time thinking about this.

What is there that’s a bit Ambiguous? – that we know is going to be a requirement of some kind, but it’s not particularly clear or definite as yet. That’s probably going to be a ‘should’ – desirable but not mandatory. But again, we might have to spend a bit more time thinking about it.

So we keep digging down into the ‘Not-known‘, pulling out requirement after requirement, stretching them out into one of the other three categories.

And note that there’s still uncertainty about both Complicated and Ambiguous: we’re going to have to spend more time on each requirements-item there, to determine whether they really are a ‘shall’ or a ‘should’.

Yet to quote a great comment by Cynthia Kurtz on the previous post:

Give me ten years and I can work my way into making just about anything work (if it doesn’t kill me first). Give me ten minutes and it had better be simple.

So if we don’t have the time to explore further, we treat each item just as they are: Complicated gets squeezed down into the enforced ‘shall’ of Simple, and Ambiguous gently drops back into the acceptance of a less-enforceable ‘should’, where it may still remain somewhat ‘Not-known’ right up until the last moment.

That’s how Agile-style requirements-processes work: just before the start of the sprint (or whatever the development-cycle is called), we compress everything down to Simple, or Not-until-next-iteration. At the end of the cycle, we allow ourselves the time to re-assess what we’ve done, and re-explore the requirements-space for items that we could do in the next cycle. We push the time-box back-and-forth: stretch to review the Complicated and the Ambiguous, the ‘shall’ and the ‘should’; pull some of the ambiguities across to ‘what we we think we can do’; and then compress it back down again to get the work done in the available time.

EA reference-framework

Reference-frameworks are a commonly-used tool for governance in enterprise-architectures. In effect, they’re another type of requirements-specification, but one that straddles across a whole suite of projects, programmes or portfolios, and often aim to apply for several years across the whole of that space. It’s a tool to manage risk, opportunity and cost over the longer term.

(The example above is the raw ‘unpopulated’ shell for the TOGAF 9 ‘Technical Reference Model’. For real-world use, specific technologies would be defined for each of the cells in this framework, as the standard reference-framework for the organisation’s IT technology-architecture.)

A reference-framework is typically used to specify particular technologies for use in particular contexts, in IT and beyond. As with the requirements, there’s a balance between ‘shall’ and ‘should’ and the real-world: the reference-framework says what we want to happen, the real-world tells us what we have, and there’s then the governance-negotiation that goes on between the two. Hence TOGAF Phase G, for example, and the delicate diplomacy needed around architecture-dispensations or waivers and the like. We then also use the reference-framework later on, when reviewing previous dispensations, to see what we should have done ‘in a perfect world’, and explore possibilities to bring whatever-it-is back into line with the intended architecture.

The catch is that most reference-frameworks take a Simple view: everything is portrayed as an ‘is-a’, a ‘shall’, a ‘must-be’. Which tends to bring on a lot of fights, and denigration about ‘the dreaded architecture-police’, because the real-world just isn’t that simple… And this tension is only going to get worse as the business-space becomes further fragmented with outsourcing, cloud, ‘bring-your-own-technology’ and more. We need a better, more flexible way to define and use reference-frameworks.

To reduce the fights, we can use a SCAN to help us identify where we must stand our ground, architecturally speaking, and where it’s safe to back off and let people ‘do their own thing’.

That time-axis in SCAN is important. If we know we don’t have time, we’re forced into a straightforward split between the Simple – what we know we can do, what we know we can support – and the ‘Not-known’ – otherwise described as either “you ain’t havin’ it” or “you’re on your own, bud, we ain’t touchin’ it”. Which, yes, sometimes that’s the only choice we have. And in that case, the reference-framework would describe what’s supported, and what isn’t: which also means that there needs to be the governance to support those constraints in real-world practice – and the clout to back it up without brooking any argument.

Yet most real-world contexts demand a bit more flexibility – which also means that we need the time to support that flexibility, and the governance to support that flexibility, too. Given that stretching of time, we can give a somewhat more sophisticated assessment that covers the full SCAN.

In effect, we extend the simple ‘true/false’ – it is or it isn’t, ‘we can’ versus ‘we  can’t’ – to a more modal logic of possibility and necessity:

• is-a (Simple)  - “we’re a Microsoft house” (that’s what we do, so don’t expect it to be cheap or certain or even doable with anything else)
• is-sometimes-a (Complicated) – “we prefer Windows, and we do that best, but we can also support Microsoft packages on Mac, UNIX and Red-Hat Linux” (it’ll cost extra time and money, but we know it’ll work)
• is-believed-to-work (Ambiguous) – “there are [these listed] equivalent packages on Windows and on [these listed] other operating-systems: we’ve been told they work, but we haven’t yet tested them ourselves” (and if you want us to test them, it’ll cost both time and money, and may not work anyway)
• none-of-the-above (Not-known)- “sure there’s plenty else out there, but we don’t know much of anything about it” (we have no idea what it’ll cost even to find out more about it, and no idea if it’ll work at all with what we have)

A practical catch here is that most current EA toolsets don’t support this kind of modal-logic in reference-frameworks (or anything else, for that matter). Usually the nearest we have for this are composition- or aggregation-relationships: they’re sort-of-usable as a workaround for this, but they’re not quite the same, and can be misleading if we’re not careful.

Anyway, much the same happens with reference-frameworks as in Agile-development: over time, there’s a steady migration of some (but not all) from Complicated to Simple, and some (but not all) Ambiguous to Complicated. Yet some will always remain Complicated; some will always remain Ambiguous; and even more, there will always be some that’s Not-known. A repeated, recursive SCAN helps to clarify what will move between those ‘domains’, and when.

Yup, I admit: I got it wrong. (Well, the kind of ‘wrong’ that happens often in early-stage development-work, anyway. )

In my initial version of the SCAN sensemaking-framework, I wasn’t happy with the ‘A’ keyword for the ‘not-certain but we do have time to make it sort-of work’ domain (upper-right quadrant). I’d started with Agile, but that’s more about a set of methods that we use in that domain. I’d floundered around with a whole bunch of different keywords, but settled for the awkward ‘Actionable but Awkward‘ because I couldn’t think of anything else.

Courtesy of a blog-post I was reading when a comment from the incomparable Cynthia Kurtz about the previous post came in, this is the all-too-obvious alternative: Ambiguous.

(Duh… I shoulda seen that one much earlier… oh well… [beats self with horse-whip, remembers eventually that all that does is hurt... dumps horse-whip, gets back to writing...])

More to the point, in another comment, Cynthia shows that it would work better if I switch the statement round:

I love ambiguous. Only I would say it as “ambiguous but actionable” matching your other three as what-it-is then what-you-can-do. And it is perfect that the N-spot does away with what-you-can-do because it’s not that simple there. I also like how you have “but” on the top and “and” on the bottom, which is meaningful.

I hadn’t noticed that distinction between ‘but’ versus ‘and’ – entirely accidental, to be honest – but again, she’s right. It’s only when we have time to argue that we can afford the luxury of ‘but’; when time is compressed to almost-nothing, all we have time for is the improviser’s ‘Yes, and…’.

Anyway, courtesy of those two exactly-to-the-point comments from Cynthia Kurtz, here’s the updated core-graphic:

More posts about how to use this in real-world practice will be coming up Real Soon Now, I promise!

Hope it’s useful, anyway?

Sensemaking in business? What is this [choose-your-expletive] ‘SCAN‘? Why complicate things with yet another sensemaking-framework? Isn’t SCAN just a rebadged rip-off of Cynefin? And why not just use Cynefin like everyone else does, anyway?

I’ll be providing some detailed worked-examples of SCAN in the next few posts or so, but I’d better get these questions out of the way first, because otherwise someone or other will jump at me about it if I don’t. The quick answer is, yes, there are solid reasons for all of this, and no, this isn’t ‘having a go’ at Cynefin or anything else. Okay?

To answer each of those above questions in turn:

• making sense – and making sense fast - of things that don’t yet make sense, is an essential business requirement, in enterprise-architecture and in just about every other business-discipline
• what we often need for business-sensemaking is something simple, fast, and easily memorable, yet also has all the sensemaking depth behind it – and SCAN supports that need
• the aim is to simplify, not complicate – the main reason for SCAN is to uncomplicate something that’s become almost hopelessly complicated and problematic
• the two frameworks may look similar on the surface, and I’ve intentionally designed SCAN so that they can be used in parallel, but they actually have significantly different roots, roles and methods
• in practice, in most of the business-domains I work in, usage of Cynefin seems a bit like TOGAF for enterprise-architecture – just about everyone says they use it, but almost no-one actually seems to use it as per the published specification

That last point has lead to lots and lots and lots of fights over the past few years: too many fights, between too many people, in which I’ve too often found myself in the painful position of pig-in-the-middle… So in the hope that it’ll defuse some of the drivers for at least some of those fights, what I’m aiming to do here is:

• separate out two fundamentally different types of sensemaking – ‘considered’, versus ‘business-speed’
• explicitly acknowledge that Cynefin fits well with the needs of ‘considered’ sensemaking
• describe how and why Cynefin has proven problematic in ‘business-speed’ sensemaking
• how SCAN sets out to resolve each of those issues, specifically for ‘business-speed’ sensemaking

There’s some overlap between SCAN and Cynefin, obviously, because both are tools for general-purpose sensemaking; but the key point is that they serve and emphasise different business needs.

Business roles

Making sense, to support good decision-making, is an obvious business need.

In practice, there are two fundamentally-different kinds of business sensemaking:

• ‘considered’ – analysis and experimentation, classically done by consultants, professionals, senior management and strategy staff
• ‘business-speed’ – categories, checklists and personal judgement, classically done by line-managers, supervisors and front-line staff

The crucial distinction is available time. If we had the time at the front-line to make a proper ‘considered’ assessment and decision, we’d do so: but we rarely have that luxury. So at ‘business-speed’ we have to make do with a different kind of sensemaking: it’s not as pretty, not as precise, not as ‘scientific’, but it’s pragmatic and practical. Simply what works, at the time, in the time available.

In other words, both kinds of sensemaking are ‘true’, for a given value of ‘true’. The practical question is about which kind is more appropriate – more useful – for a given business need.

Cynefin explicitly positions itself for ‘considered’ sensemaking. To use the Cynefin terms, it emphasises the Complicated and, especially, the Complex domain. I believe it’s fair to say that it aims to elicit insight and understanding by focussing on nuance and subtlety, on emergence in complex adaptive systems, and so on. We do get the most ‘scientific’ results this way: but it takes time.

SCAN explicitly positions itself for ‘business-speed’ sensemaking. To use the Cynefin terms, it emphasises the interplay between the Simple and Chaotic domains. It uses classically simple-yet-powerful techniques such as recursive checklists, to access the full depth of sensemaking whilst still maintaining full business-speed.

In short, the frameworks’ roles and emphases are not the same: as above, they’re both about sensemaking, but they service somewhat different business needs.

Framework roots

Cynefin’s roots go back to at least 1999, and are primarily in the sciences. As its Wikipedia page puts it, “the Cynefin framework draws on research into complex adaptive systems theory, cognitive science, anthropology and narrative patterns, as well as evolutionary psychology”.

SCAN’s roots go back to at least 1986 (the ‘swamp analogy‘ for sensemaking), and are primarily in pragmatics. There’s a lot of science and more behind it – for example, on Jungian psychology and the tetradian, cognitive psychology, textual deconstruction, real-time learning and real-time decision-making – but the focus is always on real-world practice.

In other words, one has a science focus, the other a technology focus. It doesn’t make much sense to try to assess either one solely in the other’s terms.

Practical problems with Cynefin

This section describes some practical problems that I and others have often come across whilst trying to use Cynefin with everyday business-folk in enterprise-architecture and the like – in other words, primarily in contexts that demand ‘business-speed’ sensemaking. I’ll also describe how SCAN addresses and, I hope, mostly resolves each of those problems.

I know it sounds petty, but often the first hurdle is just the name ‘Cynefin’. Even the pronunciation is problematic: I’ve come across several people who’ve talked excitedly about ‘sign-fin’ – which is how standard-English would (attempt to) pronounce ‘cynefin’ – and get very confused when someone else uses the proper Welsh-style pronunciation ‘kuhnevin’.

[It's not that the Welsh pronunciation is 'wrong', because obviously it isn't. It's just that it confuses people, and gives an unfortunate impression of an 'in-group' who know how to pronounce it properly, versus an 'everyone-else' who don't.]

By contrast, SCAN is pronounced exactly as per the standard-English spelling.

We’ve had similar problems around the meaning of ‘Cynefin’. The Wikipedia page explains it as follows:

Cynefin is a Welsh word, which is commonly translated into English as ‘habitat’ or ‘place’, although this fails to convey its full meaning. A more complete translation of the word would be that it conveys the sense that we all have multiple pasts of which we can only be partly aware: cultural, religious, geographic, tribal etc.

In practice, with front-line managers, I’ve possibly lost them at the first word, probably lost them at ‘Welsh’, and definitely lost them by the time we bring ‘habitat’ or ‘place’ into the picture – let alone ‘multiple pasts’ or anything else. I then have to do quite a long explanation as to how and why, yes, this is about business-sensemaking, and it’s useful and important. That’s if they allow me any time to do it, which often they don’t… which doesn’t help.

[Again, this is purely pragmatics: the richness and depth of the word 'cynefin' is indeed valuable, yet the lack of self-description in the name makes it that much harder to get started.]

By contrast, SCAN says straight away what it is and does: we do a scan through the context to make sense of what’s going on.

Cynefin also depends on special meanings of common terms. The worst problems have been around ‘complex‘: Cynefin uses this in the specific sense as in complexity-science, but that’s landed us with huge arguments with IT-folks and others who’ve always used ‘complex’ to mean ‘very complicated’. We’ve had similar arguments around ‘complicated‘ itself; and likewise ‘chaos‘, which Cynefin uses in an uncommon way, quite different from the colloquial usage. Even ‘simple‘ has turned to be not as simple as we’d thought.

[Once again, this is purely about pragmatics: those special-meanings in Cynefin do enable much more precision, but at a significant cost in understandability and versatility, especially at 'business-speed'.]

By contrast, SCAN provides suggested, colloquial terms for what are essentially similar sensemaking-domains to those in Cynefin, but beyond that it leaves terminology intentionally open. Surfacing personal interpretations of terms thus itself becomes part of the sensemaking process.

In my experience, perhaps the most serious problem has been that Cynefin presents way too much scope for methodological confusion – and especially so when people try to use it for sensemaking at ‘business-speed’, where everything will be pared down to the bone, whether we like it or not. The most obvious of these confusions is that it looks like a straightforward two-axis matrix – which it isn’t. Visually, it’s presented as a categorisation-framework – which it isn’t. (Or is. Or isn’t.) There are those four straightforward domain-categories that everyone sees – the SCCC-categorisation of Simple, Complicated, Complex and Chaotic – but then there’s the fifth-domain of Disorder – which is both a domain in its own right and the backplane for everything else – and the ‘squiggle’ – which frankly takes too much effort to explain.

Then there are all the Cynefin methods behind it, which in principle are grounded in complexity-science and so on, but often don’t match up with how most people understand ‘complexity’ in just about any discipline other than complexity-science. In sensemaking at business-speed, we simply don’t have time to do that kind of translation between disciplines – hence no surprise that key nuances get lost in the non-translation. And the general opacity and special-meaning-after-special-meaning of the methods mean that there are – as I and far too many others have discovered the hard way – all too many options for ‘illegitimate’ usage of Cynefin, and not many ‘politically-correct’ usages that actually do make practical sense in our work-domains. So in practice we end up saying, yes, it’s a sort-of four-category framework that isn’t, sort-of, that’s why it has those pretty curved boundaries, sort-of – and then just kind of hope for the best, hiding behind cautious phrases such as ‘inspired by Cynefin‘ and suchlike. Which is not a good way to use anything.

Sure, Cynefin’s terminology is wonderfully precise, and likewise its methods: in skilled hands, and given enough time, it really can work wonders. But in practice, all too often, it’s been a bit like letting business-folk loose on a typical EA toolset: it’s so dependent on everything being done exactly right, that it doesn’t take long for the whole thing to turn into an impenetrable tangle of misunderstandings and confusion – the exact opposite of what we’re aiming for in business-sensemaking. And for ‘business-speed’ sensemaking, we simply don’t have time to sort out that kind of mess.

[A reminder again that I'm not saying Cynefin is 'wrong' - because clearly it isn't. All I'm saying is that these are the kinds of methodological problems that I've seen arising time after time, in real-world practice, in enterprise-architecture and the like.]

By contrast, SCAN is bald and straightforward: it makes no pretence of being more than a simple cluster of four categories, arising from a plain ordinary two-axis matrix – and if we want to, it can be used, and useful, just like that, with nothing else. (In fact it can even be used as a single-axis ‘matrix’ – the tension between Simple and Not-simple, known and not-known.) It can, however, also go a lot deeper than that – yet all still with the same set of categories, all of the way.

A bit more detail on SCAN

The real power of SCAN comes not from the frame itself, but from what happens when we use that frame in conjunction with an equally straightforward set of systems-thinking principles. We can use those principles to any extent and any depth that we need – including none at all.

To use that usefully-precise Cynefin terminology, we could split those principles as follows:

• Simple: repetitive rotation between multiple views or perspectives or focus-themes – such as in a checklist or, here, a simple four-category frame
• Complicated: reciprocation – balance across a system – and resonance – the ‘snowball effect’ (positive-resonance) and damping (negative-resonance)
• Complex: recursion – self-similarity at different levels – and reflexion – patterns, particularly ‘the whole contained within the part’
• Chaotic: cognitive-dissonance – deliberate-mismatch to trigger ideas – and serendipity – allowing ideas to arise in unexpected ways

In terminology that might be more familiar for enterprise-architecture folk, this is about iteration and allowing emergence of new ideas and requirements, much as in any of the Agile development methods. It’s done at real-world speed, not ‘sit-and-think-about-it’ analysis-paralysis; there’s an explicit architecture to it, but it’s not the old Waterfall-architecture of ‘big-requirements-up-front’. It’s kept as simple as possible, but it’s not simplistic: there’s real depth behind it, whenever we need.

What we’re after – one of our key success-criteria – is when someone says, “Oh, I hadn’t thought of it that way…”, and then develops the whole discussion in a new and different direction. In other words, useful insights, arriving ‘from nowhere’, at business-speed.

In essence, SCAN is a ‘stealth’ form of context-space mapping. For simplicity, it’s constrained to a single type of base-map, but we can still apply any other overlay – including the Cynefin frame – to use as a cross-map in conjunction with any or all of those systems-thinking principles above. So it’s simple enough, and familiar enough, not to scare people off: yet we can go down into whatever depth we desire – or dare – in whatever little time as there may be available to do it.

Different trade-offs, different roles

To me, as a practitioner, I’d guess that the key difference between Cynefin and SCAN is that they make different trade-offs between precision versus flexibility, sophistication versus simplicity, and several other suchlike themes. Perhaps the best way to illustrate this difference would be the comment of an old friend of mine, who said that his greatest challenge as a mathematician working in aircraft-design was to make his mathematics sufficiently imprecise to be useful.

Another anecdote comes to mind here, a conversation some years ago in Lisbon. One of the people there was passionately holding forth about the inadequacies of English as a language: “We should all be speaking French!”, he exclaimed. “French is the language of diplomats! It is exact; it is precise.”

“The advantage of French is that it’s precise”, was the quiet reply. “The advantage of English is that it isn’t.”

Cynefin’s advantage is that it’s precise, a science-based ‘language’ appropriate for the needs of complexity-consultants engaged in ‘considered’ sensemaking.

SCAN’s advantage is that, by intent and design, it isn’t precise – which makes it a better fit for the more pragmatic needs of ‘business-speed’ sensemaking.

Different trade-offs, different roles.

Different choices.

But probably important that we don’t mix them up?

Over to you for comments and suchlike, anyway.

What’s a quick way to start making sense of some context? – fast enough to help in making good decisions fast, too?

If you’ve been watching this blog or any of my other writing, you’ll know I’ve been working on this one for years, worrying at it like a dog with a bone. My first books were actually about a variant of this, three decades and more ago. In recent years, mostly for enterprise-architecture, I’ve developed or re-used a number of approaches: the tetradian dimensions, classic Five Elements, context-space mapping, all the different themes that came together for Enterprise Canvas, and much more.

There’s a lot there, with a heck of a lot of theory behind it. But that’s the problem: there’s a lot of it, and there’s a heck of a lot of theory. Sigh…

What’s really needed is some sensemaking-structure that’s quick, simple, snappy, that’s as easy to grasp, and as ubiquitous in use, as something like SWOT.

And I think I may have found one, with this:

“Let’s do a quick SCAN on this.”

It’s a form of sensemaking that actually comes down to two very quick questions:

• Is it simple, or not?
• How much time do we have to make it work?

Visually, this gives us a simple sort-of-two-axis-framework that looks like this:

[You could use the plus-or-minus symbol ± as a quick scrawl for this - particularly as it's both visually-descriptive and gives that sense of uncertainty yet sorting things out, "plus-or-minus a bit, here or there...".]

And you choose what each of those domains will mean. It’s your context, hence your choice: intentionally, there are no preset ‘special definitions’ here.

Looking at anything in that space, is it Simple, Straightforward, makes Sense; or Not-known, Not-sure, Not-certain, a kind of niggling ‘None-of-the-above’? That’s our horizontal-axis: a simple sort into what we already know how to handle, and what we don’t; what we’re certain about (for now, at any rate), and what we’re not.

[The key here is what we might call the Inverse Einstein test. Einstein once said that craziness is doing the same thing and expecting the different results. On the simple side of the scale, that's true: if we do the same thing, we should always get the same results. But if we do the same thing and don't get the same results, that automatically pushes us to the other side of the scale - for now, at least, until we've had a chance to do some sensemaking about it.]

If there’s no time at all to make sense, but we’re dealing with something that doesn’t make sense, that’s what we’d do: split it straight away into the stuff that that we know, and the stuff that we don’t, and then get on with it straight away with the bits that we can do. The important part is to not throw the ‘stuff-that-we-don’t-know’ into the too-hard basket: instead, we keep it to one side, clearly labelled ‘None-of-the-above’.

When we do have time – our vertical-axis here – we apply the same test, but stretch it out a bit. Think of it as the Blu-Tack® school of sensemaking, perhaps, because we always start with this sticky blob called ‘Not-known’ or ‘None-of-the-above’. Or perhaps like stretching pizza-dough. Anyway, what we’re doing is stretching that ‘None-of-the-above’ out into four rather more distinct domains:

– Is it Simple and Straightforward? – we know what to do, and we can do it fast, with simple rules or simple guidelines.

[In practice, this means that we could probably do it with what we already have, or with something that we can buy off the shelf or train people to do in a couple of days or so. Keep it simple, keep it cheap, keep it working: that's what we'd expect here - or aim for, at any rate.]

– Is it Complicated but still Controllable? – it might take us a bit of analysis and an algorithm or two, but we’re certain we can make it into a predictable, predefined, packageable process. One of the keys here is that it’d be ‘fit-and-forget’: once we’ve solved it, it stays solved.

[This'll likely take some significant time, and possibly some serious costs, but importantly it'd be a once-off investment: once this kind of problem is solved, we shouldn't need to do it again. We hope...]

– Is it Actionable but Awkward, always a bit Amorphous and self-Adapting, sometimes almost an ‘Anything-goes’? – we know how to do it, but we have to watch for patterns, textures, trends, work with experimentation and emergence. It’s always similar, or sort-of-similar, but we can never be certain that it’ll be the same. Typically anything that involves working with real people, or anything that connects directly with the real-world, is going to have at least some of this. The key difference from the Complicated is that we can’t solve it as such, we have to keep ‘re-solving‘ it, time after time.

[This is not going to be a once-off investment: we're going to have to go through the same loops time after time, yet likely with subtle differences every time. Which means there'll be an ongoing training effort, and ongoing costs. Which is fine, once we know it: what placing something here will do is help us accept that fact.]

– Is it still Not-known or None-of-the-above? – Not-sure, Not-certain, No-sense-yet, even No-idea or Not-a-clue…? The point is that all of those are fine: that’s what sensemaking is for, after all. Whenever any kind of unplanned-for-change happens, we’re always going to have a bit of this; likewise in innovation, where we’ll actually want to go into this space of ‘the unknown’. The crucial concern is that, rather than hiding these items away in the ‘too-hard basket’ and vainly hope that they’ll disappear on their own, this gives us a known place where we keep track of them, where we do acknowledge that they exist, and work on them as best we can.

[In practice, this is the realm of skill and experience - the troubleshooters and trailbreakers and mapmakers and make-it-up-as-we-go-along improvisers who work with the uncertainty and create new pathways that others can follow. People who can do this reliably and well are often hard to find, hard to grow, rarely come cheap, and rarely fit well with anyone else's rules: so if this part of our business depends on this, we need to respect that fact, and plan accordingly.]

Note that we always end up with some of what’s going on still in the Not-known area: it gives us something to go back to later, if you like.

And we can also apply the same SCAN on each of the areas that we’ve found, separating those out into their own Simple, Complicated, Awkward and still-Not-known. May well be some interesting surprises there, too – sometimes useful surprises as well.

What we do with this depends on the business, and the context. Scientists would classically aim to follow a path from idea to hypothesis to theory to law, which in effect is None-of-the-above (a new idea) to Awkward (an uncertain hypothesis) to Controllable (a more certain theory) to Simple (a ‘scientific law’). Many businesses will want to push to make everything as Simple as possible too, because that’s often where the profit is mostly easily made. But others – an advertising-agency, for example – will often want to explore out in the idea-space of ‘None-of-the-above’; and one person’s Simple might well be another’s confusingly-Complicated that would collapse in chaos whenever time runs short. In other words, it all depends on what the needs might be; and those, in part, are what we aim to find out here.

So this isn’t a fixed ‘one framework fits all’: it’s much more fluid than that, more adaptable to the way that real people work in real business contexts. The aim here is that this gives us a quick, simple, straightforward way to get started, to make sense and map out what’s happening, and hence make quick choices that do make sense in practice.

There’s a lot more to this, of course, and a lot more ways we can use this, as I’ll explore in subsequent posts on this. But for now, that’s it – all we need for basic sensemaking in business is to start with the question:

“Let’s do a quick SCAN on this?”

Comments or questions, anyone?

[Note: In case anyone's wondering where this comes from, its real roots are a sort-of Jungian model I described in the chapter 'Can't we explain this scientifically?' in my book Inventing Reality, first published way back in 1986. Perhaps take a look at the original text: it may amuse. Or something. ]

There’ve been quite a few Twitter-responses to my post ‘An economics challenge for enterprise-architects‘, about a literally-fundamental flaw in present-economics, and what we as enterprise-architects could do about it.

(This gets long again: sorry…)

Read more…

As usual, the previous post ‘The architecture of a no-money economy‘ ended up way too long and involved and ‘wordy’. Sorry…

So let’s do a shorter version, in some ways going a bit deeper, but concentrating only on the issues and suggested actions.

Here’s the problem: there is no way to make a possession-based economy sustainable.

(Trust me on that one. I’ve been researching it for at least the past couple of decades: the best outcome we can get from a possession-based economy is ‘The Worst Possible System‘, in which most resources automatically end up where they’re least needed.)

Which is a problem, because what we think of as ‘the economy’ is actually a money-based economy built on top of a barter-based economy built on top of a possession-based economy, scaled up to a full global scope.

Which means, in other words, that there’s no way to make what we think of as ‘the economy’ sustainable.

Which means that in the longer-term – or even in the medium-term, at the rate we’re currently going – if we don’t find an alternative that actually works, we’re dead.

Oops…

So here’s the challenge: find a way to run an economy, in a radically different way, that actually is sustainable. Start at the household level first; then scale it up to a work-team or business-unit; then an entire organisation; and keep on scaling up towards a full global scope.

Big challenge? Yep. Big stakes too…

We can’t use money for this, or any form of so-called ‘alternative currency’. The problem isn’t money itself, but rather the fact that money is a standardised form of barter, which assumes that we have something to withhold from others in order to barter with, which in turn depends on the notion of ‘right to exclude’ that’s built into the notion of possession. And that’s the part that doesn’t work: which means that nothing else that’s built on top of possession will work, either.

The only thing I’ve found that does work is responsibility – literally, ‘response-ability’, the ability to choose appropriate responses in accordance with the needs of the context. Mutual responsibilities interlock within a social context: we can build upward and outward from that fact. Without any form of possession.

But this is where it gets interesting…

For a start, money vanishes from the economy. No banks, no insurances, no pensions, no social-security, no medical bills or grocery-bills or school-bills or college-bills or lawyers-fees or consultants-fees, no sales-commissions, no savings or loans, no credit-cards, no mortgages, no monetary taxes, no salaries, no pay-rates, no threat of lost income from lost job, no threat of monetary fines. Gone. All gone. Can’t use them, either as stick or carrot, or any part of the economy.

Because possession doesn’t work, the entire property-model that we know and, uh, well, know, disappears as well. There are property-responsibilities, in the same sense as we talk about ‘project-owner’ or ‘process-owner’; but all those much-vaunted ‘property-rights’ vanish. Gone. We own something because we declare responsibility for it, and for no other reason. (This isn’t a fiction, by the way: most ‘traditional’ property-models operate this way. What we think of as normal, they rightly regard as an aberration.) So we can’t use that as a stick or carrot, either: whether via the offer of property, or the threat of loss of property, it isn’t going to work.

(It’s not that we can’t make a ‘property’-type model seem to work: that’s actually quite easy to do, and that’s what the present possession-economy does right now, after all. It’s that we cannot build anything of that type that does not automatically fall back to an unsustainable ‘Worst Possible System’. That’s why this challenge is a lot harder than it looks.)

We don’t possess ideas, so ‘intellectual property’ vanishes completely. (It never made any sense anyway, so it’s no loss.) We can be responsible about ideas, but they’re not ours to possess. They never were.

We don’t possess people, either. We can’t really talk about ‘our’ people: that’s treating people as possessions, and the only time when people are assets is when they’re slaves. Not a good idea, especially when you have no possession-based way to bribe or bully them into staying in your chosen place. Which, by the way, means that the usual family-model – ‘to have and to hold’, of children in parental ‘custody’ and the like – also vanishes, in much the same way that no-one ever really possesses a cat. Tricky, that…

Almost all of the usual controls disappear from this scenario. No stick that we can wield, no carrot that we can control. Hmm…

How do we get an economy of any kind to work under these constraints? A global economy? An industry? A town or village? A company? A school? Even a family?

Definitely an interesting challenge… especially compared to what we think of as ‘normal’ at present…

(We know it can be done, because, again, this is how most ‘traditional’ societies operate. But in most cases they do so only in small family or tribal groups in agrarian or nomadic contexts – not huge sprawling megacities dependent on complex supply-chains, high technologies and very high energy-demands. Same idea, very different scale – and scale is where so many of the really hard architectural problems arise…)

As I see it, just about the only way to make this work is by reconnecting to enterprise, via shared-vision and the like. Which is why whole-of-scope enterprise-architecture turns out to be really important in this kind of economics.

Which is why this is a challenge for enterprise-architects almost more than for anyone else.

So: Interested? Over to you for your ideas?

Oh, and for an extra challenge: how do we get from here to there?

[Update: Forgot to mention: my sort-of-novel Yabbies is in part an exploration of these themes: Share & Enjoy, perhaps? (At present, download the whole book for free from here.)]

A couple of days ago I wrote an intentionally-controversial post on my Sidewise blog, saying that ‘The future of money is that it has no future‘.

Was I being serious? Yes. Very serious: I really do mean it when I say that the only feasible future for money and the money-based economy is that it has no future.

Which in many people’s eyes would no doubt immediately mark me as some kind of nutcase. Or worse.

To which all I can say is that if they don’t know how proper futures-work actually works, and how to apply it in practice, that’s their problem, not mine.

Perhaps they needn’t worry, though: the money-system that they know and, uh, love, isn’t going to vanish overnight. (Or rather, it almost certainly will, when the change actually takes place; but that change is probably a fair while off yet. Probably…) My point is that as enterprise-architects we need to be fully ready for that change when it comes: otherwise collectively and societally we really are going to be in a mess.

Which means it’s a topic that as enterprise-architects we perhaps really ought to be exploring right now?

Read more…

What do I do, and how do I do it? What’s the nature of my work, and the methods that I use? And for that matter, why?

That’s perhaps the shortest summary to a request by Anthony Draffin, in a comment to my previous post ‘Not quite bus-pass day‘:

On a selfish note… It’s apparent that the common thread to dowsing, printing and enterprise architecture is your ability to look at a field holistically and apply logical thought to extract inconsistencies and errors, as well as looking at new ways of doing something more efficiently to meet the original aims. That’s a rare skill. Have you given thought to documenting how you go about doing this? While I imagine it’s the application of a number of taught skills, the way you put these together must be far from ubiquitous. Have you considered teaching this? Personally, as a 27 year old, I want to soak up as much of your approach and thought process as you’re willing to offer.

(Warning, this is going to be another (very) long one, mainly because there’ll be several case-studies.)

Read more…

Happy to announce that I’ve at last gotten round to publishing my sort-of-novel Yabbies. Hooray!

(I perhaps ought to say ‘completed and published’, but as you’ll see, ‘completing’ isn’t quite the right word, since much of the content is made up of story-fragments that could be assembled in just about any order.)

At present you can download the full content in PDF format for free from the Tetradian Books website.

More details and background to follow, but for now, here’s the book-blurb:

“Yabbies. Funny little things, all in their own world at the bottom of the dam. A bit like us, ain’t they? Can’t see a thing for all the mud in the water; bits and pieces drift down, in any old order, all out of sequence, an’ we have to make sense of them as best we can.”

This unusual novel explores ideas about sustainability from a different angle: that we can’t achieve a sustainable world without a system of law that fully supports it. To make that happen, we would need truly revolutionary change in the way we see our world: a refocus of passion from possession to purpose. In some ways, as one of the characters here explains, we may not have much choice:

“The whole system is so fragile that there’s a real risk it could collapse at any time, in a really big way. Those problems are inherent in the system, so to speak, so that the whole thing is held together by little more than wishful thinking.”

But what would happen if only some countries made that change – and others didn’t? What would happen to trade, to international relations, to everyday living? How would they deal with each other’s business-visitors, or tourists? Yabbies explores these themes through story-fragments, each piece as if drifting down to us through the waters of time, different characters describing their own worlds and experiences each in their own unique voice. And perhaps a little magic, too.

Yabbies first appeared more than a decade ago as YABI – Yet Another Book Idea. Although it has taken many forms over the years, as an interactive website, screenplay, annotated text and more, this is its first time available as a conventional novel. This new edition includes a background section on the ideas and principles behind the story, and also a suggested timeline to link the fragments together.

Author Tom Graves is best known as a writer on a broad range of non-fiction topics – from the structure of organisations to the structure of magic, and much more besides. He applies the same perceptive eye and acerbic humour to this story, using fiction to explore some of the deep-questions and ‘undiscussable’ themes of the present day.

Share and enjoy, perhaps?