Uh, no. Not a good idea. Not just because it’s a really bad deal from our perspective, but much more that Reality Department really doesn’t work that way: there’s no short-cut to experience.

Yes, it all looks simple enough – in fact that’s the whole point. A lot of simple visual summaries, and surprisingly simple-seeming methods, too. Yet it only looks simple because we’ve been through a heck of lot of hard work to make it that way. Hard-won experience, won the hard way through years and years of practice in many, many different contexts, getting it ‘wrong’ time and time again, in many, many different ways in order to get it right.

The real trap is that these simple-seeming ideas and methods aren’t simple rules, prepackaged sense-making and decision-making that will always work in every context. These are simple principles, simple guidelines, the kind of easy-to-memorise information that helps decision-making in real-time, in circumstances that are subtly different every time. (See my SCAN posts for more on these distinctions.) If you try to use them as ‘rules’ for inherently-uncertain contexts, without understanding why those principles apply, or how they need to be tweaked every time to match each different context, you’re going to be in real trouble – along with everyone else around you. Not a good idea…

The same often applies even to things that really are ’rules’. Take that example of perhaps the greatest simplification ever made: e=mc². All the core information you need to build a nuclear power-station is right there in that equation: but there’s a heck of a long way – a heck of a lot of engineering-experience – to go from that one equation to building a nuclear-power station that actually works.

Same with everything else, really: simplification is essential, but can also be deceptive – especially when people mistake ‘simple’ for ‘easy’…

Which is also why I get a bit hot-under-the-collar about the current proliferation of ‘certification-schemes’ in enterprise-architecture and elsewhere. Some of them are genuinely valuable, but others – to be blunt – are little better than money-spinning scams, in terms of the actual value that they (don’t) deliver. And the crucial distinction revolves around the role and recognition of experience.

For example, the TOGAF Foundation and Archimate Foundation certifications have real value. They verify that the respective person has a credible command of the terminology and language – a requirement that matters a lot for communication across a dispersed and disparate team.

Likewise the ATAC certifications should have real value, because each explicitly tests practical experience in the respective area.

But unless they’ve changed it in the past year or so, the full TOGAF certification is delivered through the absurdly-inappropriate mechanism of a multiple-choice test. And to my mind, that’s not merely useless, it’s actually worse than useless, because it’s exactly how not to test for the kind of experience that that type of competence requires. (When I did the TOGAF 8 exam some years back, I almost failed because I answered several key questions correctly in terms of real-world experience, rather than the theory-based wrong-assumptions that the test thought were ‘right’.) The result of that kind of pseudo-test is a bevy of people who can wave a certificate around, but have no idea how to do the work in any real-world context.

A good training-course can make all the difference, and the better training-providers do take up some of the slack here. (I’ll wave a flag at this point for John Polgreen at Architecting The Enterprise, who’s been doing sterling work for years on adapting TOGAF for the US-government context.) Yet none of that competence carries through anywhere into the actual test: so unless we know each of the training-providers, we have no way to tell whether a candidate does actually know what they’re doing, or merely that they have a piece of paper to prove that they know just enough to get into real trouble, but not enough to get out of it again.

In effect, right now, the full TOGAF certification is of less real-world value than the Foundation certification – which is both bizarre and sadly pointless. And I’ll hasten to add that I’m using TOGAF here merely as one example amongst many: it may well be that most of the so-called ‘certifications’ in this field are even more meaningless than that. And the results can be seen everywhere in the trade…

In short, it’s a mess.

What we need to be testing for is genuine understanding of a context, and the ability to adapt for uniqueness. And that calls for much, much more than can be covered in a crude multiple-choice test delivered through a mindless machine. Sure, that kind of test is cheap, and relatively easy to administer: but it’s also all but meaningless for anything than foundation-level rote-knowledge. It really does take years of painful practice to develop the experience needed to do this work well: and if this trade is to gain the credibility that it needs, we need to stop pretending that we don’t need to test for that experience.

Time to re-think how we do this, and how we respect this, too: there’s no short-cut to experience.

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

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

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

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

Maintaining the balance in real-time

What came up from the previous post in this series – and perhaps even more from the post ‘Domains and dimensions in SCAN‘ – is that we have three distinct dimensions we’re dealing with in sensemaking:

• modality – the extent of perceived ‘controllability’ versus ‘possibility and necessity’
• available-time – the amount of time remaining before an action-decision must be made
• repeatability – ability to reliably recreate the same perceived results

At the highest speed, just about all we’ll have time to see is the modality – in particular, whether it’s Simple (a true/false choice) or Not-simple (broader range of ‘possibility and necessity’):

As we saw in the third post in the series, we have known-tactics to work on either side of that split. The crucial concern is to use the appropriate tactics – which means we need to know which side of that Simple/Not-simple boundary we’re on.

The reason why this is important is that we also need to balance the variety in the system with reliability and repeatability of results. A Simple technique such as a predefined work-instruction allows for only a small amount of variety in the system – which is fine if there is only minor variety in the system. But if the variety, or uncertainty, is higher than the technique allows, we’re going to be in trouble – but given the limited perspectives of the technique, we may not even know it until too late, let alone how or why it failed. Conversely, using a Not-simple technique in a low-variety context is not only overkill – too many options! – but is probably less reliable as well. To summarise:

• a Simple technique would give the most repeatable results in a low-variety context
• a Simple technique is unreliable in a high-variety context
• a Not-simple technique is overkill (‘too complicated! too ambiguous! too uncontrollable!’) in a low-variety context
• a Not-simple technique is the only way to gain repeatability in a high-variety context

Another key trade-off here relates to skills and experience: any Not-simple technique is going to rely on skills and experience, whereas on the Simple side it usually won’t. (In fact that’s one of the reasons why it’s Simple: anyone or anything can do it, as long as they follow the same Simple rules.) We gain the best repeatability and reliability at the lowest effective cost by achieving and maintaining the right balance between Simple and Not-simple.

Yet in many real-world systems, or perhaps most, the effective-variety itself may change – sometimes even on a moment-by-moment basis. Which means that to gain that required repeatability and reliability, we need to be able to ‘move’ back-and-forth across that spectrum of modality, in line with the changes in variety. This can be tricky… – and especially so in a bureaucratic command-and-control context where everything ‘should’ be predictably Simple, but isn’t…

This is actually the role of sensemaking: identifying the variety in the context, and the nature of that variety. Once we’ve ‘made sense’ of what’s going on, we can then decide what to do about it – and do it. In most present-day business contexts, we need to be able to do this at ‘business-speed’ – in other words, fast. As a quick summary:

• the moment we need to ‘make sense’ of something, then by definition we’ve moved over to the Not-simple side of the scale
• we gain the best reliability and speed by pushing it back over to the Simple side
• we maintain the best flexibility – but perhaps at a cost in required skill-level and ‘understandability’ – by holding it on the Not-simple side

(Note too that in skilled-work ‘Simple’ is often subjective, not objective: it’s experienced as ‘Simple’ by that individual – such as via ‘body-learning’ from long practice – but not necessarily ‘anyone can do it’ in the usual sense of “follow these step-by-step instructions in the manual”.)

Adding time to the sensemaking equation

All of the above is what happens at business-speed. Yet in the same way that contextual-variety can change, so too can the amount of time-available before we have to act – in other words, the available time for sensemaking itself. Given more time, we can bring more ‘considered’ sensemaking-techniques into the mix – particularly the various flavours of ‘systems-theory’ and the like.

For SCAN, it’s a bit like stretching a roller-blind outward from the ‘now’ to give us a bigger picture of our available sensemaking-options:

Stretching outward in time also highlights important nuances between Simple and Not-simple – a gap that the ‘considered’-techniques would seem to ideally suited to fill. This is where the word ‘complex’ tends to come into the picture…

Managing complexity is, uh, complex… – but the real key is probably around variety. For example, on the ‘organised complexity’ side of the scale, Roger Sessions‘ technique Simple Iterative Partitions aims to reduce (or, ideally, remove) complexity in IT-’solutions’ for a context – in effect, identifying what is or is not in the Complicated ‘domain’, and assessing and clarifying the factors that could bring it down into a real-time Simple ‘solution’. On the ‘disorganised complexity’ side of the scale, the various forms of complexity-theory and suchlike will aim to bring the higher volatility, uncertainty, complexity and ambiguity down into patterns and leverage-points and the like that would be usable on the Not-simple side of the story – preferably in way that would be experienced as ‘simple’ by the agents for that action.

Yet all of those ‘considered’ sensemaking-techniques take time to execute – and we forget that fact at our peril. Available-time has a nasty habit of collapsing to nothing – and if we’re in the middle of a ‘considered’ sensemaking-process when that happens, we can find ourselves with some seriously-scrambled notions of what makes sense and what doesn’t, and a serious misalignment between context-variety and what we think of as ‘simple’ in that context. That’s where things can get messy…

And that’s where we also discover that, yes, a little knowledge can indeed be more dangerous than no apparent knowledge at all – not least because it can slow things down to the point where they really don’t work.

[A classic example of this in juggling is trying to think too much about what we're doing whilst we're doing it... gravity won't wait while we try to think out our every move!]

Doing the ‘wrong’ thing at real-time is often okay if we’re running fast enough to recover – especially if we design for ‘safe-fail’ or ‘graceful failure’ – and if we have some solid idea of our intended outcome. And we can often get away with a Simple decision-structure that tries to calculate and compensate for every Complicated factor, as long as the cycle-time is fast enough to do this at or near-real-time – as it can be in many IT-based ‘solutions’ for the organised-complexity side of the scale. But I’ve learnt the hard way to be very wary of certain forms of complexity-theory, because they’re not usable at ‘business-speed’: they shy away from ‘Chaos’, deride the Simple, and insist that we should only work with their concept of the Complex – a ‘solution’ which requires time that we rarely have available to us in real-world practice.

[One well-known example asserts that the only relationships between the Simple and a real-time Not-simple are either a collapse into chaos, or a rigid 'take control' - neither of which actually make much sense in practice. It also indicates that the only reason to be in the Not-simple - and to leave it, as quickly as possible - is to garner information to assess at relative leisure in tools for the Ambiguous 'domain': we may bounce back-and-forth between those two 'domains', but the focus is always away from the real-time.

In effect, that structure explicitly leaves us with almost no means whatsoever to deal with real-world variation of variety in a real-time context - which is, however, where almost all real-world sensemaking and skill-based work takes place. Not helpful...]

In practice, we would use time-variation – or rather, the easing-off of time-pressure – to move back-and-forth between a ‘considered’ sensemaking-framework to gain greater understanding of how to work with complexity, and the real-time Simple/Not-simple balance to take action at business-speed. This is what all ‘learning-loop’ processes aim to do, such as PDCA, OODA or the various Agile development-methods. But when a ‘considered’-type framework purports to resolve ambiguous-complexity at business-speed, watch out – because it doesn’t work.

Architecture for sensemaking

So as enterprise-architects and the like, what can we usefully do about all of this? Some practical suggestions:

– Identify the types of sensemaking and decision-making required in each context. Document these in the architecture-models.

[Where appropriate, note also the skills and skill-levels required for the respective sensemaking and decision-making - see later with regard to skills.]

– For inherently-Simple methods such as employed in machines, most IT-systems and rule-bound (‘regulated’) human processes, identify the limits of variety covered by those systems and social structures. If – as is often the case – the real-world context may at times contain a higher range of variety, we must identify, design, develop and test methods to identify when those limits may be breached, and Not-simple processes that can take over as soon as those limits are breached.

[This is a typical concern for business-continuity / disaster-recovery planning, recovery from security-breach, or recovery from social 'fail' such as public-relations or anti-client problems, ethics breach, lawsuit or supply-chain failure.]

– Identify the ‘business-speed’ cycle-time for sensemaking – in other words, establish just much time is available before action-decisions must be made, and hence how much ‘considered’ sensemaking-techniques can be used in customer-contact processes and the like. Very tight cycle-times with significant amount of Not-simple sensemaking will need training in learning-loops such as real-time OODA; longer cycle-times; longer or more variable cycle-times can use more mainstream learning-loops such as PDCA, typically supported up by After Action Review and the like – but again, training will be required.

[Note that learning-loops will typically also need information-system support of various kinds, including availability of 'lessons-learned' wikis and similar tools to support real-time sensemaking.]

– Identify options to bring the Not-simple towards the Simple. More specifically, identify processes where ‘lessons learned’ and other idea-gathering in the Not-simple ‘domain’ can be brought into the Ambiguous as patterns; where appropriate Ambiguous emergent patterns can be brought into the Complicated ‘domain’ and potentially be distilled into algorithms; and where Complicated algorithms can be reduced to Simple rules and work-instructions. In the sciences, this sequences is classically described as ‘idea to hypothesis to theory to law’.

[Note that only some items can be moved from one 'domain' to the next in this sequence. Some Not-simple items will always remain inherently unique and uncertain, even though a pattern can be identified for it - such as the fission-point for a single atom in radioactive decay, relative to the statistical half-life for atoms of that type. Some Ambiguous items will always remain inherently uncertain - such as many social processes, or iterative processes where the result of one loop acts as a cause for the next. And some Complicated algorithms - especially those with longer delay-loops - cannot be reduced to Simple real-time rules. The point here is to do what we can to move things towards the Simple - and to acknowledge those items that can't be moved on any further. More on this in another post, anyway.]

– Identify processes, or parts of processes, which rely on skill and experience – which by definition will place some or all of their activity on the Not-simple side of the scale. (Conversely, anything on the Not-simple side of the scale is likely to require skills and experience.) Identify the respective skills and required skill-levels in each context. Document and design for these within the architecture.

[In the terms of the service-content model used in Enterprise Canvas, these are usually classed as capabilities. Wherever appropriate and practicable, these should be documented and tracked as such within the architecture-models.]

– For all identified skills, identify the processes by which these skills will be developed, either by outside organisations, or preferably in part via learning-loops in live business-processes. Again, document and design for these within the overall enterprise-architecture.

[Note that key parts of skills-development can only take place when time-pressure is slackened-off enough to do 'considered'-sensemaking on personal aspects of the skill over significant periods of time - typically over months or years. There is a huge kurtosis-risk for any organisation that maintains time-pressure such that it does not allow sufficient time for that type of skills-development or skills-transfer to take place. Again, I'll explore this in another post soon, but for now, see the Sidewise posts '10, 100, 1000, 10000' and 'Where have all the good skills gone?'.]

– Identify the ‘practice-spaces’ required for skills development, typically either ‘safe-fail’ or (usually for higher-level skills) ‘brown-out’ or ‘graceful failure’. Describe, document and design for these in the overall architecture.

[This will typically include simulation and real-time 'games', and explicit practices for observation and reflection, and for skills-transfer from more experienced practitioners. This should also include specific social-structures to support skills-learning, such as the explicit 'no-blame' rules that underpin the US Army's usage of After Action Reviews.]

It may also be interesting – and potentially important – to explore Mask-effects or options within the organisation and its context, and structural support for the ‘Don’t Panic!‘ theme, as both summarised in the ‘Not-so-simple’ section of the third post in this series.

Anyway, more than enough for now, I think? Over to you if you wish: comments or suggestions, anyone?

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

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

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

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

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

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

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

Making sense, making decisions: ‘considered’ vs ‘business-speed’

In an earlier post I contrasted a ‘considered’ approach to sensemaking, versus ‘business-speed’.

A ‘considered’ approach assumes that there is available time in which to make sense of the context. Formal ‘hard-systems thinking’, for example, tends to focus on analysis, whereas a ‘soft-systems‘ or ‘complex-systems‘ framework such as Cynefin tends to focus on experimentation and emergence. All of these methods rely on an iterative cycle of information-gathering and review – ‘sense / analyse / respond’ or ‘probe / sense / respond’, in Cynefin terms – that takes a significant amount of time to execute each iteration. There are ways to speed up the analysis/experimentation cycle, but in practice there is probably no way to make it work at business-speed, at or close to the real-time ‘now!‘.

A ‘business-speed’ approach assumes that there is little or no time in which to assess, analyse or experiment in the context, yet sensemaking and intentional decision-making must still take place. Whilst the ‘considered’ frameworks do make various recommendations here, in my experience they’re mostly aimed at gathering information to bring back for analysis or experiment – which actually doesn’t help that much when we’re in the real-time context. For the latter, we need something different.

To summarise this in SCAN terms, look first at the core graphic, with its two axes of decision-logic and time-available-before-decision:

In practice, methods for analysis (for the ‘Complicated’) and emergent experimentation (for the ‘Ambiguous’) are only viable if there’s a fair amount of time before a choice must be made and expressed in immediate action. At ‘business-speed’ – at the moment of action – time-to-decide is often compressed right down to the single ‘horizontal’ dimension of real-time decision-logic:

At that level, we need radically-different methods to those we would use in more ‘considered’ sensemaking. In principle, it’s a continuous spectrum of modality of decision-logic, but the crucial distinction is the ‘Inverse-Einstein’ test:

• if we do the same thing and get the same results, we’re ‘in control’ (whatever that means in the context) – which places us on the left-hand ‘Simple’ side of the spectrum
• if we do the same thing and get different results, we’re not ‘in control’ – which places us on the right-hand ‘Not-simple’ side

Again, it is a spectrum, and in real-time contexts we typically move back-and-forth across that spectrum, often at very high speed. For simplicity, though, we’ll split this exploration into those two parts: Simple, and Not-so-simple.

At the Simple end of the scale…

For here, the ‘considered’ tactic is ‘sense / categorise / respond’. Which is valid in its own way, but definitely not sufficient – not least because those categories have to come from somewhere…

[I remember a consultancy-session with a large security-organisation: "We have a rule for everything!", they said proudly. "What happens when you come across something new for which you don't have a rule?", we asked. "We make up another rule, of course!" "Yes, but when do you make up this new rule?" "After the event, I guess...". "So how do you choose what to do during the event itself?" An interesting silence...]

Machines work on rules. Most IT-systems work on rules. Work-instructions are rules, of a kind. As mentioned in the previous post, checklists provide very important rule-like support for real-time action. Yet rules themselves are not the whole story, because the capability to apply those rules also has to come from somewhere – which likewise is not always as simple as it seems.

And when the ‘agents’ for that capability are real-people, some other quite different aspects often come into play. This is what we might call ‘body-learning’, literally embodying very-high-speed response that some people might describe as ‘instinctive’, but it’s an ‘instinct’ that’s grounded in often very long periods of first-hand practice. What makes these responses seem instinctive is that they occur in sequences that are far faster than are feasible for rational thought – and yet it is in response to real-time events. Consider, for example, the kind of ‘instinct’ that causes you to press your foot down on an imaginary brake-pedal when a passenger in a car…

[I'm playing in an Irish-music session at the local pub: I'll freely admit I'm no master-musician, so I'm keeping well in the background here, yet still keeping pace with everyone else. It's a very fast reel we're playing, probably upwards of 150 beats per minute: that's more than 10 distinct notes a second, or an average of perhaps 20-40 finger-moves a second, often not in linear sequence. The tune ends, another starts, still exactly on the beat; just about everyone switches straight away to this new tune, within a note or two at most - though no-one had rehearsed any of this beforehand, or even knew which tune would come up next.

And yet the typical reflex-response interval for rapid change like this is around 200 milliseconds - the time taken up by at least two notes at this speed, maybe more. So this is faster even than reflex-response, let alone conscious decision: clearly something more than just 'considered' sensemaking and decision-making is going on here...]

What’s going on in this body-learning is that patterns and sequences are embedded through constant repetition – in theory, itself a Simple process. Quite where these patterns are executed in physiological terms I’ll admit I don’t know, but the speed suggests it’s run via local ganglia – there certainly isn’t time to run solely from the brain. The overall instructions to run each pattern may come from the centre – but not every move.

[There's a nice analogy here with the distributed parallel-computing system we used for a major long-duration aircraft test at the lab, starting almost two decades ago. There were over a hundred independent local-controllers, each managing their own control-law for their actuators, sensors and feedback-loops. All that the central-controller had to do was pass required overall positions or loads to the local-controllers every half-second or so; the local-controllers handled all the rest, including any unplanned-for interactions across the system. The control-intelligence was distributed in real-time as an emergent property of the whole system - not embedded solely in the central-controller, as it would be in a classic 'hard-systems' model, or a Taylorist model of a business.]

Training usually takes place in a ‘safe-fail’ context such as a simulator, where no-one gets hurt if – or more likely when – things don’t work out as intended. With more experience, the pressure gets ramped up, and then ramped up again – but as far practicable it still remains a ‘safe-fail’ environment.

[An Irish-session is a learning-context, not a performance as such. In the early part of the evening it tends to be slower-paced, with simpler, more consistent tunes; as the evening wears on, and the more experienced players join in and the drink and the adrenalin flow, the pace gets faster, and faster, and the tunes get 'curly' with unexpected twists and jumps and key-changes - and that's when we mere mortals, one by one, drop out in awe, and the real masters get to strut their stuff at full speed... And yet these are often the same guys who sat with us earlier in the evening as we struggled to get our heads and fingers round even one new tune: for this kind of work there's no 'class-separation' between trainees and masters, but everyone here together, all of us with something new to learn.]

One of the most interesting tricks in a context that is known likely to include uncertainty or uniqueness is to hold to the Simple, by simple repetition of the same thing, over and over – and allow the Not-simple to emerge from that, making itself visible by contrast or contradiction. That’s the other purpose of a checklist, for example: we do the same things, to make sure that nothing is missed, but the same process also highlights anything that isn’t right, that doesn’t fit. And that’s when we flip over to the other side of the story – the Not-so-simple…

And the Not-so-simple…

For here, a ‘considered’ approach would describe the typical tactic as ‘act / sense / respond’: do something, to get some kind of information out of the system, and then either withdraw to the ‘Complex domain’ to assess it at more leisure, or collapse back to the Simple. Neither of which will work well when we need to be dealing in real-time with something that isn’t Simple, or ‘known’…

[The classic example here is juggling. In principle, it's really Simple: throw one ball upward, then another, then another, catch the first one in time to send it back up again, then the next, and so on. Ain't quite that easy in practice...

Juggling-balls being what they are, and human hands and arms and timing being what they are, there are many possibilities for variation. And every variation, however slight, has to be allowed for and counteracted in real-time. Yet gravity won't wait while we work it all out: and it doesn't take much to have the whole spiral thing further and further out of control, until we lose the plot completely. And then - this being a relatively 'safe-fail' environment, start again. And again. And again... Until, yes, we do start to get it right...]

The first rule in this space – and it does indeed have its own bizarre rules – is the same as that etched in large friendly letters on the cover of The Hitchhiker’s Guide To The Galaxy: DON’T PANIC!

[This is actually much more sensible advice than it might seem. The 'pan-' prefix literally means 'all of' or 'everything' - hence panorama, pandemic, pandemonium and so on. In classic Greek, the god Pan represented the moment of absolute uniqueness, the zero-point, where everything is possible, and where every time and every place all co-exist at once. If we can't cope with it, we collapse into the state called 'panic' - trying to get away from the madness of 'here', which we can't do because everything and everywhere is already here... But if we can cope with it, 'hold the centre' within that space, then by definition somewhere within that infinity of possibilities is the information that we need. Hence that quote in the first Tweet earlier: "Sometimes all you need is just one more good idea." Which is available somewhere in this space - if we don't panic.]

The next key is observation – which again takes on a different form here to what it usually does in the other sensemaking domains. It’s particularly well described in this quote (via Ruth Malan – thank you!) from a 2009 article on a keynote by Daniel Pink, published on the Wharton University website:

In another case, medical schools at Yale and Harvard have begun taking students into art museums to increase their observation skills, Pink said. The logic is that in today’s world, a huge amount of medical information is already available online. But learning to observe a patient is something that can’t be memorized from a checklist.

“Doctors have to be able to ask the right questions,” said Pink. “That calls for extraordinary observation skills — the observation skills of a painter, of a sculptor. So, medical schools are taking students to art museums to make them better diagnosticians. And, lo and behold, doctors who receive this type of diagnostic training are better diagnosticians than those who haven’t.”

Pink calls the results of these experiments “a great irony” for the educational system as a whole. “We want to prepare kids for science-oriented careers, so we cut out the arts. Meanwhile, people who are preparing for science-oriented careers are bringing in the arts.”

Other keys here arise from the practices of intentional improvisation, such as described in Keith Johnstone‘s classic Impro, and by more recent business-oriented practitioners such as Mike Bonifer (Gamechangers) and Michelle James (Creative Emergence). For example, two key techniques that have direct business-applications are ‘yes-and‘ and Mask-work.

In ‘yes-and’, we take whatever is given to us – however crazy it might seem at first – and add to it whatever comes up in the spur of the moment. This works well in improv-comedy, of course, but there are plenty of business-contexts where much the same principles will apply: front-line sales, for example. The shoe-retailer Zappos is one example of a highly-successful organisation that has literally built its business by throwing away the script for the call-centre, and instead responding to and with the customer’s needs.

Often the story – or business-story – will only seem to make sense after the event, as Keith Johnstone explains (Impro, p.116):

The improviser has to be like a man walking backwards. He sees where he has been, but he pays no attention to the future. His story can take him anywhere, but his must still ‘balance’ it, and give it shape, by remembering incidents that have been shelved and reincorporating them.

Very often an audience will applaud when earlier material is brought back into the story. The couldn’t tell you why they applaud, but the reincorporation does bring then pleasure.

Business-folk too will often applaud when a story seems to ‘make sense’ in this way – perhaps because it’s made to seem Simple again, although each of the individual threads that make up that story may have little or no real connection with each other, than those that we chose to perceive at the time..

The concept of the Mask is somewhat stranger. An actor puts on a Mask, and in effect enters into negotiation with it. The Mask seemingly has its own choices: different actors who wear it will often find themselves doing much the same thing, though what it does can rarely be predicted solely from its appearance. Even more strange is that whilst wearing a Mask, a performer will be in a kind of semi-trance, working with the Mask rather than attempting to ‘control’ it – in fact the whole process breaks down if there is too much of an attempt to ‘control’.

All of which no doubt sounds a bit abstract, except for one key point. Although improv-theatre Mask-performances will typically use a half-face mask, with the eyes covered but the mouth exposed ‘to speak with one’s own voice’, in fact anything can be a Mask: and that includes a business-uniform, a professional ‘prop’ such as a consultant’s clipboard or doctor’s stethoscope, or even a business-location.

[I remember reading a psychology-study some years back that found that a strong organisational culture could change a new employee's 'natural' behaviour in as little as half a day - almost literally taking on the Mask of the organisation. Helping staff to re-find their own choices in this inadvertent type of Mask-work can sometimes be very important indeed...]

Strange as it is, Mask-work has a number of practical applications in business: for example, almost every profession has its ‘props’ that help establish credibility with clients and others. These processes can also help to get past inhibitions and blocks such as “I’m not creative, I’m not able to work out a new way to do this process”, and so on. Strange, then, but well worth exploring further.

Finally, for here, we can also seed the Chaos, bringing a chosen idea or image into the space as a focus-point for sensemaking and decision-making. This is why vision and values are so important – especially in organisations which, by the nature of the work, must deal with a high level of uncertainty and unpredictability – because they act as a ‘guiding star’ against which the images arising in the turmoil can be contrasted and compared.

[Preparation also plays an important part in this: to use Pasteur's famous quote, "Chance favours the prepared mind".]

One of the most difficult parts of this is “trust the process”. Quite often, the ‘guiding star’ will seem to be leading us the ‘wrong way’: it’s essential at this point to trust the ‘star’ rather than our own assumptions, which would drag us back to the over-Simple and its – for here – inappropriate notions of ‘control’. The analogy here is a city with many one-way streets: often the only way to get to somewhere will involve going in what at times will be ‘the wrong direction’, but is actually the quickest way to go.

We do need to be careful what ideas and images we bring into this type of process: in a very literal sense, whatever we bring with us can act as a ‘seed’ around which other ideas and images can coalesce. That can take us in some unexpected and perhaps unwanted directions: yet sometimes – especially after the event – some small seed-image can turn out be the one thing that saves the day. The cockpit voice-recorder of US Airways Flight 1549 provides a fascinating example of this:

Ironically, the Hudson River was in the sights of the two pilots right from the very beginning of the flight.

As the plane lifted into the blue sky moments after take-off, Captain Sullenberger remarked to his first officer: “Uh what a view of the Hudson today.”

“Yeah,” First Officer Jeffrey Skiles said.

There are many other tactics, techniques and processes designed to tackle sensemaking and decision-making ‘on the edge of chaos’, of course, but these should at least give some idea of what needs to happen at business-speed on the ‘Not-so-simple’ side – and also how different most of them are from the overly-simplistic ‘act / sense / respond’ expected in the ‘considered’ approaches to business-sensemaking.

Simple and Not-so-simple – a summary

On the Simple side, the techniques we explored include:

• work-instructions and other ‘rule-like’ processes
• checklists and other ‘sequence/check’ mechanisms
• repetitive patterns to embed ‘body-learning’
• intentional ‘mismatch’ to trigger a move over to the ‘Not-so-simple’ side

On the Not-so-simple side, these included:

• discipline to keep the ‘panic’ at bay, and stay in the ‘Not-so-simple’ space
• open-observation – allowing the context to ‘see itself’ through us or with us
• improv-techniques such as ‘yes-and’ and Mask-work
• ‘seeding the Chaos’ with intention, ideas, images and principles such as organisational vision and values

As in those two Tweets with which we started here, when we’re faced with the unknown at business-speed, intention is the one thing that makes the key difference between a collapse into chaos, and a path to creating something new; and sometimes all we need is just that one more good idea.

That’s it for here. In the final part of this series we’ll explore how to keep all of these in balance as we move back-and-forth across that spectrum between Simple and Not-so-simple. And we’ll also explore the architectures that we need in order to support this type of sensemaking and decision-making at business-speed.

Over to you, anyway – any comments so far, anyone?

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

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

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

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

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

Another brief aside on Boisot

Two more points came up in that brief exploration of Boisot.

One is that the core problem that he was tackling in most of the articles and other items that I found was a specific aspect of economics: the perceived-value of a portfolio of ‘knowledge-assets’, and their profit-potential in terms of utility versus scarcity – leading to strategies such as hoarding versus sharing, or Neoclassical (‘N-Learning’) versus Schumpeterian (‘S-Learning’). That’s obviously going to be important in a possession-economy, where ideas and information are treated as personal possessions, and where information-hiding and price/value mismatch are crucial to the viability of many business-models – however questionable those might be in terms of business-ethics and the like. Yet the practical problem for enterprise-architectures is that within the organisation, we need a functional economy – ‘the management of the household’ – not a dysfunctional one: which means that the economics-models we need are responsibility-based, not possession-based. Hence for most architecture-purposes, Boisot’s business-focus, interesting though it may be, is likely to be more of a hindrance than a help, relative to what we actually need in practice.

The other point is that, whilst the Social Learning Cycle (SLC) does indeed touch that instant of uniqueness – tacit-knowledge at the moment of action – it seems to skim over it as of almost no relevance. (It’s Step 1, ‘Scanning’, in the SLC diagram above.) I see exactly the same happening in Cynefin, which is based in part on Boisot: there’s the same apparent avoidance of the uncertain, the same rush to the ‘more interesting’ areas of complex-adaptive-systems and the like, represented in Boisot’s SLC as the early stages of abstraction, codification and knowledge-sharing (Steps 2, 3 and 4). To me this is like saying that the only thing that matters in a football game is the final score, and ignoring everything about the individual moments and individual skills from which that score will actually arise. Sure, the score may be of interest to someone who wasn’t personally involved in the action: but to those who are involved, it’s the sense-making and decision-making at the moment of action that matters most.

Hence, in an enterprise-architecture, we need to support that kind of ‘business-speed’ sense-making and decision-making – because that ‘irrelevant’ moment-of-action is where everything happens, where every choice and every part of preparation becomes a concrete fact. The crucial point is whilst there’s time for abstractions before that moment, and time after that moment, when we’re in that moment there’s no time for abstractions at all.

To describe this in SCAN terms, look first at the core graphic:

Then remember that the vertical axis is available-time – the time we have available to us before a choice must be made, and expressed in immediate action. When time gets compressed to nothing – as by definition it must, at the moment of action – we’re left with only the single ‘horizontal’ dimension of decision-logic. In visual form:

So at that brief moment, all previous analysis and experimentation – the entirety of the Complicated and the Complex, to use the SCCC terms – will likely become unavailable, because there’s no time for it, or no time to access it. Analysis and experimentation can be useful afterwards, of course – but only after that crucial ‘turning-point’, the moment of choice, the moment of action. Within that moment, everything is stripped down to the bare bones: which leaves us only the Simple, and… something else. A ‘something else’ that’s often misdescribed as ‘the Chaotic’, but is better understood as an explicit ‘Not-Simple’, an explicit ‘None-of-the-above’.

We know how to do Simple. That’s not in question. Yet that ‘something else’ is, well, something else…

And one of the few things we know about that ‘something else’ is that tools that place their focus elsewhere – such as complex-adaptive-systems and the like – are going to be no help there at all. For useful insights on that kind of sense-making, we need to look elsewhere.

Sense-making in real-time

Let’s put this into a real-world context.

You’re an airline pilot, on a yet another scheduled flight in a twin-jet airliner, 150 passengers on board, five crew. Routine, everyday, nothing unusual about it at all. You’re still on first fast-climb out of the airport, full thrust but barely above stall-speed, not yet three minutes from takeoff, five miles out, 3000 feet up. And without any warning at all, you hear several loud thuds, the windshield turns brown, both engines go silent. Yep: you’re in trouble… big trouble…

Remember when they told you that an airline-pilot’s life is years of tedium separated by moments of terror? Well, this is one of those moments…

The plane’s still flyable, sort-of: no fatal damage in that sense, at least. But you know that this thing is going down – no choice about that at all. And soon, too: at this height, you’ll be lucky to have even three minutes’ flight-time left. That’s maybe ten miles at most. But you really, really do want to have some choice as to where and how this thing comes down – because if you get it wrong, here above a city that stretches as far as the eye can see, it’s not just you and your passengers that are going to die. This is a city that knows only too well just how much death and destruction a fully-laden airliner can cause…

What happens now depends on what you choose to do right now. So what do you do right now?

This is the real-life story of US Airways Flight 1549, of course. What Capt Sullenberger and his crew chose to do is a matter of public record: the (necessarily-terse) communication with air-traffic control, for example. And the relatively-happy ending of the story, in the middle of the Hudson River, with all passengers and crew safe, to be rescued by the ferry-boats mere minutes later.

Just remember that this story could so easily have had a very different ending… So it’s worth exploring what went right that day – and the architecture for real-time sense-making and decision-making that made that outcome possible.

The first point is this: there’s no time to stop and think. Whatever analysis we do here is going to be minimal at best; any experiments that we can do in this time must return usable results in seconds. In short, no Complicated, no Complex.

There’s a huge amount of thinking and experimentation that’s gone on before this point, of course – long before the flight took off, in fact much of it before the aircraft was even built. Someone sat down and worked out what to do if the engines don’t work: there’s a separate auxiliary generator, for example, and another ram-air turbine that’s driven just by airflow. The fly-by-wire system can be set to self-levelling – a factor that could well be critical in any emergency-landing. There’s even a panic-button to close up key vents in case of a water-landing. But all of that is only useful if it’s actually used: which may not be the case.

[That vent-closer panic-button wasn't used, as it happens: Sullenberger said afterwards that the water-landing had ripped holes in the hull far greater than those that the closer would have sealed, so it wouldn't have made much difference.]

Another part of the experimentation is on a personal basis, developing personal skills. This is the role of the simulator: we know we can’t make the context ‘fail-safe’, so we practice emergency response in ‘safe-fail’ conditions – where no-one will get hurt when we get it wrong – so that we have certainty in ‘body-learning’ for when it does happen for real.

[Both pilot and co-pilot had spent many, many hours on simulators, practicing responses for all kinds of emergencies - including an engines-out water-landing. This wasn't just conceptual knowledge, abstract knowledge: this was about 'body-learning', appropriate action without need for conscious thought.]

In preparation for the emergency itself, there’s a huge focus on keeping things Simple. The aviation industry were the first to make intensive use of checklists – with good reason, because they help to make sure that nothing vital is missed.

[The co-pilot skimmed rapidly through the three-page checklist for engine-restart. Nothing worked, so they turned to other options. But note that the checklist was there, available, immediately to hand: someone had planned in advance for exactly this kind of incident.]

In an emergency of this kind, no-one can afford to panic. (The nature of panic is important in this: we’ll come back to it later.) The whole culture is geared to keep everything calm, focussed, making maximum use of what little thinking-time that is available.

[Listen to the air-traffic audio-track: the tower-manager asks "which engines?", in evident disbelief. "He lost thrust in both engines, he said", says the controller. "Got it", is the terse reply.]

And there’s a lot more than just Simple thinking going on – this is much more than just ‘sense / categorise / respond’. This is a very fast continuous scan, using every form of modal-logic – the logic of possibility and necessity, the logic of ‘None-of-the-above’.

[The transcript shows that within a mere six seconds after the report of bird-strike, traffic-control provides a return-course to the airport - but to runway 13, coming in from the far side. Just twenty seconds later, Sullenberger has already worked out that he won't make it, and that a river-landing is possible - "we're unable, we may end up in the Hudson". A quick check for other nearby airports - runway 01 at Teterboro would require too steep a turn, Newark is too far. Fifty-two seconds after the bird-strike, Sullenberger reports "We're gonna be in the Hudson".]

At some point, it becomes essential to focus only on the task at hand: all communication with others shuts down until the immediate task is complete.

[After "We're gonna be in the Hudson", Sullenberger has no further contact with air-traffic control; his aircraft disappears from radar. The transcript shows the controller continuing with his job, handling incoming and outgoing traffic almost as if nothing unusual has happened. Sullenberger and his co-pilot ditch the aircraft safely in the river less than two minutes later.]

After the immediacy, the task may well continue, though in other forms.

[Sullenberger personally checks that everyone is clear of the aircraft, twice walking the length of the cabin in chest-deep icy water. He is the last to leave the aircraft.]

The emergency ends; the pressure eases off. The next part of the architecture cuts in at this point: it’s crucial to help the people involved to ‘change gears’, and to know that time-compression has ceased – otherwise there can be can be a collapse into a kind of counterpart to panic, namely post-traumatic stress.

[The controller reported later that for him the most traumatic point was after the incident had ended. During the incident itself, there simply wasn't time to do anything but focus on the job at hand; but afterwards, all the possibilities of what might have gone wrong came back to haunt him. All 'imaginary', yet experienced as if 'real': this is a type of context in which the usual distinctions between 'real' and 'imaginary' make very little sense.]

In effect, we explicitly re-engage the Complicated and, especially, the Complex – ‘Ambiguous but Actionable’ – through tactics such as an After Action Review of four simple questions:

• “What was supposed to happen?” – requires us to know the expectations of the context
• “What actually happened?” – requires us to observe, to have observed, and to remember what was observed
• “What was the source of the difference?” – requires us to assess, evaluate
• “What can we learn from this, to do differently next time?” – re-embodies the results of the evaluation as personal ‘response-ability’

In SCAN terms, the time-available axis may change radically during the progress in the context, with time seeming to compress and expand according to the stress of the moment; yet the decision-making options, from true/false Simple to fully-modal None-of-the-above, remain much the same throughout. The real requirement here is for some means to support appropriate choice of decision-making method from moment to moment.

And that’s what we’ll look at in the next part of this series.

Enough for now: any comments so far, anyone?

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

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

A brief overview of Boisot’s I-Space

In essence, and as I understand it, Boisot’s model aims to describe how information moves around and is transformed and used within ‘information-space’ – hence ‘I-Space‘. He maps out the transformations across three distinct dimensions: concrete/abstract, uncodified/codified (unstructured/structured), and undiffused/diffused. As described on the Trainmor website, this gives us a panarchitecture-like cycle of creation, renewal and re-use:

And as described on the I-Space Institute website, if we collapse that down to just two dimensions – unstructured/structured, and undiffused/diffused – we have what Boisot calls the ‘Social Learning Cycle’:

Personal or ‘tacit’ knowledge is structured through sense-making and problem-solving; this is then ‘diffused’, or shared with others, perhaps via some IT-based ‘knowledge management system’; the shared-knowledge is re-interpreted by the individual; and applied in personal practice.

Boisot’s applications were primarily in economics, about knowledge-diffusion and the different dynamics of utility versus scarcity relative to that for physical goods, to enable maximum ‘value’ and maximum profit in information-driven industries. There’s also a great range of key ideas about organisational cultures as complex adaptive systems, with different cultures managing the structuring and diffusion of knowledge in different ways.

For enterprise-architecture, all of this has obvious applications and implications in information-system design, and in encouraging adoption of EA principles and practices with the organisation.

Yet I’m not sure that it has all that much validity for enterprise-architecture itself. It fits well with the larger picture, with the overall flows, with modelling a culture as a whole. But in my own experience of enterprise-architecture, all of that is what happens after the critical moments of change – and in some ways this type of theory actually prevents us from being able to work with or even to see those moments of change.

To use the SCCC-categorisation, this is what I’ve been describing as the difference between the Complex and the Chaotic – the unique, the particular, the ‘market-of-one’ that occurs at the exact moment of sale. Boisot and the like will obviously handle the Complex well, because that’s what they’re designed for and optimised for. But to me they don’t fit well with uniqueness: and that’s what I’ve been struggling with all of this time, always looking for some theoretical-frame that would describe it properly.

To explain why this is needed, and to explain what’s going on here, I need to do a brief diversion into some of my own background.

A bit of background

Some of my own personal history is relevant here. Both my parents were GPs, or general practitioners – ‘family doctors’, in US-speak. The practice was on the edge of a large town, not all that far from London, but extended right out into into farming-country. And I mean rural, too: when I was kid, back in the 1950s, there was still quite a lot of horse-drawn traffic, and the village carpenter was also the blacksmith and farrier, making and fitting horseshoes for working carthorses, and fitting steel-tyres to wooden cartwheels.

The surgery was built into the family home, so I grew up in a very busy, very active medical background. And along with that, I learnt a lot about the role of the generalist: a specialist in hospital might see a fair few variations on a specific theme, perhaps, but a general practitioner is a key first-point-of-contact for medical needs, and hence comes across everything.

For example, there was the farm labourer who’d been bitten by a cow whilst trying to remove a lump of turnip from its throat, and had become infected with anthrax – not all that rare in cattle at that time, but for humans it’s a disease that’s classed not just as a bio-hazard but as a biological weapon. That one was definitely, uh, interesting…

There was a woman who’d called on a Sunday to say she’d had a minor scratch from a rose-thorn, nothing to it as such, but was feeling oddly unwell: my mother never did find out what had happened there – some allergic reaction, probably – but if she hadn’t got her into hospital straight away, it was clear she would have died before the regular ambulance arrived, less than hour later.

And there was the case of an elderly woman with a supposed terminal stomach cancer, sent home to her family to die in peace: some discreet enquiries identified the real nature of the ‘cancer’, which uh, cleared itself after a few sessions with a powerful laxative… and she went on to live a happy family life for another two full decades.

So yes, a true generalist will come across just about anything you can think of; and has to be ready for anything, too. The point here was that whilst mainstream medical practice was always focussed on statistics and probabilities and the like, those kinds of ideas and assumptions weren’t all that much use at the ‘sharp end’ of general-practice: diagnosis needs to deal with this patient, right here, right now – and no matter how much it might look the same as everything else, it’s always subtly different, every time.

For me, another influential item from that background was an item in a now-defunct medical magazine, World Medicine. The article, ‘Ulbricht the Badger’s Guide to Immunology’, was a nice allegory on the relevance – or perhaps lack of it – of medical research on medical practice. I won’t go into the detail of the story itself, but one part that’s stuck with me ever since was this: we actually understand extremely well why people fall ill; what we don’t understand is why people don’t fall ill – and even less why, or how, they get well again when we don’t expect them to do so.

Then, for me, on to university. Again I’ll skip the details, but one theme that came through all of that period was exploring how people develop individual skills, and develop the personal sensitivity, awareness, judgement and ‘taste’ on which that skill is based. I did my Masters research and thesis, in the ‘General Studies’ department at London’s Royal College of Art, way back in ’76 (yikes! more than a third of a century ago!  ) on “Design for the education of experience”, the use of different media to support skills-development. (Video was by far the worst medium for this, by the way.) Some key ideas came out of this, such as the crucial distinctions between ‘methods’ – what we do – versus ‘mechanics’ and ‘approaches’ – respectively the objective and subjective components of the skill, from which personal methods are derived.

And my test-case for that Masters-research – which, somewhat surprisingly, went on to become a best-selling book that’s never been out of print since – was a detailed description of how to develop the rather arcane yet very practical skill of water-divining (US: ‘water-witching’). Technically, it’s almost a ‘pure skill’, in that there’s almost no mechanical component to it: almost all of it is about sensitivity to context, awareness, interpretation of results. Otherwise known as sense-making and decision-making, all in a real-time context.

[A later book of mine that focussed more on sensemaking was Inventing Reality, first published in 1986. See the chapter 'Can't we explain this scientifically?': it introduces some of the core themes that underly SCAN.]

Uniqueness in enterprise-architecture

So how does all of that connect with enterprise-architecture?

Lots, is the short answer.

There’s a lot about structure in enterprise-architecture; perhaps less obviously, there’s also a lot about story. But to me the single most important point in an enterprise-architecture – and in fact the most important point about it is that it is single – is uniqueness.

If we get it right, the enterprise-vision is unique. If we get it right, our values are unique enough to make us stand out. If we get it right, the market niche is unique. If we get it right, the products and services are unique. If we get it right, every opportunity arises from a moment of uniqueness.

At every moment of sale is a market-of-one, something unique. Every interaction with customers, clients, suppliers, employees, has a moment of uniqueness about it. Something special, that in turn makes it special.

And if we get this right, there’s a huge premium for uniqueness.

By contrast, there’s not much of a premium for doing the same as everyone else. In a commercial context, if we don’t have something that really is unique, that helps us stand out from the crowd, often the only thing we’re left with is a race to the bottom. Which is not a fun place to be.

Uniqueness matters.

Sameness is crucially important too, of course. Consistency matters; predictability matters; reliability matters. All of those things matter. But in most cases, by now, we know how to do all those: we know how to do certainty, we know how to do control. It’s hard, but it’s not that hard.

But uniqueness? That’s whole different kind of ‘hard’. And one where, by definition, statistics are no help to us at all – because it’s unique. And likewise where and why Boisot’s I-Space and suchlike are of little real help to us – because they don’t work well with the unique.

So how do we get the right balance between certainty and uniqueness – between the Simple and the Not-Known? That’s what’s been my real driver here.

And that’s what I’ll continue with, in the next post in this series.

For now, enough to whet your appetite for more, I hope?

But there’s a catch. A big catch. People should not be ‘designed in’ to the architecture.

We can see this well in building-architecture: there, the only case where people have been literally part of the architecture is that of the anchorite in the mediaeval church. An anchorite would choose to be permanently walled into a cell that was part of the fabric of the building, to act as a spiritual anchor for the people’s faith. Somehow I don’t think we’ll be likely to find many people willing to do the same for today’s for-profit enterprises…

Yet in most building-architecture, evidently, people are everywhere. Other than in certain special-cases – the equivalent of an IT-specific ‘enterprise’-architecture, perhaps – the building and its purpose and design will centre around people, about what people do, why they do it, what the building represents to people, and so on. And the equivalent of that ‘people-centrism’ is what we need in a viable enterprise-architecture.

But if we can’t design people into the architecture itself, how do we map people within the architecture? I would suggest four key themes:

• vision and values
• relational-assets
• roles and responsibilities
• capabilities and competencies

Let’s look at each of these in some detail.

Vision and values

Conventional enterprise-architecture is not good at this. TOGAF, for example, uses the term ‘vision’ to mean a particular goal, a description of the desired ‘target state’ of the IT-architecture: it’s one valid meaning of ‘vision’, I suppose, but not much use in relation to people. Business-architecture frameworks are often less helpful: the BRG/OMG Business Motivation Model, for example, describes as a similar ‘future state’ for the organisation, but framed in terms of some kind of ghastly marketing-puff – “to be the best provider of…!” etc – that really is worse than useless in practice.

What’s needed instead is something that provides a permanent stable anchor that is also ‘greater than’ any individual or the organisation as a whole. Daniel Pink refers to this aspect of motivation in his book Drive, as ‘purpose’; this is also the sense of ‘vision’ used in the ISO9000:2000 quality system. In my own EA work – as described in the section ‘Identifying the enterprise’ in the post ‘Context-space mapping with the Enterprise Canvas‘ – I use a distinct three-part structure to define this form of vision:

• a descriptor for the content or focus for this enterprise
• some kind of action on that content or focus
• a qualifier that validates and bridges between content and action

These components may occur in any order, but all of them need to be present. The aim is to identify a short phrase that gives sufficient motivation for anyone involved to ‘want to get out of bed in the morning’ on behalf of the overall enterprise. One particularly clear example is that for the TED conferences, “ideas worth spreading”: ‘ideas’ [content]; ‘worth’ [qualifier]; ’spreading’ [action]. Note that none of these components describe the organisation at such – but do describe the focus, the area of action, and the key value-metrics which define the meaning of ’success’.

Another key point revolves around the crucial distinction between ‘organisation’ and ‘enterprise’ – because although many business-folk view their organisation as ‘the enterprise’, they’re not synonymous. As noted above, vision is also the anchor of the quality-system, and in effect the hierarchical structure of ISO9000 provides us with a useful way to clarify that distinction:

• ISO9000 ‘vision’ :: architecture ‘vision’ – anchor for the overall architecture
• ISO9000 ‘policy’ :: architecture ‘enterprise’ – loose often-dynamic affiliation, bounded by shared values and shared commitment to the vision
• ISO9000 ‘procedure’ :: architecture ‘organisation’ – formal collective entity, bounded by usually-explicit roles and responsibilities
• ISO9000 ‘work-instruction’ :: architecture ‘process’ etc – practical context-specific entity and/or activity

The point here is that the organisation is merely a means to implement the vision, in relation to the broader shared-enterprise within which the organisation exists – its supply-chain, market and broader social context. Other than in terms of its declared or implied responsibilities towards this shared-enterprise, the organisation does not ‘own’ the enterprise at all – another crucial point that is frequently misunderstood in business-architectures and business-models. The organisation does choose the shared-enterprise to which it relates and within which it operates: but having done so, it in effect commits itself to the respective vision and values – and will be assessed by other participants in the shared-enterprise in terms of those values.

Which, in turn, leads us to the centrality of values in enterprise-architectures. The values are what determine ‘success’ within the shared-enterprise, especially in the longer-term. Any for-profit business in a money-based economy needs to ‘make money’, of course, and hence concerns such as monetary profit and ‘shareholder-value’ are of real importance to such a business. But value is rarely measured solely in monetary terms within a shared-enterprise: attempting to measure ‘success’ by monetary profit alone is a sure-fire way to kill the company, especially in the longer-term – hence Michael Porter’s warning that the obsession with shareholder-value is “the Bermuda Triangle of strategy” [PDF], within which companies sink without trace. The point here is that are three distinct sets of values in play in the architecture:

• required values – the values implied by, inherent in and derived from the enterprise-vision, and against which the organisation will be assessed by the broader shared-enterprise
• espoused values – the values that the organisation purports to live by, and against which it and its members supposedly expect to be assessed
• actual values – the values that are actually expressed by the organisation and/or by individuals within the organisation, and against which actions and inactions of individuals are actually assessed, rewarded and/or punished

It is rare for these sets of values to match exactly… in fact there are often glaring disparities between them, often unconscious, yet critical all the same. One of the most difficult and politically-explosive aspects of enterprise-architecture is to map these value-sets, the disparities between them, and the practical implications and risks of those disparities, and identify appropriate means to resolve them. Difficult though it may be, this is probably one of the most essential tasks of a whole-of-enterprise architecture.

Relational-assets

People are essential to an architecture, but should never be included as such within it. To resolve this requirement, we turn to an old computing tactic: we include people not ‘by value’ – as ‘objects’ within the architecture – but ‘by reference’ – via relational assets.

That much-used phrase “our people are our greatest asset!” may be well-meant, but it’s actually an insult of the most extreme form: the only time when people are ‘assets’ is when they are slaves… Instead, the relationship is the asset: the ‘asset’ in context is the relationship that the organisation has with each other player in the shared-enterprise, not those people themselves. (This relationship is what a Customer Relationship Management system and the like should assist in maintaining, yet so very rarely does…)

As described elsewhere, I use a model in which there are four distinct categories of assets that an organisation and enterprise will need to maintain: physical (things), virtual (information), relational (real person-to-person links) and aspirational (person-to-abstract links, such as brands, beliefs, goals etc). Many real-world entities – perhaps most – are composites of these categories: a book or a video-disc, for example, is ‘thing that carries information’, and hence a composite of physical and virtual. These four categories of assets are fundamentally different: an object is alienable (if I give it to you, I no longer have it), whereas a virtual entity is non-alienable (if I give it to you, I still have it). Failure to understand these fundamental differences within an architecture will guarantee failure of that architecture: hence, for example, the inherent invalidity of media-industry business-models which try to ‘control’ virtual-only information-assets (digital-only books, music and video) as if they’re still in their old partly-physical ‘pre-digital’ form.

People are physical, yes: but they are not solely physical ‘things’, ‘units’, ‘consumers’ – even though too many employment-models and business-models seem to treat them that way.

People may be represented by information, yes: but they are not solely information-entities – even though too many CRM- and HRM-systems seem to treat them that way.

People have relationships with other people. These relationships – relational assets - are direct, and personal: they cannot be exchanged directly with anyone else.

People have relationships with emotive ideas, often an idea or image as proxy for person or for a desired memory or future (such as the relationship with someone deceased, or the aroma that brings back memories of another place and time). In a business context, such proxies include logos, brands, and the reputation of the organisation itself. These relationships – aspirational assets - are indirect, but personal: they cannot be exchanged directly with anyone else.

(The latter, by the way, is the reason why the accounting concept of ‘goodwill’, which purports that aspirational-assets can be transferred directly from one ‘owner’ to another, is only marginally better than outright fraud. In essence, the ‘goodwill’ is mostly dependent on ‘relational inertia’, the perceived physical, virtual, relational and aspirational effort required to abandon one aspirational-asset relationship and shift to another. For aspirational-assets, much of that inertia is linked to reputation, but is also dependent on the medium through which the relationships take place: for example, the ‘friction-coefficient’ of a web-relationship is far lower than that in an in-store relationship – hence one of the key drivers for the ‘dot-com bomb’…)

In the architecture, we would map real-people primarily via relational-assets and/or aspirational-assets. (Virtual-assets describe those links, but not are those links: the distinction is important! Likewise some aspects of architecture may need to describe people as if ‘things’ – for example, space-allocation in buildings, or workspace in manual-processes – but should never describe people as things: that distinction is important too…) Within the architecture, an employee ‘is’ a complex composite of many ‘sub-assets’, such as (physical) space-allocation plus (virtual) employee-record plus (relational) personal-relationships with peers and co-workers and managers and suppliers and customers and many others, plus (aspirational) sense of belonging to a team, a business-unit, an organisation, the core enterprise of the organisation, and any number of professional or other affiliations. Of these, only the physical-asset is directly exchangeable: everything else is linked to the person, not solely to the organisation.

Note also that relationships have to be maintained at both ends: the asset exists between the respective entities, not as an attribute of either of them. In effect, it exists as an asset only as long as it is maintained: and all of the usual asset-lifecycle concerns also apply to relational and aspirational assets. A customer may choose to drop the relationship – and there is nothing that the company can do directly to prevent that from happening. If strong person-to-person relationships are maintained, a customer may well follow a (former) employee to a new employer: a classic problem in consultancy organisations, for example. If there is strong aspirational attachment to a brand, there is likely to be a ‘customer revolt’ if the brand is changed or dropped’ – as in the Gap logo debacle.

So in Enterprise Canvas, for example, we would model all of these as assets of the respective primitive and/or composite types, using the single-row extended-Zachman frame:

Each asset also implies a responsibility for the asset-lifecycle of that asset: its creation, usage, maintenance and, where appropriate, destruction. (The latter being a key reason why not to refer to real-people as ‘assets’!) Responsibility, in turn, implies real-people to enact those responsibilities, either directly or by proxy. Real-people to whom the organisation must link via relational- and//or aspirational-assets… This might seem somewhat circular at first, but it does make sense once we think about it for a whole!

Roles and responsibilities

It’s not just assets that require responsibilities: in principle, every entity in the architecture should have its own ‘responsible owner’. And each of those owners, as above, is a real-person – and ultimately can only be a real-person, not an IT-system, a machine or an amorphous ‘the organisation’.

The architecture should link to each respective ‘responsible real-person’ via a relational- and/or aspirational-asset. In principle, each of these relationships should be modelled and mapped within the architecture itself. In practice, it’s huge job, requiring near-real-time links to HR systems and/or CMDB systems – so it’s unlikely anyone would attempt to do it for everything. Instead, we need to use the architecture to identify the criticality of each entity, assigning priorities appropriately. For true business-critical items, we do need to be able to identify the ‘responsible owner’ at all times; for the rest… well, we do what we can, really, guided by the usual trade-offs of diminishing-returns.

Within the organisation – where legal or similar boundaries of responsibility will usually apply – these responsibilities should typically be mapped in terms of a RACI-matrix:

• responsible – the one person formally responsible for the entity (legally a ‘delegate’ of the CEO or equivalent, who in principle has ultimate responsibility for everything in the organisation)
• assists – any number of additional people who do the actual work related to that responsibility
• consulted – other people whose work and/or responsibilities may be directly affected by any changes or status-issues associated with this entity (two-way engagement)
• informed – other people who have a ‘need to know’, such as for indirect impact on their work (one-way broadcast)

We may also need to note other categories of (non-)responsibility such as not-consulted or not-informed – for example, a senior manager who does not need to be distracted by detail-level status-changes.

Responsibilities often overlap – another set of concerns that should be identifiable via the architecture models. Some of the overlaps occur at intersections of different architectural layers or domains – for example, a senior manager having responsibility for a ‘business capability’, with operations-layer managers responsible for the underlying infrastructure, the equipment in use, the data and applications referenced by that equipment, the processes that traverse through that equipment, and then also managers for other ‘cross-cutting concerns’ such as security, safety, quality and cost-assurance. A layered architecture helps to clarify the respective boundaries of authority and responsibility, and the need for negotiation at each of those boundaries and intersections.

Note too that for many entities – especially business-critical ones – the effective ‘ownership’ and RACI-matrix will need to change often, with handovers of responsibility at each change of shift, or whenever the respective people go on vacation, or whatever. Particularly important are changeover-events such as joining or leaving a company: in particular, each person’s individual RACI-matrix must be reassessed and reassigned on exit from the organisation. Also important on exit is to ensure that relational- and aspirational-assets with each departing person are maintained as far as practicable: this forms a key link in the chain of long-term knowledge-management, and also many organisations find that maintaining an ‘alumni’-style relationship with former staff pays real dividends in both directions.

And note also that responsibility cannot simply be assigned to someone: it must be accepted and taken on by that person at a personal level, a personal commitment, otherwise it’s likely to fall back to ‘responsibility’ in name alone, with a concomitant increase in organisational risk. Again, this is where explicit linkage to enterprise vision and values can present real value to the organisation, because it provides an overt anchor for aspirational-assets – a sense of belonging, of being engaged in something ‘greater-than-self’ – that make it that much easier to take on and enact those personal responsibilities.

Finally, a person should be assigned responsibility only if they have the skill and ability – the competence – to take it on. This, however, can lead us into yet another architectural hornet’s-nest: modelling of capabilities and competencies in relation to real-people.

Capabilities and competencies

In principle, capabilities are straightforward: they represent the ability to act on specific types of assets in specified ways. That’s how we model the capabilities of machines and IT-systems, anyway. We can then map these capabilities to what might call a set of skill-levels:

• rule-based – simple real-time action and response, predictable and repeatable
• algorithmic – more complicated contexts affected by multiple dependencies, delays, etc, yet still follow a straightforward true/false logic (‘hard-systems’)
• pattern-based or heuristic – true complex contexts that are highly-sensitive to starting-conditions (wicked-problems etc), in which outputs can become inputs to the next iteration, and which often follow modal-logics (‘soft-systems’)
• principle-based – near-unique, unique or true chaotic contexts in which there is no actual repeatability, hence new ‘solutions’ most be created in each case

A given capability at a given skill-level is described as a competence. Capabilities are linked with functions, and appropriate business-rules (‘decisions‘) and the like, to present services that respond to specific events at the respective locations, as per the single-row extended-Zachman above. For a service-oriented architecture, we then assert that everything is or provides a service, and that any service could in principle be done by any combination of machines, IT-systems and real-people. This makes it possible, for example, to design IT-services such that real-people can take over in the case of IT-system failure or other disaster-recovery, using essentially the same service-interfaces, and then hand back to IT again when recovery is complete. And to a significant extent, I’d argue that this is how we should model our architecture – hence the design and structure and usage of the Enterprise Canvas model-type (two-page reference-sheet here).

Simple enough in principle: perhaps not quite so simple in practice…

To me, there are two key concerns here: the order/unorder dichotomy, and the Taylorist trap.

The order/unorder dichotomy mainly relates to that stack of skill-levels.

The first two skill-levels – rule-based and algorithmic – fall into what we might call the ordered domains – a world in which simple true/false logic is assumed to apply, and in which doing the same thing will always lead to the same result.

The other two skill-levels – pattern-based and principle-based – operate more in the unordered domains, in which modal logics (should, could, may, might, etc) usually apply, where simple true/false logic can be dangerously misleading, and where doing the same thing often leads to different results or doing different things can end up with the same result.

Machines follow physical rules; IT systems usually follow a predefined true/false logic. That makes them very suitable for use in the ordered-domains – but not good in the unordered domains. Therein lies a key-cause of many ‘IT disasters’ such as IT-centric ‘business process-reengineering’: they tried to use IT as the sole means for managing unordered contexts for which, almost by definition, IT was not suited.  The two usual ‘solutions’ were either to try to control everything, planning for every possible exception or eventuality; or simply ignoring anything that didn’t fit with the system’s predefined logic. Both approaches were all but guaranteed to fail, and usually did so, expensively…

On the other side, real-people can be very good at handling the inherent uncertainties of unordered contexts. What they’re often not good at is ‘following the rules’ in a predictable, ordered way. Itr’s possible to force people to work in an ordered manner, but it’s rarely efficient or effective; and – as Daniel Pink and others have shown – if the work involves any cognitive skill, performance drops off rapidly if attempts are made to motivate people in any ‘mechanical’ way.

So although in principle service-handovers and the like should be a straightforward mapping between machine- or IT- capabilities versus human-capabilities, in practice it’s not quite that simple: we need to design-in appropriate balances for ‘unorder’ on the machine-side, and misplaced ‘order’ on the human side. Some nice architectural complexities there…

Then there’s the Taylorist trap – or rather, several of them.

One trap is implied from the order/unorder dichotomy. In classic Taylorism, manual-workers are essentially viewed as components in a machine: there is no concept of skill, only a strict separation between ‘brain’ (management) and ‘brawn’ (workers). All thinking and reevaluation is done by managers or by external ‘experts’ (e.g. the dreaded ‘time and motion man’). Every exception is escalated to the next higher level. Since (as lated pointed out by Deming) the knowledge needed to solve a problem usually occurs at the point o contact with the problem, one of the key results of Taylorism is for the problem to be ‘escalated’ to people who may have greater theoretical knowledge, but less and less practical knowledge, creating an apparently ‘unsolvable’  problem.

Another trap arises from the same source: treating workers as components in a machine. The competencies required by the work itself are listed in a job-description or the like, in much the same way as a functional-specification for a machine. Anyone who has the required competencies is likely to be capable of doing the work. This approach is extremely useful when designing services that may need to be implemented in different ways with different combinations of manual, machine and/or IT-based ‘actors. The catch is that in effect it defines a ‘lowest common denominator’, and takes no account of skill-levels or abilities beyond the specified minimum. The result is that innovations and creativity – such as would definitely be required in a ‘chaotic’-type near-unique context – may be all but designed out of the overall service, reducing the effectiveness that could otherwise be available. Treating workers as mindless ‘robots’ is also dangerously demotivating, frequently with dire results for overall performance and for overall risk. Hence although in the Enterprise Canvas we would typically model the nominal capabilities and competencies required for a given service, we need to take care to ensure that the relational-asset aspects are also full addressed in any enterprise-models that involve real-people.

One further Taylorist trap is rather more subtle and insidious, and relates to the process via which skills are learnt. The classic learning-process involves working the way through the skill-level stack, first tackling repetition of ‘simple’ rule-based tasks and problems, then moving on to ‘complicated’-type tasks, and thence to true complexity. But when all simple tasks and even many complicated tasks are automated, there is no routine method to learn complex-level skills: instead, people are somehow expected to take over when the machines fail – in other words, when ‘order’ moves into ‘unorder’ – but without any means to understand what’s actually going on. This trap is explained in more depth in the post ‘Where have all the good skills gone?‘

In summary, we can and probably should model capabilities and competencies within an enterprise-architecture: however, we do need to beware of the various traps and problems that can arise if we’re careful how we do this, and how we apply it. You Have Been Warned?

The next post will explore another key aspect of any architecture that includes real-people: the problem of power. Watch This Space?

See also:

• A question of who
• Principles, values, ends and means
• People, assets, relationships and responsibility
• The meaning of service
• Context-space mapping with Enterprise Canvas, Part 5: Service content
• Enterprise Canvas, Part 6: Models
• Economics as enterprise-architecture
• New economics models – what impact on enterprise architecture?
• Capabilities, reference-models and job-descriptions
• Zachman and capability
• More on Zachman and capability
• On EA ‘owners’ and primitives
• Rethinking Zachman – the ‘Who’ column

There’s plenty of purely pragmatic advice one could give, of course, but I don’t know the Indian context that well – for example, I don’t even know if anyone’s doing TOGAF trainings there as yet, though I guess someone must be doing so by now. But I thought I would concentrate instead on the same kind of advice in one of my favourite books, William Beveridge’s The Art of Scientific Investigation:

Elaborate apparatus plays an important part in the science of to-day, but I sometimes wonder if we are not inclined to forget  that the most important instrument in research must always be the mind of man. It is true that much effort is devoted to training and equipping the scientist’s mind, but little attention is paid to the technicalities of making the best use of it.

So in the same spirit about “the technicalities of making the best use” of the architect’s mind, I suggested the following ideas, in no particular order:

IT-architecture is a cross-disciplinary specialism: the enterprise IT-architect will bridge between the various IT domains, but the focus essentially remains centred around IT alone. By contrast, to the enterprise-architect, everywhere and nowhere is ‘the centre’: he or she must be a consummate generalist, interested in everything. So I would encourage you to lift your eyes from the screen and the imaginary worlds within IT-systems, and look around you. IT-systems describe a digital world, but they are also very physical: they exist in a real world beyond data alone. A real, messy, chaotic world, where computers need to be fed power and kept cool (the two huge demands of present-day data-centres), placed somewhere safe from dust and rain and flood, with all of their cabling and other data-links protected from birds and mice and wayward excavator-operators digging up the roads. And a human world, where real people have real emotions and do the real work, and where passion for code (and, sometimes, a confused passion for ‘control’) is what creates all of this in the first place.

So get interested in everything, in anything that happens. Allow yourself an explicit time in the day – as a meditation, if you wish – in which you allow yourself to notice whatever happens around you. See the four-dimensional shapes that people make as they move down the street, the surging textures of a moving crowd. Notice the momentary sounds and individual words that appear in the midst of the noise and tumult – they may not necessarily mean anything in themselves, they just are, yet noticing them builds a habit that creates space for noticing things that do matter. Watch an individual ant choose its path across the dust; then watch the patterns that a colony of ants will make; then crosslink that to the path you can see in the lifecycle of a single data-entity, the patterns you can see emerge from the flow of data. Be interested in machines as well as IT boxes: learn how a spinning-wheel works, a loom, a sewing-machine; the four-dimensional paths and movements built into the workings of a printing-press; the amazing complexity within an ordinary-seeming office-printer to deal with the physical variation of paper moving through the feed-path, of real particles of toner moving from the cartridge and thence to the paper, all held somehow within precise positions in space and in time. Be interested especially in people: it’s so easy to see them as machines, as ‘manual processes’, extensions of your IT-systems, yet remember to see them also as strange beings with choices unique to themselves, every one of them different, passionate, frustrated, bored, somehow surviving against all the unyielding pressures of entropy. Allow the world to be strange, new, like the world of an ever-curious two-year-old; and remember to keep those images and impressions and feelings with you when you come back to the ‘real’ world of deadlines and meetings and production-schedules and impatient clients who want it all done by yesterday!

Notice your own heritage and culture: notice what is uniquely India, what it brings to the world. So much of the global perspective is dominated at present by the worldview of ‘the West’, of Europe and the US: and it is easy to miss the cultural assumptions that are embedded in technology and business-practices, many of which may not fit well with local ways of working at all. (A significant part of my work here with US-owned multinationals in Mexico has been ‘cultural translation’: US culture assumes the predominance of the individual, whereas Latin culture places far more focus on the family, the collective, leading to some serious confusions around incentive-schemes and rewards for ‘personal’ performance and the like, with impacts rippling all the way through the entire architecture of the enterprise.) Notice your own culture’s enormous strengths: its proud yet unique tradition of mathematics, for example, or its amazingly inventive ability to ‘make do’, leading to world-leading innovations such as robust, lightweight, inexpensive, highly fault-tolerant medical-diagnostic systems for use in all those myriad small villages off the main roads with erratic mains-power and even more erratic network-connections. Notice where those ideas and innovations came from in your own culture – and then find that same place within yourself.

On enterprise-architecture itself, look wider than TOGAF and the other IT-oriented frameworks, to models that encompass more of the overall enterprise. Look at FEAF, the US Federal Enterprise Architecture Framework: note the two not-quite-blank sections in the PRM (Performance Reference Model) marked ‘Human Capital’ and ‘Other Fixed Assets’, and ask yourself what should go there, to complement the [IT-specific] ‘Technology’ in the centre. Look at DoDAF, MoDAF and other defence-oriented frameworks, and ask yourself how you would bring those same ideas back into the civilian world. (TRAK, an adaptation of MoDAF for the rail-engineering requirements of London Underground, would provide some useful ideas there.) For industry-specific frameworks, see SCOR (Supply Chain Operations Reference) or the Telemanagement Forum standards for the telecoms industry: eTOM (enhanced Telecom Operations Map), NGOSS (New Generation Operation Systems and Software) and SID (Shared Information/Data). Look also at how an any enterprise-architecture is put into practice in the real world: for example, balance TOGAF with ITIL (Information Technology Infrastructure Library), to see how IT-services are enacted by IT service-management.

In all of that, I would suggest to keep remembering that enterprise-architecture literally means ‘the architecture of the enterprise’ – not merely the architecture of the enterprise-IT. The IT exists within the context and needs of the broader organisation; and the organisation exists within the context and needs of a far broader shared-enterprise. An organisation is bounded by rules, roles and responsibilities, but an enterprise is essentially a human construct, bounded by aspirations, commitments, hopes, fears. We create an enterprise-architecture for an organisation, but about that broader enterprise. And ‘quality’ in all its forms is what arises from that broader enterprise: hence all those quality-oriented issues in architecture such as reliability, efficiency, resilience, safety, sustainability, security and the like. If you remember to keep that idea of the broader enterprise in mind whilst you work on even the smallest item of code, it will help to show you what an ‘enterprise’ really is – and hence the nature of enterprise-architecture itself.

The last point, perhaps, is to respect that all of this does take time – many years, if we’re honest. But you’re already a long way down that track: after more than ten years in ‘the trade’ you will certainly have learned a great deal about the difference between academic theory and real-world practice! And remember too that every item you notice is a step along the way: we never actually ‘arrive’ as such – as we do with an academic qualification or a framework-certificate – but somehow discover one day that we’re already doing that work, and never noticed the change.

So in a sense you are already an enterprise-architect: the only difference is one of scope (beyond IT itself) and scale (beyond the business-unit, and even beyond the organisation). So enjoy! – have fun!

I hope it’s been useful, anyway – and thank you also for asking the question.

My best wishes to you and to your colleagues
- tom graves

• the internal enterprise-architect
• the external enterprise-architect

They’re both focused on ‘the architecture of the enterprise’, but it’s important not to mix them up, because they require different temperaments and different approaches to business-relationships.

The internal enterprise-architect is actively responsible for the ‘enterprise DNA’ of a single organisation. They typically either report direct to the CEO (who has the ultimate authority and responsibility for that ‘DNA’, but in practice probably doesn’t have the time to do much about it), or else are attached to the CEO Office or a senior-level strategy-group.

The key point here is that, to use Kevin Smith‘s term, this enterprise-architect role acts as “the glue between strategy and execution” – which means that they need direct person-to-person relations with people at all levels and in all domains of the organisation and enterprise. Developing these relationships takes time, and a lot of time at that – often ten or more years in a typical large organisation. Hence the best people for this kind of role are those who’ve “come up through the ranks” and built a personal network on the way, or – even better – have grown up with the company, “have been in from the start” or suchlike. (The CEO can and should do the enterprise-architect role for a start-up, but once the organisation grows beyond about a dozen people the role will typically need to be part of someone else’s explicit responsibilities, and once we get past the crucial social-network boundary of Dunbar’s number – roughly a dozen-squared – it needs to be a distinct role in its own right.)

This role is about how the idea of enterprise-architecture – that “things work better when they work together, with efficiency, with elegance, on purpose, in practice” – is expressed throughout this organisation, in terms of this organisation’s business-purpose.

The external enterprise-architect (or consultant enterprise-architect) is actively responsible for promoting the ‘idea’ and practice of enterprise-architecture itself. It’s important that they maintain their independence as much as practicable, though for practical reason many will work via the auspices of a consulting-organisation of some kind. Their person-to-person relations are with other architects – again in many different domains and at all levels, but across many different organisations and enterprise-types.

Their primary role is practice-refresh for in-house enterprise-architects: they help to keep the overall architecture up-to-date on methods, practices, and frameworks, and help to lift the architecture-maturity and architecture-capability of the internal team. They also act as external peer-review, to reduce the risk of an insular and often destructive ‘groupthink’ developing within an organisation. This role too requires many years of experience, but this experience will have been gained across multiple disciplines in multiple organisations and, preferably, multiple industries.

The internal enterprise-architect deals with architecture in depth; the external enterprise-architect deals with architecture in breadth. An organisation’s architecture gains most from an appropriate balance of these two roles – not one or the other, but always some of both.

The worst possible combination of these two roles is unfortunately that which many large consultancies try to promote: full long-term control of an organisation’s enterprise-architecture by an external consultancy. An enterprise-architecture works right at the core of an organisation and enterprise: hence assigning responsibility for the organisation’s DNA to an external party is not a good idea… You Have Been Warned!

Sometimes a word will pop up out of nowhere, like the mushrooms did yesterday on the grass verge just down the road on this small suburban block.

But ‘ideafarming’ is a good way to describe the work that I do:  like a old-style farmer, planting seeds for new ideas, tending them, nurturing them, watching them grow.

Perhaps not as exciting as fishing for facts; perhaps not as challenging as herding cats; yet in its own way definitely as much hard work as either of those, and it has its own quiet pleasures too.

Different styles of ideafarming, of course. Some go for a machine-like monoculture, repeating the same ideas over and over again to reap the maximum benefit before the ground itself is exhausted – at which point an overly-artificial hydroponics-style approach may be the only option left. Others are aggressive – almost obsessive, even – in their war against the weeds: “Any idea needs to be challenged, vigorously and early … to make it more resilient”, thundered one erstwhile colleague – a tactic which seems more like ripping every tender young shoot out of the ground to check if it’s growing. My own ideafarming is probably more organic in style: watching, waiting, letting things be, letting things grow together in unexpected ways, companion-planting between disparate ideas and the like.

Some ideas ripen quickly, to give a quick harvest – but those ideas tend to be the most perishable of all, and getting them to market in time can be a chancy business. Other ideas are more predictable, perhaps with a yearly harvest – but that can mean long gaps where the work is as hard as ever but still no return in sight. Others again may take years, decades, even centuries, before they start to yield their crop – the metaphoric grapevines, hazels, chestnuts, walnuts of the ideafarmer’s harvest. They all look much the same when their first shoots first push their way out of the ground – and yet each needs nurturing in their own distinctive ways. Often the nurturing consists of deliberately ‘doing no-thing’ – which is not the same as ‘doing nothing’; and sometimes what we most need to do may make no sense at all to ‘outsiders’ – such as the paradoxical advice that “in order to remember something you never knew, first set out to forget it”.

And we’re always at the mercy of the elements, too. City-folks may see the machinery that we ideafarmers use – the mobile-phone, the library, the computer as metaphoric combine-harvester – and think that that’s what does all the work; but the reality is that those machines do nothing on their own, they help us in our work, but they don’t make the ideas grow at all. If we’re fortunate, and skilled, and careful, we may indeed at times have a bumper harvest, a glut of new ideas; but sometimes – and sometimes even for years – nothing will grow. Stuck. No matter how much we might like it to be otherwise, it’s not something we can control.

So we ideafarmers tend to be of a taciturn temperament: quiet, reflective, often rather solitary, a bit scruffy, perhaps, even a bit eccentric in our ways at times. Observant, yes – because we have to be; careful; innovative, always trying something new, yet always aware of how things work out over the longer term, looking to the future by being carefully aware of the present and the past. Passionate about what we do – as anyone can see at any conference – yet often irritable with those who get overly excited about everything: after all, there’s not much room for excitement in a working life that for the most part consists of watching, very carefully, at the way the grass grows.

And it’s a working life that never stops: get up in the morning, walk the fields, tend the fences, watch for pests and predators, for termites and ‘term-hijacks‘, for wild ideas and other weeds that will run rampant if we don’t watch out for what’s happening to our would-be harvest; a moment’s rest on the porch at sunset, perhaps, but then it’s time to settle down to get ready for yet another day. We don’t have much time for the bustle of the market: the work is calling – never stops calling – for our attention, we know we have to get back to the farm. And ideafarmers don’t take vacations as such: the ideas continue to grow whether we’re there or not, so we’re always working even when we’re not at work. We don’t have much choice about that: ideafarming isn’t a job, it’s more a way of life, a way of being. In reality, it’s not just something that we ‘do’: we’re ideafarmers because that’s who we are.

Ideafarming. A strange job, but someone’s gotta do it, I guess?

• ‘Everyday Enterprise Architecture‘ on Amazon.com
• ‘Everyday Enterprise Architecture‘ on Amazon.co.uk

Note that Amazon have an unfortunate habit of listing print-on-demand books as ‘out of stock’: all that it means is that it takes at most one extra day for delivery.

The publisher-blurb is as follows:

All of architecture comes down to one simple idea: things work better when they work together, with clarity, with elegance, on purpose. Yet how do we express that ‘one idea’ in practice, within our organisations? With what results, and for what business-value? This book describes the down-to-earth detail of everyday enterprise architecture, to show what architects actually do to deliver value fast, across the entire enterprise.

Working step by step through a real ten-day architecture-project, this book explores the activities that underpin sensemaking, strategy, structures and solutions in the real-time turmoil of an enterprise-architect’s everyday work.

Topics covered include:

• • how to use enterprise-architecture to tackle executive-level business-problems
  • how to develop an agile architecture practice that can keep pace with the real-time pressures of the real business world
  • how to identify the business-reasons and business-value for each activity
  • how to thrive on the inherent uncertainties of the architecture process
  • how to use context-space maps to guide sensemaking and solution-design
  • how to apply architecture ideas and activities to describe what actually happens in a real enterprise-architecture project
  • how to enhance architectural skills, judgement and awareness, for continuous improvement across the enterprise and in the architecture itself

If you want your enterprise to flourish and prosper in the midst of relentless change, this is one book you’ll definitely need.

The book describes the actual thinking-processes and business-activities that typify real architecture-work at an enterprise-wide scope and scale. The structure of the book is a walk-through of a simultaneous pair of architecture projects, using an agile-style adaptation of the well-known TOGAF Architectural Development Method. Both of the projects need to be delivered in parallel, and fully completed within a ten-day period. One of the parallel projects focusses on ‘the architecture of architecture’; the other – adapted from real whole-of-enterprise architecture-consultancy assignments – tackles a serious business-strategy problem for a fictional bank.

The book also introduces a new sensemaking technique for enterprise-architectures, known as ‘context-space mapping’. The technique draws on systems-theory and complexity-theory to enable a much richer view of the architecture context, yet still deliver actionable results in tune with the timescales of the real business world.

The book-cover includes an illustration from the Dover Collection, indicating the kind of stress under which most enterprise-architects work! The aim is that the book should help to ease some of the overload, and make it easier to describe to others what it is that enterprise-architects actually do.

At present you can also download the full ebook version for free from the Tetradian Books website; note that this offer will only be available for a few more days, after which the the full ebook will be replaced by a  ’sample’ edition, containing contents and sample-chapters only.