Tom Graves / Tetradian

Another follow-on to the earlier post ‘Helping others make sense of my work‘, just a quick note to let you know about two current book-projects.

The first has a working-title of The enterprise as story: the role of narrative in enterprise-architecture. This has been a major theme on this blog for the past couple of years or so: more than 40 posts here on various aspects since ‘The enterprise is the story‘. And as in the post ‘The no-plan Plan: architecture as story‘, it’s one of the five key-themes in my ‘no-plan plan‘ for my current and future work-direction. So it’s something I need to get down on paper, in more direct, usable form.

There’s a definite deadline of end of February for this one, because I’ll need it available in time for my presentation ‘The enterprise is a story: a narrative approach to enterprise-architecture‘ at the Integrated EA conference in London on 6-7 March 2012.

The second has a working-title of The business-anarchist: enterprise-architectures for the edge of chaos. This has perhaps been a less prominent theme on the blog, but it’s turned up quite a few times, such as in the post ‘Analyst, anarchist, architect‘. In essence, it’s about being deliberate and responsible about working with disruption in the business-context, preferably before that disruption is thrust upon us – a concern which is rapidly becoming more and more important almost by the day.

I’ve been nibbling at this one since mid-2009, and even wrote a fair chunk of it at various points last year, but didn’t finish it then, in part because it didn’t feel like the right time. Now, post-Occupy and suchlike, it does feel more like the right time, so I need to get it done. It’ll have to come after The enterprise as story, but with luck and lack-of-distraction it should be ready somewhen in April.

There’s also another enterprise-architecture book I’ve been working on for quite a while now with a colleague in Guatemala, Michael Smith. We don’t have a working-title for this one yet, and it’s rather further away in time – somewhen mid to late next year, probably – but it’s probably worth mentioning at this point. It’ll focus on the Five Elements theme that comes up in quite a few places in my work – for example, the structure of the effectiveness model used in SCORE strategy-assessment and the book Real Enterprise-Architecture, and the core of the market-cycle that’s used in conjunction with Enterprise Canvas.

Will let you know when any of the books become ready and available, but thought I’d keep you up to date with this part of work-in-progress, anyway.

Yes, I know I’ve gone a bit quiet in the past couple weeks, and no, I haven’t abandoned those ideas about SCAN sensemaking and real-time decision-making and the like.

Reality is that those ideas are very much in the ‘work in progress’ stage at the moment, and as yet still quite some way from a form that might make much sense to anyone else. To illustrate, for the past couple of weeks I’ve spent rather too many hours staring at and tweaking of a set of whiteboards that look like this:

In other words, it’s coming together, sort-of, but it’ll take a bit more time yet to clean it up into usable form. Watch This Space, perhaps?

Why do we need enterprise-architecture in a business? And why does that EA need to be broader than just IT, often all the way out to a true enterprise-wide scope?

One reason is implied this Tweet by Belgian consultant Patrick Van Renterghem:

itworks: Big discussion now about what happens when cloud vendors go bankrupt or out-of-service. Should [be] in the contract… #BAEA

“Should be in the contract…”: yes, indeed – but what should be in that contract? And why?

Without an enterprise-architecture that covers a broader scope than just the bare IT-transactions, we have no way to know what actually needs to be in that contract – and also in the parts that can’t be covered by contract, and that really do depend on relationships and trust. Which could be a serious problem from a business perspective. Hmm…

I’ve covered a fair bit of the detail of this in other posts here, such as ‘Enterprise-architecture and the Cloud‘. Some people seem to have misunderstood the questions there as somehow being ‘anti-Cloud’, or even ‘anti-IT’: it’s not. It’s about really looking at the whole context – about the whole ‘market-cycle’, about understanding the full implications of a customer-centric view, about maintaining consistency of service across all in-source and out-source relationships, and so on. And we do need to do that: because if we don’t, it can get really expensive.

Yet cloud-outsourcing is only one small example. As enterprise-architects, we also need to be able to extend out to a much broader business-picture, as Steve Denning describes in his Forbes post, ‘Clayton Christensen: How Pursuit of Profits Kills Innovation and the U.S. Economy‘

when a firm calculates the rate of return on a proposal to outsource manufacturing overseas, it typically does not include:

• The cost of the knowledge that is being lost, possibly forever.
• The cost of being unable to innovate in future, because critical knowledge has been lost.
• The consequent cost of its current business being destroyed by competitors emerging who can make a better product at lower cost.
• The missed opportunity of profits that could be made from innovations based on that knowledge that is being lost.

Failure to apply a proper enterprise-scope architecture-assessment of such themes can be more serious than merely expensive: mistakes at that level can easily kill a corporation. In short, it matters.

That kind of in-depth EA assessment might at first seem pernickety and pedantic, especially to those who just want to get moving. But as John Seddon warns, most of the ‘conventional’ methods to save money and effort usually end up costing far, far more: if we do need to cut costs, for example, we need to take more systemic, whole-of-context view in order to find the real places where those costs can be cut back. And the reality is that often they’re not where we’d expect them to be: hence, again, the need for a true enterprise-scope architecture.

Cloud-IT and other forms of outsourcing often look like the quickest, easiest and most practical way to cut costs. But Steve Denning quotes John Maynard Keynes to warn:

Practical men, who believe themselves to be quite exempt from any intellectual influence, are usually the slaves of some defunct economist.

Most often, those ‘defunct economists’ have failed to account for the hidden costs of a context – particularly the real human costs, which can be ignored only at our peril, especially in the longer term. There are good reasons why those ideas became ‘defunct’: but unfortunately, it seems each new generation has to re-learn those reasons time and time again…

In our domains, those forgotten lessons are reflected in IT-centrism and the like, and the over-simplification of otherwise-valuable ideas such as ‘scientific management’ and ‘business process reengineering’, and, now, cloud-based IT-services. A key role of a whole-of-enterprise architecture, here in the context of outsourcing, is to remind us of why those lessons about the real complexities of outsourcing and the like are so important, and what they mean in real-world practice to Keynes’ ‘practical men’.

In short, use enterprise-architecture to help identify the real hidden-costs of outsourcing – so that your business doesn’t get hit by the bill when those hidden-costs come back to bite…

What is it that drives decisions at the exact moment of choice and action? – even in the most mundane, everyday action? If the choice-point itself is a true moment of chaos – a point where literally anything is possible – then what is it that guides us through each of those infinitesimal yet ubiquitous moments?

A lot of this is still tentative, very much ‘a work in progress’. Yet what I’ve found myself returning to again and again over the past few days, whilst working on the design and workflows for the SCAN app, is a pairing of two words: belief, and faith.

[Don't worry, I'm not going to go all religious on you. (Well, probably not, anyway. ) This is still the same enterprise-architecture exploration about the context of SCAN, about sensemaking and decision-making at real-time, particularly in what some would term the 'Chaotic domain'.

Minor warning, though: this is written in English, and from the perspective of an Anglo culture. I think (believe? guess?) that what follows is close to generic across all human cultures, but note that you may well need to do some translation here, both linguistic and cultural.]

Where SCAN’s ‘Simple’ and ‘Not-simple’ are about about how to describe sensemaking, belief and faith seem more about decision-making – the actual moment of choice that immediately precedes each moment of action. In other words, decision-making in real-time. And because sensemaking, decision-making and action are all intertwined with each other within real-world practice, belief and faith also map onto the SCAN frame in much the same way as for real-time sensemaking.

[There's also a mapping to the full SCAN, that extends this outward to the scope where there is more time available for review, but I'll describe that in another post.]

In short, belief maps to the known, the certain, the Simple; whilst faith maps to the unknown, the uncertain, the Not-simple:

As in sensemaking, the crucial distinction occurs where the modality of the decision-choice changes from a Simple deontic true/false to a Not-simple true alethic logic of ‘possibility and necessity’:

– over on the left-side, belief provides a straightforward black-or-white choice: true or false, right versus wrong, culturally ‘proper’ versus ‘politically incorrect’;

– over on the right, choices are more blurry, more uncertain, more ‘shades of grey’ – or more colourful, perhaps – and the only guide we have is faith or trust that what we do is right. (Right in its own way, but still ‘right’ in some sense.)

Both of these are actually about the individual, about ‘I’. Which it should be, of course, because that’s all we have at the exact point of action: our own choice, and our own ‘response-ability’.

Belief is fast, and importantly doesn’t demand any personal skill as such: the whole point is that they’re deemed to be ‘true’ for all who enact them, regardless of who or what enacts them. (A belief may be believed to apply only to self – such as ‘nothing goes right for me’ – but is still held as an ‘absolute truth’ in that sense.) This has both advantages and disadvantages, mainly relating to how well the belief does match up to actual reality. Advantages include:

• simple beliefs are useful when the person enacting them has only a limited level of skill and ‘response-ability’ – “just follow the instructions, kid…”
• even for those with skill, simple beliefs are useful as a structured fallback for whenever the faith falters in the context and in one’s own ability – “when all else fails, follow the instructions”
• advising acceptance that some contexts are constrained by ‘laws’ of some kind – particularly the physical-world constraints implied by ‘scientific law’ and the like
• beliefs are also useful as a disciplined means to temper excess enthusiasm – “trust to Allah, but tie the camel first”

A classic example of a structured belief of that last type is the checklist - mapping out essential safety-checks and other ‘known truths’ prior to or during any activity that is inherently uncertain.

The disadvantages of ‘prepackaged’ belief-structures are more complex, and often rather more subtle:

• the usefulness of beliefs ultimately depends on the myth of ‘control’, the myth of predictability and certainty – none of which may be valid in a real-world context
• beliefs themselves can and do act as perceptual filters, potentially rendering invisible essential contrary information from the context
• as guides for choice and action, beliefs can apply inappropriate constraints to action in any given context – following ‘the letter of the law’ rather than ‘the spirit of the law’
• in much the same way, beliefs can be used to evade difficult or challenging choices – for example, ‘morals’ as ‘the lazy-person’s ethics’

Faith is often the only choice-mechanism available whenever the context is inherently uncertain. It also correlates closely to skill – so much so that, in essence, ‘skill’ is a proxy for the real-world reliability of faith in one’s own ability to work with the inherent uncertainties of a given type of real-world context. In other words, skill is what determines whether we really can do what we believe or hope we can do in that kind of context.

Sometimes, though, it isn’t about skill: it’s just about faith, or trust. Every change of belief requires ‘a leap of faith’; innovation or experimentation always requires us to accept that we don’t know what the outcome will be. (That’s very different from belief, where we do expect the outcome to be what we expect.) A modal-logic of possibility and necessity is the only place where ‘the impossible’ first becomes possible – and thence, through skill, becomes probable, then predictable, and eventually something resembling certain, a kind of ‘law’ in its own right. It may end up as a checklist or some other pre-packaged set of beliefs – but it always starts with faith, in the midst of a moment of inherent uncertainty.

As with belief, there are disadvantages to faith too: not least what we might describe as ‘misplaced faith’, where lack of skill – or plain old lack of awareness – leads to inappropriate outcomes. Whether we like them or not, sometimes the constraints of belief do apply – such as in most (though not all) assertions of ‘scientific law’ and the like.

So in practice we need to be able to bounce back and forth along SCAN’s ‘horizontal’ axis of modality. Sometimes we need to hold to a Simple true/false belief; sometimes we need to let go into the Not-simple world of faith and trust. And of course, recursively, there are no set rules about which one should always apply at any given moment – which means that this too is a skill in itself. It’s Complicated, perhaps, or Complex… yet in real-time action we don’t even have time for either of those. All we have is this decision, right here, right now – no time for anything else. Belief that we know what to do; or faith that the results we need will arise from within the chaos itself.

All of which means that, as enterprise-architects, we need to understand how belief and faith work within our organisation and enterprise, and provide structures to support them in real-world practice.

Enterprise-architecture implications

It’s essential to draw a distinction here between the individual and the organisation. Belief and faith are expressed in practice directly by the individual, or indirectly by proxy, such as via the design or operation of a semi-autonomous machine or IT-system. Yet in an organisational context, it’s the collective belief and faith that we want expressed in action – expressed by the individuals on behalf of the organisation, the collective.

In effect, that’s the key role of organisational culture – and despite the wishes of executives and others, it’s not as simple as it looks… For enterprise-architects, it also means that we often have to address aspects of organisation-architecture that are more usually the territory of HR and change-management and the like – which means that we have to tread carefully at times, and engage in some potentially-challenging negotiations. But the payoff is an enterprise-architecture that really works – for everyone.

The organisation’s beliefs-in-action are expressed in definitive statements such as work-instructions, reporting-relationships and business-rules. One of the architectural concerns here is to provide support such that these business-rules and the like are actually implemented in practice, in real-time decision-making.

To make this work, we in effect need each individual to take up those shared-beliefs as if they are their own personal beliefs. This is especially important wherever these rules must normally be followed ‘to the letter’ – such as in regulatory compliance.

It’s crucial to understand, though, that rules cannot be imposed onto individuals from outside, whether by fiat or threat of force. Although as an organisation we can give ourselves the illusion that this has been done, it rarely works in practice: instead, there will usually be a myriad of small ‘failures’, ranging from unconscious errors to covert rebellion, which effectively sabotage the intended functional impact of the rules. (The former will tend to occur more often in collective-oriented cultures, the latter especially so in individual-oriented cultures.)

What does work is to engage people in the rules – the ‘why’ as much as the ‘how’ and ‘what’. To use the terms from Hagel, Brown and Davison’s The Power of Pull, we create that engagement by shifting from ‘push’ to ‘pull’. In an enterprise-architecture, we do this by treating organisational-beliefs in much the same way as for organisational-values. The Enterprise Canvas model describes a generic structure for this purpose:

• create awareness of the rules-structure, its purpose and rationale, and the context for its use
• build capability to apply the rules-structure in real-time practice
• apply the rules-structure in run-time decisions
• verify and validate the usage of the rules-structure
• derive lessons-learned from the (attempted) usage of the rules-structure

Working with HR, change-management, process-management and others, we create what is in effect a PDCA-type learning-loop, to develop, apply and revise the business-rules and other belief-structures for the organisation.

The faith-in-action side of that decision-making modality-spectrum deals with anything that isn’t covered appropriately by business-rules and the like – which is a large part of most real-world organisational contexts. For enterprise-architecture, the two key focus-areas are skills-development, to enhance individual ‘response-ability’; and vision, values and principles, to enhance consistency in decision-making across the collective.

The skills-issue is one that is almost completely missing from most current-enterprise-architectures, especially those of an IT-centric bent. That’s rapidly becoming a lethally-dangerous oversight – see the Sidewise post ‘Where have all the good skills gone?‘ – and one that we need to address, working in conjunction with HR, organisational-development units and suchlike. EA will come into the picture by mapping out skills-requirements and competency-levels needed within enterprise-capabilities; the actual skills-development would usually be out of scope for EA, of course, though overall much of it would follow that generic structure for values as above.

The values-issue is one I’ve been pushing for a very long time as the true core of the enterprise-architecture: for example, it forms the topmost layer of abstraction in Enterprise Canvas, and thence acts as the anchor for the generic structure described above for values-management services. The reason why it’s important is that if the organisation isn’t clear about its values, then what will be used instead – as the drivers for ‘faith’-type decision-making – will be whatever values happen to be around for that individual. Which could be anything at all. Including not just a destructive ‘me-first’, but a really destructive ‘me-only’. In other words, not a good idea… clarity on values matters.

A lot more that could be said on all of that, but I’d probably best leave that for the moment. The only point that does need to be added here is the importance of story – the enterprise as story, the enterprise is the story – as the ‘glue’ that holds all of this together.

Overall, the real point here is this: that at the point of action – and despite whatever we might plan beforehand – decisions seem to be taken primarily on the basis of belief, or of faith or trust. Which means that, architecturally, we need to design for that fact. Not a trivial point, then.

More on this in another post soon, but any comments so far, anyone?

What do we do when we don’t know what to do? – and how do we ensure that whatever we do is the right thing to do? How do we make sense fast, at business-speed?

I’ve been tussling with this one for quite a while, most recently culminating with a simple sensemaking framework called SCAN:

The horizontal green-line axis here represents the decision-type, from a simple true/false choice to a not-so-simple modal choice of possibility and necessity; the vertical red-line axis is the amount of time available before must make a choice and take action.

[For more on SCAN and its technical background, see the posts '"Let's do a quick SCAN on this"' and 'Domains and dimensions in SCAN'.

In a sense, though, that red line of 'available-time' goes both sides of the 'now', extending outward both into future plans and past record:

Time and distance and even social-distance all compress down towards the point of decision, the moment of action, the now. That 'now'-moment is the only one that matters: prior to that point, every 'decision' may be nothing more than a vague statement of intent, which may not actually happen in practice - as I know only too well...

At each moment of 'right here, right now', it's always our responsibility - our 'response-ability', our individual and personal ability to respond.

The 'now' is the still-point at the centre of action. Yet it's an active stillness, and there are still choices there in that moment. So what we aim for in this kind of real-time sensemaking is to create just enough space to enhance that 'ability to respond' - enough space to enable appropriate choice for appropriate action.

If we don't create that space for choice, the only 'choices' we have come from habit - which may not be appropriate to to the context - or the various 'hard-wired' reflex-responses, such as 'fight', 'flight' or 'freeze'.

[The other natural-reflex is 'fornicate', but we'd, uh, best leave that out of the conversation for now...? ]

Whilst it’s easy enough to describe what goes on either side of that choice-point, it’s surprisingly hard to describe the choice-point itself without sounding somewhat mystical. Rather like the cosmological moment of the Big Bang, it’s both technically and literally a moment of chaos, within which the ‘normal rules’ break down, and which contains within itself every possibility and every other point.

This is the literal meaning of Pan, by the way – ‘the everything’. If we can’t cope with this infinity of (im)possibility, we’re like to fall into panic. And that’s what leads to those three reflex-responses – each of which rejects the uncertainty in their own distinct way:

• fight: grab at a single possibility and ‘take control’ (whether or not that single chosen option is appropriate to the needs of the context)
• flight: ‘run away’ from the choice (such as to a ‘considered-sensemaking’ framework which cannot work at real-time, and hence leads to some variant of ‘analysis-paralysis’)
• freeze: do nothing and hope that the need for choice will go away (which only works if there’s no actual need for choice or action)

What we need to do instead is stay within the ‘chaos’ for as long as we can, to allow the appropriate choice to emerge from and with the context itself. Describing this as ‘act / sense / respond’ is way too simplistic: it’s more like a real-time dance of choice and action, a transitory yet immensely powerful condition of flow that is often experienced as a kind of ‘no-time’ that is seemingly beyond time.

[People who can hold that space are often described - or derided - as 'eccentric', 'the crazy ones'. Yet 'eccentric' is literally away from the centre - and that's the place where change can happen, because that distance also provides leverage for change. Being seen as 'eccentric' can be difficult at times, but it's certainly important...]

What I’ve been working on over the past few days or so is trying to a detailed mapping of what actually happens in the real-time space, using this specific question of real-time sensemaking as the ‘target problem’ to keep in focus.

[As usual, I've gone back to first-principles to do this, so in effect I've been watching myself at work whilst doing this work. What I've been seeing may not be the way that others do this, of course, but it actually does match up quite well with what's in the rather eclectic mix literature that I happen to know, from Lao Tse's Tao Te Ching to Csíkszentmihalyi's Flow, and from Zen and the Art of Motorcycle Maintenance, to The Art of Scientific Investigation. So no claims to be 'academic' as such, but that isn't the point: I'm a practical toolmaker, not a 'pure' theorist, after all.]

For this, I’ve used the ‘time-compressed’ version of SCAN, in which everything is squeezed down to a real-time choice of tactics, between ‘Simple’ and ‘Not-simple’:

The crucial boundary on this dimension is what I’ve called ‘the Inverse Einstein test’:

• if we do the same thing and get the same results, it’s on the Simple side of the story – so we would attempt to use Simple-side tactics
• if we do the same thing and get different results, it’s on the Not-simple side of the story – so we would need to use tactics from the Not-simple side

In real-time sensemaking we actually swing back and forth between these ‘domains’, using a variety of real-time checks to tell use which side we need to be on at any one moment. They’re different disciplines: but by swinging back-and-forth in a conscious and deliberate way, we maintain an overall discipline at all times.

[First-hand example: doing a formal back-massage. At first, I'll follow the rules, following the standard sequence of moves and work-patterns, using that pattern itself as a focus. At some point it switches into that 'flow-state', and I'll find myself doing something subtly different, applying pressure in a different way, following kind of 'inner instructions' that seem to come through my hands themselves. Then, just as suddenly, the 'flow-state' fades, leaving me feeling a bit lost, like I don't where I am, I don't know what to do. That's when the key-phrase 'Don't Panic!' comes in, and reminds me to go back to 'the rules' - back to the Simple-side - and follow that pattern until the 'flow-state' returns. Which it may not, of course - but at least I'll have done something useful simply by following 'the rules'.]

If I use the tags ‘[S]‘ for Simple-side, and ‘[N]‘ for the Not-simple side, these are some of the points I’ve noticed during this week about that real-time back-and-forth:

– [S] is about following the instructions, following ‘the rules’; [N] is about allowing ‘the answers’ to arise in whatever way they seem to choose.

– [N] is what we do while that ‘inner knowing’ lasts; [S] is what we do when the knowing fades.

– Both sides need calm, and need discipline – including the discipline about how and when to switch back and forth between them.

– [S] has notions of ‘truth’, of ‘control’, of certainty, “I know what to do”; [N] calls for a kind of faith, a lot of trust, perhaps Susan Jeffers‘ “feel the fear and do it anyway” – and often a difficult balance between “do something, don’t just stand there!” and “don’t ‘do something, just stand there…”.

– In a rework of the old slogan “think global, act local”, [S] seems to focus on ‘act local’, whilst [N] seems to allow the broader space of ‘aware global’ – no time to stop and think at real-time, yet use that deep-space of ‘the everything’ to help maintain the big-picture awareness.

– [S] seems to work best with rules or checklists – which is hardly surprising since in essence it thrives on real-time certainties. Some of the rules and checklists I use a lot in real-time sensemaking for enterprise-architecture include:

• allow the uncertainty to be uncertain (i.e. keep gently returning to the Not-simple side)
• don’t try to control – allow ‘the answers’ to arise in their own way
• use the ‘checklist for checklists‘ to create checklists on-the-fly with whatever ideas I’ve gleaned from the Not-simple side
• use quick enquiry-techniques such as ‘Five Whys‘ to push into the Not-simple side for new ideas and information
• use Five-Whys to move up the scale of abstraction towards core-purpose
• use Five-Hows to move down the scale of abstraction towards real-world implementation
• use the R5 set of system-thinking principles – rotation, reciprocation, resonance, recursion, reflexion – to look for factors and patterns in the context
• use the REAL checklist – reliable, efficient, appropriate, elegant – to test for effectiveness themes (sometimes extended to ‘LEARN’ with the addition of ‘integrated’)
• use the tetradian set – physical, virtual/conceptual, relation/emotional, aspirational/spiritual – to review asset-dimensions in a context
• use the Five Elements set – Purpose, People, Preparation, Process, Performance – to assess balance across strategy, tactics and operations (which also aligns with the Tuckman project-lifecycle sequence ‘forming, storming, norming, performing, adjourning’)

– Almost by definition, [N] doesn’t seem to have any clear patterns: the only ‘patterns’ I see myself doing all too often on that side are ones about how to avoid making sense, such as running away to check emails or make yet another cup of tea…

Anyway, that’s it for the moment. It’s just a work in progress, as usual, but make of it what you will.

Comments/suggestions, anyone?

This is another follow-on to the earlier post ‘Helping others make sense of my work’ – this time about how to bring all of this to a wider audience and market, and help bring ‘whole-enterprise architecture’ ideas into more general use.

If you’ve been around this weblog for a while, you’ve probably noticed I tend to churn out ideas for tools for whole-enterprise-architecture. That’s what I am, really – a toolmaker, a maker of conceptual tools.

Some of those ideas for tools, I’ll have to admit, have pretty much gone nowhere. Others, though, have gained a fair bit of attention and interest. A few have so far made it out into book-form, and look like going a lot further.

But what I really want to do is re-work all of the best ideas into apps – tools that can be used online or offline, on any part of the EA toolset-ecosystem, from smartphones to tablets to laptops to desktops to ‘proper’ repository-based EA-toolsets.

The practical catch is that I’m long out of date as a software-developer, and at present I don’t have access to investment funds to pay someone else to do it.

So I’m looking for partners to work with me in developing these apps.

I firmly believe that if we get it right, there’s a huge potential market for several of these app-ideas, and at present there’s little or nothing out there to serve that need. And the first developer who fully ‘gets’ what I’ve been struggling to explain here on this weblog over the past few years is going to gain a market-position that should establish them for many years to come. So, your choice, folks: anyone interested?

I’ll quickly outline below the five ideas that I think are the most ready to be implemented as apps:

• SCAN sensemaking-framework
• Context-space mapping sensemaking-method
• ‘This’ exploratory game for service-oriented enterprise-architectures
• Enterprise Canvas for modelling service-oriented enterprise-architectures
• SEMPER diagnostic and intervention-design for organisational ‘ability to do work’

For each app-idea, I’ll summarise:

• why and how this app will help
• what the app would do
• what it would look like
• existing apps which include some aspects of this
• how this links with broader EA-tools context
• probable market (and hence potential revenue)
• probable complexity / difficulty for development (and hence potential cost)
• current development-status
• posts and other sources for further information on this prospect
• other notes (if any)

For the right person, or the right team, there really is a huge opportunity here that’s too good to miss…

Read on, anyway: and if you’re interested in any of this, or know someone else who might be, please get in touch with me as soon as possible. Thanks!

Read more…

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

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

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

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

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

Read more…

What are the sensemaking-domains in SCAN? What are the boundaries between those domains?

A great challenge in an earlier comment from Roger Sessions, where he asked me for the mathematical basis for those domains and boundaries. I think he was a bit shocked when I said there wasn’t one – but in fact there is such a basis, sort-of, and it’s worth summarising here, out on the surface rather than buried away in the comments.

(Whilst working on this I’ve realised that in some ways this is a repeat of the section ‘The structure of SCAN’ in the post ‘On SCAN, PDCA, OODA and the acronym-soup‘. But it’s probably worth having the extra detail, anyway.)

The dimensions of SCAN

There are three distinct dimensions to SCAN:

• 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

The SCAN frame is usually shown with four apparent domains, derived from the first two dimensions above:

In part, though, this format is mainly for people who are more comfortable with a simple two-axis matrix, or who need to translate across from other domain-oriented frameworks such as Cynefin or the Jungian-based ‘swamp analogy‘. This layout can be somewhat misleading in that the boundaries between apparent domains are not straightforward, and that third dimension of repeatability does also need to be taken into account. We’ll explore how this works in practice in the rest of this article.

Dimension of modality

The ‘horizontal’ dimension for SCAN is a scale of modality of the logic used for sensemaking and decision-making. Modality in this sense is the scope of possibility and necessity; a scale of modality ranges from a simple ‘yes/no’ or ‘true/false’ choice, to an infinity of possibilities. We make a choice from the palette of possibilities on offer in the context, in accordance with what we perceive as the necessity in the context.

In principle, for SCAN, we should draw this as a horizontal graded spectrum of 0..n possibilities for choice, from left (choice of 0..1) to right (choice of 0..infinity). In practice, though, we can put an explicit boundary at the 0..1 point, because the way the choices are usually addressed will change radically on either side of this point. In SCAN, we describe this distinction as a Simple choice, or a Not-simple choice:

Anything that relies on absolute repeatability regardless of agent, on identical circumstances, or on any true/false logic, must by definition be constrained to the Simple side of the scale. This includes almost all machines, most IT, and any rule-bound human context.

The key point is that on the Simple side, there’s only one choice: do it, or don’t do it. Very straightforward. (Whether it actually works, in terms of creating the required results, is another story, of course…) Once the options start to multiply, the choices become more Complicated, but as long as the choice-mechanism is still some form of true/false, it still remains ‘controllable’ – we just need more time to sift through the options and factors and make the ‘right choice’.

But once the options become contextual, or dependent on the skill and capabilities of the agent, or for any reason cannot be absolutely repeatable, that pushes us over the boundary to where a Simple true/false logic is unlikely to work. In other words, it’s Not-simple. And we start to need other ways to work with it – ways that are usually not available from machines or IT, or from inexperienced human trainees. The further over into the Not-simple that it gets, the higher level of skill it will require to get to the equivalent of ‘repeatable’ results – the same perceived outcomes reached via different routes.

One important complication arises from different experiences of ‘simple’ versus ‘complex’. The definition for Simple here is the use of true/false choice-logic, of true/false rules and so on. However, many people experience that as anything but ‘simple’ – especially where rigid rules are applied in contexts that have high natural variability and hence need greater modality. In those contexts, more fluid patterns and guidelines are often experienced as ‘simple’, because it’s easier to use them to achieve the same perceived outcomes.

In those types of circumstances it may be better to change the horizontal scale from a ‘mathematical’ one of modality’, to a more subjective scale of what is experienced as ‘Simple’ versus ‘Not-simple’. We do, however, need to be really clear and explicit as to which type of scale we’re using!

Dimension of available-time

The ‘vertical’ dimension for SCAN is a straightforward scale of time-available-for-decision. We can use a linear or logarithmic scale scale for this: the choice probably doesn’t matter, although since the time-available can potentially stretch to infinity, a logarithmic scale might make more sense in practice.

The key point here is that as we gain more time before a decision must be made, we also gain the ability to assess a broader range of options. When the time is tightly focussed, we must focus on ‘right here, right now’, the specific point of action, using only what is available at the time. When the time is less tightly focussed, we get to have more choice about how to tackle decisions, about what can be used to enact those decisions, and so on.

It’s a continuous spectrum, of course, so any ‘boundary’ we put along along that vertical axis is going to be somewhat arbitrary. One easy way to partition the timescale is the classic three-way split between Strategy (far-future), Tactics (near-future) and Operations (NOW!). Another – which would obviously be a better fit with the notion of a two-axis matrix – is ‘Time-to-think’ versus ‘No-time-to-think’.

If we use the latter, and combine it with the Simple/Not-simple split on the ‘horizontal-axis’, that gives us a conventional ‘four-domain’ layout for SCAN. So let’s use that for now - always remembering that the position of the vertical-axis boundary between ‘domains’ is an arbitrary choice.

The horizontal-axis here still has that boundary between 0..1 true/false decision-logic to the left, and a true 0..n modal-logic to the right.

So on the left, Time-to-think (‘Complicated’) gives us the rules and categories that we would use in a true/false logic when there’s No-time-to-think (‘Simple’). In other words, it allows its ‘world’ to be more Complicated, but it still expects it to be ‘controllable’, for there to be an identifiable, repeatable ‘right answer’ to every context-related question. In terms of systems-theory, this is the kind of space where we would expect to find ‘hard-systems’ models in use.

And over on the right, Time-to-think (‘Ambiguous’) gives us the patterns and ‘seeds’ – and also the support to work with the uncertainty – for when we work with inherent-uncertainty when there’s No-time-to-think (‘None-of-the-above’). It allows its ‘world’ to be Ambiguous, uncertain, yet also still ‘actionable’, understandable, describable in some sense. In terms of systems-theory, this is the kind of space where we would expect to find ‘soft-systems’ models in use, or concepts of ‘complex-adaptive-systems’ or ‘emergent-systems’ and the like.

When it gets down to No-time-to-think in that modal space, though, there often isn’t any way to understand it, or even describe it: it’s too context-specific, too unique to the context, the person or both, often dependent on personal skills and experience that only ‘make sense’ to that individual person. It’s often not sharable as such within anyone else, and there’s no obvious way to make it fit into any predefined category, or even into any identifiable pattern. Hence the label ‘Not-known’, or ‘None-of-the-above’: it simply is. And yet that also is the domain in which perhaps most human work is actually done – and hence should not be ignored…

Dimension of repeatability (variety)

Perhaps the real point about the None-of-the-above domain is that it’s probably the closest we have to ‘the real-world’: everything else is an abstraction.

What we actually have in sensemaking – and, hence, its derived decision-making – is a myth of abstraction: the belief that abstractions are somehow ‘real’. Something ‘makes sense’ because we choose that it should ‘make sense’ in that way: just how much it actually is ‘real’ is often an open question…

In practice, there’s a spectrum of certainty of abstraction, from idea to hypothesis to theory to ‘law’ – lowest-certainty to highest-certainty. The closer we get to ‘law’ (in the scientific sense, at least), the more predictable the context should be – assuming that the ‘law’ is an accurate abstraction, of course. The more predictable it is, the more we can rely on its repeatability – where the same actions deliver the same results. Conversely, the less predictable it is, the less we can rely on the same actions delivering those same results. Which gives us a spectrum of repeatability.

That spectrum of repeatability does sort-of line up with abstraction, but even more so with the variety – in the cybernetics sense – in the actual context. When there’s a mismatch between the type and range of variety that the abstraction can cope with, versus the actual variety in the context – the ‘system’ – then we’re likely to get systemic failure.

This is crucial in enterprise-architecture and the like, because most IT and the like, and most systems that depend on ‘command and control’, are almost by definition constrained to the amount of variety that can be covered by their own true/false logic. The whole point of conventional command-and-control is that it doesn’t permit any variety beyond its own scope. And when the real-world does happen to contain greater variety – which, to be blunt, it often does – then, again, the system will fail. (Though likely that it’d be the real-world, rather than the inadequate abstraction, that would be blamed for the failure…)

When we put all this together in SCAN, that spectrum of repeatability – or, inversely, of variety – ends up somewhat like this:

When there is low variety in the overall system, it’s relatively Simple to set up straightforward rules, and enact those rules in real-world practice with high to very high probability of repeatable results – including the same results from different agents that use the same rules.

As the variety increases, we need time to be able to identify the various factors and feedback-loops. The system becomes more Complicated, but up to a certain point will still be able to deliver repeatable results with different agents that follow the same more-complicated systemic rules.

As variety continues to increase, there is a crucial cross-over point where doing the same thing can no longer be guaranteed to deliver the same results, sometimes even with the same agent. The crossover into Ambiguous automatically occurs whenever an unaccounted-for factor enters into the supposedly-predictable picture. We can sometimes work out new rules for that new factor, but in some cases there will always be uncertainty, ambiguity – and trying to force the system to fit the lower-variety assumptions of the Complicated ‘domain’ will usually cause systemic failures such as ‘wicked-problems‘ and the like. ‘Soft-systems’ and ‘emergent-systems’ methods will help to address the issues here, often developing patterns and guidelines for use at real-time, but as the Complicated ‘domain’, all of these techniques take time – which may not be availability.

As time-available becomes compressed towards real-time, or variety increases still further towards non-repeatable uniqueness, we end up being forced into a ‘domain’ that’s probably best summarised as Not-known or None-of-the-above. Increasingly, the equivalents of ‘repeatable’ results on not repeating the same actions – and it takes increasing levels of skill to guide the context towards desired ‘repeatable’ results. Conversely, repeating the same actions can deliver different results – which again, with skill, may return highly-desirable uniqueness.

Overall, though, note the transitions here: both Simple and Not-known, at the opposite ends of the scale, can work well at or near real-time, whereas Complicated and Ambiguous, in the mid-range, require time to execute. If ‘control’ is required at real-time, it must be Simple: there is no other option. Any other choice either requires more time, or an acceptance that ‘control’ will not work in the context. Again, this point has huge implications for enterprise-architectures.

A possibly-simpler summary

Some quick follow-on points from all of the above:

• In the real world, ‘control’ is a myth – we can simulate some of it, but it often constrains ability to cope with real-world variety such that it’s likely to break down.
• When it does break down at the Operations level, at or near real-time, we’re automatically forced into a None-of-the-above context, which requires skill and experience to bring the context back to a simulation of ‘control’.
• If the skill and experience are not available, or are excluded, the overall system is going to fail – as happens often in misguided attempts at IT-centric ‘business process reengineering’.
• Analysis and experimentation take time to execute – they’re not viable when time-available is compressed down to the real-time level.
• In most real-world systems, time-available will vary: there are periods of intense time-pressure, where only the Simple and the None-of-the-above will work; and there are periods when the time-pressure eases off, which can be used for review and reassessment via a move ‘into’ the Complicated and/or Ambiguous ‘domains’, to prepare for the next high-intensity part of the work-cycle.

I’ll stop there for now, but there’ll be more on this in the upcoming final part of the ‘on sensemaking in enterprise-architecture series‘, and in other future posts.

As usual, comments, anyone?

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

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

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

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

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

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

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

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

Read more…

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

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

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

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

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

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

Read more…