Tom Graves / Tetradian

Coincidensity – a really nice neologism that I first saw in a Tweet by social-business specialist David Cushman:

• davidcushman: RT @stoweboyd: the right word isn’t serendipity, it’s coincidensity: the likelihood of serendipity
• jonhusband: @tetradian @davidcushman @stoweboyd … I much enjoy the #neologism coincidensity .. bravo !

From the Tweet, I’d assumed that the term had come from Stowe Boyd: but being the gentleman that he is, he was quick to assign the credit elsewhere:

• stoweboyd: Coincidensity was coined by Matt Biddulph, though. I’m just a user/thief @jonhusband @tetradian @davidcushman

The link between serendipitous ‘coincidences’ and innovation has a very long history. For example, one of my favourite books, Beveridge’s The Art of Scientific Investigation, includes a whole chapter on the role of chance in science, and points outs that it’s nothing like as ‘random’ as it might seem:

If these discoveries were made by chance or accident alone, as many discoveries of this type would be made by any inexperienced scientist starting to dabble in research as by Bernard or Pasteur. The truth of the matter lies in Pasteur’s famous saying: “In the field of observation, chance favours only the prepared mind.” It is the interpretation of the chance observation which counts. The role of chance is merely to provide the opportunity and the scientist has to recognise it and grasp it.

For me, in enterprise-architecture, two distinct themes come to mind from this.

One is the crucial role of uniqueness: the ‘one-off’ that stands out just enough to make itself distinct and noticeable – much as in Common Ground‘s concept of ‘particularity’ or local distinctiveness – yet is also in some way useful. I’ve explored uniqueness in enterprise-architecture from quite a few different directions over the past few years, so I’ll just mention again that it’s important, and that we need to take note of it, and leave it at that for now.

The other theme is about how, in an architecture, we can design for coincidensity – or design against it. Coincidensity can indeed be left to chance: but exactly as in that quote of Pasteur’s, “chance favours the prepared mind” – or, in this case, the prepared architecture.

So, for example, in a high-innovation environment, we can design for high coincidensity. In a physical building, we can ensure that the natural pathways encourage ‘accidental’ meeting between disparate groups. In social networks, this is a key part of the role of the ‘super-node’, he brings together people in ‘unexpected’, seemingly-serendipitous ways. We can do much the same in virtual-spaces, either by structures that are designed to create ‘accidental’ cross-connections between different groups, or through simple ‘randomisers’ such as Google‘s archetypal ‘I’m feeling lucky’ button.

And in some cases, where we need to break out of too-entrained thinking, we might even sort-of trick people into a high coincidensity of ideas, using a flood of deliberate mismatch and cognitive-dissonance – much as described in Raymond F Jones‘ classic science-fiction short-story Noise Level. Some aspects of the context-space mapping sensemaking-methodology, of which SCAN is a simplified version, are structured to support that kind of intentional not-quite-mismatch.

We can also design to reduce the coincidensity of a context. That’s not as strange as it might sound, because random variation or random interruption is the one thing we don’t want in a high-control or high-repeatability context. We want some types of business-processes to be as predictable as possible: for example, to put it the other way round, we probably don’t want strange surprises in our lunchtime salad.

Some low-coincidensity contexts are rather less pleasant: the design of a high-security prison, for example, will aim to minimise uncontrolled or unplanned connections between individual prisoners. One of the fundamentals of 18th-19th large-house design in Britain and elsewhere was the notion of the ‘invisible servant’, that the house should be structured to prevent – or at least minimise – any contact between servants and owners: house-plans show hidden passageways and stairways and service-areas that servants and maintenance-staff would be required to use, to scurry literally between the walls without being seen or heard. And some present-day executives are infamous for enforcing complete separation between themselves and their staff, hiding away in the top-floor suite – and then expressing surprise when the business fails because the structure had ‘successfully’ blocked out key information that they needed to know.

So coincidensity is a design-choice: we can design for high-coincidensity, low-coincidensity, or anywhere in between. (Or we can just ignore it and hope for the best – which is rarely a good design-strategy…) To do this in enterprise-architecture and the like:

• identify the types and levels of coincidensities that we need
• identify tactics and design-features that will support the required coincidensities
• work with others to develop and implement the required features

I’ve summarised some example-tactics above, though there are plenty more, of course: it’s up to us what we do, really. The key point is to recognise the principle of coincidensity – its nature as the density of ‘unplanned-for coincidences’ in any form – and design our structures to promote or dissuade such coincidences according to the need.

Again, will leave it there for now, though do let me know if you want me to explore this further here.

As usual, comments or suggestions, anyone?

How do we make sense of uniqueness in enterprise-architecture? How do we support decisions at ‘business-speed’ – especially when the context is in part unique? And what architectural support do we need to provide for sensemaking and decision-making at business-speed?

In the first part of this series we looked briefly at uniqueness, and why it’s a crucial if often-forgotten aspect of enterprise-architecture.

In the second part we explored how sensemaking and decision-making change when time-available is squeezed down to business-speed, using the real-life case of US Airways Flight 1549 as a worked-example.

In the third part we reviewed some of the tactics used for sensemaking at ‘business-speed’, and why it differs from conventional ‘considered’ sensemaking.

In this final post for the series, we’ll look at how we can balance all the different sensemaking techniques in real-world business-practice, and the architectures that we’d need in place to support this.

Read more…

How do we make sense of uniqueness? How can we use uniqueness? And how do we make appropriate decisions when some or all of a context is inherently unique?

In the first post in this series, we skimmed through Max Boisot’s I-Space and its impact on sensemaking in relation to complex-adaptive-systems. I then added a bit about my personal background, and why my own work focusses much more strongly on the individual context, the individual and personal moment of action, and its expression as personal knowledge and personal skill. Finally, we saw a quick overview of why uniqueness or ‘particularity’ is important in enterprise-architectures.

In the second post in the series, we had a brief exploration of why Boisot’s I-Space and similar frameworks don’t fit well with the sensemaking-needs for unique contexts – and illustrated this point with the real-life example of Flight 1549, the so-called ‘Miracle on the Hudson’.

In this post, I want to explore the different types of sensemaking that need to happen at ‘business-speed’ – especially when we have to cope with uniqueness as well at that speed.

In the final post in this series, which will follow this one, I’ll summarise some of the issues around how to balance the sensemaking techniques at ‘business-speed’, and the architectures that we need to support such forms of sensemaking.

First, though, a couple of Tweets to illustrate why this matters:

• SAlhir: RT @DennyCoates “Ideas can be life-changing. Sometimes all you need is just one more good idea.” – Jim Rohn
• CreatvEmergence: The difference between the unknown which leads to confusion and the unknown which leads to emergence is intention with creativity

So: ideas, intention, creativity, ‘life-changing’, even – all at ‘business-speed’. Let’s get down to it?

Read more…

How do we make sense of uniqueness? How can we make sense of what’s happening at the exact moment of action?

In the previous post in this series, I looked briefly at Boisot’s I-Space – promoted by some as ‘the answer’ to everything in the information-space – and discovered that, useful though it may be for other types of sensemaking, it doesn’t really address this specific challenge of uniqueness.

[If you're interested in Boisot, I understand that Cognitive Edge have just released a selection of his blogs there as a stand-alone document - check it out, perhaps?]

I then delved into a bit of my own history to identify the key theme for me here: the interaction between the individual and the context, in the moment of enacting some form of skill. In other words, uniqueness in practice.

So why is this relevant to enterprise-architecture? The last part of that post gave a brief overview of some of the reasons why uniqueness – and the balance between sameness and uniqueness – is right at the core of business-models, business-architecture, risk/opportunity management, operational excellence and many other key concerns in enterprise-architectures and the like.

So let’s keep digging a bit deeper here, to explore what we can use for sensemaking in that context of uniqueness.

Read more…

We know how to do sensemaking in enterprise-architectures; but why do we do it? What’s the purpose? What’s the point?

As a result of various recent proddings from Bruce Waltuck and Stephen Law, amongst others, I’ve finally gotten round to taking a more than just a cursory glance at Max Boisot‘s concept of information-space, or I-Space. It’s still only been a brief exploration, I’ll admit – a handful of academic papers, and a few I-Space websites. But what I’ve learnt even from that is just how radically different from mine is the problem that I-Space aims to address, in what might otherwise seem to be much the same context – and hence why the approach I’ve been using likewise needs to be radically different too.

Anyway, a warning: this is likely to be very theory-oriented, so it’s probably only relevant if you’re involved in the underlying theory of enterprise-architectures and suchlike. It’s likely to be very long as well, though I’ll probably split it into several parts, for everyone’s sake…

Read more…

Every discipline is blighted by their own versions of an all-too-common problem: “For every difficult, complex, challenging question, there’s at least one clear, simple, easy-to-understand wrong answer”.

In Australian parlance, that type of magnificently-misleading ‘wrong answer’ is known as ‘the toad in the road’.

Every ‘trade’ has its toads, in some form or another. In the case of enterprise-architecture, given our necessarily very broad scope, we do seem to have rather a lot of them. Oh well.

It’s a toad. It sits there, blocking the way. In reality, it’s not actually that big, but it somehow demands our attention, making it difficult to deal with anything else. But we can’t just drive over it, stomp on it, squash it into a literally bloody pulp: I know that some people would do that, but it does have its own right to live, after all. Yet we do need to be careful: some toads are downright toxic. And, it’s well, kinda, yuck… no-one seems very willing to pick it up and put it politely out of the way… Oh joys…

Yeah: that kind of problem.

So how do we deal with ‘the toad in the road’?

It’s different in every case, of course.

Some of the toads in our space are really no problem: they’re just in the wrong place, that’s all. Some of them are positively genial, the kind of toad that, if it had a hat, would doff that hat with a broad smile and an offer to share a slightly-chewed slug. Like all toads, of course, they’re stubborn and they’ll stand their ground, which isn’t exactly helpful when they’re in the middle of the driveway and we need to get moving for the day; but they’re usually quite cooperative as long as we’re respectful about how we shoo them back under the strawberries instead.

Roger Sessions‘ IT-oriented version of ‘complexity’ is one such toad: it’s fine for IT, but for enterprise-architecture it’s an over-extension of ‘order’ into a realm of inherent ‘unorder’, and it really doesn’t work. Likewise John Zachman‘s notion of ‘engineering the enterprise’: it would make sense if an enterprise was an aircraft, which, however, it isn’t. Oops. In both cases, it’s definitely “right idea, wrong place”; and yes, we do all kinda know it. Sure, there will always be arguments about the positioning of that kind of toad: but people like Roger and John are unfailingly courteous and polite, so much so that it’s always a pleasure to disagree with them yet again.  It’s just a kind of game we play from time to time, and we all know it’s a game – sort of how a toad would really like it if the driveway would turn itself into a strawberry-patch because that’s what they know best, and it’s somehow our fault that it isn’t.

There are other kinds of toad that are somewhat similar, but they often seem a bit brainless, so it’s lot harder to negotiate with them. The real problem is that there’s just so many of the darn things: they turn up everywhere, all crawling over each other beneath our carefully-tended bushes and shrubs, digging around for worms and grubs, and generally making a right old mess of everything in the process. Their all-pervasive slime and stench is… well, let’s just say we wouldn’t call it pleasant? – and they don’t really help in any way in the garden.

At present, the dominant toad of that type in our space is IT-centrism, though there are signs that a relatively-new species of business-centrism is beginning to move into our enterprise-architecture garden as well. Perhaps we shouldn’t mind so much, but it’s difficult to get any rest with the constant croaks of “Cloud! Cloud!” and the like… Sigh… Unfortunately, it is hard keep them out of the garden – and if we do somehow succeed in doing so, we’d probably block out all the friendly toads as well, which would be a real loss. Other than the mess that they make, though, these toads are fairly harmless, and there’s probably not much we can do anyway until they get the other side of their current breeding-frenzy (otherwise known as ‘sales-hype’ and ‘certification’). In the meantime, we just need to be careful where we tread, and keep on tidying up the mess as best we can.

There are a few types of toad that we really don’t want in the garden – in fact we need to apply considerable care to keep them out of the entire metaphoric country. These are the cane-toads of a trade – so poisonous that they’ll kill off just about everything in sight, just by their mere presence. Yikes… The real tragedy of the cane-toad, though, is that often it’s initially thought of as some kind of saviour – as was true of Taylorism in our industry’s case, for example. But the reality is that they’re seriously toxic, in almost every possible way – and that toxic nature soon wipes out any possible value they may have had. Not a good idea…

Some disciplines – social-work, in particular – seem beset by cane-toads on every side; by contrast, we don’t seem to have any at present in enterprise-architecture, which makes us fortunate indeed. There’s some risk that IT-centrism and the like could turn into cane-toads, but they don’t seem to have done so as yet – though they’re certainly enough of a problem for us as it is. Taylorism and its more recent sub-species such as BPR and over-hyped ‘business-rule engines’ have been fairly serious cane-toads for us in the past, but each seem now to have faded back into a more natural niche in the overall enterprise-architecture ecosystem. The existence of cane-toads, though, should warn us to be very careful of what we introduce into the enterprise-architecture garden, and to be wary indeed of the ever-present risk of unintended-consequences.

And there a few types of toad that are kind of in the middle – literally in the middle, too, because often it seems that all they really want to do is get in the way. In some cases there may only be one individual of a species in our garden: but like the brainless toad, it somehow manages always to be right in the middle of where need to be – and it won’t budge. At all. Unless it can do so in order to get in our way again… It’s perhaps not as toxic as the cane-toad, but it’s definitely in the wrong place – yet will not respond to any kind of reason, or any request to move on. It just sits there, puffing itself up like a bullfrog, making lots of noise, demanding our attention, and generally acting like it’s the only thing that could matter to anything or anyone in any way. It could perhaps be of use elsewhere in the garden: but since it won’t move there, we never really get much of a chance to find out. What it somehow never manages to accept is that in reality it’s nothing special – it’s just another toad. That’s all. A toad in the road: another darn nuisance that we could really do without…

For enterprise-architecture, IT-centrism has been a bit like that, though it is getting somewhat more amenable these days. All the hype around Cloud is getting to be a bit too much of a toad-in-the-road these days, too. But for me at least, by far the worst toad of this type is Cynefin. It seems we can’t ever talk about complexity without Cynefin insisting on getting in our way. We struggle to talk about even the simple or the complicated without accidentally invoking its unwanted presence. We can’t talk about uniqueness or inherent uncertainty – the business sense of ‘the chaotic‘ – without Cynefin demanding that it alone knows the truth about that space – when in reality it has nothing useful to say other than that we shouldn’t be there. Much like IT-centrism, it has perhaps rather too many characteristics of a cult. And whilst in principle it could be useful in enterprise-architecture, we can’t make much use of it in practice, because its promoter endlessly insists on barging into our space, spitting venom at anything he regards as ‘heresy’ - literally, ‘to think different’ in any way from himself.

We’ve all spent too much time hiding in fear from those attacks: I know way too many people – myself included – who’ve had to invoke Bob Sutton’s ‘No Asshole Rule‘ in that person’s direction, too. The bleak reality is that I’ve spent way too much time and effort pandering to his insatiable demands – much like the pointlessness we supposedly ‘must’ go through in order to get round a toad that endlessly insists on putting itself in our way, and then blaming us for the resultant conflict.

After the last attack, though, I took a more careful look at his snarky putdowns, in which he dismissed my work as valueless, a “hash-up”, “invalid in certain essential aspects” – yet notably failing to give any details as to how or why it should be so regarded. Hmm… time to stand up for myself, for once? So I’ve spent the past few days proving, to myself at least, that my work on context-space mapping is of value, by using it to assess Cynefin itself in terms of its usefulness – or lack of usefulness – for our enterprise-architecture discipline.

The results have been, uh, interesting… (I’ll publish it here if anyone wants, though I’d warn that it’s kinda long even by my standards…) It certainly confirms that, in present form, Cynefin is indeed likely to be useful in the Complex domain; but it’s of questionable value in any other domain, and inherently worse than useless for anything in the Chaotic domain. Another interesting point was that, despite its promoter endlessly railing at anyone who dares to use Cynefin as a categorisation-framework, that’s exactly how he himself uses it in ‘his’ much-publicised HBR paper [PDF]. And that analysis also highlights some nagging suspicions that the base-level Cynefin Framework is actually a Simple-domain technique that’s merely masquerading as a Complex-domain tool – which would be neither helpful nor wise.

Perhaps the most disturbing point, though, is what came up from a more detailed cross-comparison from the context-space map. That’s that the simplified version of Cynefin that’s all that most people see, and the way in which it uses its purported theoretical base in complexity-science, make it an almost perfect tool for (mis)use by any consultant who wants to pander to the fears of worried executives, and provide them with spurious ‘evidence’ that they’re ‘in control’ of something that, by definition, cannot be controlled. That’s not good – doing that would be seriously dishonest, so surely no-one would be so unethical as to do that, would they? And yet that temptation is built right into the very fabric of the framework… worrying indeed…

But the most important point this is this: it’s just another toad. Yes, sure, for our own safety, we might well need a shovel to scoop the wretched thing up: and, despite the strong temptation to use the shovel in another way entirely, we can toss that toad into another discipline’s garden where it might be more at home – and then make darn sure that it doesn’t come back again into ours. That’s probably the best way to deal with that type of toad.

So that’s four types of toad-in-the-road we all have to deal with, perhaps rather more often than we’d like:

• the friendly toad that gets in the way a bit, but is really useful in the right place
• the not-much-use-for-anything toad that gets a bit too much in the way for a while, especially when it’s over-excited
• the darned-dangerous toad that we need to keep out of our space at any cost
• the bloomin’-nuisance toad that we’re best off to toss out of the garden, and keep out as best we can

What’s your experience of ‘the toad in the road’? What are the various types of toad that you have to wrestle with in your own work? And how do you best cope with each?

Comments/experiences/suggestions, anyone?

[Update: A reminder, because a couple of people already seem to have missed this point: in this context, the 'toad' is not a person, it's an idea - "a clear, simple, easy-to-understand wrong answer". For example, the idea of IT-centrism is an example of the second type of 'toad'. This is very important indeed: for example, in no way would I describe either Roger Sessions or John Zachman as 'a toad' (though knowing them both, they might quite like the image above of "doffing a hat with a broad smile and offering to share a slightly-chewed slug"... )]

There’s a core theme that reaches right to the heart of every enterprise-architecture: what is the appropriate tradeoff between sameness versus uniqueness?

The classic Taylorist solution has been to emphasise extreme sameness: to force everything – and everyone – to be the same, because it keeps things simple, controllable and easily replicable. But we now know that it’s too simple to work well with the real complexities of the real world. In fact it only ‘works’ as long as we can maintain the delusion that it does work: and whenever it fails – which eventually it always does – there’s a tendency to collapse into complete chaos. Which is not much of a ‘solution’ at all.

Yet to focus only on uniqueness all but takes us back to a pre-industrial age where everything is custom-made, everything is different, nothing is actually designed to work with anything else, there are no possible economies of scale, and no certain means to communicate with each other – all of which would seem to be the antithesis of architecture. Which is likewise not a good idea.

Clearly there is an architectural tradeoff there: and hence we need something – some conceptual framework – to help us tackle it.

For at least the past half-decade, and probably longer – see, for example, Andrew Johnston’s 2005 article ‘Architects: Masters of Order and Unorder?‘ – enterprise-architects have turned to Kurtz & Snowden’s Cynefin framework for help on this. For many of us, the Cynefin categorisation of Simple [aka 'Known'], Complicated [aka 'Knowable'], Complex and Chaotic has proven extremely valuable, such as for identifying structural themes and potential problems in conceptual misalignment. One example of the latter, as Dave Snowden has also often pointed out, is the misuse of Simple-domain techniques such as Six Sigma: by definition, these depend on very high degrees of repeatability – literally millions of identical events, in Six Sigma’s case – yet there are frequent attempts to apply them in contexts that have little or no repeatability (‘Complex’ or ‘Chaotic’ respectively, in Cynefin terms), which makes no sense at all.

Beyond that basic categorisation, though, attempting to use Cynefin in enterprise-architecture can itself be problematic, particularly where we need to tackle inherent uniqueness. The explicit focus of Cynefin, and Snowden’s Cognitive Edge consultancy, is the application of techniques derived from complexity-science to inherently-complex areas such as policy. (Which, from a cross-map of Cynefin to the ISO9000 quality-standard ‘stack’, is exactly what we should expect: ‘Complex’ maps to the ISO9000 ‘Policy’ layer, in the same way that ‘Simple’ maps to ISO9000′s ‘Work Instruction’.) Yet whilst Cynefin uses the sciences to tackle complexity, what we also need in enterprise-architecture is some means to use complexity to tackle ‘chaotic’ uniqueness – which is not the same at all. Therein lie some serious problems – and some potentially-serious mistakes – if we try to re-use Cynefin concepts in contexts for which it was not designed.

I’ll admit that I’ve probably made some of those mistakes myself. Over the past couple of years I’ve written a number of articles on Cynefin on enterprise-architectures, which made a lot of practical sense to many people, but unfortunately also led to some extremely unpleasant arguments that I have no wish to revisit. What’s become clear to me over the past few months is that the beguiling simplicity of the Cynefin categorisation can blind us to the fact that although its descriptions of the Complex and Complicated domains are essentially the same as we would use for context-space mapping in enterprise-architectures, its definitions and usage of the Chaotic and Simple domains are fundamentally different to those that are needed to tackle uniqueness and sameness in architecture. It’s like comparing a cross-head screwdriver with a flat-head one: at a cursory glance they may seem to be the same, and it’s clear that they are related in the sense that they have similar functions – but in practice they’re not interchangeable, and trying to use them as such will cause a lot of frustration and possibly a lot of damage too. Not a good idea.

So I’d like here to explore what aspects of Cynefin can be used in enterprise-architectures, how and why and where it should not be used, and what we could use as an alternative in those contexts. [I perhaps need to emphasise here that this is not a critique about Cynefin itself, but solely about certain (mis-)uses of Cynefin in enterprise-architecture.]

This again will need to be quite long – apologies – but at least this time there’ll be a fair number of diagrams to break the verbiage into more manageable chunks.

Read more…