Tom Graves / Tetradian

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.

In case you’ve been wondering why I’ve been ranting about those apparently-abstract ideas about ‘Possessed by possession‘ and the like…

What I’ve been calling ‘Really-Big-Picture enterprise-architecture‘ is about looking at how we can apply enterprise-architecture ideas at a much larger scale, right up to a fully global scope. The simplest way to describe this is as follows:

• every society or culture is held together by mutual responsibilities
• in some (but not all) societies, there may be an overlay of personal possession
• arising from this concept of possession is a notion of property rights
• to support exchange of personal property in accordance with property-rights, we have point-to-point barter
• to resolve the point-to-point nature of barter, we introduce an intermediary currency
• to support futures in a currency-based economics, we introduce the idea of debt-based finance
• to support certain types of debt, we introduce financial-derivatives

All straightforward, all non-pejorative, a simple stack of overlays, each one built on top of the previous layers. We could summarise it visually like this:

There’s only one catch: it doesn’t work.

Most people realise by now that there are huge problems with financial-derivatives and the like: anything that is potentially-infinite that claims to have absolute rights over something that’s definitely finite is by definition going to be problematic. But that isn’t the core problem that we have to deal with.

Debt-based finance is a problem: it tends by definition to concentrate all wealth in the hands of those who control the mechanisms of debt. But that too isn’t the core problem that we have to deal with.

A lot of people argue that the problem lies with the currency: if we could switch to an alternate-currency, they say, everything would work out just fine. There are huge arguments about what kind of currency we should move to – time-based, ‘local energy’, reputation-points or whatever. But the reality is that all of those arguments are almost completely irrelevant, because currency itself isn’t the core problem that we have to deal with.

Some people say that we should drop the whole currency-thing, and go back to barter. But the point-to-point nature of barter causes huge problems, which in many ways currency does help to resolve. But in any case, barter isn’t the core problem that we have to deal with.

Quite a few people say that the real issue is around property-rights. Capitalists and communists alike will argue intensely over who has the right to possess, and who doesn’t. But this misses the point too, because property-rights in themselves aren’t the core problem that we have to deal with.

The real problem is the concept of possession – because that’s what breaks the mutuality of responsibilities on which a sustainable society and its economics depend. Possession is a literally childish view of an economy, one which asserts the primacy of ‘I’ over ‘We’. It’s a view which asserts that that the only thing that matters is my own needs and desires, that I am not responsible to others, either in the present or elsewhen – yet still insists that they are and must still be responsible to me. The reality is that the moment we allow that kind of pseudo-mutuality to exist, by definition we have a broken economy: there’s no way we can make it sustainable – especially over the longer-term.

Imagine an economy that’s run by, for and on behalf of the most childish in the society, and in which anyone who does take responsibility is punished for doing so. That would be insane, wouldn’t it? – in every sense of ‘insane’… Yet what we would have there is something remarkably similar to what we think of as ‘the economy’ in the present day – an ‘economy’ that’s ultimately based on the possessive self-centred temper-tantrums of a two-year-old…

Yet the fact is that anything based on a possession-model will tend automatically to create dysfunctional failure, to not only invent a status of ‘rich’ or ‘poor’ but an ever-widening gap between them, to always assign far higher priority to the present than to future or past, and to create a ‘trickle-up’ pyramid-game structure that can only appear to work as long as it can maintain an illusion of infinite ‘growth’ – because if the growth ever stops, its only option is to cannibalise itself into oblivion. There is no possible way to make a possession-based economy sustainable.

Which means that we have a rather serious problem. If possession doesn’t work – and not only doesn’t work, but by definition can’t work - and we need to move towards a truly sustainable economy – which, with seven billion humans and still increasing fast, we clearly do – then it means that we need to rethink not just possession itself, but everything that’s built on top of it. In short, every single one of those overlays is irrelevant, because they’re built on top of something that doesn’t work. Or, to put it in simple graphic form:

If the core problem is possession, then it should be evident that futzing around at any of the layers that are built on top of that myth of possession is not going to make any significant difference. It’s a waste of time, of effort, of everything else – a waste that we can ill afford right now, given the real inescapable all-too-literally ‘deadlines’ that we’re starting to face in the near future. Our only option is scrap the whole lot, and start again almost from scratch – because anything that retains any hint of possession in its structure will cause the whole thing to fail all over again.

And yet it’s scary just how much of our society and economics and the rest assume that possession is the only way to go. Just to give one small example: if “possession is nine-tenths of the law”, what does that tell us about what changes in law would be needed for a sustainable society? Not a trivial problem, yes…?

Yet I do believe that enterprise-architects have skills that could be genuinely useful for this type of challenge. We’re used to working at large scale, and at every scale, across every aspect of a whole system. We’re used to seeing how all of the different aspects come together to make a single unified whole. We’re used to doing roadmaps for change and suchlike – and the, uh, interesting politics that go with any large-scale change. What we have here is still enterprise-architecture, still the ‘big-picture’ – just a rather bigger picture than we’re used to, that’s all.

So that’s what I’m describing as ‘Really-Big-Picture Enterprise-Architecture’ – a form of enterprise-architecture where the ‘enterprise’ in scope is actually everything that happens and will happen in human activity on the entirety of the planet. In other words, probably the largest enterprise-architecture challenge that any of us will ever face. Interested?

Looking at your enterprise vision – or any kind of future intent – is it defined in terms of being for something? Or against something?

That distinction can sometimes seem subtle – yet it’s very important indeed…

On the surface, it always seems a lot easier to be ‘against’ something. Many NGOs define themselves this way; quite a few businesses will do so, too. Whatever it is that we’re against, it already exists – otherwise we wouldn’t be against it, would we? (In some cases what we’ll say we’re against is the risk of whatever-it-is occurring – in other words, it ‘exists’ only in imaginary form – but as we’ll see, this comes down to much the same in the end.) We want it to stop existing, or not exist: that’s the whole point. It’s real, definite, and wrong – because since we’re against it, it must be wrong. Which means in turn that, by definition, we must be right, we’re ‘in the right’. That’s a good feeling to have: certainty, righteousness, righting the wrongs of the world. Which creates a lot of emotion, a lot of drive. The kind of energy we definitely need in an enterprise-vision and the like.

But…

It’s all too easy for it to be subtly dishonest: we point the finger at others, blame others, show them up as ‘the bad guys’ – which means that, conveniently, there’s no attention placed on us, on how we also support that whatever-it-is that we say we’re ‘against’. (In fact, as Jung warns in his concept of the ‘Shadow‘, we may actually be the worst offenders here, using ‘Other-blame’ as a mechanism to avoid facing our own actions. For examples of this, look at the behaviour espoused or demanded by almost any ‘activist’-group that says it’s ‘against’ something, and compare that with the actual behaviour of that group in action…) Which also means that the only aspects of that which we’re ‘against’ is the parts that others do – not the parts that we do. After all, by definition, we’re ‘the good guys’, we couldn’t be doing anything wrong, could we?

Oops…

If we define ourselves as ‘against’ something, we then need that something to continue to exist, in order to be against it - otherwise we would have no apparent reason to exist. The more we succeed in being against it, the more we’ll find ourselves needing to re-create it, in order to still have something be against. Which, over time, leads us into the inevitable vapidity of the Shirky Principle: “Institutions will try to preserve the problem to which they are the solution“.

Oops…

In short, defining ourselves as ‘against’ something will feel strong, powerful, ‘good’; but it may well be subtly dishonest, and unfortunately it’s all but guaranteed to make things worse.

Not such a good idea, then…

Defining ourselves as ‘for’ something is usually a lot harder. For a start, it probably doesn’t exist as yet – in fact our aim would usually be to create it, to bring it into existence. But because it doesn’t exist, it’s not tangible, it’s often a bit amorphous, a bit blurry, uncertain. Because it doesn’t exist, we first have to imagine the possibility of its existence: and by definition, that can be a somewhat conceptual, abstract exercise. Which means that to make the intent emotive – which it needs to be – we first have to imagine the whatever-it-is, and then convert that imagination into emotion: which can be quite hard to do.

Tricky… definitely. But if we can do it, we can create something new, something valued, something we’re for – all literally ‘real-ised’ from nothing. It didn’t exist; yet when we succeed, it now does exist. That’s pretty impressive, when you stop to think about it.

So defining ourselves as ‘against’ something always seems the easier way: but it doesn’t work. Whereas being ‘for’ something may seem a whole lot harder, but it does work.

So whenever we define a vision or the the like, we need always to do so in terms of ‘for’, not ‘against’.

No doubt, though, that it is easier to start from a ‘being-against’. So to make it work, we need to convert – or invert – that initial ‘against’-definition into a ‘for’-type format.

For this, let’s use the example of workplace-bullying.

It’s easy to be against bullying in the workplace: very easy to see it as ‘bad’, ‘wrong’, ‘wicked’, and all the rest. Very emotive, obviously.

Yet it’s also all too easy to point to ‘Them’, ‘the bullies’ – and fail to notice how we ourselves do exactly the same… And being ‘against’ bullying typically means that the more successful we are in ‘naming and shaming’ the bullies (which, by the way, is itself a form of bullying…), the more we’ll need to keep hunting harder to find even the slightest scrap of bullying-type behaviour in others. Which leads, in time, to that style of bullying so typical of any form of ‘political correctness’; and from there, all too easily, to the workplace-equivalent of the Inquisition. Being ‘against’ slowly pushes us towards where we preserve – in fact become – the ‘problem’ to which we purport to be ‘the solution’. And yes, that really is what happens, time after time after time.

So to make it work, we need to turn it round: for, not against.

For this example of workplace-bullying, one place to start is not so much the undesirable behaviour, as the consequences of that behaviour. This is described well, for example, by Bob Sutton in his book The No-Asshole Rule: “After encountering the person, people feel oppressed, humiliated or otherwise worse about themselves”. If we’re against workplace-bullying, we would be against these consequences too, because they’re symptoms of the occurrence of bullying in the workplace.

So we now turn it round: what does a workplace look like if bullying isn’t happening? – because that’s actually what we’re ‘for’. So, for example, we might look at key themes of intrinsic-motivation, as described in Daniel Pink’s Drive: autonomy, mastery, and purpose. Or we might look at the ‘equality’ column in the gender-pronouns version or gender-neutral version of the extended-Duluth framework, for a broader range of desired behaviours and outcomes: this shows us emotive themes such as safety, trust, respect.

We can now apply to this to the three-part structure for enterprise-vision:

• a descriptor for the content or focus for this enterprise - the ‘things’ or themes that concern everyone in the shared-enterprise
• some kind of action on that content or focus - what is to be done to or with or in relation to those themes or ‘things’
• an emotive qualifier that validates and bridges between content and action - why this matters, why is this of importance and value

If we put all of that together, we’ll end up with something like “we are for creating workplaces where everyone feels safe, supported, valued and productive in their work”.

To achieve those outcomes, yes, we’ll have to address workplace-bullying and the like: but to do so we keep the focus on the desirable outcomes, and behaviours that create those outcomes (the ‘for’), rather than the undesirable behaviours that work against those outcomes (the ‘against’). And by saying that these desirable outcomes apply to everyone, we’ve also avoided the ‘Other-blame’ trap – which makes it easier to engage everyone in creating those outcomes.

[Avoiding 'Other-blame' is especially important in this case, by the way, because one of the most common causes why people indulge in bullying behaviour is because they themselves have been bullied by someone else.]

So, the one-line summary:

always frame an enterprise-vision, or any other statement of intent, in terms of what you’re for – not what you’re ‘against’.

Hope you find this useful, anyway.

Those notions of ‘whole-enterprise architecture’ that I’ve been describing in the ‘no-plan Plan‘ series of posts make solid sense to a fair few people – particularly those who’ve some experience of systems-thinking, design-thinking and the like. But it’s painfully clear that it doesn’t seem to make much sense to anyone else: and I must admit I’m struggling a bit with this…

How do we bring those different worlds together, so that we can put these ideas to practical use?

How do we make it make sense?

Okay, so part of the problem is the age-old clash between theory and practice. Practice needs theory; theory needs practice; that point seems fairly well accepted, I think? Yet there’s that old joke (from Yogi Berra?) that “In theory, there’s no difference between theory and practice. In practice, there is.” Which means that practitioners tend naturally to be somewhat wary of too much theory. And there’s the ‘time-compression’ problem as wel: right out the rough edge of real-time, people simply don’t have time to stop and think about theory. Yet the fact that they don’t look enough to theory may itself be a key reason why they don’t have the time…

Chicken and egg: which comes first – theory or practice? Yes… therefore no… sometimes…? How do we get out of that loop?

There’s also the “in a perfect world” excuse, as my colleague Marcus [not his real name] was bewailing the other day:

It’s just chaos out there, doing everything the hard way. But if I suggest anything to cut down on the chaos, even something really simple like using scripts in a spreadsheet, so that they could get a chance to get started, it’s always the same response: “yes, Marcus, in a perfect world, but…”, “that might work in a perfect world, but…”, “we could do that in a perfect world, Marcus, but in the real world…”.

What’s worrying was that this was the architects – the people who were supposed to understand IT-architecture. Worse, he said, they were hardly using any of their architecture tools to clean up the architecture: in fact, of the thousand licences for a high-end EA toolset that their corporation had paid for, they were actually using just six.

Sure, many people are running on extreme overload most of the time; but with these guys, and many others like them that I’ve dealt with in so many different disciplines over the years, I sometimes feel a bit like that line from the old Jethro Tull song, that “Your wise men don’t know / how it feels / to be thick / as a brick”. These guys are all really smart, and I’m acutely aware that in most ways I’m the one who’s “thick / as a brick”, the one who doesn’t fit in, who doesn’t think the same way as everyone else; yet what the heck is going on here? It just doesn’t make sense.

I remember a string of conversations here about value in business, and about why we couldn’t use money as the only measure of value within an enterprise-architecture: but that went straight down like a lead-balloon too. Likewise just about all of those themes in the ‘no-plan Plan’; likewise many other what seem to me fairly straightforward points such as the one about ‘people are not assets’. It’s really clear that these notions just don’t make sense to most people in business and elsewhere. And as for some of the more way-out themes – such as an end to most current management-models, an end to money, and end to ‘rights’ or, ultimately, an end to possession itself –  that, in a futures-sense, I see as shifts that will and must be inevitable in the longer term… well, to most people that seems like all of that’s just on another planet. Cloud-cuckoo land. Forget it.

Or, perhaps, is it just too scary? – too far out of comfort-zones for people who must be able to purport being ‘in control’ at all times? I just don’t know. As Peter T pointed out in a recent comment here, even simple factual implications from a decent SCM [software configuration-management system] were deemed all but too fear-laden to face: so how the heck are most business-folks gonna face a mythquake that is – for most people, it seems – literally of almost unimaginable proportions?

And even though what we’re doing is ‘enterprise architecture’ in the most literal sense of those words, we can’t even use that term any more, because it’s been too ‘poisoned’ by Open Group and their ilk: their consistent misuse of the term has made things so bad for all of us – themselves included – that no one in business would trust us if we used the ‘A’-word at all. Which leaves us in a bit of a quandary even as to what we can call what we do…

It doesn’t make sense. And it needs to. Urgently. That part at least does make all too much sense…

Anyway, the quick summary of what we need to ‘make sense’ would seem to be much as per that initial post on ‘the plan that is no-plan‘:

• it’s about the architecture of the enterprise as a whole – how everything works together towards some overall aim
• it’s about the underlying ‘why’ of the overall enterprise, and how that links to the ‘how’ and ‘with-what’ and so on that make everything happen
• it’s about both structure and story, in the broadest sense of each
• it’s planning for and working with change, with inherent-uncertainty, rather than trying to fight against it
• it’s about identifying and managing hidden costs and risks – and hidden opportunities too
• it includes a strong focus on where people fit within the overall enterprise
• it’s about defining and using toolsets, visualisations, dashboards and other techniques to help people make sense of what’s happening within the enterprise, and in making decisions about how to keep the enterprise on track
• it’s about bringing all of these themes down into really practical, concrete, everyday expression, enhancing effectiveness through the enterprise

All straightforward and obvious – to me, at least. Also straightforward and obvious – to me at least – is that lack of awareness and integration of these themes is a large part of why there’s so much stress at work and elsewhere. Yet it’s also obvious that most of this just doesn’t make sense to most people. And the really serious ‘really big picture’ problems really don’t make sense to most people – so much so that even talking about them at all usually gets me labelled as crazy or worse. But if we don’t do something about those themes, a lot sooner than just Real Soon Now, we’re in deep trouble. (Okay, we’re in deep trouble already, frankly, hence this would be even worse Deep Trouble from which there really is no way out…) Yet if it doesn’t make sense, then no-one is going to do anything at all – until it’s too late even if it does finally make sense.

Really struggling with this feeling of “thick as a brick”, the lost toad-in-the-road, ‘the crazy ones’. When something that makes obvious sense doesn’t make sense to anyone else, how do we make it make sense? Or should we even try?

A real serious challenge here, in almost every different sense. Oh well.

That description of ‘the plan that is no plan’, about the direction that I’m moving into after moving out of mainstream ‘enterprise’-architecture, kind of ended up a bit longer than intended. (No surprise there, unfortunately… ) Oh well.

In effect, though, it’s also a kind of ‘manifesto’ for whole-enterprise architecture – about what needs to be added to the current so-called ‘EA’ in order to make usable and useful at a whole-enterprise scope. Whatever type of enterprise that might be.

So here’s a quick summary of all the posts in this ‘no-plan Plan that is also a sort-of manifesto’:

• Time for this old toad to move on – on why I’m moving out of mainstream ‘enterprise’-architecture
• Getting down to work in a different garden - setting out the overall scope, and describing what I will and won’t be doing within that scope
• Making plans, sort-of – outlining the overall approach, including the notion that ‘the plan is to not have an explicit plan’
• More on the ‘no-plan Plan’ – outlining the five core themes for this ‘plan that is no plan’, beyond a natural emphasis on deep-structure for the overall enterprise
• The no-plan Plan: the ‘why’ of architecture – creating a better balance between ‘how’ and ‘why’
• The no-plan Plan: architecture as story – providing stronger support for the human narrative
• The no-plan Plan: architecture for change – designing for change and ‘chaos’, rather than against it
• The no-plan Plan: architecture-dynamics – providing stronger support for versioning, lifecycles and other change within the architecture
• The no-plan Plan: people in architecture – ensuring we remember that every enterprise is, foremost and always, about people

Note that there’s a whole lot more that isn’t covered in that ‘manifesto’: about detail-layer stuff, about IT-architecture, mainstream business-architecture, security-architecture, process-architecture, and so on, and so on – lots and lots of lots of it.

The reason why those aren’t in that ‘manifesto’ is simply that there are already many other people working there – most of whom are a lot more competent than I am at that kind of work. There’s no need to extend the architecture in that direction, because it’s already being done, and for the most part done very well indeed – no doubt about that. The only point that is relevant here is that because we’re talking about a much broader scope, we need to ensure that that broader scope does properly incorporate and link to and with all the existing types of architecture-work – and make sure that the latter don’t split off into their own separate domains, much as per the ongoing disaster-area of the ‘IT/business-divide’.

Anyway, that’s the overall ‘plan that is no Plan’: now, back to work to put it all into practice.

So, over to you: comments/suggestions, anyone?

Okay, time for the final theme in that ‘no-plan Plan‘ – which somehow seems to be turning into a kind of ‘manifesto for whole-enterprise architecture’ or something like that, for some reason. Oh well. Anyway, this part’s about what is perhaps the most-serious ‘the Forgotten’ in almost all current ‘enterprise’-architectures, namely people.

I’ll keep this one short(ish), but I can see at least four sub-themes here:

• people and enterprise
• people and story
• people as ‘actors’
• people as ‘assets’

Most of the people and enterprise sub-theme is about the ‘why‘ of the enterprise, which I’ve covered already in the ‘no-plan’ post on the ‘why of architecture. Just note that everything that’s described over there also has strong cross-links to here, that’s all.

Much the same with the people and story sub-theme: go look at the ‘no-plan’ post on ’architecture as story‘. It’s pretty much all there: just note that all of that, almost by definition, is all about people too.

On the people as ‘actors’ sub-theme, I think of this as how people are engaged in the doing of an enterprise, and thence to what people do within an organisation. A few thin fragments of this are already covered in mainstream ‘enterprise’-architecture, such as ‘actors’ in use-cases, or clunkily-inadequate descriptions of ‘business services’ in Archimate and the like. It’s clear, though, that we’ll need a whole lot more than that if we’re going to get the enterprise-architecture to work well. A few examples:

• roles and responsibilities: who does what, who makes the decisions, and how and why and when do they do this?
• end-to-end processes: what happens in the largely non-automatable ‘Barely Repeatable Process‘ components of end-to-end processes? how do we ensure appropriate actions and handovers between all the stages within any end-to-end process?
• load-balancing and business-continuity: what are the trade-offs between manual and automated processes? what needs to happen when (not ‘if’!) the automated processes fail? what skills and capabilities are needed to make that happen?

I’ve drifted across this thread here already from time to time – for example, see the post ‘A question of Who‘ – but it’s clear that there’s a whole lot more that’ll need to be done. A lot more. Including how to get it down into the really practical, concrete, everyday, ‘this-is-how-it-works-just-do-it’ kind of stuff. Interesting. Very. To me, anyway…

On the people as ‘assets’ sub-theme, well, yes, I admit I do have a bit of a knee-jerk response to that dreaded if usually well-meant phrase “our people are our greatest asset”… Fact is, though, that it is a real asset to have the right people hanging around in any enterprise: it’s just that we need a very different understanding of ‘asset’, and how and where and in what ways real-people fit in with that notion of ‘asset’, in order to make it all work.

The first point here, and it’s a really, really, really important point, is that people are not assets. We should never describe people as ‘assets’. (In fact, in conventional economics terms, the only context in which people could be described as ‘assets’ is when they’re slaves – which is not a good idea in most business contexts…) Instead, the relationship is the asset – not the person, but the relationship between ourselves and each person.

And that’s a real asset: we can create it, ‘read’ it (access and use it), update it, delete or destroy it, generally manage it and its lifecycle and so on, much as for any other type of asset. But the catch is that that asset only exists between two entities – which means that it can be dropped from either end, without the other end necessarily knowing that it’s gone. Which means that although it’s an asset, it does need to be maintained in a much more engaged and active way than for a physical or virtual asset such as a building or a data-record. And because it only exists ‘between’, and can be dropped by the other end at any moment, it’s not an asset that we can ever truly ‘possess’, in the same sense that’s so often used for physical-assets and for the bad-joke of so-called ‘intellectual-property’. It’s an asset, but it’s a fundamentally-different type of asset: and we forget that fact at our peril.

I’ll use a couple of diagrams to explain what’s going on here. First, we start with that tetradian – four distinct axes or ‘dimensions’ in a kind of tetrahedral relationship:

Those axes apply to pretty much everything, and they’re quite distinct from each other. For example, physical-assets – tangible ‘things’ – are what’s known as ‘alienable’: if I give it to you, I no longer have it. By contrast, virtual-assets – data, information and so on – are ‘non-alienable’: in general, if I give it to you, I still have it. Entities will often be composites of dimensions: for example, a book is both a physical-asset (the book itself) and a virtual-asset (the information in the book).

What we’re mostly concerned with here, in this sub-theme of ‘people and architecture’, is a swathe of architectural concerns around the relational and aspirational dimensions: relating with or to people in two distinct ways.

To put this into a more conventional ‘enterprise’-architecture context, take any single row from the Zachman framework - a single level of abstraction. Then tweak its ‘What, How, Where, Who, When, Why’ columns a bit so that we can use terms that actually make sense in real-world practice; and then add the tetradian-dimensions into the mix. What we end up with is the ‘single-row extended-Zachman’ checklist for service-content – the ‘service-content map’ used in Enterprise Canvas:

Conventional ‘enterprise’-architecture handles most of the ‘virtual’ row very well indeed, for IT-maintained information at least: in other words, data, functions that act on data, virtual-locations such as IP-addresses and the like, algorithms, and information-based events. It handles some of the ‘physical’ row quite well, too: in essence, if it’s an IT-box (physical-asset) or a network-infrastructure (physical-location), it wants to know about it. But to be blunt, conventional ‘EA’ varies between not-much-use, to useless, to worse-than-useless, on just about everything else. Which is a serious limitation – to say the least. (Which is why those of us who want work with whole-enterprise architecture get so darned frustrated with most of what claims to be ‘enterprise’-architecture… though that’s another story for another time.)

Relational-assets are person-to-person links between people; and not only are they non-alienable, but they’re also non-exchangeable – for example, I can’t give you my relationship with my cat, or the postman, or the guy who sells cheese in the nice corner-grocery, or anyone else. (Of course, that blunt fact doesn’t stop businesses trying to claim that they can sell you relationships, as ‘goodwill’ etc, but that’s another story too.) The point is that it’s personal – it doesn’t exist without the person – and it also exists only between individual real-people. So, a relational-function acts on relational-assets; a relational-location indicates some kind of positioning or whatever (such as the dreaded org-chart), relational-events are events that are associated with, well, relational events, and so on. It is all straightforward, once we make the jump to realising that the asset in context is the relation between people – and not the people themselves.

Aspirational-assets are person-to-abstract links – a personal sense of relationship with (or to) something abstract. In the business-context, the obvious example of this is a brand – or rather, a brand-relationship, the personal connection to brand. I’d probably best not go into any more detail here – this is supposed to be just a summary, after all – but one of the key concerns for any business here is the interweaving and trade-off between relational versus aspirational: the former connects with the person (such as an employee), which makes things happen, whilst the latter connects with the organisation, but in itself is too abstract to make anything happen at all. Anyway, long story, another time: leave it for another post, I guess. Get back to the no-plan Plan.

So, last part: architecturally speaking, the capabilities – the ability to actually do something – are always associated with some kind of asset. Some capabilities can be built into machines and software – particularly physical-capabilities and virtual-capabilities respectively. We access that kind of capability via direct access to the respective asset. But when those capabilities reside in a real-person, we can only access the capability indirectly, via a relational-asset and/or aspirational-asset. If the link with that person is lost, so is the capability. And that still applies even if the person is physically present – a condition known as ‘presenteeism’ (or one of the variants of presenteeism, anyway).

To summarise all of this: from a business-perspective, we need all kinds of people around in the enterprise, in a wide variety of roles: customer, employee, prospect, partner, whatever. There are also a whole range of other people-roles – employee-spouse, regulator, tax-auditor, anti-client, whatever – who may either seem irrelevant or we don’t want to know about, but who are in the broader shared-enterprise whether we like or not, and to whom we therefore do need to pay attention as well. All of these are relevant to a whole-enterprise architecture: and the key means by which we can model what goes on in our architecture in relation to people is through modelling those relational links – the relational- and aspirational-assets.

Okay, stop there: more for another time – a lot more, as you can see. But that’s the overall set of themes for now, anyway.

Comments, anyone?

And the next part of that expansion on my ‘no-plan Plan‘ (or ‘manifesto for whole-enterprise architecture’, or whatever it is): this time on the dynamics of architecture. In other words, it’s a focus on how we handle changes to the architecture itself, rather than mainly about changes that that architecture needs to address.

Most of this will be painfully familiar to every experienced enterprise-architect – whatever type of enterprise-architecture we do. It’ll be especially painfully-familiar to those who’ve had to struggle with the current crop of EA toolsets, which – to be blunt – seem to range between mostly-useless and worse-than-useless for almost anything to do with architecture-dynamics. Oh well.

So, first: what do I mean by ‘architecture-dynamics’?

In essence, it’s about how we keep track of change within the architecture itself – in particular, versioning, transitioning, lifecycles and dependency-dynamics. Let’s look briefly at each in turn.

Versioning

In principle, this should be simple: keep track of edit-changes to anything. In practice, it’s a bloomin’ nightmare: doing it properly requires some seriously clever thinking in the design of the architecture-repository, and some equally clever tricks in user-interface design so that we can actually retrieve the older versions in any comprehensible way. (For example, take a look at Apple’s Time Machine for some good ideas on version-access, though in a context that’s actually a lot simpler than what’s needed for an EA-repository.)

How do existing EA toolsets do this? In way too many cases, they ‘solve’ the problem by doing nothing about it: there’s no version-management at all. Instead, it’s just been tossed into the ‘too-hard basket’, and then rather carefully forgotten in the forlorn hope that somehow we won’t notice it’s missing. (We do.) Sure, there are various kludges and workarounds: for example, one vendor’s recommended ‘method’ for versioning is to clone the entire repository and save it as a named backup somewhere. Okay, a few vendors do do a reasonable job of it – Troux comes to mind here – but even that is mostly done by a clone-and-relabel at an instance-level, which still seems pretty clunky in practice, and definitely error-prone if we were ever to risk letting inexperienced users loose on the system.

What’s absurd is that it shouldn’t be all that hard to do. As I remember, versioning-support is defined right down at the root MOF metametamodel level for the OMG notations such as UML and BPMN, so for that at least there ought to be a swathe of different implementations, surely? For my own work I haven’t gone down into implementation fine-detail as yet, but the ‘mote’ metamodel structure that I described in a series of posts a couple months back had all of that built in as well. The design-concept was based on a really simple yet fully-versioned wiki-engine that’s been around for over a decade: and if I can describe it, surely someone more competent at system-design than I am – which is just about anyone in ‘the trade’, I would have thought – should be able to do it a lot better than that?

Overall, though, versioning is still a ridiculous mess in most (all?) EA toolsets, and we need to be a lot more vocal about saying so, and demanding a better deal on this.

Transitioning

This is about keeping track of the process of change: from what to what, how, when, who, why, and so on. Again, should be straightforward. And usually isn’t. Sigh…

One of the things that really confuses everything here is the myth of ‘architecture state’. We all know how it’s supposed to work: there’s the current-state (the ‘as-is’), the future-state (the ‘to-be’), and, perhaps, various intermediate-states. Everything nice, neat, tidy, well-defined and all. There’s only catch: there is no ‘state’.

‘State’ is a myth, made up by project-managers – and, hence, toolset-vendors – to make their life seem simpler and prop up the happy delusion that they’re ‘in control’ of something that, by definition, cannot be controlled as such. The idea is that, once we reach that perfectly-planned end-point of the project, we’ll have ‘got there’ – all finished, all done, all over bar the congratulations at a job well done. But by the time we ‘get there’, the ‘future-state’ that we’d predicted in the plan isn’t ‘there’ any more: to quote Gertrude Stein, “there is no there there”. The same is true even for ‘current-state’: in any dynamic environment, change happens all the time, so even ‘now’ isn’t ‘now’ any more, either. There is no state.

Except, of course, all those EA toolsets assume that there is. Well, for those that can actually conceive of the idea of change, that is: for several toolsets that I’ve seen, their ‘method’ for describing difference is, again, to clone a copy of the repository and save it somewhere with a label of ‘current-state’ or ‘future-state’. (Except, again of course, there’s no way to create links between those two different repositories, so we have no way to describe, within a single repository-based report, what will change between those two ‘states’, and what won’t. Real helpful. Oh well.)

Much like versioning, we need to be able to define arbitrary labels for planned time-points and such-like, and attach them to any entities as we choose within the repository. And create cross-reference links between ‘as-is’ and ‘to-be’, to mark a state that isn’t a state because nothing is static anyway. And describe all the other aspects of transitioning – responsibilities, temporary bypasses, timings, dependencies and all the other transitory mechanics of the tasks – in any way that even the most pernickety of project-managers might need. All within the same EA toolset. Please?

Again, what we have on offer at present is mostly just another ridiculous mess, and again we need to be a lot more vocal about saying so, too.

Lifecycles

Everything has its own lifecycle: things change within the architecture, whether we plan to change them or not. Call it self-versioning, if you like: except that some of it may happen behind our back, whilst we’re not looking, and it still affects the viability of architecture, whether we know about it or not. T-r-i-c-k-y…

Some of our toolsets – particularly those that have developed out of a CMDB background or equivalent – do seem to have a fairly good handle on this point; most others, uh, don’t. At all. Or worse.

That’s about all that needs to be said about that, really. Except that, again, it’s something we probably need to make some noise about to the vendors. Or perhaps make that a lot of noise? Again? Loudly? Sigh…

Dependency-dynamics

Okay, this one is a serious challenge, though the toolset-vendors really ought to be up for it if they want to keep our business.

In principle, it’s a straightforward follow-on from all of the above: if something changes, other things that depend on it may be affected too. But that means that each of those items may also need new versions, new transitions, and new changes to their lifecycles. Which then affects anything else that may be dependent on that, which then affects anything dependent on that, and so on, and so on, sometimes with odd, unexpected, untraced, looped, delay-ridden, reciprocal-and-everything-else complexities. This can get to be real tangled, real quickly… Oh joys…

Again in principle, this is little different from the usual ripple-effects in a plain old bog-standard spreadsheet. Except that most spreadsheets don’t deal with versions, transition and lifecycles along with all those supposed-to-be-relatively-straightforward ripple-effects. And a repository is not the same as a spreadsheet anyway (unless you happen to build it that way). Which means that this is a lot trickier than it looks at first glance. Which is why most toolset-vendors seem to take the easy way out, and don’t bother to do anything about it at all.

Which would be fine if we didn’t need it. Which unfortunately we do. And will need a lot more once people start to realise just how powerful a well-populated holographic whole-enterprise architecture can be. Oops…

So yes, something else about which we again need to be vocal. Lots.

(And lots more that could be said about all that, no doubt, but again best leave it at that for now?)

And more on that expansion on my ‘no-plan Plan‘, which does seem to be morphing somewhat into a kind of ‘manifesto for whole-enterprise architecture’… Anyway, this part is about that theme of ‘architecture as change’ – though perhaps ‘architecture for change’ might be a better way to put it..

[Obviously this is related to the next theme, on architectural dynamics. Yet they're also kind of orthogonal to each other: the dynamics are more about the ways in which the architecture itself will change over time, whereas here it's more about change itself - the nature of change, and how we work with it rather than against it. Both views seem equally important in this developing approach to enterprise-architectures.]

I’m going to start this one with a graphic of what I’ve termed a tetradian – four distinct axes or ‘dimensions’ in a kind of tetrahedral relationship: