Tom Graves / Tetradian

Architects are designers too. Application-architecture designs link across an array of applications, process-architects design ways to link processes together, business-architects design business-models and their linkage into the everyday practices of the organisation. That much should be obvious, I would presume.

Yet in practice – and certainly as the scope widens – more and more of our actual day-to-day work consists of creating and enabling new conversations: architectural conversations between business and IT and anyone and everyone else in the overall enterprise. The ‘one idea’ of all architecture is that things work better when they work together, with efficiency, with clarity, on purpose: and to make that happen, we need to get people to talk with each other. Simple as that, really.

One practical problem we face is that the architecture tools that we have available to us at present are not that well-suited to that purpose. For some conversations, yes – but those tend to be the most technical of the conversations. For the ordinary-yet-important conversations with everyday stakeholders, we’re not well-served at all. And as we move more and more out of the purely technical domains and towards a true ‘architecture of the enterprise’, the more that gap is going to get in our way.

One tool to rule them all?

What we really need is something that’s probably impossible in practice: a single tool that will cover the whole spectrum from the loose, freehand sketching and storyboarding of architectural issues and requirements, all the way through to the tight rigour and discipline that we need in specifications for real-world design and implementation.

We also need that imaginary ‘one tool’ to cover another whole spectrum of usages, from centralised repositories and very large ’scorecard/analysis’ displays through to multi-screen desktops to single-screen laptops to tablets and touchpads right down to handhelds and smartphones.

The big, expensive enterprise-architecture toolsets such as System Architect or ARIS or Troux Metis tend to sit over in one corner of the matrix between those two spectra: they embody the formal rigour of software-, system- or process-design and simulation, and they need big repositories, big servers and big displays to deliver their best performance. These are also definitely not tools that should (or even can) be used by general users – a fact I know from painful first-hand experience of the months we had to spend tidying up the mess that our business-managers made of our repository after we’d foolishly allowed them to play with it for a single week…

Then there’s the mid-range: toolsets such as Avolution or BizzDesign Architect or Sparx Enterprise Architect, or Alfabet or Essential. All of these are well suited to laptops and other larger single-screen systems, and each tend to emphasise particular themes: metamodelling with Avolution or Essential, for example, or Archimate business/IT-alignment with BizzDesign or Sparx, or IT-infrastucture configuration with Alfabet. They all have some kind of internal repository, which in turn supports some kind of diagramming; but it’s not always easy to share – especially across a whole multi-organisation enterprise. And these are still tools for specialists – not something that we can use with everyday business-folk, as I discovered the hard way when I presented a set of BPMN diagrams at an executive-meeting…

Down in the far corner, though, there’s almost nothing: no usable toolsets for idea-thrashing with ops-staff, developers, executives and all the other myriad non-specialists. Office tools such as Powerpoint and Visio are just-about-okay for documentation after the event – though they provide little to no support for architecture-rigour at all – but they’re far too slow and cumbersome for real-time discussion. So it’s no surprise that for most architects I know, their most important tools are a whiteboard and a sketchpad – and not only do those provide no linkage to formal architecture-rigour, but it’s usual not even possible to record and share the results. Which means that we have almost nothing with which we can engage people in the architecture itself – in the discipline of the architecture.

But what would such a toolset look like? What aspects of architecture-discussions could it cover?

Enabling interactive conversations on architectures

One project that I’ve been involved in (as a member of its alpha-test team) is Alex Osterwalder’s iPad app for his Business Model Canvas framework – perhaps take a look at the videos on Alex’s post. That’s also a key reason why I developed the Enterprise Canvas concept, to extend the same basic idea to the whole-of-enterprise scope. And there’s also a swathe of iPad or smartphone apps that cover themes such as sketching or mindmapping or outlining or project-management, that do at least enable us to record in a form which can be stored and re-used later.

The real aim, though, is to get to some kind of toolset that is freeform enough to be used in live discussions, yet beneath the surface embeds at least some of the rigour needed for architecture-development. There are some great hints towards this in an article in HBR by Michael Schrage, ‘How Your Smartphone Will Transform Your Elevator Pitch‘, which are worth noting in some detail here:

… His [business-idea] was undeniably clever, but aspects of his business model weren’t clear to me. He had his elevator pitch answers down pat, but I wanted to learn more. Unprompted by me, Osman whipped out his smartphone and handed it over. I was watching a decent video clip illustrating his product’s features and functionality. I could tap to hear testimonials. I could tap to play with a simulation of the software. In a matter of moments, the device had transformed Osman from an entrepreneur I was having a conversation with to a guide and narrator of an interactive experience. My focus and attention alternated between what he said and what appeared onscreen. Sometimes he’d take, touch, and hand back the device; other times, I’d point to something onscreen and ask another question.

The object — and our interaction with it — became an intimate part of our conversation. We couldn’t have discussed either [his product] or his answers to my questions the same way without it. An idle part of me wondered how cool it would be if our conversation (and my questions) could be recorded and time-stamped along with what was appearing onscreen. Osman refused to allow his smartphone to decay into a sales tool or product pitch — although those elements were baked into the material — and instead used the device as a medium to both reinforce his conversation points and invite new questions and comments from me.

I can say without hesitation that this felt technically and interpersonally different from “laptop-on-the-table” presentations I’d experienced 1,000 times. We were standing up, drinking coffee, chatting, and taking turns holding, viewing, and manipulating this device. The kinesthetics, eye contact, questions, and interruptions revolved as much around the device as us. We would have been worse off without it.

And, further on in the article:

Elevator pitches are important. The ability to boil down the essence of your innovation into a tasty forty-second sound-bite remains essential. Only now, the pervasiveness, ubiquity, and visuality of mobile devices quantitatively and qualitatively changes the ecology of interpersonal interaction. It’s no longer about what you say and how you say it; it’s increasingly about what you hand over.

What do you hand over that transforms the conversation? What do you hand over that visually and interactively adds value to your spoken words? What do you hand over that complements and supplements your pitch? What do you hand over that invites and inspires the curiosity you want? What do you hand over that makes you more persuasive?

… “Hand-it-over” innovation pitches can be seamlessly slipped wherever your prospects desire. Indeed, an excellent measure of “hand-it-over” effectiveness is whether the person who you “hand-it-over” to actually asks you to send what they’ve been seeing and interacting with.

So let’s summarise some of the key themes there:

• it’s not a presentation, it’s an interaction – a two-way or multiway conversation
• the interaction is kinesthetic – it involves touch (ie. handling and interacting with the device) as well as listening and seeing
• if practicable, the interaction itself should be recorded, as an annotation on the original presentation
• if practicable, it should be possible that the whole interaction can be shared

Beyond the whiteboard

That’s what we need for that part of our enterprise-architecture work – a toolset that enables us to engage directly with our stakeholders. And it needs to go both ways, too: to take a model or diagram from the formal ‘big-system’ part of the toolset-spectrum and share it and discuss it; and also enable and capture discussions about requirements, about trade-offs, about different understandings and paradigms and worldviews and expectations and assumptions across all the myriad of different perspectives in the enterprise. Both ways. About anything – about any aspect of the architecture.

Which also means that we must have some kind of language to enable us to move information up and down through that spectrum, across different devices, different systems, different toolsets. (It seems very unlikely that one vendor will ever cover the whole range that we need – but the information itself must be able to move around in any form that we need, yet always anchored back to the formal rigour required by each architecture-domain.) So that’s another hurdle to cross, because no such language exists at present.

So, given all of this, how could we improve on the venerable whiteboard and sketchpad? How could or would we record that kind of interaction? And how can we support a form of diagramming that is as interactive and illustrative as a whiteboard-session, yet still enables the underlying rigour? The specialist EA toolsets may be too cumbersome for this kind of interactive use, but surely we can create something with more rigour than Powerpoint or Visio?

That’s our challenge here. Comments/suggestions, anyone?

In part this is a follow-on from the previous post on the fundamental flaws underlying all forms of currency, but it also has many implications for businesses, enterprise-architectures, societal models, corporate social responsibility and much else besides.

And don’t worry, I’ll aim to keep this one short(ish) [later: turns out it's another long one - sorry...] – though I’ll probably return to the theme quite a bit in subsequent posts.

The key point in the previous post was that no ‘alternative-currency’ would solve the socioeconomic problems that we currently face: the all-too-evident failures and failings of the money-economy are merely at the symptom level, and attempting to replace conventional state-issued currency with some other kind of home-grown alternative would be merely one more variant on the theme of ’shifting deckchairs on the Titanic‘.

Yet clearly we do need something that will enable us to operate the kind of global-scale exchanges that our current economic models allow – because without that, it’s obvious that the city-based cultures especially could quickly collapse into anarchy of the worst possible kind.

It might perhaps be a surprise that what I’m suggesting here as an alternative actually is anarchy – but anarchy only in a strict technical sense, and of a radically different form.

Let me explain.

In the previous post I hope I made it clear that there is no way in which a possession-based economy can be made sustainable. Therein lies the real economic problem: possession is a classic example of the antipattern that “for every complex problem there’s a least one clear, easily-understood wrong answer”.

Underpinning that ‘wrong answer’ is another even deeper ‘wrong answer’: the notion of rights. Possession is defined as a right – the right to personal property, and so on. (In British law it’s more subtle again, in that it’s actually defined as a right to exclude others from access to resources that they may need: as the 18th-century jurist William Blackstone put it, “that “sole and despotic dominion which one man claims and exercises over the external things of the world, in total exclusion of the right of any other individual in the universe”.) But there’s a catch – a very important catch. To paraphrase Margaret Mead:

Rights are a social fiction; responsibilities are a social fact.

More to the point, it’s probable that responsibilities are the ’social fact’ – that the structure of a society is actually an emergent property that arises from the intermeshing of mutual responsibilities. A society – and hence that society’s economics – arise from those mutual responsibilities. A society’s economics represent its recognised means and controls via which its available resources are shared, exchanged and used – and those ‘means and controls’ are, in effect, defined and circumscribed by mutual responsibilities.

You might ask “So where do rights come into this?” But that’s the whole point: they don’t. Rights don’t even exist in any real sense: they’re just a convenient social fiction, useful for some circumstances – as we’ll see in a moment – but dangerously misleading in others. And economics and purported ‘rights of possession’ are a good example of where the rights-discourse is indeed dangerously misleading – as all of us are discovering right now…

Read more…

Any competent observer of economics would acknowledge that the money-based model on which most current economics is based is in deep trouble right now: somewhere between seriously-dysfunctional and completely broken. Many of the purported key-metrics such as GDP and GNP don’t really tell us anything useful at all about the actual functioning of the economy: all they describe, really, is the potential tax-base, in monetary terms – and the distortions that this introduces into the economic picture are the direct cause of many economic problems. Banking and, especially, finance have moved so far from their functional roots that they’re now little more than engines for embezzlement on an almost unimaginable scale. And the preferred ’solution’ to the fact that many, many things cannot be meaningfully described in monetary terms is simply to declare that such things do not exist or, if they do, they cannot conceivably matter within the overall economy.

(I won’t give links for any of those assertions above: we’d be here all day. They’re all well-known and long-proven problems, as a few hours’ worth of careful web-searches will demonstrate all too clearly. Just take it as read for the moment that that’s so, because the details as such aren’t that relevant right here.)

Given that there’s a perceived problem with the ‘money-economy’, what can we do about it? Well, the usual ’solution’ – and I use that term advisedly – is to rush out and devise some form of alternative-currency. I’ve seen dozens of these so far, and apparently there are actually thousands of these projects, across a whole spectrum from simple barter to community-based currencies to time-based currencies. But they all have one thing in common: they won’t work.

Not just ‘won’t work’: they actually can’t work. They can’t solve the problems that we face.

No form of currency will satisfy all of the requirements for managing an economy, without requiring distortions to the economy itself that will render that economy non-viable or non-sustainable, especially over the longer term.

And there’s no way round that fact.

My apologies if that fact offends anyone, but it is indeed a fact. And refusing to face that fact is not going to help anyone. Sorry.

Read more…

One of those happily-bizarre conversations about enterprise-architecture that happens on Twitter from time to time.

It started with a Tweet from Jörgen Dalhberg (@greblhad), to which I duly threw in a lighthearted reply:

• greblhad: If your #entarch can not be illustrated in 3D using LEGO then you have a problem.
• tetradian: RT @greblhad: If your #entarch can not be illustrated in 3D using LEGO then you have a problem <does that include LEGO ‘people-figures’?

I’d presumed that Jörgen was being reasonably serious about it – as in fact he was, as will become clear later. But I was also fairly serious about it too, because a couple of years back the CTO at one of my clients had done a beautiful physical ‘demonstrator’ for her overall infrastructure/applications-architecture, built as a three-layer wooden jigsaw-puzzle, which she’d presented to the organisation’s executive. By making all the trade-offs and dependencies visible – and literally tangible – in this way, she’d finally given them a means to understand what was going in their systems, and what they needed to do to help her bring it into a more sustainable state.

So I’d seen how such models really do work in practice – and was a lot more inclined to take Jörgen at his word. But for various reasons, others perhaps weren’t, as the following Twitter-conversation shows:

• oscarberg: RT @greblhad: If your #entarch can not be illustrated in 3D using LEGO then you have a problem > Static view only. How show interactions?
• oscarberg: @tetradian @greblhad 3D LEGO is better suited to describe a physical architecture than for #entarch
• richardveryard: @oscarberg @tetradian @greblhad LEGO (even with people figures) shows momentary instantiation of an architecture, wrong level of abstraction
• tetradian: @richardveryard @oscarberg @greblhad yeah, true, but playing with those little LEGO-people is *fun*!
• oscarberg: @tetradian @richardveryard @greblhad  I play a lot with LEGO with my kids, but it doesn’t make it suited for describing #entarch
• greblhad: @tetradian @richardveryard @oscarberg you should all check out http://www.seriousplay.com/ that’s part of what has inspired me #entarch
• greblhad: @richardveryard @oscarberg @tetradian LEGO … wrong level of abstraction < all illustrations are momentary, still useful though
• oscarberg: @greblhad @richardveryard @tetradian  would agree 3D Lego can be used to describe certain aspects of an #entarch, but not complete
• greblhad: @oscarberg @richardveryard @tetradian  Oscar what aspects of an #entarch are you referring to as not possible to model with Lego?
• oscarberg: @greblhad @richardveryard @tetradian perhaps “not possible” is not what i mean, but rather “not usable” // a model is a communication tool. We need different ways to communicate different things
• greblhad: I am so sure any #entarch in production today could be expressed perfectly well in a Lego model, I’d probably bet a 100.000 GBP on it.
• jenshoffmann: @oscarberg @tetradian @greblhad we have succesfuly used LEGO #entarch modells in early stages to dev. a shared view of the stakeholders // you wouldn’t document/manage an #entarch with Lego, but as a tool for critical discussions.
• oscarberg: @greblhad @hypergogue original discussion was about describing entire #entarch with Lego. Lego as a comm tool is another question
• greblhad: @oscarberg @hypergogue original discussion was about describing  #entarch with Lego. < which is a one way of communicating intention
• oscarberg: @greblhad @hypergogue yes, but using one tool to communicate every aspect of an #entarch is unlikely to be effective
• greblhad: @oscarberg  @hypergogue yes, but using one tool to communicate every aspect of an #entarch is unlikely to be effective < I agree

There the conversation seemed to languish for a while, so whilst writing this I tossed in a request for more information:

• tetradian: .@greblhad would love to see some LEGO models of #entarch – even just for communication purposes – a blog-post w photo examples, please?

What I hadn’t realised, until following up the Serious Play link, is that this really is a serious part of the Lego domain, with serious registered-trademarks and all. Via a network of licensed facilitators they’ve in fact been running Serious Play workshops for the past five years or so – I remember now that I’d once heard of it somewhen, but had long since forgotten about it. But they’ve now (as of June 2010) opened it up as a kind of ‘open source’ toolset: take a look at the LEGO® Serious Play® Open Source page, for a download document describing the principles, and then perhaps take a wander round the website itself. Will admit I’m surprised, and impressed: ’serious play’ indeed.

No further information as yet from Jörgen or any of the others in that conversation - will post an update here if any comes past. Watch This Space?

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?

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?

This one’s about uniqueness and serendipity and ‘chaos’, and I’d better say straight away that it’s a lot more tentative and exploratory than many of my posts of late.

I’m seeing a theme in enterprise-architecture and the like that’s always been there in the background, but seems to have recently started to become a lot more visible to a lot more people. It’s difficult to pin it down precisely, but it can be seen sort-of sideways-on in many other themes:

• design-thinking and the like, now even embedded in the new US Army field-doctrine
• references to the difficulties of designing for uniqueness or ‘being prepared for surprise‘
• a lot of posts on applications of improvisation-training in business, not just for sales-folks but for business-execs as well
• more references to futures (futures-plural, that is, rather than the singular ‘predicting the future’)
• more interest in ideas about personal-level strategies and tactics for innovation, such as those from one of my favourite books, Beveridge’s The Art of Scientific Investigation
• a sense that the pace of change in business is heading towards real-time, and often is already at real-time
• a surprising number of references to serendipity in business, often linked to innovation in various forms
• a renewed focus on disaster-recovery, business-continuity and the impact of ‘long-tail’ kurtosis-risk and ‘black swan‘ events
• the recognition that every sales-event is actually a unique ‘market-of-one’, in which the choices at the moment of choice are not predictable or ‘rational’ at all
• the role of visioning and the like within enterprise-architectures, business-architectures, quality-systems and so on

Or, to illustrate, a couple of items from today’s Twitterstream:

• CreatvEmergence: Improvise to Innovate – http://bit.ly/apch2U
• oscarberg: RT@esauve: “The Social Web is moving toward a future where serendipity replaces search” http://wp.me/p4P8c-zug from @gigaom

This isn’t about emergence, or the ways in which unique or ‘chaotic’ events can be used to guide sensemaking and pattern-identification in complexity: others are better-qualified to explore that domain than I am. Instead, what I’m seeing here is almost the inverse of emergence: rather than deriving a pattern within complex events, we choose and use a pattern to guide our choices in inherently-unique events. Not just serendipity, but serendipity by choice – an architecture for uniqueness.

One item that comes to mind here is Gooch’s Paradox, identified by the psychologist Stan Gooch: “things have not only to be seen to be believed, but often also have to be believed to be seen”. To enable serendipity to occur, we first have to be a mental space that allows it at all. In that sense, beliefs themselves become tools.

Another is a quote from The Art of Scientific Investigation:

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.

In a truly unique context – and it seems to me that every real-world context must always be in some part unique – there is only chance: there is no actual connection between anything and anything-else, other than that which we give it. Everything is coincidence, in an exactly literal sense of ‘co-incide-ence’: any meaning that we may ascribe (or not ascribe) to such coincidences is our choice.

Yet from Gooch’s Paradox, this also seems to be able to run backwards: we have the meaning first – predetermined beliefs from our culture or ’scientific law’ or the like – and then find coincidences to match. The belief determines what we see – which can lock us out of an ability to see anything else.

So in a business-context, for example, the beliefs that we use to filter what we see need to be tight enough to allow us to make useful sense of what’s happening around us, but also loose enough to allow true serendipity to happen – where the context itself seems to be giving us what we need. Hence Pasteur’s “chance favours only the prepared mind”: a preparation that has the right balance between precision and openness.

Which leads us to the idea of an architecture of uniqueness, an architecture designed to enable and enhance opportunities for serendipity.

Improvisation is one obvious component of such an architecture: a deliberate practice in working with uncertainty, in real-time.

Another component might be some variant of meditation, where continual, consistent repetition of the same actions or conceptual behaviours provides a stable ground within which useful ideas and events can coalesce. (This is the exact inverse of Einstein’s famous remark that “insanity is doing the same thing and expecting different results”. That dictum is true enough in a predictable world; but in an inherently unpredictable world – any context which is truly unique – anything we do will always lead to different results, hence repeating the same action over and over may be the only thing that will keep us sane! )

Sometimes we also need to deliberately ‘trick’ people into a state where serendipitous events can occur. For science-fiction buffs, this is very well described in Noise Level‘, a classic 1952 short-story by Raymond F. Jones: a group of scientists and engineers are asked to ‘reconstruct’ a supposed anti-gravity device, and actually manage to do so – only to be told at the end that the whole thing had been a kind of hoax, to show them how to open their minds to new possibilities that their conceptual filters would otherwise prevent them from being able to see. The method was a deliberate trick, but the end-results were no trick at all: nicely recursive, in that a very practical real-world technique is embedded in a fictional story about a fictional story.

There’s also the key role of visioning – a real enterprise-vision, that is, not the usual useless marketing-puff ‘vision’ – as a principle-based anchor for real-time decision-making amidst inherent uncertainty: the role in the military of ‘Commander’s Intent‘, for example, or John Boyd’s OODA (Observe, Orient, Decide, Act) cycle.

And there’s much more, such as the distinctions between analysis and emergence – which only ‘make sense’ outside of real-time – contrasted to the real-time spectrum between the simple and the chaotic; or the need for some kind of boundaries between the ’special world’ or chaos – where anything is possible but can send us into panic the moment we go off-balance – compared to the ‘ordinary world’ of rules, regulations and supposed certainty.

So what’s your opinion on this? What can we do to make this work? What strategies, tactics, models, methods would we need for this ‘architecture of uniqueness’, and architecture to support serendipity? And how would we apply this in enterprise-architectures and elsewhere?

Over to you, if you would?

History seems to be all in vogue in Cynefin circles at present. On one side, for example, there’s Cynthia Kurtz – the too-often-unacknowledged co-creator of Cynefin, and originator of some of its key concepts such as the crucial distinctions between ‘order’ and ‘unorder’ – who’s recently written some truly excellent posts on her past involvement with Cynefin and her subsequent development of those ideas into her current Confluence model. Very strongly recommended.

On another side, Dave Snowden has been busily documenting his own ‘history of Cynefin’, in a series of blog-posts with that title. In Part 4, for example, I’m very glad to see that he does indeed describe Cynthia’s crucial role in the development of Cynefin. And in Part 5, bizarrely, he uses my own work on context-space mapping – uncredited, unacknowledged, and, of course, completely out of context – as his sole example of an ‘illegitimate approach’ to usage of Cynefin concepts. I suppose I ought to be flattered at this singular censure, though to use Dave’s own words, “I don’t know whether to laugh or cry” at this, because all it really demonstrates is his continuing inability to get the point. Oh well…

(Unlike Dave, I’ve never laid claim to the mantle of ’scientist’. I’m a toolmaker, a creator of conceptual tools: my real field is metamethodology, the methodologies for creating methodologies to create context-specific methods like those in Cynefin – and although there’s always a large theoretical component to that work, the core focus is always on practice, not theory. In a classic Two Cultures sense, might the real problem here be that we’re operating in different metaphoric ‘worlds’? No matter: it is what it is (or isn’t), and that’s that.)

The point that Dave seems to be missing is that he’s still using entirely the wrong criteria to assess what context-space mapping is all about. None of it is about ‘truth’ in the formal scientific sense: it’s much more about ‘mashups’, about the quest for something useful, that has value in a given context – which is a fundamentally different concern. To use one example he so pointedly dismisses in his ‘History’, if we were to merge the Cynefin categorisation with the classic ‘data, information, knowledge, wisdom’ stack, and claim that it was somehow ‘true’, that would make indeed no sense at all: if I’d actually done that, Dave’s critique about ‘illegitimacy’ would indeed be valid. But the whole point here is that in context-space mapping and many other related techniques – such as the venerable SWOT – we intentionally create crossmaps with  nominal-’mismatches’ of that type, and use the resultant cognitive-dissonance to trigger new ways of looking at a context. Mistaken notions of ‘truth’ or ‘legitimacy’ simply get in the way of this process: the legitimacy is determined from the discipline and precision of process, not from an ultimately-arbitrary ’scientific lineage’.

It’s possible to argue that I continued to associate what’s now context-space mapping with Cynefin for a little while too long – a month or two, perhaps – beyond the point where it had become probable that their paths had diverged too much to make sense. It’s a common enough mistake, though, and perhaps a less reprehensible one than simply renaming someone else’s work as one’s own, without any actual difference in model. (Is acknowledging influence a greater ’scientific crime’ than denying it? – I honestly don’t know.)

There’s also the blunt reality that every ‘new’ model is sort-of ‘illegitimate’ – Cynefin included, as Dave makes clear in his history – in the sense that it’s a kind of ‘bastard child’ of many different ideas coming together in unexpected ways. For context-space mapping, I’ll freely admit that the overall method and model each have many different ‘parents’, some of which I’ve long since forgotten and some I may never even have known. Yet that’s true for the work of most of us, I’m sure.

So in the current spirit of exploring the history of our respective models, I’ll point to a key influence behind context-space mapping, which came up in several different forms, most of them predating my involvement in Cynefin by several decades.

Read more…

Development of new ideas, processes and practices will always be a social process, and always somewhat messy.

To enable that development to happen, we need social conditions that can support it – and screen out behaviours that prevent it.

Those social conditions can best be described in terms of policy, which from my experience I would summarise as follows:

The debate needs to be respectful of the process – the fact that, by its nature, much of the work must pass through periods of inherent uncertainty. For example, see my Sidewise post ‘On innnovation, foundations, scaffolding and Portakabins‘ for some suggestions on how to handle this.

[Update in response to comment #1 below - many thanks to Paul Jansen for the critique]
The debate needs to be respectful of emotion – the fact that, by its nature, development and debate is inherently challenging, and will hence trigger many different emotions as positions and views are put forth, defended, argued, abandoned and so on. We need to ‘play fair’, ‘be reasonable’, allow ourselves and others to make mistakes, to stumble, to get things ‘wrong’, to feel embarrassed yet still feel safe in being embarrassed, yet also to keep moving towards the desired or emergent aim.
[end of update]

The debate needs to be rational – by which I mean an ability and willingness not only to test the internal logics of the ideas in scope (which in some cases may not follow simple ‘true/false’ binary-logics, by the way), but also to move outside of one’s own assumptions, theories and beliefs.

The debate needs to be honest – by which I mean that each party will need to focus strongly on facing their own personal challenges from the requirements for respect and rationality, both of each other and of respect to the ideas themselves.

The debate needs to exclude all forms of violence and abuse – or at least, given the realities of social interactions in often-challenging circumstances, that all parties in the debate must actively address and minimise these concerns to the maximum extent possible, both within themselves and with and/or from others. (The more positive form of this point is that we should always aim maximise each person’s ‘ability to do work’ in the respective context: see my ‘Manifesto on power and response-ability in the workplace‘.) ‘Violence’ is any attempt, in any form whatsoever, to prop oneself up by putting others down (or the ‘lose-win’ variant, putting self down to prop others up); ‘abuse’ is any attempt, in any form whatsoever, to offload responsibility onto others without their engagement or consent (or the ‘lose-win’ variant, taking responsibility from others without their engagement or consent). This requirement was famously summarised by Bob Sutton in ‘The No-Asshole Rule‘:

Two tests are specified for recognition of the asshole:
1. After encountering the person, do people feel oppressed, humiliated or otherwise worse about themselves?
2. Does the person target people who are less powerful than themself?

If we wish to be engaged in meaningful debate, it is the responsibility of each of us to uphold that policy to the best of our ability.

In my own case, I challenge myself constantly on that policy. I know that, like everyone else, I will often be ‘wrong’ about some aspect of application of an idea; I know that, like everyone else, I will never have sufficient complete, accurate and final information needed to make concrete, unchallengeable decisions; and I know that none of this process is easy, for anyone.

It is clear, however, that some people, for various reasons such as excessive ego, assumed ‘authority’ or mistaken notions of ‘possession of the truth’, seem to believe themselves to be exempt from such policy, and instead believe that they have the ‘right’ to override others in any way that they wish. The result in each case is failure of the debate, and damage to or destruction of the development in scope – a circumstance from which everyone loses.

It is therefore our unfortunate but necessary responsibility to exclude such people from debate, until such time as they can demonstrate that they are able to hold to that policy.

In some cases we can do so by removing ourselves from the debate: I have had to do so quite often in discussions on LinkedIn, for instance, where there are all too many infamous examples of ‘debate-destroyers’.

Yet in other cases – and a personal weblog is one of them – there is no way to withdraw, and hence the only option is to explicitly exclude the offender.  I’m glad to say that over the past couple of years I have only been forced to do so here on two separate occasions, with two different people: yet it needs to be understood that it unfortunately is necessary in each case, for everyone’s sake. It also needs to be understood that in each case it is solely that that person’s behaviour makes it impossible for the debate to continue: it says nothing about the person as such (a crucial distinction between what they do versus who they are).

Similar policies are in place elsewhere, such as this extract from one of the LinkedIn discussion-groups on enterprise-architecture:

If you are not willing to have a civil discussion, you will not be permitted to play in this educational playground to further the cause of EA. No one that attacks will be permitted to play. This is a healthy environment to exchange ideas … not to better your cause at the expense of others.

I would urge everyone to consider and apply such policy on their own weblogs, on their Twitter-conversations, and everywhere else where difficult discussions need to take place.

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…