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.

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.

TOGAF TRM Orientation Views ((c) The Open Group)

(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.

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?

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.

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. ]

(This gets long again: sorry…)

Most of the responses pose good questions, which I’ll come on to in a moment. But first, one response was so far wide of the mark that I’d better not say who wrote it:

• “A strategy that depends on a rethink of the basics of Economics has a low chance of success.”

Apart from one comment I’d made right at the end of the last post, asking for ideas about a possible ‘roadmap from here to there’, there was nothing that was about strategy either in that article, or in the two posts that preceded it. It was all about structure, and narrative – in other words, about architecture, and what has to happen before strategy-exploration can take place. Where the heck that idea about strategy came from, I do not know: to be blunt, it was a complete red-herring, and one that we must reject at this pre-strategy stage.

As for “a low chance of success” etc, all I can guess is that the person concerned didn’t read the article properly, or even at all. The key point made very early on in the article was that we don’t have a choice about this: there is a fundamental flaw right at the root of current economics – a flaw so serious that, if unaddressed, it would inevitably cause a complete catastrophic collapse of the entire economic system. The evidence that we’re seeing now indicates that that point of failure is not far off: hence we must find ways around that structural flaw, and rebuild the overall system to bypass it.

The practical problem is that the flaw is right down in the foundations of the system: so yes, we are talking about a major rebuild here – but we do not have any choice about the scale of that rebuild if we’re to have an economic system that will work at all at large scale in the longer term. That’s what I’ve been trying to address in an architectural sense in this brief series of articles. Hence the correct way to frame that person’s assertion above is actually the exact opposite:

• “A strategy that depends on avoiding a rethink of the basics of Economics has a low chance of success.”

More accurately, that kind of strategy – the most common type of ‘strategy’ at present – has a zero chance of success in the longer term. That’s the problem I’ve been aiming to face here: I just wish others were more willing to face it, too, instead of trying so very hard to pretend that the problem doesn’t exist…

A much more useful comment came from Martijn Linssen:

• “Great post but link to #entarch confuses // it was a pretty “controversial” post and I liked it, but ending references to #entarch sent me into the woods”

In other words, what has any of this to do with enterprise-architecture?

Short answer: a lot.

The slightly longer answer is that this is enterprise-architecture, albeit at a much larger scale than most of us are familiar with.

Think about it: An enterprise-architecture is about identifying the structures and relationships and resources and other items that an organisation needs in order to deliver on its value-promise within its broader shared-enterprise. Enterprise-architecture also assists in designing and developing those structures and the like; and also to help keep things on track in change-management and deployment, and perhaps in some aspects of operations too. Now compare that to economics: in essence, it’s exactly the same role and task. Economics is enterprise-architecture, or an aspect of enterprise-architecture, at a societal or even global scale.

(To be more precise, most current ‘economics’ is actually a subset of business-architecture, misframed as ‘enterprise’-architecture. It’s a term-hijack, in which the small subset of economics that deals with business-transactions purports to be the entirety of the scope, and actively prevents any discussion of any other facet of full-scope ‘management of the household’. In short, the same kind of problem as IT-centrism, but ‘business-centrism’ in this case, and writ large – so large that most people seem to unable to see the mistake at all. Oh well…)

So it’s actually the same as any other enterprise-architecture gig:

• What’s the overall enterprise-vision?
• What are the drivers?
• What structures exist (‘as-is’) and/or are needed (‘to-be’)?
• What are the services within this context?
• What are the protocols between services, the processes within them?
• What forms of governance are needed, both to guide change, and at run-time?
• What are the resource-needs and resource-flows, and what governance do they need?
• What are the information-flows, and their structural trade-off between ‘backbone’ versus agile?
• What are the performance-metrics and reporting?
• What ‘dashboards’ are needed at each level and in each context?
• What are the relationships needed between people to make this enterprise work, and the structures and processes and governance to support those relationships?
• Overall, in the human sense, what’s the story?

And so on: it is enterprise-architecture – just on a larger scale. And the reason why all of this is of real, practical, immediate concern to everyday enterprise-architects is actually the same as why business-architecture matters to IT-architects: we can’t do our domain-level work without at least being aware of risks and opportunities and impacts from the big-picture context. Enterprise-architecture is also one of the few disciplines within the business-context that must take a longer-term view: and as a former professional-futurist, the issues I’ve described here may be barely-visible out only on the far horizon at present, but believe me, they’re coming up on us very fast indeed. (As I said in one of the previous posts, anyone who thinks otherwise isn’t thinking…) We need to be ready for those changes: and enterprise-architecture would – or could – form a key part of how we can get ready.

Another sense in which this is like enterprise-architecture is that this is mostly about decision-support – not decision-making. The task here is about identifying options, and the implications and consequences of each option. In some cases we might go so far as to develop preliminary designs – though mainly to give decision-makers something more tangible to argue about. Yet the decisions are not ours to make: we don’t attempt to usurp the authority of those who do have the duty of decision-making. In this case, that authority and responsibility – gods-help-us… – rests primarily with politicians and the like. “Interesting times ahead” indeed… But at least we can be – and should be – ready for root-level change, even if others aren’t.

We do need to be wary of the age-old enterprise-architecture trap of jumping to solutions before we’ve even assessed the context. The popular obsession with ‘alternative-currencies’ is one example of this unfortunate trait. Another example in the Twitter-stream came from Michael Vrijhoef:

• “Shortest answer to the posed problem: Unified common goals, disposal of religion and value of ‘self’”

Well, yes, that would be close to my preferred solution too: but fact is that we’re nowhere near any solution-stage as yet. It’s not a wise move to go jumping for ‘the answers’ when we’re still nothing like clear enough about the questions that we need to ask here. (There’s a very good reason why in the TOGAF ADM we don’t look at any would-be ‘solution’ until Phase E of the cycle: the same applies here.) Keeping ‘solutions’ at bay until we do understand the context is one of the hardest parts of the enterprise-architecture discipline: and it’s one that will really matter in this context.

We also have to be especially aware – and wary – of surface-level ‘solutions’ that fail to address any of the deeper underlying issues. Sadly, such would-be ‘solutions’ are very popular, mainly because they change only the things that we know and understand – giving us the comforting illusion that we’re doing something about it, whilst still allowing us to avoid facing ‘the unknown’ where we know the real problems reside. Roland Ettema sent a link to a McKinsey article [behind their registration-paywall, unfortunately] that illustrates this trait all too well:

• “interesting timing Tom, see mckinsey quarterly #sustainable ‘In search of a sustainable model for global banking’.”

The blunt fact is that minor tweaks to the banking-system won’t make any real difference here: in essence, it’s like tweaking the position of a single deckchair on the Titanic in the forlorn hope that this will somehow save the ship. It won’t: the problems are much deeper than that – and much more visceral, too.

Chris Potts came up with some useful comments to link us back to classical-economics:

• “Echoing my recent Tweet, each of us is an economy-of-one. If we’re in a household, it’s a layer on top. // Being an economy-of-one, each of can use the 4 Factors of Production to create value (Land, Labor, Capital, Enterprise) // Re: Factors of Production. The assumption of possession is in the eye of the beholder. #entarch”

And Richard Veryard pointed to a previous post of his on much the same themes:

• “I talk about the 4 factors of production in my paper on the future of money. #LongFinance ‘Sempiternal Coin‘”

Chris is certainly correct about two key points there. One is the fractal nature of economics and its enterprise-architectures: much the same issues repeat at every scale. If a pattern that we develop won’t work at some scale, it probably isn’t actually working properly at any scale – and in fact that’s we’re dealing with right now, in mainstream economics. It’s not quite true to say that an individual is ‘an economy-of-one’, because the functional focus of economics is not so much within but between ‘economic entities’; but the economic relationships between individuals is probably the place where we need to ‘test-bed’ any new economic ideas – because if they don’t work there, they won’t work anywhere.

The other valid point Chris makes above is about the dangers of possession-based assumptions. The catch there is that the ’4 Factors’ arose not only out a possession-based culture, but one in which even the nature of the purported ‘possession’ was different to now – namely the primarily pre-industrial context of early 18th-century Britain. There, the aristocracy still possessed most of the Land; the still relatively-new merchant class possessed the monetary Capital; between them they would create the Enterprise, “the animal spirits of the entrepreneur”, around some joint venture. The collective Labour, whilst technically possessed by itself, was not far off a possession of the aristocracy – via the remnants of the feudal-system – and of the merchants – via a vast yet carefully-maintained gulf between the incomes of rich and poor, and an equally carefully-maintained absence of any social safety-net (particularly severe in the new cities, where the old safety-nets based on the mutual-responsibilities of village or extended-family became fragmented and no longer available). What we don’t see in that context is the major capital focus of the industrial age, namely machines: the nearest equivalent in that period would usually be the physical structure of a ship, the ‘machine’ for a trading-voyage.

Even in the later industrial period, it’s also very much a physical model of economics: in fact we see an almost complete absence of awareness of many typical capital-type concerns in the present age, most of which are not physical. For example, there’s conceptual capital, such as ideas and innovation and other ‘intellectual property’; or relational capital, such as goodwill or market-share or the fabled ‘eyeballs’ of the dot-com era; or aspirational capital, such as brands and enterprise shared-vision and the like. Even by their very nature, it’s definitely problematic to view any of those forms of capital from a ‘possession’-oriented lens. There’s also financial capital, yet even that is often in a much more abstract form from the simple monetary finance of the 18th-century: and when trades and ‘ownership’ can last for literally milliseconds or less – or never exist at all, as in some futures-derivatives – there are significant problems there too around the classical notions of ‘property-rights’ and possession.

So yes, the classical ’4 Factors’ do still apply – sort-of. But they need a radical rethink even for present-day possession-based economics; whilst for any truly viable and sustainable economics – such as the responsibility-based approach that I’ve been somewhat-tentatively exploring so far – that rethink of all economics-assumptions would have to be radical in the most literal sense, right down to its deepest roots.

So there’s a lot to do here: and yes, it is a kind of enterprise-architecture, albeit on a much broader scale than most architects would deal with at present. If you’re interested, let’s keep talking?

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.)]

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?

What’s the background?

Let’s first do a quick recap of that post.

It’s fairly obvious to everyone, I’d think, that globally the money-system is in deep trouble at present, and hence the entire money-economy on which it’s based. It’s also fairly obvious to most people that the problems are structural and systemic. In other words, this time we can’t simply ignore it and wait it out, as in other ‘recessions’ – the underlying structural flaws have finally broken right through to the surface, which means that the more we try to make it work, the worse the problems will get. An interestingly awkward ‘inconvenient truth’…

Hence a lot of well-intentioned people are doing intensive study on ‘alternative currencies’ and the like. Yet unfortunately, by the very nature of what they’re trying to do, none of those proposed ‘alternatives’ will work, or even can work, in the longer term or at a societal scale.

The reason why they won’t work is that all of these would-be ‘solutions’ are only scratching the surface – yet the real problems they’re trying to resolve are several layers beneath that surface. Those various scratchings won’t touch the deeper flaws at all: at best all they’ll do is make things worse by giving the illusion that something useful has actually been done…

The simplest way to put it is that the money-economy is an inherently-dysfunctional overlay on top of another inherently-dysfunctional overlay – the concept of barter – on top of yet another inherently-dysfunctional overlay – the concept of possession – on top of what could actually be a functioning economy: one that’s based on mutual interlocking responsibilities.

(By ‘economy’ I mean the term in its literal sense as ‘the management of the household’, on any scale from a work-task to a literal household to an organisation to an industry to a country to an entire planet. In other words, a perfectly ordinary fractal-type pattern-structure, ‘self-similar’ at every scale, much like so many other things we deal with in enterprise-architectures.)

There are some really serious problems that we’re facing here, especially from an architectural perspective. One of the more obvious symptoms is that a possession-economy is inherently inefficient and ineffective in its management of resources: via mechanisms somewhat analogous to gravity, most resources will automatically tend to end up where and when they’re least needed, resulting in what we could describe as ‘The Worst Possible System‘. In a money-economy, money confers ‘rights’ to access resources, yet it too is a resource that’s subject to the same possession-based ‘gravitational’ pressures – which further magnifies the resource-misallocation problems.

In short, it’s a mess: yet there’s no way to escape it in a money-economy, because it arises automatically from fundamental flaws that are baked right into its core. And this is true not just of dollars or pounds or yuan or any other ‘fiat-currency’: it applies to anything that might be used in a currency-like way. Which is why no ‘alternative-currency’ model can work.

Yet the core problem isn’t money, or currency: the core problem is the concept of possession, for which money or the like will act as a proxy or token. The difficulty here is that there’s no doubt whatsoever that a possession-based economy would seem to deliver the best possible economic results, especially in the shorter-term: that’s the conceptual basis of capitalism, for example. The catch is that it’s actually a kind of addiction, a kurtosis-risk in which apparent short-gains are overshadowed by a real yet hidden probability of much greater long-term loss – a risk that could eventuate at any time. In effect, it ‘succeeds’ by stealing from elsewhere or elsewhen – and it can only conceal that theft, and the real economic consequences of that theft, through a myth of ‘infinite growth’, “a rising tide lifts all boats” and so on. (This might start to sound a bit familiar?) It must maintain that illusion of ‘growth’, because the moment it stops ‘growing’, its only possible option is to cannibalise itself. (Which might also start to sound a bit familiar…) If a possession-economy hits up against real unbreakable constraints, it will end up consuming itself into oblivion.

And yes, what we think of as ‘the economy’ started to hit up against exactly those kinds of unbreakable constraints, certainly around half a century ago – such as documented in Limits To Growth – and probably quite a bit further back than that: colonialism can be seen as one of its symptoms, for example. What we’re seeing right now is the early-ish death-throes of a delusionary ‘possession-economy’ in non-recoverable terminal decline: and if we don’t want to be taken down with it, we need to be doing something about developing some real global-scale alternatives right now.

Hence a real sense of urgency in this. In a sense it’s not quite that urgent: we probably have a decade at least before everything really does start to fall apart in an irretrievable way. Yet the point is that will take at least a decade to get alternatives in place such that we can swap over to that an alternative in an instant: in the real world, an apparent ‘overnight success’ usually takes a very long time to prepare. It’s a bit like the old orchardist’s aphorism: the best time to plant a fruit-tree is twenty years ago, but if you haven’t done that, the next-best time to plant it is today. Right now. Prepare the ground, plant the sapling, keep a careful eye out, but mostly a lot of waiting-around and careful yet apparently ‘unprofitable’ tending whilst nothing much seems to happen, for what probably seems much too long a time. That to me is what we’re facing right now, at the ‘Really Big Picture‘-scale of enterprise-architectures.

What do we do about it?

Most enterprise-architects aren’t ‘economists’ in the conventional sense – which, under the circumstances, is probably a good thing. Yet we are economists in a much more general sense, because we do know a lot about the broader ‘management of the household’ within our business-domains and business-organisations. Most of us know well that whilst business-folk will talk about most things in monetary terms, about ‘cutting costs’ or ‘making money’, in reality the business runs neither on money nor on machines, but on the responsibility and commitment of individual people. In other words, the business may purport to be a money-economy, but it’s actually a responsibility-economy, a value-network of interlocking mutual responsibilities. For the most part, money just gets in the way…

Most of us have also learnt the hard way that many of the real intractable problems in a business context arise from misunderstood notions of possession. For example, when we talk about a process-owner or project-owner, we mean the person who accepts responsibility for the appropriate usage or completion of that item – and it’s when someone tries to claim exclusive ‘possession’ of that item that things go wrong. (Or the corollary as ’anti-possession’ – the purported ‘right’ to not accept responsibility for something.) It’s only by gently breaking free of delusions of ‘possession’ – or, in a few cases, prying the desperate claws of a would-be ‘possessor’ off from something that needs to move on – that things can actually be made to work.

We also know from writers like Daniel Pink that money is actually one of the least-successful motivators in a business context: in any kind of knowledge-work, for example, monetary rewards are more likely to damage performance than to improve it.

And there are a few other closely-related themes that most of us would know all too well: for example, the chaos that will routinely arise from the fact that whilst the physics definition of ‘power’ is (roughly speaking) ‘the ability to do work’, far too often the social definition is more like ‘the ability to avoid work’…

So as enterprise-architects we do know what works, and what doesn’t work, at the relatively small scale of business change in a business context. What we’re talking about here is the need to adapt that experience and awareness up to a much larger scale. We know that we can do that, because we know it’s a fractal pattern. (Unlike the money-economy: try scaling-down a supposedly all-inclusive money-economy model to the level of an ordinary family-household, and watch how fast its fundamental dysfunctionalities will surface! ) And we can also observe and test and practice what does work there within a business – a responsibility-based economy, without the possession/barter/money overlays – so that we do know how to scale it up when the time comes.

Some practical questions to explore:

• In what ways do attempts at ‘possession’ of anything tend to slow things down? What is it that is attempted to be possessed? – money? authority? ideas? resources? others’ attention? Who attempts to do the possessing? And what are the results of the attempted ‘possession’ – especially in the medium to longer term?
• In what ways do attempts at possession reflect a lack of trust? Who or what is not being trusted, by whom?
• In what ways do attempts at possession reflect overt or unacknowledged fear? What or who is feared in each case? What could be done to ease those fears?
• In what ways is responsibility taken up and enacted by people? What problems arise when ‘anti-possession’ attempts are made to ‘assign’ or otherwise offload responsibility onto others, rather than the responsibility taken up as a conscious choice and commitment by the respective ‘other’?
• In terms of the overall metaphoric ‘management of the household’, what structures, processes, procedures, performance-metrics and governance assist in this active take-up of responsibility? What deters it? Architecturally speaking, what works, and what doesn’t?
• Given what you know about what works and what doesn’t, what can you do architecturally to support what works and gently dissuade what doesn’t?
• What would you need to do to scale this up to your organisation’s relations with its immediate partners and clients, the broader market-space (or equivalent), and the overall shared-enterprise in which it operates? How would you scale it up to a city, a country, an entire global economy?

Some serious challenges there…

(And yes, given that the money-economy and its dysfunctions do still hold sway in almost all organisations, it’s probably best to do this kind of exploration ‘by stealth’, in the background. The results will speak for themselves in terms of greater real efficiency and effectiveness, but probably best to keep quiet for now as to how you got there… )

To see how this works in the wider world, just imagine a world without money. From what you’ll have done above within your own organisation, you’ll have recognised by now that it actually isn’t necessary: it’s just a huge and scarily-wasteful overhead on the economy that we really don’t need at all. Money doesn’t make the world go round: in reality, it mostly makes it go stop – as you can see every day in the struggle to get out of the darn supermarket…

So imagine your High Street, or Main Street, without any of the accoutrements of money. All the banks and building-societies and insurance-companies would vanish: they’re literally just a waste of space. Down at the grubbier end of town, the pawnshops and betting-shops would vanish, too. The general shops would change, quite a lot, but would still be there: a much stronger focus on not-selling, rather than selling-for-the-sake-of-selling. Cafes and bars and bakeries and restaurants would still be much the same as at present. It’s a very interesting thought-experiment… And the only thing that stands between us and that world – one that, for most of us, is a lot more appealing than what we have right now – is just one literally deadly delusion: the myth of possession, on which the current myths of ‘property’ and ‘money’ are based.

I’m not saying money is somehow ‘wrong’: it isn’t. The same applies to money-economy capitalism: I’m not saying it’s ‘wrong’. (Far from it, actually.) In reality, all of it’s just a kludge at best – though it is a workable kludge if you’re trying to do any of a fairly limited range of types of trade. But the point is that most of us aren’t doing those kind of trades – and it doesn’t scale properly either to anything outside of that scope, or to a global scale. Which means that in most real-world cases it’s an unworkable kludge – along with the entire possession-model on which it’s based. And pretending that it does work, when it doesn’t, is not a good idea…

Money isn’t ‘the root of all evil’; the existence of a bank or an insurance-company or monetary taxes isn’t ‘wrong’ as such. If you’re working for a bank right now (and bluntly, most of us do, one way or another…), probably best not to worry about it overmuch as yet. It’s just that it doesn’t work: it never has, and we were always fooling ourselves in pretending that it did. It sort-of worked within a narrow business-context, but it was always ludicrously inefficient and ineffective, especially at a social scale and in any social context. And whilst in the past we could sort-of gloss over its inefficiencies at the cost of a recession or two, we’re now reaching the point where we literally cannot and dare not attempt to ignore its inherent flaws and frequent failures – because they could literally kill us all. It’s in that sense, and that sense only, that money, or barter, or possession, is ‘wrong’ – and why we literally have no choice but to say that somehow they must go, replaced by an economic model that can run without them.

So yes, in this it’s definitely ‘interesting times ahead’: yet also very interesting indeed for enterprise-architects. Care to explore more?

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.)

Amused that Anthony says he’s 27, because that’s about the age that I really got going on this. (A little earlier, actually: the first dowsing book came out when I was still 24. I used to have to apologise for not being the age people expected me to be, namely at least 75! )

I wouldn’t say that any of what I do is a ‘rare skill’, although it’s true that it’s not often acknowledged or respected – perhaps because, by its nature, it necessarily tends to be disruptive to any comfortable status-quo. I’ve been doing it since a very early age – for as long as I can remember, anyway, certainly way back in primary school – but it’s actually the standard approach used in most forms of design-thinking and the like, as taught in art-college or architecture-school or good engineering courses or even in the US military. It’s also what really happens in scientific research – see, for example, WIB Beveridge’s classic The Art of Scientific Investigation.

My own particular twist on it arose because I’m not much good at doing things, or making things (I tend to describe myself as ‘ambi-sinistral’ – the opposite of ‘ambidextrous’… ). Hence I tend to focus instead on the thinking behind the doing or making or whatever, always searching for the simplest way to do things, the most effective way, and so on. Kind of recursive, if you like, but it works well. Except for that little problem that it tends to be so darn disruptive…

Methods, mechanics, approaches

One place to start would be around skill itself, and the key themes of my Masters thesis, way back in 1976. Back there, I described a skill – any skill – as being made up of three components:

• the methods used in the skill
• the mechanics and other real-world constraints of the ‘objective’ context of the skill – that which is common to everyone
• the approaches, assumptions, mindset, paradigms, physical dexterity and other ‘subjective’ context for the individual (the ‘operator’) – that which is specific to the individual

What I found, very quickly, was that most people seem to focus on the methods used in any skill. But that actually misses the point: the methods used by any skilled operator arise from their own personal resolution of the mechanics and the approaches – the ‘objective’ and ‘subjective’ components of the skill. This is why using someone else’s methods doesn’t always work, and why ‘best practice’ can be dangerously misleading: the mechanics of the issue remain the same, by definition, but the context is different, and hence may well need different methods.

Focussing on method also makes it much more difficult to tease apart the separate threads of mechanics and approaches. It should be obvious that blurring the objective and the subjective is not likely to be a good idea, and yet that’s exactly what happens whenever we focus only on method.

In all skills-work – in fact in just about every human context – we also come face to face with Gooch‘s Paradox: “things have not only to be seen to be believed, but also have to be believed to be seen”. In an all too literal sense, in skills-work, reality is what we say it is: we actually create it, from nothing, or rather from a combination of imagination and hard work. (In this kind of context, it doesn’t really make sense to ask the question “Is it real or imaginary?”, because the only possible answer is ‘Yes’ – both, therefore neither.) To resolve Gooch’s Paradox, we treat the approaches – our assumptions and beliefs – as if they are part of the mechanics of the context. The danger is that we may forget that point about ‘as if’, and – if we think about those assumptions at all – think that they are part of the fundamental mechanics of the context, rather than an arbitrary choice to achieve some particular purpose.

Once assumptions creep in – in other words, whenever the subjective is blurred into the objective without conscious intent to do so – what we have is a context to which arbitrary constraints have been applied. Which places arbitrary limits on possibility. Which is kinda pointless, really. But the only way that we’ll be able to see that the constraints are arbitrary is to step back a bit, and re-separate the subjective from the objective. Hence a kind of recursive methods-to-look-at-methods, analysis-to-unpack-analysis, and so on. Which is what I do.

As I mentioned in my reply-comment, much of the ‘how I do what I do’ is already documented in various ways throughout the books, such as in Everyday Enterprise Architecture (which focusses on method in a business context) and The Disciplines of Dowsing (which looks more at ‘thinking about thinking’). The core of the latter book is the ‘four disciplines’ section (see the summary on the separate two-page reference-sheet) and the ‘seven sins of dubious discipline’ (currently listed only in the book): it wouldn’t take much work to translate those into almost any other context.

What I’ll use here is the Five Element / effectiveness framework that I use in a lot of my client-work these days (though often in somewhat covert form). It’s nothing special, in fact it’s little more than a recursive use of a pair of matched checklists. The first of these, as summarised in the ‘Five Elements’ chapter in SEMPER & SCORE, is a set of perspectives on the overall context:

• Purpose – what are we aiming to do here? and why? (see also the slidedeck ‘Vision, Role, Mission, Goal‘)
• People – who would be needed for this purpose? what skills and relations do they need? what are their mutual responsibilities?
• Preparation – what planning and logistics would be needed for this purpose? what assumptions and mindsets apply here? what are the key events that trigger action?
• Process – what needs to be done to achieve the purpose? when, how and with what would this be done? when is each process complete?
• Performance – what constitutes ‘success’, and for whom? what information and metrics are needed to keep everything on track? what would be needed to support continuous improvement?

The other checklist is a set of keywords on effectiveness, which are sort-of orthogonal yet also sort-of linked to the Five Element set. Listing these in the same order as above:

• Appropriate – is this on track towards the purpose?
• Elegant – does this support the human-factors in the context? (e.g. simplicity, ergonomics etc)
• Efficient – does this make the best (e.g. least-wasteful) use of the available resources?
• Reliable – can this be relied upon to deliver the required results?
• Integrated – does this help to link everything to everything else in a consistent way?

To assess a context, we can start from anywhere at all. The point is that we use these checklists not as linear lists, but as a reminder to keep looking round, bouncing back and forth between each of the interconnected themes in the two lists, looking at the context from every possible angle, and at every level from really-big-picture to finest-detail, building up a kind of hologram of the overall context, using one form of sensemaking to bounce off others, and so on. The book Real Enterprise Architecture provides a complete worked-example of this kind of recursive process as applied to whole-enterprise architectures.

Questioning everything

Looking back at the various areas I’ve worked in or with, there’s a fairly consistent pattern about what I’ve done and the sequence in which I’ve done it.

The first stage is just getting involved at all: taking the ideas and practices at face-value, and putting them into practice as if they are entirely ‘true’. That usually works for a while (not least because that’s what everyone else is doing).

I then allow myself to start to notice the niggles, the things that don’t quite seem to work, where ‘what it says on the tin’ doesn’t actually deliver what it says on the tin. The problem, of course, is that we can’t assess the validity of a logic from within the logic itself. Yet we also can’t actually work on the context without being inside the logic (or some form of the logic). This is where we hit Gooch’s Paradox head-on: we have to see it to believe it, yet also have to believe it to see it. The only way out of that dilemma is to start to use beliefs as tools – which can be kinda challenging…

In my experience, there are two parts to this:

• identify the big-picture theme for the overall context (the ‘vision’ or, as architects would put it, the unifying ‘parti‘)
• apply design-thinking tactics to question everything, switching beliefs in order to experience the context in different ways, and test the apparent results

The tactics to identify the key-theme(s) are usually straightforward. A classic example is the ‘Five Whys’: just keep asking “why?” until eventually we hit a ‘Because.’ – or rather, a real ‘Because.’ that makes some degree of sense, rather than one that’s just used to get people to stop asking awkward questions! These days I tend to look for a brief overview-statement – usually only about three to five words – that has a distinct three-part structure: it identifies the ‘things’ or concerns that matter to everyone in the context, what’s being done with or to those items, and why it’s deemed to be important. This gives us a stable anchor to which we know we can return, and against which we can test anything in the context.

Then, following standard ‘design-thinking’ tactics, we use a suite of ‘disruptive’ questions about the context – for example:

• what’s another version of this?
• what does this look like at a smaller scale, or a larger scale?
• what happens if we substitute something else for this?
• what happens if we invert some or all of the rules?
• is there a ‘term-hijack’ here? – does a small subset purport to be the whole, blocking the view to any other aspect of the context?

This is where things often get to be, uh, fun… – because it’s very common to find aspects of the context that a) don’t and can’t make any sense, b) clearly don’t work ‘as advertised’, in fact usually work against the nominal aims of the overall enterprise, yet c) there are key players with a lot of vested interest in ensuring that the status quo remains unquestioned and unchallenged. Don’t be surprised at this: it happens every time.

This is where a certain amount of dogged determination becomes essential… Also essential is a very clear, insistent emphasis on the big-picture, on holding to the overall vision for the shared-enterprise, because that’s often the only thing that will persuade people that there’s no ‘personal attack’ here, that instead the only purpose of the challenge and the enquiry is to make things work better, for everyone. (We have to be real about that, too: we need belief in ourselves in order to keep going, it’s true, but we need to keep questioning ourselves as well. It’s one reason why serious self-doubt is a chronic yet necessary occupational-hazard here.)

We need to keep hammering at this until we do start to get a clear separation between the mechanics of the context – which usually turn out to be surprisingly simple – and the approaches to the context – which are, by definition, individual and subjective. Then we can start to work towards new methods that work with the context under the current conditions.

The same seems to apply to just about any type of context: an individual’s personal challenges in developing their own skill, a business, a social context, a single conceptual tool, or an entire discipline.

Scattered throughout this weblog and the sister-weblog Sidewise, you’ll find examples of those techniques in use. Sometimes it’s reasonably straightforward, sometimes rather more controversial, but you’ll see in each case that’s it’s essentially the same principles, the same tactics.

I’ll also summarise here those same techniques in use in four different large-scale domains that I’ve been involved with over the decades: dowsing, desktop-publishing, domestic-violence resolution, and enterprise-architecture.

Example: Dowsing (1970s)

Big-picture theme: finding things, particularly where conventional (mechanical/physical) techniques either won’t work or are unavailable.

History: as a discipline, has been around ‘forever’, and often highly controversial – first from priests who regarded it as ‘the work of the devil’ etc, then later from would-be scientists who wanted to ‘explain’ it and couldn’t. When I first got involved, in the late 1960s, the field was pretty much moribund, with a random mixture of wild claims, erratic discipline, no formal methodology or theory-base as such, a long history of inconclusive scientific experiments, and the first flush of hype-laden New Age ‘thinking’ (if that’s the right term…). Most of the people involved were well into their sixties, seventies or more (which I, uh, wasn’t…). The key players consisted of a kind of closed ‘military club’ (water-finding being very important to an army on the move), a few variously-erratic practitioners (often with wild-eyed ideas about health and the like), a swathe of armchair-theorist camp-followers who talked a lot but did nothing, and a few people who really did know what they were doing and wisely kept themselves well away from the mess.

Conceptual mismatch: The most common assertion was that it was a special ‘innate’ skill that only certain ‘special people’ could do. Methods that often clashed or even flatly contradicted each other could lead to the same result; the same method used by different people would lead to wildly different results. Most of the theory in use – such as notions of ‘waves’ or vibrations’ or ‘radiations’ – was either meaningless or just plain wrong in terms of conventional physics. (Much of it did sort-of make sense as metaphor, but there seemed to be little understanding of the difference between active-metaphor and concrete fact.) Muddle-headed ‘New Age’ ideas merely added to the overall mess.

Vested interests: On the one side was the moribund ‘military club’, who liked the idea of being ‘special and different’, and/or the ‘right’ to tell the ‘lower ranks’ what to do, whether it made any sense or not. On the other side were the upcoming ‘New-Agers’, who were not going to let anything block their path to potential fame and fortune. (I’m being cynical, I know, but that’s exactly what happened.)

Assessment and action: Assess the purported theory, and scrap most of it: it’s meaningless. The only parts of the theory that do make sense and do have solid experimental backing revolve around perceptual psychology and physiology – particularly around weighted-sum merging of multiple channels (which is why there’s no single ‘the method’) and around edge-triggered reflex-response (which is why some experienced water-finders can’t find static water even when they’re standing on top of it). If some kind of tool is used, almost all of the tools act as some form of mechanical amplifier – if I move my hand a little, the tool moves a lot. (I’ve only ever found one case where that principle didn’t apply at all.) Materials, structures, theories and so on seemed to matter only because people believed that they did: in most cases, a simpler alternative would work just as well, if not better. Keep stripping it back to the bare essentials.

It is a true skill – but it’s not one that’s restricted to only ‘special people’. Instead, it’s a learnable skill: anyone can do it – though whether they may or will do so are entirely separate questions! (There was quite a lot of pushback from the ‘military club’ against the idea that ‘anyone can dowse’.) It’s also a skill that requires a lot of practice and a lot of discipline to get right. (Unsurprisingly, there was a lot of pushback from the ‘New-Agers’ on that point, and there still is – see the book Disciplines of Dowsing.) It’s also a skill which often requires a wide range of psychological ‘tricks’ to help people slide past Batcheldor’s ‘witness-inhibition’ and ‘ownership-resistance’ – in other words, “this isn’t happening, and if it is, it isn’t me”.

End-result: After a few months’ experimentation and subsequent practice over several years with a wide range of students, I’d stripped it down to the point where I could get most people started on the basics within less than two minutes, using two bits of fencing-wire from the garden as simple instruments. The notion that ‘anyone can dowse’ is now firmly established in the canon, and the teaching-methods that I developed (based on, self-responsibility, self-critique and continual-improvement) are still some of the most common currently in use.

Example: Desktop-publishing (1970s-80s)

Big-picture theme: getting ideas and information out into the public space.

History: I trained as a graphic-designer/typographer, and became professionally involved in typesetting in the late 1970s, with the early developments in smaller phototypesetting machines. (‘Smaller’ being a relative term here: the first system we bought required a room of its own and a separate darkroom, and cost more than my house.) The big bottleneck was keyboard input: the typesetting unit was capable of running much faster than a single operator. Although the internal technology was extremely complex, the input was not: some machines still relied on a very simple 6- or 7-channel punch-tape reader, using control-codes to extend the effective size of the character-set.

At the same time, simple but usable microcomputers were just starting to come onto the market. (My first microcomputer had only an 8-character LED display, hexadecimal keypad and 256 bytes of memory; the more usable Ohio Scientific systems that we first used for real had a proper keyboard but still only 8kbytes of memory, and the only storage was on audio-cassettes.) Almost all of these machines used a 7- or 8-channel character-set (ASCII or extended-ASCII); most also provided some form of direct data input/output for interfacing to other systems.

It seemed to me that there should at least be some way to use a basic micro as a much cheaper input-terminal, using simple code-translation and a standard hardware-interface. It also seemed probable that other people would want to do the same – taking control of their own publishing, driving a typesetter direct, or both. In the longer term, that could well be quite a large market.

Conceptual mismatch: This is best summarised by the phrase (exact quote, in fact) that “there is no interest in typesetting from microcomputers, and there never will be”. There were all manner of arbitrary demarcation-lines across the whole context, both on the pre-press side – such as between authors, publishers, unions and printers – and on the technical side – particularly between typesetter-manufacturers, computer-manufacturers and various hobbyists and hackers – most of which arose more from historical ‘turf-wars’, ‘positioning’, and mutual misunderstanding than from any concrete distinctions. On the union side especially, there were many arbitrary assumptions, based on the belief that technology could not and would not change, or if it did, it could not and would not be allowed to make any difference to existing processes or roles.

Vested interests: The entire context was riddled with vested interests, almost all of which were in conflict. A stream of intermediaries – agent, publisher, pre-press, press, retail – stood between author and audience. Typesetting-systems were expensive pieces of equipment, yet with not all that much to justify their cost: there was lot of money to made there, both from machinery-sales and from fonts and other consumables, and hence a lot of ‘need’ to protect those sources of income. Until IBM eventually stepped in, most of the microcomputer manufacturers were trying to establish themselves as ‘the manufacturer’, resulting in a plethora of mostly-proprietary, mostly-incompatible hardware and software non-’standards’ – at one point we had to buy two machines whose sole function was to read the two hundred or more different disk-formats used on the four distinct disk form-factors then in common use: 8″, 5.25″, 3.5″ and 3″. Weaving a path between all the different vested-interests and proprietary structures was, frankly, a time-wasting nightmare.

Assessment and action: On our first machine, we’d been told emphatically that it was physically impossible to connect a microcomputer; a weekend spent poring over technical specs and waving a soldering-iron around a bit on a prototype-board soon proved that ‘fact’ wrong, whilst the only software we needed at first was a straightforward lookup-table to translate between character-sets. It really was that simple. (We avoided warranty risks by using opto-isolators, so there was no electrical connection between the two machines.) For our later, larger systems – which were capable of typesetting a reasonable-sized book in less than an hour – the hardware-interfaces were already built in. This gave us ‘direct typesetting’ capability, but it still required operators to know – and use – the distinct formatting-codes for each type of machine.

The next step was to hide the complexity, using the format-code in common word-processors such as WordStar to trigger font-changes and the like. (I believe we were the first people to use style-codes, such that a single hideable code – *F1, for example – would change the entire style, including paragraphs, indents, font-family and so on.) At that point, people could use ordinary word-processors to typeset text: the first true precursor to desktop-publishing.

It worked, but there were still limitations. (Our main competitor, meanwhile, was using a mangled form of SGML which still required people to embed hard-codes in the text; in our system, all of the formatting could be invisible.) The main problem was that people couldn’t see beforehand exactly how much space any text would take up – a very important concern to two of our customers, who were producing page-spread books and partworks, Dorling-Kindersley style. Hence some serious code-hacking (all assembly-language, with multiple overlays to squeeze into no more than 40kb of memory) to create a post-processor that would copyfit line-by-line for the correct fonts and sizes, and output a symbolic result to a dot-matrix printer. This was probably the first viable attempt at a true desktop-publishing system – several years before Macintosh and, later, PageMaker.

End-result: I’m good at creating ideas and markets, and all the preliminary work that gets things going, but I’m not good at running businesses – that’s a different mindset entirely. Eventually we sold out to another pre-press company and (in an all too literal sense) I ran away, first to the US, and then onward to Australia. I believe it’s still running, and certainly made millions for the new owners. (I didn’t, of course.)

Example: Domestic-violence resolution (1980s-90s)

Big-picture theme: reducing and repairing the damage from social harm, particularly between individuals.

History: Fights and power-games between individuals in a domestic context have been part of the human story since forever, but had usually been largely covert and ignored as ‘a private matter’ for most of that time. It was brought into public notice in 1970s by women’s activists, most notably Erin Pizzey, founder of Chiswick Women’s Aid. Unlike Pizzey herself (who has always insisted that domestic-violence (DV) is a human problem, not a gendered one), most activists purport that DV is something that happens almost exclusively to women, and caused almost exclusively by men – so much so that some have called for the term ‘domestic-violence’ to be replaced always by the term ‘violence against women’. Most current law (e.g. US ‘Violence Against Women Act’), support-structures (domestic-violence help-lines) and formal theory (e.g. Duluth) reflect this assertion. I became involved in the field during the 1980s as a member of a pro-feminist men’s group who were taking up the feminist challenge that all violence was caused by men alone, and therefore men’s responsibility alone to resolve the (purportedly) ever-rising tide of men’s violence against women. The issues became more personal later when two of my lesbian friends asked me for advice after they had ended their relationship with a knife fight (without injuring each other, fortunately) but had been explicitly shut out from any help because no man could be blamed for the violence.

Conceptual mismatch: The theory was straightforward: men are the problem, women are the solution, and the only useful thing that men can do is blame themselves for everything that goes wrong in the world. Everything in my background supported that assertion, hence it seemed to make sense: self-blame had been a very deeply ingrained habit for me, going right back to earliest childhood. Yet the whole field seemed riddled with gendered special-cases: behaviours that were definitely violence if done by a man were, if done by a woman, either deemed ‘not violence’ or ‘indirectly caused by men, therefore men’s fault’. In the Duluth model, blame itself was classed as a form of violence only if done by a man, and only if the person being blamed was an adult woman: blaming of men (or in essence almost any other form of abuse of men), was explicitly not classed as violence. And the real catch was that, in terms of outcomes, it clearly wasn’t working: no matter how much we blamed ourselves, and blamed other men, the overall level of violence in the culture around us still seemed to continue to rise.

Vested interests: Looking around, it was very clear that there were a large number of players – mostly but not all women – whose identity and self-worth depended on putting men down, regardless of whether or not this actually helped women in general, or anyone in general. There were also very large sums of money, and large numbers of jobs, that depended on maintaining the assertions around women’s purported exclusive victimhood in this context.

Assessment and action: The first warning-signs appeared in one of our standard text-books, Paul Kivel’s Men’s Work: How To Stop The Violence That Tears Our Lives Apart, which is designed around a series of workshops for senior-school students. The book includes many oddly-unrealistic role-play scenarios in which an adolescent boy or young man is suddenly violent or abusive to a woman; yet the only real example of violence described in the whole book is an actual incident in which two girls had a full claws-out fight when one insulted the other in the classroom – and in which no boys were involved at all, other than to separate the warring parties.

After my lesbian friends had their knife-fight, we discovered that no violence-resolution material was available that acknowledged even the possibility that a woman could be a perpetrator of violence. The standard Duluth model defines violence as inherently ‘male’; on the Duluth Wheel, female pronouns are used exclusively throughout to indicate victim, and male pronouns exclusively for perpetrator, and mutuality (where both parties are both ‘perpetrator’ and ‘victim’ of each other and of themselves) – which clearly applied in my friends’ case – is explicitly denied. I decided to try a very simple thought-experiment: swap the gender-pronouns throughout, and see if it still makes sense in terms of real-world evidence and experience. It did: in fact for most of the Duluth categories of abuse it made more sense than the ‘official’ way round. Also – importantly – two key categories of abuse were absent from the original model: sexual abuse, and third-party-abuse. It became immediately clear that the Duluth model itself was structured as third-party abuse, primarily leveraged through other-blame – in other words, far from reducing violence and abuse, it was actually designed to increase it. (Whether that mis-design was intentional, or merely arose from incompetence and excess zeal, is a separate issue that I will not discuss here… – but the fact of its unfitness for purpose cannot be in any doubt.) A simple ‘de-gendered’ redesign resolved almost all of the structural problems, sufficient at least to satisfy my friends’ immediate needs.

That exposure of the extreme inadequacies of the original Duluth model forced our group to reassess all of our previous assumptions about gender and violence, and thence to look again at the research on whose purported facts we’d based those beliefs. I did two analyses of a much-published study on which Australian public policy was based – the first analysis on the public version of the paper and political assertions from it, and the second analysis on the original academic study, which took quite a bit of work to obtain, since it was not publicly available. Another colleague, as his MA thesis, undertook a meta-analysis of domestic-violence studies in Australia. The results were shocking. None of the original studies were based on defensible methodologies – in fact many were so riddled with basic methodological errors such as circular-reasoning that they were essentially meaningless. And in all cases, all of the methodological errors either inflated the female injury-rate or risk, diminished or denied the male injury-rate or risk, or both: there were no exceptions. In short, almost none of what we’d previously taken as ‘fact’ was fact at all. The only genuine facts we could establish was that domestic-violence was a systemic issue with some gendered overtones, and that although it that affected both sexes in different ways, overall it seemed to do so almost equally – though there were strong indications from hospital data and the like that the majority of victims were male, not female.

We then looked at public policy, and the provision of domestic-violence support-services. These too were based on the same fundamentally-flawed assumptions and the same unquestioned circular reasoning: women are the only victims, hence support-services are only available to women; and since only women use these services, this proves that women are the only victims. In some of our interviews we discovered that men who’d been abused – knifed, in one case – were referred to police for charges, simply because the models in use automatically deemed men to be the sole perpetrators, regardless of the actual context or evidence. In short, the entire domestic-violence resolution ‘industry’ it was, and still is, an unworkable and fundamentally dysfunctional mess whose structures and methods are all but guaranteed to cause far more harm than good: an archetypal example of the Shirky Principle that any institution will attempt to preserve the problem to which it purports to be the ‘solution’.

End-result: The domestic-violence ‘industry’ is the outcome of a classic example of a ‘term-hijack‘, in which a small subset of systemic issue is misframed as the whole, and strenuous efforts are made to deny or conceal any other aspect of that issue. In effect, the term-hijack converts a resolvable systemic context into a non-resolvable ‘wicked-problem‘, in which every attempt to resolve a problem is constrained by the structural myopia, inevitably making things worse with each iteration. Unfortunately, there are huge vested-interests in maintaining the term-hijack. Anyone who challenges it – as I and many others have learnt to our cost – is likely to come face to face with extreme violence from women who somehow purport that no woman is ever violent. It seems clear that resolving these structural problems would require a high level of honesty and humility from those players – an honesty that in most cases at present seems conspicuous only by its absence…

Some of the material I wrote is out there and in daily front-line use by others – with real success, according to the occasional emails I still receive on the subject. But to be blunt, after a decade of relentless ongoing abuse from almost all sides, I just gave up and literally threw away most of the work that I’d done… the structural dishonesties in this mess are so entrenched and so ‘political’ that I found it just too painful to be involved at all, and it still seems that resolving the mess would require fundamental shifts in societal attitudes and beliefs that would be unlikely to occur within my own lifetime. Oh well.

The issues are generic, though, and can be resolved at a more generic level. You’ll see how some of these exact same issues are addressed in the business-context in my book Power and Response-ability: the human side of systems and its accompanying ‘manifesto‘.

Example: Enterprise-architecture (2000s-to-present)

Big-picture theme: helping organisations and overall shared-enterprises become more efficient and effective (‘doing the right things right, on purpose’).

History: The main focus of enterprise-architecture is around the relationships between structure, purpose and business-execution.As a discipline, it’s been around for at least a century in various forms, such as Taylorism (‘scientific management’), operations-research and organisational cybernetics. I often describe it as based on a single, very simple idea: that things work better when they work together. Although my work often touched on it over the decades, I first became actively involved perhaps fifteen years ago, when trying to tackle issues around long-term knowledge-management in aircraft research. Over the past decade, most of my work has revolved around various aspects of enterprise-architectures.

Conceptual mismatch: The term ‘enterprise-architecture’ implies a very broad whole-enterprise scope. In recent decades, though, the term ‘enterprise-architecture’ has often been (mis)used to denote a very small subset of the real scope, relating to IT-infrastructure or IT-systems in general. This (mis)usage probably arose from a simple conflation of the term ‘enterprise- or organisation-wide IT-architecture’. The result, however, is a very serious term-hijack: the tiny subset of the overall enterprise represented by IT purports to be the whole, with all other aspects of the enterprise – including people, purpose, physical facilities and non-IT machines of any kind – either concealed or denied. In effect, it becomes all but impossible to discuss any aspect of enterprise-architecture without being forced to describe everything in terms of IT – even in contexts where IT-systems are either not relevant or not available.

Vested interests: There are huge vested interests in maintaining the story that ‘enterprise-architecture’ relates only to IT. Many, many billions of dollars are invested each year on IT-systems that purport to resolve inherently-complex enterprise-scale concerns such as customer-relationships, market-relationships, regulatory-compliance and the like. However, by definition, many if not most of these systems are incapable of resolving all aspects of the respective concerns, in effect converting them into non-resolvable wicked-problems; maintaining the ‘enterprise-architecture’ term-hijack makes it possible to conceal or deny the inherent dysfunctionality of the systems, instead maintaining the faith or fiction that the problems created can only be solved by yet another IT-centric system at yet further cost. There are also large vested-interests in training, certification and the like for IT-centric ‘enterprise’-architectures.

Assessment and action: The starting-point for assessment was a simple review of the term itself, deriving the natural-meaning via term-inversion. The ‘natural-meaning’ of a term is the meaning implied by the individual words of the term. The term-inversion here is ‘the architecture of the enterprise’: hence the natural-meaning is ‘anything to do with the structure and purpose [architecture] that underpin the emotional drivers and actions (the animal spirits of the entrepreneur”) in the shared context [enterprise]‘. The purported exclusive-association of enterprise-architecture with IT does not occur in the natural-meaning: in fact the role of IT in the enterprise-architecture is implied only peripherally, as a minor aspect of support for ‘the animal spirits of the entrepreneur’. In other words, what we’re dealing with here is definitely a term-hijack – and an extremely unhelpful one at that, because the constraint on the scope (i.e. ‘enterprise’-architecture constrained solely to IT aspects of the enterprise) has such a limited connection with the actual scope (which would naturally focus more around people than machines).

Most of my work in the past decade, and particularly the past five years, has been focussed on finding ways to highlight the term-hijack, to resolve the resultant problems and dysfunctionalities, and to create models, methods and frameworks to guide a true enterprise-scope architecture, in some cases all the way out to a global scale. The public outcomes of this work so far include several books, a couple of dozen conference-presentations and other slidedecks, and many, many weblog posts.

End-result: We are getting somewhere with this one. Most ‘enterprise’-architecture conferences these days do explicitly include some discussion of the enterprise-scope beyond IT, usually under a banner of ‘business-architecture’, and there’s much stronger linkage to true business-architecture models and techniques such as Business Model Canvas. The real danger now is there’s a tendency towards ‘business-centrism’ rather than ‘IT-centrism’ – in other words, where the architecture sub-domain of ‘the business of the business’ rather than the sub-domain of ‘the IT-systems’ becomes used as the base for yet another term-hijack. The crucial understanding that we’re still somewhat struggling to get across to most of the players in the field is that in a true enterprise-architecture, everywhere and nowhere is ‘the centre’.

But yes, we are getting somewhere with this one. Slowly…

Summary

So that’s what I do, and how I do it:

• explore a context that is of interest to me
• identify the conceptual mismatches that occur within that context, and that make it difficult to achieve effective results within that context
• identify the vested-interests that drive and maintain the current dysfunctionalities in the context, and, where possible, devise strategies and tactics to disarm and disengage those vested-interests
• assess the details of the dysfunctionalities in the context, and identify or design workarounds for those problems, and methods to work on the context when the dysfunctionalities are disengaged
• document the end-results in various forms, as appropriate

It’s a lot of work, and sometimes very painful work, but someone has do it?

A gentle warning on occupational-hazards

To anyone who might want to do this kind of work, I really ought to add some important caveats.

The work itself is actually not that hard. All it requires is a willingness to let go of assumptions, and tackle each of the issues with a rigorous attention to discipline, following the ever-changing rules of the different disciplines that apply at each moment whilst working in that context. Using beliefs as tools can be kind of challenging at times, but again it’s just another skill, and one that’s not that hard to build up over time.

It’s the social aspects of the work that are hard: sometimes very hard…

For starters, it’s often lonely. Very lonely. Part of that is because there aren’t many people who do this kind of work: at a guess, from what I’ve seen around the net and elsewhere, there may be as few as five or ten thousand people in the entire world who work in this space. Social-media does help to ease the loneliness a bit – the people I work most closely with are scattered literally across the entire globe – but it’s not the same as working in close proximity with close colleagues every working day.

Another part of the loneliness is that the feeling of loneliness – and likewise insistent sense of self-doubt – is actually inherent in the work. It’s almost an indicator of success: as Whitney Johnson put it in her HBR article ‘Disrupt Yourself‘, “If it feels scary and lonely, you’re probably on the right track”. To put it the other way round, the times when we feel most certain are probably the times when we’ve most likely missed the point. It’s hard, and it usually hurts, every single day: so if you can’t cope with a relentless, all-pervading feeling of failure, and yet somehow still create the required results, you really shouldn’t to do this work. There are plenty of other much easier ways to make a living, after all. (This isn’t a macho thing, “I’m tough” and that kind of garbage: in my own case, to be honest, I’m probably not suited to do most other kinds of work anyway. For me, though, there’s a real sense of ‘a calling’, an inner drive to do this work, whether I want to or not: and often that’s the only thing that keeps me going… )

Another crucial point is that whilst there’s a great need for this kind of work, there’s also a huge ‘anti-want’ for it. Every aspect of this work implies some kind of mythquake; and anyone who has a vested interest in the status-quo – which in effect that includes most of our would-be employers, amongst many, many others – will not want that mythquake to occur. It’s disruptive: it is, in a very literal sense, often anarchic. So for much if not most of the time, we’ll need to do the work ‘by stealth’, embedding it in other more conventional analysis-work or the like. Doing it ‘by stealth’ is often the only option if you’re an employee, and even then it can be risky: as one of my ProFuturist colleagues put it, “if you’re employed as a professional futurist, and you’re not being fired at least once every year or so, you’re probably not doing your job properly!”

In my own case, I’ve never been an employee: only ever a self-employed contractor, an independent consultant or running my own business. I’ve survived somehow, though often I don’t know quite know how – it’s certainly not an easy way to run one’s professional-life. But I’m well aware that’s not a viable option for many people, especially those with young families. If you are an employee, and you want or need to do this kind of work, you definitely need a Plan B – and work hard on building and maintaining your professional reputation, such that you can recover from being fired after that ‘one disruption too many’.

Another subtle problem that affects many of us arises from the fact that this work requires us to be very good generalists. The good part of being a generalist is that we’re able to learn fast and be interested in anything, at any level of the enterprise. The disadvantage is that, when people compare us to specialists, we almost always come off second-best – and the fact that we specialise in being generalists doesn’t seem to count, especially where the over-simplistic assessments of recruiters and the like so often come into play. In almost all of my contract- or consultancy-work in the past couple of decades, I’ve ended up doing a different (and much broader-scope) role than the one I was nominally employed for: the problem was that I somehow needed to employed for something in the first place, and that can be a real hurdle. So the catch for us is that we need to be at least as skilled as the typical specialist, whilst also being very skilled as a generalist. It’s not easy, and is one reason why the really good enterprise-architects tend to be older, often into their fifties or more – simply because it takes that long to build up the generalist portfolio and experience whilst embedded in what is (to be honest) often a complete waste of time and effort in a ‘required’ but irrelevant specialist role.

Overall, though, it’s probably the loneliness that hurts the most. But if you can cope with that, and with all of the other challenges of ‘the trade’, then yes, we definitely need you… come and join the club, perhaps?

(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?