Tom Graves / Tetradian

One of the key reasons why I’m so vehemently against any-centrism and suchlike revolves around the question of competence – or, more usually, the lack of it.

Competence is where someone knows what they’re doing, and does it. And, oddly, often don’t bother to say that they’re competent – perhaps because they don’t need to say it, their actions say it well enough instead. The outcome of competence is fairly certain, even in contexts of high uncertainty.

Non-competence is where someone doesn’t know what they’re doing, and will either not do it, or will do the best they can, yet with the explicit intent to use it as a learning to improve their competence. Importantly, they will usually say that they don’t know what they’re doing. The outcome of non-competence is uncertain, even in nominally-certain contexts, but at least we are aware of the risks.

Incompetence is where someone doesn’t know what they’re doing- i.e. is non-competent to do the task – but either purports and/or believes themselves to be competent. They will usually say that they are competent, even though demonstrably they are not; they claim to be responsible, yet have limited ‘response-ability’. The outcome of incompetence is fairly certain, and frequently dire, yet lack of awareness of the risks is often rampant, or in some cases the risks actively concealed.

Someone who is non-competent can become competent by learning the respective skills, or be competent by proxy, via finding someone else who is competent at doing the respective type of task. I treasure my non-competence, because it means there’s always more for me to learn. And as an enterprise-architect, I am, almost by definition, non-competent in much if not most of the detail-aspects of areas that I need to cover: hence one of my key competencies is the ability to learn enough of a new area fast enough to be able to guide meaningful exchanges between people who are fully competent in some detail-area but are not competent in others with which they need to connect.

Yet one of the key criteria for non-competence, and to separate it from incompetence, is a willingness to accept that we are non-competent, and say so. If we’re not aware that we’re non-competent, we automatically increase the risk of being incompetent. And if we know that we’re not competent, yet somehow ‘need’ to claim that we are competent, we would, again, automatically be incompetent – with a very high risk of inappropriate or ineffective outcomes of the work.

In part it’s a cultural problem: the risk of incompetence increases wherever a culture exhibits any of these characteristics:

• prioritises content over context, ‘truth’ over context-dependent usefulness
• has an insistent ideological base (leading to the same as above)
• is typified by rampant egotism, self-advertising and self-centrism
• is frequently swayed by tides of hype and ‘following after the latest fad’
• displays an almost desperate need to be ‘right’

Unfortunately, all of these attributes are extremely common in business, and in many cases are actively prized… By definition, they’re also more likely to be common in any ‘truth’-oriented domain, one which operates primarily on ‘true/false’ decision-making – hence, in practice, the tendencies towards IT-centrism and finance-oriented business-centrism, both of which rely on simple true/false logic for most of their operational decisions.

In SCAN terms, all of these are where the Simple certainties of Belief – either as ideology and/or as self-belief – are inappropriately applied to the far side of the Inverse-Einstein Test, where the uncertainties of the Ambiguous and the Not-Known cannot be avoided.

This gives us a dysfunctional ‘diagonal’ decision-path, where Assertion is imposed on the Not-known, or Ambiguity ‘solved’ by arbitrary Belief:

Yet the real problem here is somewhat more subtle:

• someone who is competent will typically not bother to say so, but will just get on with the work instead
• someone who is non-competent will typically say that are not competent, but will often actually be adequately-competent, or at least willing to learn to become so
• someone who is incompetent will typically claim that they are competent, and will usually not be willing to learn how to become so, because to do so would betray to themselves and others the fact that they are actually not competent

Which, in practice, leaves us with a huge dilemma:

• those who do not claim to be competent usually are competent
• those who do claim to be competent frequently are not competent

Hence, again, the kind of mess that we see so often in enterprise-architectures, wherever IT-centrism, business-centrism and the like predominate… Oh well.

Comments, anyone?

How is it that what we do doesn’t necessarily match up with what we plan to do? How can we best ‘keep to the plan’? Or, alternatively, how do we know how to adapt ‘the plan’ to a changing context? What governance do we need for this? How do we keep everything on-track to intent in this? And what implications does this have for our enterprise-architectures?

What we’ve been looking at in this series of posts is a key architectural concern: at the moment of action, no-one has time to think. Hence to support real-time action, the architecture needs to support the right balance between rules and freeform, between belief and faith, in line with what happens in the real-world context. And it also needs to ensure that we have available within the enterprise the right rules for action when rules do apply, and the right experience to maintain effectiveness whenever the rules don’t apply.

As we saw in previous parts in this series, this implies is that within the architecture we’ll need to include:

• a rethink of ‘command and control as a management-metaphor [see Part 1 of this series]
• services to support each sensemaking/decision-making ‘domain’ within the frame [see Part 2 of this series]
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame [see Part 3 of this series]
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

So this is Part 4 of the series, the final part: exploring the architecture of governance – and architecture-governance too – that we need for all of this to work well.

[Those two key reminders again: this is 'work-in-progress'; and all of this is recursive - so you'll likely need to do some work of your own here too.]

Read more…

How is it that what we actually do in the heat of the action can differ so much from the intentions and decisions we set beforehand? How can we bring them into better alignment, to ’keep to the plan’? And how does this affect our enterprise-architectures?

What we’ve been looking at in this series of posts is a key architectural concern: at the moment of action, no-one has time to think. Hence to support real-time action, the architecture needs to support the right balance between rules and freeform, belief and faith, in line with what happens in the real-world context. And it also needs to ensure that we have available within the enterprise the right rules for action when rules do apply, and the right experience to maintain effectiveness whenever the rules don’t apply.

As we saw in previous parts in this series, this implies is that within the architecture we’ll need to include:

• a rethink of ‘command and control as a management-metaphor [see Part 1 of this series]
• services to support each sensemaking/decision-making ‘domain’ within the frame [see Part 2 of this series]
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

So this is Part 3 of the series: exploring the architecture of how we link together the various domains of sensemaking and decision-making within the enterprise.

[Two key reminders here: this is 'work-in-progress', so expect rough-edges and partly-baked ideas; and although I'll aim to keep the descriptions as simple of possible, note that all of this is recursive, with many intersecting layers of simple and definitely-not-simple - so please do expect to have to do exploratory-work of your own here too.]

On services to support the ‘horizontal’ and ‘vertical’ transitions:

We can summarise this part in terms of the following diagram:

Although sensemaking and decision-making tend to be blurred together within these transitions, there’s usually a clear set of distinctions:

• services that work across the modalities in real-time action
• services that bridge between certainty and uncertainty in planning for action and reflection on action
• services that improve how we apply certainty in action
• services that improve how we work with uncertainty in action

The first two sets of services are primarily ‘horizontal’ across the SCAN frame, linking across the modalities but at a single timescale; the other two sets are primarily ‘vertical’, crossing timescales but on either side of the Inverse-Einstein boundary. There’s obviously enormous scope here, but to keep things simple I’ll stick to a single scenario for each.

For real-time, imagine starting this off with a checklist – a pilot’s pre-take-off check for an aircraft, perhaps.

This gives us a Belief-based structure for decision-making – ‘belief’, because the ‘correct method of working’ is embedded in the sequence of the list. It also gives a Simple true/false method for sensemaking – ‘simple’, because either something checks off against the list, or it doesn’t. After much repetitive practice, using this checklist is ‘second-nature’ to the person doing this work – yet the list is also followed with care and attention.

And because the checklist is followed with care – as ‘the truth’ – the pilot notices that something doesn’t check off correctly. For this example, we’ll assume it’s the radio: there’s no response and no apparent signal from the control-tower.

The moment that we hit something that ‘doesn’t fit’, by definition that throws us across the other side of the SCAN frame, into the Not-known. Notice that for a (very) brief moment, there’s a sense of panic – at which point all the previous training and skill and experience should kick in, together with Faith-based decision-making, to cope with ‘a context larger than that covered by the rules’.

[I've deliberately chosen a fairly minor yet everyday example here: an incorrect radio-setting. For a far less everyday example where the same principles and processes apply, moving back-and-forth across the real-time spectrum, see the section 'Sensemaking in real-time' in the post 'On sensemaking in enterprise-architectures [Part 2]‘.]

In a fully-structured process, there would be another checklist here, specifically to guide sensemaking and then decision-making around what’s (not) happening with the radio – in other words, a tool to pull this back over to the left-side of the frame again, with Simple / Belief. But if the checklist doesn’t exist, or isn’t found, the sensemaking and decision-making remains over on the Not-known / Faith side of the frame.

It’s a high-risk context, so the pilot can’t afford to ignore the problem, and also can’t ‘go on faith’ – the checklist makes it clear that that radio must be working correctly before take-off can be allowed. So notice what happens next: the sensemaking remains on the unorder side, but drops out of real-time. Everything slows down: the pre-take-off process has to stop whilst the pilot carries out a quick series of experiments – in other words, moving somewhat up into the Ambiguous / Use space.

Most of these are Simple true/false tests (is the radio switched on? is the headset connected? is the frequency-setting correct?), which in principle are rule-based, except that the pilot is creating these tests on the spot, from past experience and knowledge of the equipment, rather than following a (non-existent) checklist. One of these tests shows that the frequency has been set for the destination airport rather than this one. The pilot looks up the correct frequency from a reference-chart – another Simple tool – and then changes the channel – a Belief-based decision.

Going back to the original checklist – in other words, now back in real-time again, over on the left-side of the SCAN frame – the pilot re-checks the radio-call: this time it does confirm correctly. The pilot then completes the pre-take-off checklist without any further Not-known interruptions.

From an architecture perspective, notice two points here.

The first is that real-world sensemaking and decision-making at the point of action will often bounce back and forth between Simple / Belief and Not-known / Faith. Most typical business-processes will start over on the Simple / Belief side of the frame – in other words, ‘follow the plan’; yet anything unique, anything different, anything unexpected that doesn’t fit the predetermined ‘the Rules’, will automatically force a transition over to the Not-known / Faith side of the balance. And in most cases, only skill and experience will bring it back over to the Simple side again, to deliver the required result. That’s what skill is, and largely what it’s for.

The second point is that systems which can only work with rules – which in practice includes almost all machines, and most IT-systems – cannot actually cope with that transition into the Not-known. And many if not most real-world contexts do include uncertainties of some kind or other. In such cases – which, again, is most cases – rule-based systems cannot be used to address the whole context: there must be a human skill-based component both to identify when the rule-based system is out of scope, and to take over when it does go out of scope.

The danger here is that IT-systems can sometimes simulate full-context capability from sheer speed applied to a sufficiently large rule-base – which gives the illusion that it can cope with the full context. Fact is that it probably can’t – that uncertainty again – but if we design on the assumption that it can, we’re going to be in real trouble when (not ‘if’) it fails. The architecture needs to take great care on this point: yet the sad fact is that most current architectures – especially IT-centric ones – don’t take anything like enough care with fallbacks and the like here. You Have Been Warned?

For reflection-time – moving back-and-forth across the frame, but at some distance from real-time – what we need are processes that focus on pragmatics and praxis: distilling theory from practice (right-to-left on the SCAN frame), and applying theory to preparation for practice (left-to-right on SCAN) in the unordered-realms.

This is the transitions between what’s described in SCAN as Complicated / Assertion and Ambiguous / Use. What we’re looking for here in the architecture is support at various different timescales – strategic, tactical, operational – for a whole swathe of interactions and trade-offs across the two sides of the frame. As mentioned back on the post ‘Decision-making – belief, fact, theory and practice‘, some of the keywords we’d look for on each side of that balance would include:

• theory versus experience
• ‘objective’ versus ‘subjective’
• ‘science’ versus technology
• ‘control’ versus trust
• true/false versus fully-modal
• organisation versus enterprise
• structure versus story
• sameness versus difference
• ‘best-practice’ versus (understanding of) ‘worst-practice’
• ‘sense’ versus ‘nonsense‘
• certainty versus uncertainty
• rules (‘the letter of the law’) versus principles (‘the spirit of the law’)

For example, this is – or should be – the ‘applied science’ transactions between the assertions of science and the usefulness of technology, each lifting the other to new levels of capability. And we’ll only achieve a real effectiveness via a fully-nuanced ‘both/and’ balance across all of these dimensions, and more – which is what the architecture needs to support.

At present, though, most enterprise-architectures and their subsidiary domain-architectures will be hugely skewed towards the left-side of that balance: theory and ideology, ‘objective’, ‘science’, structures, sameness, ‘sense’, rigid rules, near-random re-use of others’ supposed ‘best-practice’, true/false ‘proof’, abstract organisation (rather than human enterprise), and, above all, certainty and predictability. Yet the end-result of such imbalance is an architecture that is all but incapable of coping with either uncertainty or change – and relies instead on a stream of management-fads to give a spurious sense of certainty where none actually exists. Which is not a good idea, especially in the increasing uncertainties of most present-day business contexts. We need that balance…

The simplest way to work towards a better balance is that, for each item that seems to fit in either the Complicated / Assertion domain or the Ambiguous / Use domain:

• what is its counterpart in the opposite sensemaking or decision-making domain on the other side of the frame?
• what processes link these two items together, such that each can learn from and support the other?
• how do these processes vary at different distances from the point of action?
• how do these processes vary for different skill-levels or for use with different real-time process-implementations?

(We’ll come back to that last question shortly.)

So, for example, Complicated-domain analytic, algorithmic hard-systems theory has its Ambiguous-domain counterpart in experimental, emergent soft-systems theory: in what ways do these link together? How do they support each other, inform each other, conflict with each other, enhance each other? How do we identify (make sense of) which approach would apply better to any given context? What are the trade-offs that would guide such decisions?

[For some great examples of how this kind of interaction works in scientific research, see WIB Beveridge's 1950 classic The Art of Scientific Investigation.]

Using those tests and guidelines, work your way across all aspects of the architectures, to identify gaps and imbalances across the SCAN domains.

For improvement of real-time action, the processes would, in principle, be partitioned across either side of the Inverse-Einstein test: those processes that focus ensuring that the same actions lead to the same results, versus those processes that focus more on skills-development, such that we can achieve the required variation in similar contexts or the required ‘sameness’ in different contexts. In very quick summary:

• improvement on the left-side (‘order‘) will focus primarily on efficiency (typically described in quantitative terms, and often regarded as synonymous with effectiveness)
• improvement on the right-side (‘unorder‘) will focus more on broad-spectrum effectiveness (with an emphasis on qualitative factors and human-concerns)

That order-versus-unorder partitioning is valid in itself – the Simple true/false methods used by machines and IT-systems, versus the full modality of methods available within skills-work. Yet it’s also in itself too simple, or too simplistic, rather: we need the framework to give guidance on skill itself.

This is where we come back to that question about reflection-processes that vary according to skill-levels. In essence, it’s not really a skill unless there’s some inherent-uncertainty involved in the context: before that, all the way over onto the Simple side of the spectrum, everything is literally mechanical, rule-based.

For this, we can turn to a cross-map of the SCAN frame with a spectrum of variability or predictability – shown as the blue curve in the diagram below:

The diagram is perhaps slightly misleading here, because the impact of variability doesn’t come out well enough: the blue line is itself another kind of continuous spectrum, rather than the Simple true/false implied by the colour-shading here.

[Part of the reason is that I don't yet know how to how to do multi-layer multi-colour graded-shading in Visio: accept it as it is for now, if you would?]

What is relevant here is the the way in which skills-development follows the same effective path of increasing variability – including that increased distance-from-action in the middle of that curve.

What we actually have in skills is not so much a Simple ‘either/or’ – Simple or Not-simple, order or unorder, as implied on the diagram – but more a ‘both/and’ mix of order and unorder. Higher levels of skill also implies or requires the ability to cope with higher levels of modality, variability and unorder. We can split this in terms of five distinct skill-levels:

• Robot: no skill as such – Simple rule-following only
• Trainee: low level of skill – mostly Simple / Belief, aware only of ‘here and now’, requires active supervision to cope with variability
• Apprentice: some level of skill, still primarily order-based but able to manage more Complicated / Assertion contexts with broader factors and feedback / feedforward loops, with some active supervision
• Journeyman: significant skill, able to cope with higher levels of Ambiguity and context-dependent Use, with supervision mainly in the form of mentoring
• Master: high skill, able to cope with inherent-uniqueness, balance of ‘big-picture’ with ‘here and now’, and ‘supervision’ only in the form of peer-review

So when we look at the ‘vertical’ improvement-processes implied by the SCAN frame, we tend to find that they work best when they act on specific mixes of order and unorder, sameness and uniqueness – in other words, in alignment with these skill-levels.

We can also see the classic ISO-9000 quality-system derivation-sequence at work here, between each of those steps:

• work-instruction: context-dependent rules used by Robot and initial Trainee – emphasis on What and How
• procedure (basis for new work-instruction): used by Apprentice and above, defined by Journeyman and above – emphasis on Who, Where and When
• policy (basis for new procedure): used by Journeyman and above, defined by Master – emphasis on Why
• unchanging-vision (permanent-anchor for quality-system, used as basis and cross-check for new policy): used by Master, defined by Master in peer-review – the ‘Because.’ behind the Why

There are many, many types of review / improvement-processes – PDCA (Plan, Do, Check, Act), for example, or AAR (After Action Review) or OODA (Observe, Orient, Decide, Act). Yet almost all of them have this ‘vertical’ character, to link:

• from real-time action – where there’s no time to think
• to distance-from-action – which creates thinking-space and review-space, to enable improvement
• then back to real-time again – to apply that improvement in real-world practice

There’s a usually a slight sideways-move in there somewhere – because wherever practicable the aim should be to enhance those skill-levels, not leave them solely as they are. But what we don’t want are ‘diagonal’ moves that try to link one type of order / unorder mix at ‘thinking-time’ with a very different mix at real-time – because it all but guarantees failure in practice. We’ll explore that point in more detail in the next part in this series: for now, we’ll focus more on the ‘verticals’.

We can again summarise these processes in terms of those five distinct skill-levels:

– Robot: Simple / Belief only (typically machines or real-time IT-systems) – aim is to optimise efficiency within a specific defined context

This is the classic realm of Taylorist time-and-motion study, of Six Sigma and suchlike: if we assume that everything in the work-context remains the same, what can we do to improve the efficiency of that ‘sameness’?

The crucial point here is that the Robot can only follow the rules that it’s given: it can’t change anything by itself – or even adapt to any significant change in its context. The Robot must rely on an external ‘expert’ to redefine its rules whenever the context undergoes any significant change, yet the ‘expert’ does not have to deal with real-world consequences: a fact which, if misused, can lead to a dangerous co-dependent relationship between Robot and ‘expert’, based on mutual evasion of responsibility – something that we see far too often as an outcome of dysfunctional blame-based management-structures.

– Trainee: Simple / Belief <-> Complicated / Assertion – aim is to develop ‘rule-following’ efficiency and to develop awareness of the ‘larger picture’, to place own work in context, and to begin to cope with variability

We typically see two types of review-processes here. One type concentrates on practice – embodying ‘the rules’ through constant repetition, mainly focussed on method, on the ‘what’ of those rules as applied to real-time action. The other type, typified by the US Army’s ‘After Action Review’, begins a focus on enhancing personal ‘response-ability’ – a concern that will continue all the way through the skills-development sequence.

– Apprentice: Complicated / Assertion <-> Simple / Belief (with some bridge over to Ambiguous, e.g. via experimentation) – aim is to develop ability to use formal-theory to redefine own rules as the context changes

This is the classic realm of formal education, with an emphasis on theory and on the mechanics of the skill, the ‘how’ behind its processes and methods. However, the focus is almost more on ‘order’ than at the Trainee level, defining rules as ‘objective truth’ to be applied by others in real-time action. The main contextual-shift is a developing awareness of more and more Complication in those ‘rules’ – a layering nicely described by Jack Cohen and Ian Stewart as an increasing sophistication of “lies-for-children” – in which additional factors, interaction-loops and delay-impacts are added to the rule-definitions. One of the hardest parts of this stage is re-simplifying these ever-more-complicated algorithms and ‘rule-sets’ down to a form that can be used in real-time action…

– Journeyman: Ambiguous / Use <-> Not-known / Faith (with some bridge over to Complicated, e.g. as ‘applied science’) – aim is to enhance ability to work with increasing levels of variation and near-uniqueness, such as by applying patterns and guidelines

This is typified by the crucial shift in awareness that theory alone is not enough: in the real world, ‘truth’ is often highly contextual. This is the realm of ‘real’ complexity, of emergence, of iterative exploration and experimentation, and also a more explicit acknowledgement of the inherent unorder that underlies wicked-problems and the like. It’s also a realm of probability and improbability – hence a strong focus on concerns such as the uncertainties of statistics, on kurtosis-risks, long-tail opportunities, and so on.

[Note the danger of failure to understand the probabilistic nature of statistics - that they always embed and embody some degree of unorder and uncertainty. It has its rules, but they're not the same order-based rules as in the Complicated domain: for example, it's true that chaos-mathematics can enable us to be very precise about the degree of uncertainty in a context - but it does not remove the uncertainty itself. Another important 'You Have Been Warned' that we need to pass on to our architecture-clients?]

There would also be a stronger emphasis here on guidelines and patterns, and on what we might describe as the approaches to each skill – the unorder of the ‘other mechanics’ of the skill, such as in the psychological and emotional drivers, and in ergonomics and individual difference. Continuing and expanding the theme of the After Action Review, this is the realm of responsibility-oriented continuous-improvement processes such as PDCA and kaizen, of simulators and ‘sandboxes’ and other ‘safe-fail’ learning-spaces, and also of context-exploration tools such as the skills-labyrinth.

– Master: Not-known / Faith <-> Ambiguous / Use – aim is to enhance effectiveness, being able to work with any level of variability and uniqueness at real-time, in line with overall vision and values

It’s at this level that we return to real-time practice, but this time aiming to be able to work with unorder, rather than fight against it (or even pretend that it doesn’t exist…), as in the rule-based assumptions of the Robot space. Here there’ll be a strong emphasis on enhancing capability for improvisation, and for coping with inherent uncertainty, such as with innovation and with Black Swans and other opportunities and risks at the extreme end of unorder. For skills, this would also bring together the previous themes in active acknowledgement that method = mechanics + approaches – hence true skills are both same and different for everyone at every time. On a practical level, there’s also a strong emphasis on the use of principles, vision and values to provide a stable anchor for guidance amidst inherent-uncertainty.

[Notice that, again, all of the above sequence is recursive: we may well be at Master level in some skill-domain, but barely at Trainee-level in another - a fact that can at times be somewhat challenging... ]

Implications for enterprise-architecture

For enterprise-architects, there’s a lot to review here, because all of those items need to be in place if the overall architecture is to work well for the organisation and enterprise:

• services that bridge across the modalities of certainty and uncertainty in real-time action
• services that bridge between certainty and uncertainty in planning for action and reflection on action
• services that improve how we apply certainty in action, how we work with uncertainty in action, and the skills of each person to work with these

We’ll need to identify each of these items, for each of the respective ‘horizontal’ and ‘vertical’ contexts; and wherever there are gaps in the needed support, identify what needs to be done to create and embed the respective items.

We also need to be aware of and act on some really nasty booby-traps that, if we’re not careful, can damage or even destroy the entire enterprise. Dysfunctional management-structures and misapplied Taylorist ideas are well-known examples of these: the real problem there is that the illusion of ‘control’ is so comforting to so many that these muddle-headed mistakes keep on coming back to bite us time and time again, like the proverbial ‘bad penny’.

Another serious danger that’s a bit more subtle can arise from those seemingly-relentless demands to do more and more, faster and faster. Part of this is that the sheer pressure to produce can cause a disconnect between strategy and tactics and even between tactics and operations: when everything has to happen now, there’s no time to think about what’s being done, or why. Not a good idea…

But a corollary of that is that if there’s no time to think, there’s also no time to develop skills – a point which again is made clear in that cross-map between SCAN and the variability-curve above. All too often we’ll come across an organisation that in essence consists of Masters and Robots (such as machines or IT-systems, or ‘crowdsource’ structure such as Mechanical Turk which in effect treat real-people as Robots), with nothing in between – perhaps a few Trainees to do the grunt-work, but that’s about it.

There’s little question that this can be highly profitable in the short term. Yet it’s a model that, almost by definition, cannot and does not scale – hence the constant complaints we see about ‘skills shortages’ and the like – and why so many startups seem to crash-and-burn so soon after their first flush of sweet success. And if there’s no means within the organisation’s architecture to develop those skills, there’s also no way to learn the contextual information needed to create the next generation of Masters – see the post ’Where have all the good skills gone?‘. Ignoring the skills-development issues may seem profitable at first, but it’s actually a guaranteed path to commercial suicide. Once again, You Have Been Warned?

Anyway, enough for now: more on this and other related themes in the final post in the series.

Any comments or questions so far, anyone?

How is it that what we actually do in the heat of the action can differ so much from the intentions and decisions we set beforehand? How can we bring them into better alignment, to ’keep to the plan’? And how does this affect our enterprise-architectures?

This is Part 2 of this exploration: the first part is in the post ‘Decision-making – linking intent and action [1]‘. (Once again, please note that this is ‘work-in-progress’, so expect rough-edges and, uh, partly-baked ideas in various places?)

What we ended up with the previous post is that we what we do want is strong ‘horizontal’ connections across the modalities at the same time-distance to action, and strong ‘vertical’ connections across the time-scales at the same modality:

What we usually don’t want – unless intentionally, and with considerable extra care – is ‘diagonal’ connections across both timescale and modality in the same link:

The key point for architecture is that at the moment of action, no-one has time to think. Hence everything that we build in the architecture to support real-time action also needs to support the right balance between rules and freeform, belief and faith, in line with what happens in the real-world context.

It needs to ensure that we have the right sets of rules for action when rules do apply, and the right experience such that the fallback into faith is as effective as possible whenever the rules don’t apply.

What this implies is that, within the architecture, we’ll need to include:

• services to support each sensemaking/decision-making ‘domain’ within the frame
• services to support the ‘vertical’ and ‘horizontal’ paths within the frame
• governance (and perhaps also services) to dissuade following ‘diagonal’ paths within the frame

It also implies the need for a radical rethink of ‘command and control’ as a management-metaphor, which is where we finished in the previous post. What we’ll turn to here is the other items in that list immediately above.

Before we start, though, one important point to note: all of this is recursive. For sanity’s sake, I’ll need to keep things as Simple as possible here, using bullet-point lists and the like: but in reality all of it is also Complicated, Ambiguous and None-of-the-above – and each of those aspects likewise has components that are simple, not-so-simple and so on. It’s clear-cut and simple, and it’s blurry and messy – all of it recursive, ‘self-similar’ and different, all at the same time. Which gets more than a bit complicated or complex or even chaotic if we try to describe it all in one go…

So for now I’ll take the easy way out: I’ll aim for just a brief-as-I-can-make-it summary, and go into more detail where necessary in later posts. Or you can ask for clarification in comments here: it’s up to you. Point is that, of necessity, this is only scratching the surface: I’m well aware that it ain’t as Simple as I may make it seem, and I’ll trust that you’re aware of that too.

On services to support each domain:

For this section we’ll explore both sensemaking (left) and decision-making (right) together:

In both cases, the domains here split into two distinct sets, ‘horizontally’ either side of the Inverse Einstein test:

• on the left-side (‘order‘), our sensemaking and decision-making tactics (Simple / Complicated, Belief / Assertion) assume that things are predictable – and hence that doing the same thing should lead to the same result
• on the right-side (‘unorder‘), our sensemaking and decision-making tactics (Ambiguous / Not-known, Use / Faith) assume that things may not be predictable – and hence that doing the same thing may lead to different results, or achieving the same results may require doing different things

The vertical distinctions between the domains are often rather more subtle, but it’s crucial that our architecture does provide support right down to the exact moment of action. We need to make a point of this, because there’s an all too common tendency to assume that what works well distant-from-action – Complicated analysis and Complex experimentation, for example – will also work well at the point of action. Yet as the old joke warns us:

In theory there’s no difference between theory and practice. In practice, there is.

‘Distant-from-action’ and real-time action are related, yet qualitatively different, in much the same way as Newtonian physics differs from quantum-physics. Hence these pairs of domains in the ‘vertical’ dimension as well.

So: order-domains:

What support do you have for Simple sensemaking: ordered, ‘controlled’, at real-time? What kinds of sensemaking are needed within the work at or close to the exact moment of action?

• examples: checklists, comparison-charts, mechanical sensors, real-time signals

What support do you have for Complicated sensemaking: ordered, ‘controlled’, predictable, but some distance away from real-time – either before the event as preparation, or after it, to make sense of what happened? What different types of support do you need for different ‘distances’ from real-time, from seconds to minutes to hours to days to months to years to decades and beyond?

• examples: analytics, dashboards, computational filters, aggregation

Going back the other way, from sensemaking to decision-making:

What support do you have for Assertion-based decision-making: decisions that assume the existence of order, ‘control’, predictability, yet also are some distance from – usually prior to – the moment of action? What different types of support are needed over the different timescales that we might describe as strategic, tactical and operational?

• examples: algorithms, hard-systems theory, computation or business-rules IT-systems

What support do you have for Belief-based decision-making: real-time decisions based on certainty, on rules, on assumed predictability? In what ways does this decision-making differ when there’s no time to think, no separation between decision and action?

• examples: rule-sets, rote-learning, step-by-step checklists and work-instructions, physical machines, real-time IT

And: unorder-domains:

What support do you have for Ambiguous sensemaking-contexts: some distance from the action, yet still known-uncertain? What different types of support do you need before and after action, and for different ‘distances’ from real-time?

• examples: experimentation, pattern-matching, statistics, trend-analysis, futures techniques, crowdsourcing

What support do you have for None-of-the-above sensemaking-contexts: right at the moment of action, yet inherently uncertain in some or all aspects? What kinds of sensemaking need to take place here?

• examples: listening, ‘flow‘, managing panic, social structures for ‘safe to fail’

(Note that most of that last set of examples would address not so much the sensemaking itself, but providing appropriate conditions for real-time sensemaking in inherent-uncertainty.)

From sensemaking to decision-making:

What support do you have for Use-based decision-making: decisions that are some distance from the action, yet do not assume certainty or predictability? What different types of support are needed over the various different timescales of distance-from-action?

• examples: patterns, guidelines and values, soft-systems theory, prioritisation, probability and necessity (modal-logic), social methods (from meetings to voting-systems etc)

What support do you have for Faith-based decision-making: decisions that must be made in the heat of the action in the midst of inherent-uncertainty?

• examples: principles (i.e. actionable values), skills and experience, context-design to maximise safe-fail or ‘graceful failure’, trust in ‘that which is greater than self’

(That last item is by far the hardest to describe, but it’s a key reason why I use the term ‘Faith’ here. I suppose this might perhaps be a kind of ‘hive-mind’ effect, but the point is that decisions here will often carry a feeling of ‘it was the right thing to do’, an ‘intuitive’ decision that aligns with a broader collective-purpose without conscious knowledge or certainty of how it does so. Deep familiarity with shared principles and values is a known key driver and anchor for this type of decision-alignment – hence their importance as and at the core of an enterprise-architecture.)

Review those lists above: which of those items would you currently include in your enterprise-architecture or process-architecture? Most conventional architectures will describe only the left-side (‘order’) items – yet support for all of these forms of support will need to be in place for the enterprise and its architecture to work well. Note any gaps in the architecture, and, even more important, gaps in support; and then move on.

In the next part of this series we’ll explore the architecture of how we link all these domains together. Any questions for now, though? Over to you, anyway.

How is it that what we actually do in the heat of the action can differ so much from the intentions and decisions we set beforehand? How can we bring them into better alignment, so that we do ‘keep to the plan’, at the individual level, and across the enterprise? And once again, what implications does this have for our enterprise-architectures?

This extends the previous posts on SCAN sensemaking and real-time decision-making, ‘Belief and faith at the point of action‘ and ‘Decision-making – belief, fact, theory and practice‘, this time to explore the linkage – or lack of it – between ‘considered’ decision-making and real-time decision-making.

[As before, most of this is 'work-in-progress', so be gentle with it, okay? It should be usable as-is, but do expect odd gaps, rough-edges and wobbly-bits in various places, and please give constructive feedback where you can. Thanks!]

We started from the SCAN sensemaking-frame:

And reviewed it from a perspective of decision-making rather than sensemaking:

It’s actually the same frame, so the two axes are the same in both views:

• a ‘horizontal’ axis of modality of sensemaking and decision-making, from simple true/false on the left, to infinite-possibility on the right
• a ‘vertical’ axis of time-to-decision or time-to-action, stretching from a real-time ‘now!‘ to a potentially-infinite future (and some symmetry with time-from-decision etc, into the past)

The vertical-axis is essentially continuous, but the horizontal-axis has a distinct phase-shift where the modality of decision changes from a simple-true/false [0..1] to an open n-ary [0..n] choice. To the ‘left’ of this point, the apocryphal Einstein dictum applies: doing the same thing should lead to – or is believed to lead to – the same results; whereas to the ‘right’ of that point, doing the same thing may lead to different results, or doing different things may lead to the same results.

On the left-side, there is what purports to be ‘objective certainty’; on the right-side, there is, by definition, some degree of inherent-uncertainty, always somewhat context-specific, and often somewhat personal and subjective. A conventional ‘control’-based concept of the world assumes that everything can somehow be forced onto the left-side of the frame; Reality Department and real-world practice indicates that such concepts of ‘control’ are still wishful-thinking at best, and that alternate decision-strategies must be available, dependent on context.

Hence one of the key tasks of an enterprise-architecture is to ensure that all required decision-methods are supported, and also ensure that appropriate methods are applied to each context.

The previous post, ‘Decision-making – fact, belief, theory and practice’, mainly looked the ‘horizontal’ dimension of this frame; here we’ll explore the impacts of the ‘vertical’ dimension – specifically, the separation between intent and action.

Read more…

A kind of announcement, really: a knowledge-base wiki for whole-enterprise architecture is now available and ready for content and use.

I’ve given it a temporary home on my Sidewise server:

• http://ea.sidewise.biz

No doubt it should have a proper domain of its own, but that’ll do for now to get us started.

[By the way, this is another follow-up to my post 'Helping others make sense of my work' - the need for a wiki was a suggestion that came up several times in the comments there.]

It’s a fairly straightforward wiki, based on the WikkaWiki framework – probably the cleanest and simplest wiki-framework I’ve come across. (I’ve struggled with many such frameworks over the years, of which Wikipedia is almost the worst…) Like all wikis, though, it does have its own quirks, hence some quick comments:

– Anyone can read, write or comment. (That’s the default: there’s actually a full access-control system for read, write and comment, all the way down to individual page-level, but that’d take too long to explain here.)

– However, to write, comment or edit, you’ll need to register a user-account. (There’s no charge for this, of course, and should be no privacy-implications: it’s just to stop spam-bots using the site.) There’s a quick summary on how to do this on the wiki home-page.

– One minor ‘gotcha’ is that user-names need to be in wiki-format – what’s known as ‘CamelCase’, beginning with a capital-letter and with at least one additional capital-letter after the start. For example, my user-name is ‘TomG’; you might make yours ‘FredBloggs’ or VikusVdM’.

– Editing is straightforward: click the ‘Edit’ link on the left side of the page-footer, or double-click on the page itself. The ‘Store’ (save) and ‘Preview’ buttons are at the lower-left when you’re editing.

– Formatting is a lot simpler than most wikis: in many cases it’s two repeated-characters. See the ‘Wiki formatting guide’ that’s linked from the home-page. Links are straightforward: ‘[[', then the page wikiname (internal link) or URL (external link), then a space as separator, the link-text, and ']]’.

– Usefully, a page can include a FreeMind-format mindmap: paste the FreeMind XML into the edit-space as the page-content. Read-only, unfortunately, but it’s an easy way to share mindmaps.

– Upload of images and other files is a bit more difficult, and at present only administrators can do it. I’ll hack the code as soon as I can, to allow a broader range of users to upload, but in the meantime, if you want to upload a file, send it to me and I’ll upload it for you.

I’ve put up some initial content to get started – a few dozen definitions, a couple of articles, and a whole load of links to other posts elsewhere – and I’ll continue putting more material up there over the next few days and weeks. But the rest is up to you, really: it’s everyone’s site, not just mine.

Anyway, it’s there, and usable: over to you?

In what ways do ideology and experience inform decision-making in real-time practice? How do we bridge between the intentions we make before and after action, with the decisions we make at the point of action itself? And what implications does this have for our enterprise-architectures?

This extends the previous post on real-time decision-making, ‘Belief and faith at the point of action‘, to crosslink with the earlier ideas on SCAN and sensemaking, and especially about where there is more time available to review and reflect on action.

[A gentle warning and polite request: much of this is still 'work in progress', so do beware the rough edges and knobbly bits, and use it with some caution; and whilst I do need critique on this, please don't be too quick to kick down the scaffolding that's holding it all together. Fair enough?]

The previous post was about how options for sensemaking become more constrained as we approach real-time. Right at the point of action, the options reduce to either a Simple interpretation in terms of of true/false categories, versus a Not-simple interpretation based on a modal-logic of possibility and necessity, which is much harder to explain or even to describe to anyone else. In SCAN we’d depict that compression as follows:

In much the same way, decision-making becomes compressed down to Simple belief versus Not-simple faith – neither of which are actually explainable, and both of which, at the root, are primarily emotional rather than ‘rational’:

In both sensemaking and decision-making, the crucial distinction – indicated in SCAN by where the red-line time-axis crosses the green-line axis of decision-modality – is what I’ve termed the ‘Inverse Einstein test’. Einstein is said to have asserted that “insanity is doing the same thing and expecting different results”: but whilst that’s true in a simple rule-based world, it’s not true – or not necessarily true, anyway – in a more complex world where many things are context-specific or even inherently unique.

So our ‘horizontal’ test is this: if doing the same thing leads to the same results – or is believed to lead to the same results – then it’s a Simple decision; if doing the same thing leads to different results, or if we need to do different things to get the same results, it’s Not-simple.

[Yes, I do know that that's a Simple true/false distinction across a spectrum that in reality is fully modal. If you want to apply the appropriate recursion here, please feel free to do so: I thought it wisest here to keep it as simple as possible, because this can get complicated real fast, and unless we're careful to keep the complexities at bay we could end up with a right old chaos of confusion. Which is, yes, yet another recursion... Hence best to keep it simple for now, as best we can, acknowledge that much of it isn't Simple, and allow the recursions to come back in later when there's a bit more space to work with it.]

The crucial point about real-time is that there’s no time available for a distinct sensemaking-stage: decision links directly to action, and vice-versa. (That’s why it’s called ‘decision’: the same linguistic roots as ‘incision’, it’s literally ‘cutting away’, ‘cutting apart’, the cutting-edge for action in the ‘now’.)

For sensemaking to take place, there must be a gap in time between one decision to the next. The key to John Boyd’s ‘Observe, Orient, Decide, Act’ (OODA) loop – which, importantly, is also not a loop as such – is that it still allows distinct sensemaking (‘Orientation’) to take place, but keeps it as close to real-time as possible: that’s what’s meant by ‘getting inside the opponent’s OODA loop’.

As time-available – the red-line ‘vertical’-axis in SCAN – extends outward either side of real-time, the OODA-’loop’ can become recursive, and thence, given enough time, simplified-out to a Deming-style ‘Plan, Do, Check, Act’ (PDCA) continuous-review cycle, such as is also implied in the US Army’s ‘After Action Review‘:

• “What was supposed to happen?” – what was our Plan?
• “What actually happened?” – what did we Do?
• “What was the source of the difference?” – what do we need to Check?
• “What do we need to do different next time?” – about what do we need to Act?

As I’ve described in other posts, sensemaking-choices tend to split as described in SCAN: there’s a ‘bump’ on the path, indicated by the jump between simple true/false logic versus fully-modal logics of ‘possibility and necessity’ on the ‘horizontal’ axis, contrasted with a much smoother spectrum of choices as available-time extends in the ‘vertical’-axis. Although the ‘vertical’ boundaries are less clear-cut than the ‘horizontal’ ones, this gives us the four SCAN quadrants – Simple, Complicated, Ambiguous, Not-Known:

Those distinctions determine the appropriate tactics for sensemaking, as described in those earlier posts.

Decision-making seems to follow a similar, closely-related pattern – though that’s the part I’m having trouble pinning down right now.

[Boyd's OODA is in part another attempt to pin down the same relationships; likewise Snowden's Cynefin, if rather less so. Jung's frame of 'psychological types' is probably a closer fit than Cynefin for this: I've used a generic decision-types adaptation of it for some decades now, though it's still not quite right. Hence this exploration here.]

So again, it’s ‘work-in-progress’, but this is where I’ve come to at present:

It’s a decision-making frame based on the same horizontal (decision-modality) and vertical (time-available) axes as in SCAN, and hence the same sort-of-quadrants but with a decision-oriented re-labelling: Belief (Simple), Assertion (Complicated), Use (Ambiguous) and Faith (Not-known).

On the left-side of the Inverse-Einstein test, the mechanism that links Assertion and Belief is a drive for certainty, for ‘control’. On the right-side, linking Use or ‘usefulness’ with the real-time openness of Faith, is more a focus on experience, underpinned by a deeper kind of trust – a trust which is often conspicuously absent in any concept of ‘control’.

[For this post I'll focus more on what happens across the horizontal-axis, the relationships between theory and practice, or 'truth' versus 'usefulness'. I'll explore more closely the interactions along the vertical-axis - between what we plan to do versus what we actually do - in a following post.]

In terms of decision-making tactics:

• on the left-side, theory takes precedence over practice – or, in some contexts, ideology rules, which is much the same
• on the right-side, practice takes precedence over theory

In essence, this is CP Snow’s classic ‘The Two Cultures‘, the sciences (left-side) and the arts (right-side). Notice, though, that technology sits on the right, not the left: it uses theory, but that isn’t its actual base – hence the very real dangers in the often-misleading term ‘applied science’.

Bridging the gap, from left to right, is praxis,”the process by which a theory, lesson, or skill is enacted, practised, embodied, or realized”; and from right to left, is pragmatics, “a process where theory is extracted from practice”. As enterprise-architects would be all too aware, the latter always starts from pragma, from “what is expedient rather than technically ideal”: and it usually includes the joys of ‘realpolitik’, of carefully filtering reality to fit in with other people’s prepackaged assumptions…

That boundary denoted by the Inverse Einstein Test is all too real: whether the beliefs in question are ‘scientific’, religious, political or whatever, the ‘need’ for certainty will often trigger huge resistance against anything that doesn’t fit its assumptions. For example, there’s a very close mapping between this frame and the classic scientific-discovery sequence of idea > hypothesis > theory > law, which align with Faith, Use, Assertion and Belief respectively.

In real scientific practice, it’s not a linear sequence, there’s a lot of back-and-forth between each of the steps. And in principle, it should be a continuous-improvement cycle, a broader-scope form of PDCA. But as Thomas Kuhn and many others have documented, that same ‘need’ for certainty often places a near-absolute barrier between supposed ‘scientific law’ and any new ideas – in other words, between Belief and Faith – that brings that cycle to a sudden halt, sometimes for years, decades or even centuries. All too often, in practice, if we take the real-time ‘short-cut’ from Belief to Faith, we will be forcibly forbidden to return along the same path: instead, we’re forced to go ‘the long way round’, via Use and Assertion (hypothesis and theory) – which we may not have time to do. Which is a very real problem. And one that applies as much in enterprise-architecture as in any other field – as we’ve seen with the inane IT-centrism that has dominated the discipline for far too long.

It gets complicated…

What I’ve been seeing, as I’ve explored this frame, is a whole stream of often-subtle misunderstandings and ‘gotchas’ that I’ve noticed time and again in practice in enterprise-architecture and elsewhere. These seem to be where many unnecessary complications and confusions arise – so it’s worth noting them here.

For example, fact arises from experience: its basis is on the right-side of this frame – not the left. What’s on the left-side often purports to be fact: yet it’s not fact as such, but interpretation of fact – a very important difference. The left-side operates on information, an interpretation of raw-data – but it often has no means to identify the source or validity of that information, or its method of interpreting it. (This is the same inherent problem whereby a logic is incapable of assessing the validity of its own assumptions: by definition, it must call on something outside of itself to test those premises.) So on the left-side, there’s actually no difference between ‘real’ and ‘imaginary’ – which can lead to all manner of unpleasant problems if the left-side is allowed to over-dominate in any real-world context…

Importantly, there’s no real difference here between ‘objective’ versus ‘subjective’: that distinction is actually another dimension that’s somewhat orthogonal to this plane. What I feel, or sense, is subjective, but it’s still a fact; whereas how I interpret that feeling or sensation is not a fact – it’s an interpretation. Telling someone that they should or shouldn’t feel something is just plain daft: the feeling itself is a fact – something about which we don’t actually have any choice – whereas the ‘should’ is an interpretation arbitrarily imposed by someone else.

[What we do in response to a feeling is a choice - literally, a 'response-ability' - and is something that can be guided by 'shoulds' and the like: but not the feelings themselves. That's a very important distinction which, sadly, surprisingly few people seem to understand...]

There is a specific sense in which subjective versus objective aligns somewhat with the ‘less-time’ versus ‘more-time’ on the SCAN vertical-axis. More-time means more time available for experimentation and analysis – and that can allow us to identify what’s shared (‘objective fact’) across many people’s experience, versus experiences that are more specific and personal (‘subjective fact’).

But there seems instead to be a tendency to conflate the objective/subjective distinction with the SCAN horizontal-axis – objective-fact as ‘truth’ on the left-side, subjective-fact as ‘not-truth’ on the right-side. There are ways in which that conflation can work – it’s at the core of the Jungian frame, for example – but we need to be careful about it. Using that conflation to dismiss all subjective-fact as ‘irrelevant’ – as the classic ‘command and control’ models would do – not only makes no sense at all, but is extremely unwise in real-world practice…

There also several other key distinctions across either side of the Inverse-Einstein test:

– ‘science’ versus technology, which also parallels ideology versus practice: on the left-side, there’s an assertion that something is ‘true’, whereas on the right-side we proceed as-if it’s true – which is not the same at all.

– organisation versus enterprise: the nature of an organisation is that it’s about left-side themes such as control, beliefs, repeatability and certainty; the nature of an enterprise is that it’s not certain, “a risky venture” and suchlike – with all that that implies.

– structure versus story: most structures within current enterprise architectures will, again, have a left-side focus on providing repeatability and certainty; story and other forms of narrative-knowledge provide an alternate kind of ‘structure’ that holds many of the right-side themes together

– sameness versus uniqueness: another key enterprise-architecture theme, sameness and repeatability is very much a left-side theme, whereas uniqueness is just as much a right-side theme

– ‘best-practice’ versus ‘worst-practice’: the notion of ‘best-practice’ assumes that practice that worked well in one context will be directly applicable to another, the same success repeatable in another; by contrast, maintenance engineers and others who work extensively with unique or near-unique contexts share their learning more through ‘worst-practice’, stories of what didn’t work in a given context. (I think I first heard that one from Dave Snowden? – credit where credit’s due, anyway.)

The trade-offs across each of these dichotomies all have direct implications for the design and structure of any enterprise-architecture.

Implications for enterprise-architecture

Take a look at those dichotomies again: which side do you think is emphasised by current enterprise-architectures?

The obvious answer is that, almost invariably, the left-side is given priority over the right.

However, this has huge consequences for the effectiveness of the overall enterprise, and for the enterprise-architecture that describes it:

• interpretation takes priority over fact: never a good idea…
• theory and ideology takes priority over practice and experience: that’s almost a definition of (misused) Taylorism…
• the need for (spurious) ‘certainty’ and ‘control’ takes priority over trust of anything or anyone: ditto on Taylorism…
• the reliance on true/false decision-methods can render the organisation unable to cope with any form of uniqueness
• the need to force-fit everything into sameness of content – ‘best practice’, IT-centric BPR and the like – fails to grasp the differences of context
• the over-focus on organisation – ‘the letter of the law’ – literally kills off the spirit of enterprise…

Look at most of our existing EA toolsets, too: can you find any toolset that’s actively designed around anything other than true/false logic? Other than in rare model-types such as ORM (Object-Role Modelling), there’s no means to describe modality in relationships – hence, for example, no directly-supported way to describe a usable reference-model that allows for real-world ifs, buts and perhapses.

And whilst every toolset focusses on structure – and most do that very well, too – how many of those toolsets also help us to focus on the counterpart of story? They might support few use-cases, perhaps, but that’s about it: there’s a huge gap in capability there…

What we need, urgently, is a better balance between structure and story, between theory and practice, between organisation and enterprise. And without adequate support in the toolsets, that means that we have to create that balance ourselves.

The crucial point is that this balance is not an ‘either/or’, but a much more modal ‘both/and’:

• theory and experience
• ‘objective’ and ‘subjective’
• ‘science’ and technology
• certainty and trust
• true/false and fully-modal
• organisation and enterprise
• structure and story
• sameness and difference
• ‘sense’ and ‘nonsense‘
• certainty and uncertainty

We will only achieve a real effectiveness in the architecture via a fully-nuanced ‘both/and’ balance across all of these dimensions, and more.

So take a careful look at your own organisation, your own enterprise-architectures and the like: where is it out of balance, in this sense? In SCAN terms, how much does it over-emphasise the left-side at the expense of the right-side? And what can (and must) you do to bring it back into a better balance overall?

Comments/suggestions/experiences on this, anyone?

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.

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…

I’m currently sifting through my past blog-posts of the past five years or so, with a view to republishing some of them in ebook-format, to make them more accessible in a more convenient and more portable form.

So far there are well over 400 blog-posts here on enterprise-architecture and related themes, plus a few more on the companion Sidewise weblog. That’s a lot of material – probably somewhere upward of half a million words, with literally hundreds of diagrams as well. Kinda big, even in EPUB format, and not easy to navigate in one go, given that that the various themes have been weaving through each other in different forms and with different emphases over the years.

So the idea at present is to publish them in the form of small anthologies, each of perhaps 15-30 related posts that focus on a single theme at a time. Some posts might appear in more than one anthology, but that probably won’t matter too much, I hope? – especially as keeping it simple will keep the costs right down, to perhaps $2.00-3.00 (£1.50-2.00) each.

Themes for the first few anthologies would include:

• the Enterprise Canvas set, including the simplified notation for Enterprise Canvas
• rethinking Zachman and the TOGAF ADM for whole-enterprise use
• foresight, futures and ‘really-big-picture’ enterprise-architecture
• the human side of enterprise-architecture, including management-structures and tacit-knowledge
• narrative and story in enterprise-architecture
• business-architecture and enterprise-architecture (including ‘translation’ between Business Model Canvas and enterprise-architecture notations such as Archimate and Enterprise Canvas)
• taxonomy, ontology, (meta)metamodels and toolsets for enterprise-architecture
• sensemaking with context-space mapping and SCAN

These should start to appear on Amazon and elsewhere in the next few weeks – I’ll post more details here as they become available, of course.

Any other requests for ebook anthologies? Any comments about pricing, formats, availability or anything else? Over to you, if you would?

Many thanks, anyway.