Archive

Posts Tagged ‘quality’

Architecture disaster? – we have an app for that!

August 12th, 2010 No comments

One of the comments on the previous post on the unacknowledged risks of  ’cooperative IT’ triggered off an essay-length response that really deserves its own post. So here it is. :-)

The comment that started it off was from Ric Phillips. (I’ve trimmed it slightly, but you can see the original here.)

The innovations that led to mini-computers led to the increasing importance of information processing based on the technology’s ability to capture and model transactions (atomistic events). It really did change the nature of work and organisations and made a new kind of information available.

It wasn’t really the advent of PCs that changed things. If the information about the world that could be stored in them and used had not changed radically they would have simply replaced the niche occupied by terminals. But they allowed people to simulate sheets of paper and type writers. And spreadsheets – which were existed prior to software and were done on very large sheets of paper. Later came sound files, photographs, building designs, industrial machinery, complex electronics (like audio mixing decks) and a thousand other things that are now simulated in software.

In this wave computers became personal productivity tools. The changes to how personal productivity expressed itself in our lives when assisted by the new ‘virtual’ things PCs could provide is what changed our jobs, our professions and be extension our lives.

The internet started out as an extension of publication and communications models that already existed. But (in this case much more slowly that in previous transformations) our activity on the internet started to capture large amounts of information that previously wasn’t subject to computation – social information, information about opinions, subjective value, and what we might call (tentatively) knowledge.

There are intersecting trends (consumerisation for example). But mobile computing, ubiquitous data, web 2.0 and so on are all converging to create a new domain of information – information that allows us to model and manipulate in computers new and extremely complex things. Once again this will transform organisations. But this time maybe even whole societies.

I don’t see this as an impending disaster. Our world is changing again. As a strategic profession EAs need to get their heads around this. We are leaving the era of ‘information processing’ and ‘ICT’ and entering the era of social computing and Knowledge Technology.

Reading it again, I now realise that this critique has completely missed the point: all it’s doing is extolling the virtues of each of the transformations in technology, yet seemingly ignoring any possibility that there might also be vices associated with those virtues. Yes, each of those transformations are real and valuable to some context, and that is indeed a key driver for change. Yet the change itself is not the risk, and neither is the technology: it is the dependence on that technology that creates the risk.

So, as I put it in my response, I strongly agree that “mobile computing, ubiquitous data, web 2.0 and so on” are not in themselves an impending disaster. The same applies to their initial impact on organisations and “maybe even whole communities” – in general I see those impacts as desirable, even if certainly not something we can ‘control’.

What does worry me is what happens next. As an EA I’ve spent many months at clients tracking down all those small private-to-a-workgroup spreadsheets and databases and log-files and the like that were a) business-critical and b) unmaintained, undocumented, not backed up, inherently fragile [such as trying to use MS Access as a multi-user database, which it was never designed to do], unregistered, and in many other ways a real business risk. Whenever some key person changed jobs, or a single hard-drive failed, or a sysadmin triggered an automated application-upgrade, or any other of a myriad of seeming-trivial events, that business-unit would literally lose that part of its mind – and an entire business-process, affecting an entire cross-functional workstream, would grind to a halt until someone could work out what had gone missing and how to set up yet another kludged workaround.

When the business-application is non-critical, kludges usually don’t matter: it’s how people learn, it helps get things done, and it’s exactly what ’shadow-IT’ is for. The new mobile technologies and the like are brilliant for this – just as spreadsheets and single-user databases were (and still are). Everything’s fine as long as they’re essentially used in the same way as Lego bricks or a Meccano set or the like – a ’serious toy’ that can be used to knock out a quick prototype to test out an idea, or perhaps even to keep around as a vaguely-useful tool and talking-point. And as long as they’re used for that kind of purpose, it shouldn’t matter much when they do fail – especially if we can use that failure as a way to learn what to do differently next time. In other words, we accept failure as part of the deal – it’s ’safe-fail’.

But don’t try to use a ’serious toy’ for anything that’s business-critical. It’s not inherently wrong, but it’s simply not ‘fit for purpose’: they’re not robust enough, resilient enough, agile enough, secure enough, and so on – which means that as a system we cannot set them up to ’safe-fail’ in such a context. Sure, you could use Lego to build a house (it’s been done), or Meccano to build a bridge (that’s been done, too), but the effectiveness of doing so is questionable at best, especially over the longer term.

It’s the ‘-ilities’ that usually matter most in architecture. The functional requirements for a system are usually much the same at any scope or scale, but the qualitative or so-called ‘non-functional’ requirements are what will usually make or break the system in practice. Building an IT system that can handle half a dozen strictly-sequential requests in half an hour or even half a minute is relatively trivial; building one that can handle thousands or even millions of parallel, interleaving, fragmented, potentially-incomplete requests every second is not trivial at all; and yet the functional requirements are essentially the same. That’s the difference between a ’serious-toy’ prototype, and serious engineering with serious architecture and serious service-management and support behind it.

What we have right now in mobile-computing, ubiquitous-information and cloud is a whole bunch of serious-toys desperately pretending to be more than they are, and – more worryingly – being sold and used as if they’re more than they are. Sure, the function is there – but that’s easy. It always is. Getting them beyond that ’serious toy’ stage is not easy – and because it’s hard work to get there, it hacks into the short-term profits, too, so it’s not exactly popular amongst the money-obsessed.

So we have here all the ingredients for a ‘perfect storm’: more and more of individual people’s lives and livelihoods being placed onto platforms that are inherently unstable and unsustainable, because little or none of the work to make them stable and sustainable is as yet in place or even in progress. If you’re not already seriously worried about what will happen when large chunks of our society literally lose their collective mind and memory through the failures of these kludged-together toys, you’re not thinking hard enough about the architecture of the enterprise… :-|

The lessons of history are plain to see, and it’s also plain to see that the level of unaddressed risk has been raised each time, with even the earliest-period risks still not fully addressed even now. You Have Been Warned?

CoIT: another architectural disaster unfolds?

August 11th, 2010 3 comments

Twitter-correspondent Craig Hepburn posted a Tweet this morning pointing to Dion Hinchcliffe’s excellent ZDNet article, ‘CoIT: how an accidental future is becoming reality‘, about the current rise and rise of ‘consumer IT’ or ‘cooperative IT’:

It’s a story as old as the IT department: New technology arrives in the market, it makes some type of work easier to accomplish, the business asks for it, and IT reacts and delivers it. Not always however, and usually somewhat slowly. It was this way with PCs, it was this way with the Internet, and now IT is faced with what is turning out to be a veritable perfect storm of technology and social change. …

Today’s highly mobile, social cloud has set everyone’s expectations for how easy, powerful, and simple IT can be. The genie will never be put back into the bottle.

For once I’m going to stand firmly on the side of the IT-folks on this one – because no matter how wonderful this looks right now, this is not good news at all. Looking at this with a futurist’s eye, I’m wondering how long it will take before we wish we could put the genie back into the bottle… because what I’m seeing here is a full-on disaster-in-the-making. Or rather, a double disaster-in-the-making, given how much this will interact with the ongoing disaster that is ‘cloud-computing’…

One of the first lessons any futurist learns is to look back at history, to seek out any equivalent occurrences in the past. And the blunt fact is that we’ve been here before… not just once, but several times already. Each time that we came back to the same place – if perhaps from a slightly different direction – it’s clear that the fundamental lessons were not learned, in fact were wilfully ignored; and each time it took a lot of effort, a lot of skill, and a lot discipline, to tidy up the mess – just in time for the next batch of overly-excited idiots to trash the place all over again. This is the dirty end of Gartner’s ‘hype-cycle’: someone has to tidy up the mess. And yes, “it’s a story as old as the IT department”, because in every case so far, that ’someone’ has been the much-derided IT department – and also enterprise-architecture, in its broader sense, beyond IT alone.

Go back sixty years or so, to the first beginnings of mainframes and ‘big computing’. Watch the hype-cycle at work: slow adoption, then a huge take-off in ‘data-processing’ (we didn’t get round to calling it IT until quite a bit later). It will solve every business problem! Control the world! Unlimited information on tap, right here, right now! Except it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (COBOL, the IBM-360 architecture, and so on), and then all the boring stuff about requirements, governance, maintenance, data-cleansing, service-management…

Twenty years later, it’s the mini-computer boom. It will solve every business problem! Now even medium-sized businesses can control the world! Unlimited information on tap, right here, right now! Except that it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (the C language, the Digital PDP-series architecture, and so on), and then all the boring stuff about requirements, governance, maintenance, data-cleansing, service-management…

Ten years later, we get the microcomputer revolution. It will solve every business problem! Now you too can control the world, right here on your desktop! Unlimited information on tap, right here, right now! Except it wasn’t quite as simple as that… turns out it was a lot of work to get standards happening (disk-formats, file-formats, data-architectures, the IBM-PC architecture, and so on), and then all the boring stuff about requirements, maintenance, data-cleansing, service-management…

Yup, you’ll be seeing the pattern here. The exact same sequence applied to the rise of the internet ten years later, the web five years after that (with a merry little hiatus called the Dot.Com.Bomb), the rise of cloud over the past few years, and now the rise of Hinchcliffe’s mobile IT or ‘CoIT’. In every case, there’s the same wild hype, the initial push from outside the IT-department (as ’shadow IT’) which gets the basic idea going to point where it’s usable.

(And to be fair, if that push hadn’t happened, those new developments would probably never have been usable: as Hinchcliffe implies, it’s actually quite rare that innovations arises from within the IT department itself. Because that isn’t it’s job: IT’s real job, unfortunately, is to tidy up the mess that will inevitably follow…)

In every case we see the same exuberance… then the slowly-dawning awareness that it isn’t quite as simple as that. It turns out that there’s a lot of work that’s needed in order to get standards happening – otherwise the new ‘revolution’ turns out to be something that can’t be shared, which means that the whole thing fizzles out quite quickly because we need that sharing to happen. We need clear standards for hardware, software, data-architectures, information-architectures, interchange protocols and much more besides. We need distinct disciplines around requirements, governance, maintenance, data-cleansing, quality-management, service-management and a whole swathe of other areas. And all of those, it’s now clear, need to allow for customisation, agility, security, versatility, adaptability, resilience and the like – none of which are easy to balance with conventional ‘control’-style disciplines.

So here I am, looking at the rise of Hinchcliffe’s ‘CoIT’ – particularly cloud-computing and mobile-apps. And what I’m seeing is an architectural disaster waiting to happen, if not unfolding right before our eyes:

  • security – where is it? does it exist at all? (I’ve seen lots of hype and promises, but not much reality as yet)
  • file-formats – half the iPad apps I’ve seen seem to embed their data actually within the app itself – they don’t even have a file-format other than perhaps plain-text or unstructured PDF
  • interchange-formats -if they have a file-format at all,  most of the apps seem to rely on unpublished proprietary file-structures with no means to enable exchange between different apps, whilst cloud-providers will often deliberately make it difficult to exchange, so as to enforce ‘lock-in’
  • escrow – information-lifetimes range between seconds and decades – yet no-one seems to be thinking beyond a year or more at most, and no-one at all seems to be planning for what happens when a cloud-provider or app-provider goes bust – which they will, often (over the long-term at least), and often very expensively
  • system-standards – where are they? do they exist at all? – we seem to back in the worst days of early microcomputing, where just about every man-and-his-dog-in-a-garage could and did create an entirely different architecture for everything, often intentionally incompatible with everything else

I could go on… and on… and on… there’s no shortage of other nightmare-level architectural risk-factors that aren’t being addressed at all. Other than by the much-maligned IT-department, that is (who unfortunately tend to be able to see only the IT-related risks, which represent only a relatively small proportion of the whole); or by the few enterprise-architects who actually do think about whole-of-enterprise scope (and who are mostly derided, by the hype-merchants and their ilk, as doomsayers who’ve lost the plot). Not funny… Oh well…

Yes, it’s true that the excitement (or the oft-forlorn hope that it will finally be better this time?) is what gets people going to create new ideas; so yes, the exuberance does matter. Hence, in turn, I suppose, the hype does matter too. And safe-fail experiments are also always a good idea, because they show us where things will break but without causing much damage in the process. ‘Safe-fail’ can get quite extreme, too: for example, think of the buildings in a fireworks-factory, with very solid walls, very lightweight roofs – because when you know there’s a high risk that things can go badly wrong, you can indeed design for that fact. Yet there are also many types of structures that we can’t allow to fail: anyone who’s lived through a major earthquake or major storm-event will know that fact firsthand… Architecturally we need to be able to tell the difference between those two extremes, and design accordingly.

Yet that’s exactly what’s not happening here with cloud or CoIT: architecture of any valid kind, it seems, has all but been abandoned in the usual wild rush towards The Next Best Thing… So might it not be wise to take a brief pause for thought at this point, before we rush headlong into yet another insanely-expensive IT-disaster? Or is that too much to ask of anyone whilst the hype is in full flow?

How to screw up in one easy lesson…

July 21st, 2010 No comments

Yup, I screwed up badly over that last post on IBM’s definitely not ‘new’ Component Business Model. Within a matter of minutes I’d received a whole stream of Tweets warning me I’d been mistaken about the age of the model:

  • miket0181: @tetradian IBM’s CBM isn’t new. I think it’s at least 5 years old…
  • operninha: @tetradian aqui na empresa contratamos a IBM e eles usaram o CBM (“here the company hired IBM and they used the CBM”)
  • seabird20: @tetradian I have seen CBM in RFPs for at least 5 years. Original work 10+ yrs. ago. Takes a while to get to rank and file though
  • richardveryard: @miket0181 @tetradian … IBM’s CBM came sometime after my 2001 book on Component-Based Business http://tinyurl.com/23gelj7

So yes, I was wrong on that: badly wrong. A critique about outdatedness that would have made sense if the model had been ‘new’ just looks peevish and petty when it isn’t…

Even the critique about the structure of the model is barely fair. Sure, Stafford Beer’s Viable System Model has been around since at least the mid-1970s, but the number of people who knew about it and were applying it in practice (and I actually could include myself amongst them by the mid-1990s) was and still is very small. It’s better-known these days, and its value and importance is much better-understood; but at the time the Component Business Model was devised, I would doubt that anyone in that IBM team would have even heard of it, let alone known why those kind of whole-of-system cross-checks are so crucial. The critique would definitely be valid for an equivalent model developed now, but most of the current knowledge on whole-of-enterprise impacts simply wasn’t available a decade ago. And whilst critiquing a (relatively) old model on the basis of current knowledge is valid enough, it’s only fair to do so when it’s clear when that fact of history is acknowledged – which I didn’t, because I didn’t know it was that old.

I know why I screwed up: after five years of constant struggle against IT-centrism in ‘enterprise’-architecture, I’m now seeing management-centrism promoted as an ‘improvement’, and it’s frustrating as heck… :-( The fundamental point in all enterprise-architecture is that there is no centre – everywhere and nowhere is ‘the centre’, all at the same time. In true whole-of-enterprise architecture, making anything ‘the centre’ – IT, finance, management, processes, security, whatever, even the business-organisation itself – will guarantee failure of the architecture over the longer term. When I saw the Tweet that triggered this, I thought it was yet another example of this lethal mistake. So I over-reacted.

In my defence, I did check the IBM site with some care. But the annoying point there is that there are no dates on that part of the site – nothing to give any clue as to when the material was posted, or its probable vintage. (Compare that to, say Apple or Microsoft, where just about everything has a ‘Last Updated’ timestamp.) I looked quite hard for anything there that would give me any clue as to the date. What I didn’t do, though, was search elsewhere – and yes, that was a mistake too. So I misread the implication of the Tweet, and mistakenly assumed the model was new – after all, it still says so, several years later…

Moral(s) of the story:

  • Fact-check everything, via multiple sources – not just the ‘official’ site for the respective information
  • If key metadata-items such as dates are missing, fact-check elsewhere again, and treat any implied derivatives (e.g. ‘new’) as suspect
  • Frustration is fine, and often all too understandable, but don’t let it rule the roost – engage doubt before pressing the ‘Send’ key…

Overall, though, the blunt fact remains that yes, I did indeed screw up there. Mea culpa…

On IBM’s ‘Component Business Model’

July 21st, 2010 No comments

(Another example of How To Lose Friends And Infuriate People, no doubt, but this does have to be said.)

[Update: this post was a reaction to a tweet I received yesterday, but Mike T. (@miket0181) tells me that the IBM CBM described here isn't new, in fact is apparently some years old, so my complaints on that regard are unfair. (Doesn't help that IBM don't put up any dates on their website-posts.) On that part, yes, I ought to apologise, and do - see 'How to screw up in one easy lesson...'. Yet the core critique still stands: it's not a complete model, and potentially is dangerously misleading if used as the basis for a business-architecture. That's my view for now an' I'm stickin' to it, anyways. :-| ]

A couple of weeks back, as part of the ‘Patterns‘ section in the Enterprise Canvas series, I put up a an example of a variant of the Canvas which I said was definitely dysfunctional, all but guaranteed to be ineffective, and definitely not recommended – a kind of Taylorist-style model of the organisation and its (non-)relationship with its business-ecosystem:

I said explicitly that it was a stereotype, almost a parody – a guide as to how not to view an organisation, with quality-management and coordination subsumed into ‘management’, and rigid separation between the organisation and its broader shared-enterprise.

I was quite certain that no-one would be daft enough to try to model any real organisation in that way.

I was wrong.

Welcome to IBM’s new Component Business Model, where the organisation’s business-world is partitioned into just three layers: Direct, Control, Execute:

I’m going to have to be rude here, and describe this as a kind of ‘bastard child’ of Taylorism and TOGAF, combining many of the worst features of both and not many of their best. The one good item, and a definite improvement on TOGAF, is that the model does explicitly include People as well as Process and Technology:

Using the Component Business Model methodology, our consultants identify the basic building blocks of your business. Each building block includes the people, processes and technology needed by this component to act as a standalone entity and deliver value to your organisation.

But beyond that? – well, let’s compare it to Stafford Beer’s Viable System Model, which I regard as the minimum requirement for whole-of-business modelling:

  • system-5, ‘policy / purpose‘ – uh… might be tucked away somewhere in IBM’s ‘Direct’?
  • system-4, ‘outside / future‘ – sort-of in IBM’s ‘Direct’, but no reference to ‘outside’?
  • system-3, ‘inside / now‘ – yup, right there in IBM’s ‘Control’ – lots of it
  • system-3*, ‘monitor / audit‘ (including overall quality-management) – nope, not a sign of it – presumably squeezed into IBM’s ‘Control’?
  • system-2, ‘coordination‘ – nope – no sign of it anywhere
  • system-1, ‘operations‘ – yup, that’s IBM’s ‘Execute’ – probably…

In terms of the Enterprise Canvas model above, all it has is Staff-Management (what should be the guidance-services, but all scrunched up together in a nearly-unusable way), Line-Management (the Value-Management cell, blown up out of all proportion to its actual relevance) and, uh, Everything-Else…

In other words, there’s probably less than half of what’s needed to make sense of the organisation – but presented as if it’s the whole of it, much like TOGAF’s hopelessly-IT-centric model purports to be ‘enterprise’-architecture.

The four other worked examples are slightly better, but still dangerously incomplete: a Taylorist manager’s-eye view of the business-world, without any clue as to any of the glue-functions that hold it all together. You’ll also note that each one of those examples has a very different structure in its ‘horizontal’ axis – but no indication at all as to how it’s derived. Presumably only IBM’s own consultants could be considered competent to understand the ‘magic sauce’ needed to do this, and the rest of us mere mortals may do nothing else but bow down in awe?

What’s also irksome is that IBM have the temerity to present this as something ‘new’:

IBM’s Component Business Model is a new way of looking at your business. It represents the entire business in a simple framework that fits on a single page. It is an evolution of traditional views of a business, such as business unit, function, geographic or process.

Fact is that this is nothing ‘new’ at all: okay, it might seem new to IBM, but not to just about anyone else in ‘the trade’. We were doing it more than half a decade ago in Australia Post – certainly 2004, and probably earlier. It was only a Visio hack, but in business terms it proved straight away to be one of the most valuable artifacts from our Business Transformation team: just about every single manager in the whole organisation grabbed hold of their own copy and placed it, much annotated, above their desk. Since then I’ve done one or more of these models for just about every one of my enterprise-architecture clients: you’ll find a couple of (de-identified) examples in that VSM slidedeck referenced above, and in probably half of my other TOGAF-conference presentations over the past few years. I even published the instructions on how to build an ‘organisation-on-a-page’ map, complete with Visio templates, on my Tetradian Books website some two or three years ago. Aleks Buterman and his colleagues have had their own generic version – which they call an Enterprise Architecture Capability Map – up on their website for almost a year now. And it’s even built into some of the EA toolsets, such as Troux Metis, and, I believe, IBM’s own System Architect, and again has been so for years. So what’s ‘new’ about it? Nothing, frankly – other than the fact that IBM have finally cottoned-on to what the rest of us already knew anyway.

And I hate to think how much they charge for this ‘new’ approach… a lot, no doubt…

Sorry, folks, but I’d have to say I’m underwhelmed at all of this. Seriously underwhelmed. Oh well.

Bah.

Tackling uniqueness in enterprise-architectures

June 3rd, 2010 4 comments

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…

Context-space mapping and the Chaotic domain

March 8th, 2010 5 comments

(This series of posts explores a concept of ‘context-space’ which in part draws on a categorisation immortalised in a certain well-known diagram. It must be emphasised that this is not about ’That Welsh Framework‘ (aka twf) which that diagram illustrates: for details on twf, please contact this company. I apologise for these absurd aliases, but regrettably their necessity has been forced upon us by others.)

We seem to be iterating steadily towards a full description of what I’ve termed context-space mapping (as a more permanent name than the temporary label ‘tinc‘). For example, there’s been some very useful discussion on the previous post, especially by enterprise-architects Paul Jansen and Sally Bean. Paul Jansen followed this up with another Tweet:

@tetradian May the ‘chaotic approach’ be the key to #tinc? http://bit.ly/amJa1o

In fact this leads to what is probably the fundamental difference between twf and context-space mapping (aka tinc): the role of the Chaotic domain. This particularly applies in terms of the respective views of repeatability within the context.

In the hope of preventing yet more repercussions, I won’t say anything about twf’s approach at this point, other than to express my opinion that, in the terms of context-space mapping, its focus is primarily on the Complex domain, which in turn leads to an emphasis on contexts that are ‘partly-repeatable’ in highly complex ‘unordered’ ways.

Context-space mapping, however, needs to cover all repeatability-types. As twf’s proponent indicates, the Simple domain of presumed-repeatability is covered by Taylorism et al.; the Complicated domain of analysed-repeatability by hard-Systems Thinking and the like; and the Complex by twf and so on. But there’s so far been little or nothing to cover the Chaotic domain of ‘barely-repeatable’ events and processes. So in practice it’s likely that that’s where whole-of-scope techniques such as context-space mapping will have the most impact.

The central theme in the Chaotic domain of practice is low- to zero-repeatability: some part(s) of the practice cannot be repeated, either because the conditions have changed – including the awareness and experience of the person doing the work. Conventional ’scientific-analysis’ approaches (Complicated-domain) rely on repeatability, so they’re actually not all that much use in the Chaotic components of any real-world task – in fact will often be misleading because they provide an illusion of predictability. In a way, the same is true of many Complex-domain techniques: they give us a much more reliable picture of an overall uncertain context, but we can’t reliably apply that in reverse to tell us what to do for a specific ‘market-of-one’, such as a specific medical diagnosis.

Ability to engage appropriately in the Chaotic-domain in this sense is almost a definition of skill. It’s also a key component of almost all knowledge-work – which is why this concern is coming much more to the fore, as knowledge-work becomes an increasingly important part of the overall economy.

At the business-process level, one of the key figures is Sigurd Rinde, whose concept of ‘barely-repeatable processes’ is the focus for his Thingamy business-process-execution software. The whole point of Thingamy is that the processes themselves are made up as they go along, by the people doing the work, expressing and applying their expertise. Underneath this, however, is a consistent Simple structure that records every decision, every artefact, every transfer of responsibility – which makes it possible to create any required reports from the process, including conventional statistical analysis. The result is nicely summarised on Sig’s other website, 30megs.com – so-called from his tag-line “Here’s 30 Megs. Now go run Germany”, which in principle is entirely feasible with this kind of decision-support/decision-tracking software. Sig is not alone in this, of course – for example, Stafford Beer developed something similar that in effect ran the entire economy of Chile for a while, way back in the early 1970s – but Thingamy is probably the best example of a software package available today that is designed for true Chaotic-domain processes.

Context-space mapping is part of what needs to happen before we settle on any technique or tool such as Thingamy. It’s about mapping the options available to us, and the decisions that we make within ’solution-space’, as part of an overall process of sensemaking in order to arrive at appropriate actions for the context. One of the key points in this is an awareness that we are part of the context, part of the ’solution’: in the classic Chaotic-domain sense, there is a boundary, and there is no boundary, always in the same moment.

We always start from ‘reality’ – that which in twf is termed the ‘disorder’ domain. (Everything does in fact take place within that domain: any purported subdivisions – such as Simple, Chaotic and suchlike – are sensemaking-abstractions that we place onto that domain, but are not actually ‘real’ as such.) From there, we would move into some kind of recursive OODA loop (Observe/Orient/Decide/Act), where sensemaking itself forms one or more of the earliest iterations. In those terms, context-space mapping would typically proceed as follows:

  • Observe: What is ‘the context’ here?
  • Orient: How do I make sense of what I’m seeing?
    1. What parts of the context appear to be unique (Chaotic), unordered or ‘wicked-problem’ (Complex), complicated but repeatable (Complicated) or universal (Simple)? Using that categorisation, map out the ‘problem-space’.
    2. Given that categorisation, what cross-maps would be useful for sensemaking?
      Note: There are an infinite number of cross-maps that could be used: some examples shown in this series include:

      • here: repeatability and action-tactics; domains and tetradian asset-dimensions; time versus focus; Jungian domains
      • here: twf tactics and types of practice; timescale versus ‘bindedness’; development of embodied ‘best-practice’
      • here: repeatability and ‘truth’; marketing versus sales; the ‘plan / do / check / act’ cycle
      • here: ISO-9000 quality-model; skill-levels; automated versus manual processes; asset-types; data, information, knowledge, wisdom
      • here: cause/effect relationships; decision-mode, timescale and level of abstraction
      • here: nature of boundaries between domains
      • here: phases of matter
    3. Using the categorisations from the cross-maps, what available tools and techniques are ’situated’ in what regions of the maps’ ’solution-space’? What can we learn from this?
  • Decide: Given what I have learned from sensemaking, what should be my ‘action-plan’?
    1. Select from the available tools/techniques.
    2. Decide on a plan as to how, why, when, where, by whom, with what, and in what order each of the selected tools or techniques should be used.
  • Act:  What am I doing as I am doing, and what do I see as I am doing?
    1. Enact the desired action.
    2. Apply the same overall OODA-loop to the action taken – recursively, where appropriate – for review, further sensemaking, decision and action.
  • Repeat as appropriate.

(Some people might suggest that this kind of OODA-loop fits more within a twf-style Complex-domain mode than Chaotic-domain. True, there are important similarities, such as the shared focus on ‘unorder’ versus the Complicated/Simple notion of ‘order’. But the key distinction is that this acts on a single, individual, specific context rather than a Complex-domain collective – and is often also much closer to real-time than most Complex-domain decision-making.)

The above is a start towards how we would use context-space mapping, anyway. I’ll leave it there for now: any constructive comments, ideas and suggestions would be most welcome, as usual :-) – over to you?

Previous posts in this series:

Related:

Context-space mapping and enterprise-architecture

March 4th, 2010 11 comments

(This series of posts explores a concept of ‘problem-space’ versus ’solution-space’ which in part demonstrates alternative uses and interpretations of the Simple / Complicated / Complex / Chaotic categorisation originally described in the Cynefin diagram. It must be emphasised that this is not about the Cynefin Framework; for details on Cynefin, please contact Cognitive Edge.)

This post represents yet another attempt to describe certain fundamental differences in approach from twf (aka ‘That Welsh Framework‘ – so-called because we’re no longer allowed to use its official name at all) and to find an alternative term that might reduce the ongoing friction in that quarter.

To do this, we need to go right back to first-principles: the core concept of context-space, which eventually leads us to context-space mapping.

(Another long-ish post: more after the ‘Read more…’ link.)

Read more…

More on meta-methodology (‘Beyond-Cynefin’ series)

March 1st, 2010 5 comments

(This series of posts explores alternate uses of the Simple/ Complicated / Complex / Chaotic categorisation originally described in the Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the Cynefin framework proper, please contact Cognitive Edge. The term ‘beyond-Cynefin’ is solely a placeholder to indicate this separation of concerns.)

Back to theory again – apologies… – following on from comments on the previous posts, especially ‘On meta-methodology‘.

The aim of this post is to try to create a bit more clarity around the notion of ‘problem-space’ versus ’solution-space’. To do this, I’ll draw on a variety of sources, ranging from dowsing to enterprise-architecture, Sigurd Rinde’s work on ‘barely-repeatable processes’, activity/response-models such as OODA and PDCA, and much more besides.

Will again be long, hence more after the ‘Read more…’ link.

Read more…

And more ‘Cynefin-like’ cross-maps (‘Beyond-Cynefin’ series)

February 28th, 2010 2 comments

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. The term ‘beyond-Cynefin’ is here used solely as a placeholder to indicate this separation of interests.)

Here’s another collection of ‘Cynefin-like’ cross-maps that I’ve found useful for sensemaking in enterprise-architecture and related work:

  • ISO-9000 quality-model
  • Skill-levels
  • Automated versus manual processes
  • Asset-types
  • Data, information, knowledge, wisdom

More details after the ‘Read more…’ link.

Read more…

More ‘Cynefin-like’ cross-maps (‘Beyond-Cynefin’ series)

February 26th, 2010 2 comments

(This is part of an ongoing series that explores alternate uses of a generic conceptual categorisation originally described in the well-known Cynefin diagram. This discussion is not about the formal Cynefin Framework; for details on the definition and use of the Cynefin framework proper, please contact Dave Snowden at Cognitive Edge. The term ‘beyond-Cynefin’ is here used solely as a placeholder to indicate this separation of interests.)

Another collection of ‘Cynefin-like’ cross-maps that I’ve found useful in various aspects of my enterprise-architecture work:

  • Repeatability and ‘truth’
  • Marketing versus sales
  • The ‘Plan / Do / Check / Act’ cycle

More details after the ‘Read more…’ link.

Read more…