[In part this is a follow-on from Dave Gray's excellent Dachis Group article 'Everything is a service': I strongly recommend to read that post first before continuing here.]

As Dave Gray indicates in his article ‘Everything is a service’, many people in and around business are seeing a ‘Great Reset’ – a fundamental shift in the nature of the economy, and with it a fundamental shift in the nature of a viable business: a change in focus from products to services.

In a product-oriented economy, an organisation’s market is built around transactions, exchanges of goods and services. Within this metaphor, services are quasi-products, another type of ‘thing’ to be ‘consumed’ by a passive marketplace of ‘consumers’. Financial services, for example, are packaged as ‘products’; so-called service-organisations sell ‘solutions’ to often-unspecified ‘problems’ that a ‘consumer’ is presumed to face.

Producers produce, consumers consume: the roles are explicit, and explicitly separate and distinct. The role of marketing there is to create a market ‘want’ – often entirely artificial – for whatever product the producers want to sell. The role of enterprise-architecture and the like is to support creation of the maximum volume of product for the minimum necessary effort and cost.

The overall view – perhaps still illustrated best by the implied left-to-right flow in the structure of the Business Model Canvas above – is a linear structure of processes. A supply-chain (‘Key Partners’) feeds into the business-processes of the organisation (‘Key Activities’), the results of which are then sold on to ‘consumers’ (‘Customer Segments’). The sequence ends at the ‘consumer’, or more specifically at the moment that the customer has paid for the ‘product’; and everything is centred around the organisation, as ‘the enterprise’.

This view of the market is also often possession-based, with very unequal power-relationships assumed between the organisation and everyone else: we talk about ‘capturing’ a market, ‘owning’ market-share, and so on. This often leads in turn to a very combative relationship across the market, both between organisations competing for ‘possession’ of market-share, and between an organisation and its customers, employees and broader communities – all of whom, perhaps unsurprisingly, may well object to being treated as possessed ‘objects’ or ‘subjects’ of the organisation.

In business terms, one of the key drivers behind the ‘big reset’ or ‘big shift’ that Dave Gray describes is that this model of the market is rapidly becoming less and less viable. Most markets are either at or approaching saturation-point; the hidden-costs are becoming more visible, and harder to externalise; and the supposed economies of scale of mass-production and mass-marketing deliver steadily lower returns, especially relative to smaller and more adaptable technologies and business-models. And in bald economic terms, there are practical limits as to how much ‘stuff’ we can continue to make and sell on a finite planet – limits which in many cases we’ve already overshot. Some real problems there… – and yet they’re inherent in that model of the business-market.

A service-oriented economy is radically different, in that the market is built primarily around relationships. As Dave Gray put it:

A service is at its core a relationship between server and served. Service is work performed in support of another. At every point of interaction, the measure of success is not a product but the satisfaction, delight or disappointment of the customer.

Within this metaphor, products are best understood as proto-services, typically as part of the means for self-delivery of some service. Everyone in the market is both ‘producer’ and ‘consumer’: the roles blur, and are inherently much more equal or peer-based in nature than in the product-oriented economy.

This view of the market is also based much more on mutual responsibilities: we talk about co-creation, about partnering in a shared enterprise. The power-relationships are much more equal, and necessarily focussed on building and maintaining mutual trust – rather than the combative contracts of the possession-model, which mostly reflect an absence of trust.

The overall model still has transactions and processes and supply-chains, but the perspective is different. As Verna Allee describes it, that linear ‘supply-chain’ is actually one view into a much more nuanced ‘value-network’; and a product- or service-transaction is merely one phase within a much larger market-cycle:

Importantly, the fundamental focus of relationships is inverted, from organisation-centric to customer-centric: as Chris Potts puts it, “customers don’t appear in our processes: we appear in their experiences”. The sales-focus also shifts from ‘push’ to ‘pull’, from manipulating or even forcing the ‘consumer’ into a single once-off ‘the sale’, to building a continuing long-term mutual relationship. All of this requires radically different approaches to sales and marketing, but it can be done – and increasingly, is much more profitable than the ‘push’ model.

[For example, compare your experience of the usual soulless time-driven 'customer-as-product' sales call-centre - such as that which interrupted me just now whilst writing this, and who cut me off in the middle of saying "Thank you, but no" - to an intentionally relationship-oriented call-centre such as that run by US retailer Zappos, which focusses much more on respect and mutual trust. Which approach would you prefer to deal with in your business day? The answer's fairly obvious: which is why the conventional call-centre model is becoming less and less viable, no matter how much pressure is put upon the long-suffering staff.

Another first-hand example: a couple days ago I was looking at cameras in the local branch of a medium-sized national chain of camera-stores. The absence of pressure was really noticeable; and the saleswoman's quiet passion for photography per se shone through. The change in energy of the place was very noticeable, compared to the last time I'd been there, a year or so ago: more like an Apple Store than a 'normal' sales-obsessed high-street retailer.

Talking with her, it became clear that the company had made that crucial shift from product-orientation to service-orientation. The key was that they'd come to understand they made most of their money not from selling cameras as such, but from the ongoing photo-print service. Camera-sales became viewed as a means to support that service: it needed to be profitable in its own right, but it wasn't the primary focus for profit. Hence it became much more important to match the camera to the client's actual needs - and that emphasis on matching real needs itself became a key foundation for mutual trust, and hence for long-term relationships that would be profitable to all parties.

Contrast that with the usual high-street high-pressure retailer, where the emphasis is more likely to be about offloading the highest-margin object that the 'consumer' could afford, then dropping the attention instantly so as to move on to the next 'punter' as quickly as possible. "I worked in a place like that for three months", she said, "and I felt like I aged ten years while I was there. Soul-destroying, for everyone. So I know why I'm working here! - because I want to be here."]

So what kind of enterprise-architecture do we need for a service-oriented enterprise? How does it differ from the conventional product-oriented architectures – particularly in its business-architecture and process-architecture? Probably the key requirement is an awareness of the implications of one simple statement:

A service exists to serve.

But what does it serve? And whom does it serve? Architecturally, those are not trivial questions…

In the highly unequal power-relationships in the conventional product-oriented model, the answers are very clear indeed: there is often a thin pretence of ‘customer-service’, but in reality the ‘consumer’ is deemed to exist solely to serve the organisation and its perceived ‘need’ to sell.

[And the organisation in turn is deemed to exist solely to serve the 'needs' of the stockholders, but that's another story...]

But in a service-oriented enterprise, there are two fundamentally-different types of service going on: and the architecture needs to support both of these.

One type – which we might describe as ‘horizontal’ – is the conventional ‘supply-chain’ structure: the service-producer serves the needs of the service-consumer. The issues here that the architecture needs to support are that:

• the relationships between producer and consumer are essentially peer-to-peer
• the roles of ‘producer’ and ‘consumer’ will often blur or even swap over, especially in the ‘co-creation’ relationships that are common in a service-oriented model
• the overall relationships are built via the self-reinforcing loop of the full ‘market-cycle’, as above

The other type of service is more ‘vertical’: within the context of those ‘horizontal’ supply-chain service-relationships, every player in the shared-enterprise serves the same overall vision and values. The market exists within the context of a broader shared-enterprise, defined by a distinct purpose or ‘vision’ and its associated values.

Remember Chris Potts’ point above, that “we appear in customers’ experiences”: there’s a crucial difference here between the organisation and those with whom it interacts. Architecturally speaking, the organisation chooses the vision and values to which it will align. When customers’ experiences – and, for that matter, suppliers’ experiences – happen also to align with that same vision and values, there is then a basis for a shared connection. Serving the same ends – the same vision and values – creates the basis for mutual trust, which then starts the market-cycle rolling.

So the service is delivered through the ‘horizontal’ connection; but the connection only exists because both parties share ‘vertical’ alignment to the same vision and values.

Note that the customers’ experiences – or even supplier’s experiences – may only align with the organisation’s chosen vision for a brief period: think of a restaurant at lunch-time, for example. But whilst that alignment exists, there is the basis for conversation and connection – and hence the first stage of the market-cycle already in progress.

[Back to the camera-shop. The focus throughout the conversation was photography, what kind of photography I might need to do, about cameras in general. Firstly, there was a conversation - which in some stores doesn't even happen at all; and the conversation didn't have an all-too-obvious undercurrent of 'how can we sell you a high-priced camera that you don't need?' - which I've had all too often in the high-pressure stores. Instead, I felt listened-to, respected, safe, served - all of which increases the likelihood that I'd go back there when I am ready to buy another camera. In other words, that first part of the market-cycle is already in progress; and I feel safe in the belief that the closing 'post-sale' part of the market-cycle would be there, too.

Yet note that I wouldn't go there to buy a sandwich, or clothes, or anything that wasn't about cameras - because that isn't part of their vision or purpose that they present. They're clear about what they do and what they don't do, and demonstrate their vision and values in practice: so I know when to go there, and when not to go there. Sounds obvious, perhaps: but some organisations are so sales-obsessed that they give the impression that they'll sell us anything, whether they have it or not, just to make up their sales-quota - and that's really confusing, for everyone.]

Architecturally, the vision and values are the core of a service-oriented architecture: everything in the organisation needs to be understood as serving that vision.

Hence, for example, the value of a service-viability checklist that explicitly includes tracing of support for each of the values as they touch on every aspect of the enterprise.

Hence also the importance of ensuring that that same vision is carried across any partner- or outsourcing-relationships – especially where key customer-facing connections are handled by outsourced others such as an external customer-service centre.

And hence also the importance of keeping the focus on those shared-relationships overall, such as with Chris Potts’ aphorism above. As enterprise-architect Pat Ferdinandi put it, in a comment on an earlier post here:

That’s a brilliant line by Chris. It’s the corporation’s adjustment between customer service and customer loyalty. Customer service is viewed as a “fix” of problems. Customer loyalty is earned by the customer’s experience with the corporation but not necessarily from the corporation. The experience can be from word of mouse of a trusted friend. The experience can be from reviews by “specialists” in the area.

There’s a lot more on these themes scattered around on this site, and in the various books. For example, take a look at the post ‘Where marketing meets enterprise-architecture‘, or any of the articles here on Enterprise Canvas; and the books ‘The Service-Oriented Enterprise: enterprise-architecture and viable services‘, and ’Mapping the Enterprise: modelling the enterprise as services with the Enterprise Canvas‘. The chapter ‘Step 1: Know your business’ in the book ‘Doing Enterprise Architecture: process and practice in the real enterprise‘ also describes the practical processes needed to set up the initial architecture-models for a service-oriented enterprise. It’s all there: all we have to do is do it.

It’s simple, and straightforward: yet it’s often not easy at all. And the reason why it often isn’t easy is because it does require a real shift in perspective, a paradigm-shift – and no-one should underestimate just how hard those shifts are in real-world practice. Yet also don’t doubt that, as Dave Gray says, it is the way that the business-world is moving: so as enterprise-architects we do have to support our enterprises in that change, in whatever ways we can.

Enough for now, anyway: comments, anyone?

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.

That’s perhaps the shortest summary to a request by Anthony Draffin, in a comment to my previous post ‘Not quite bus-pass day‘:

On a selfish note… It’s apparent that the common thread to dowsing, printing and enterprise architecture is your ability to look at a field holistically and apply logical thought to extract inconsistencies and errors, as well as looking at new ways of doing something more efficiently to meet the original aims. That’s a rare skill. Have you given thought to documenting how you go about doing this? While I imagine it’s the application of a number of taught skills, the way you put these together must be far from ubiquitous. Have you considered teaching this? Personally, as a 27 year old, I want to soak up as much of your approach and thought process as you’re willing to offer.

(Warning, this is going to be another (very) long one, mainly because there’ll be several case-studies.)

Amused that Anthony says he’s 27, because that’s about the age that I really got going on this. (A little earlier, actually: the first dowsing book came out when I was still 24. I used to have to apologise for not being the age people expected me to be, namely at least 75! )

I wouldn’t say that any of what I do is a ‘rare skill’, although it’s true that it’s not often acknowledged or respected – perhaps because, by its nature, it necessarily tends to be disruptive to any comfortable status-quo. I’ve been doing it since a very early age – for as long as I can remember, anyway, certainly way back in primary school – but it’s actually the standard approach used in most forms of design-thinking and the like, as taught in art-college or architecture-school or good engineering courses or even in the US military. It’s also what really happens in scientific research – see, for example, WIB Beveridge’s classic The Art of Scientific Investigation.

My own particular twist on it arose because I’m not much good at doing things, or making things (I tend to describe myself as ‘ambi-sinistral’ – the opposite of ‘ambidextrous’… ). Hence I tend to focus instead on the thinking behind the doing or making or whatever, always searching for the simplest way to do things, the most effective way, and so on. Kind of recursive, if you like, but it works well. Except for that little problem that it tends to be so darn disruptive…

Methods, mechanics, approaches

One place to start would be around skill itself, and the key themes of my Masters thesis, way back in 1976. Back there, I described a skill – any skill – as being made up of three components:

• the methods used in the skill
• the mechanics and other real-world constraints of the ‘objective’ context of the skill – that which is common to everyone
• the approaches, assumptions, mindset, paradigms, physical dexterity and other ‘subjective’ context for the individual (the ‘operator’) – that which is specific to the individual

What I found, very quickly, was that most people seem to focus on the methods used in any skill. But that actually misses the point: the methods used by any skilled operator arise from their own personal resolution of the mechanics and the approaches – the ‘objective’ and ‘subjective’ components of the skill. This is why using someone else’s methods doesn’t always work, and why ‘best practice’ can be dangerously misleading: the mechanics of the issue remain the same, by definition, but the context is different, and hence may well need different methods.

Focussing on method also makes it much more difficult to tease apart the separate threads of mechanics and approaches. It should be obvious that blurring the objective and the subjective is not likely to be a good idea, and yet that’s exactly what happens whenever we focus only on method.

In all skills-work – in fact in just about every human context – we also come face to face with Gooch‘s Paradox: “things have not only to be seen to be believed, but also have to be believed to be seen”. In an all too literal sense, in skills-work, reality is what we say it is: we actually create it, from nothing, or rather from a combination of imagination and hard work. (In this kind of context, it doesn’t really make sense to ask the question “Is it real or imaginary?”, because the only possible answer is ‘Yes’ – both, therefore neither.) To resolve Gooch’s Paradox, we treat the approaches – our assumptions and beliefs – as if they are part of the mechanics of the context. The danger is that we may forget that point about ‘as if’, and – if we think about those assumptions at all – think that they are part of the fundamental mechanics of the context, rather than an arbitrary choice to achieve some particular purpose.

Once assumptions creep in – in other words, whenever the subjective is blurred into the objective without conscious intent to do so – what we have is a context to which arbitrary constraints have been applied. Which places arbitrary limits on possibility. Which is kinda pointless, really. But the only way that we’ll be able to see that the constraints are arbitrary is to step back a bit, and re-separate the subjective from the objective. Hence a kind of recursive methods-to-look-at-methods, analysis-to-unpack-analysis, and so on. Which is what I do.

As I mentioned in my reply-comment, much of the ‘how I do what I do’ is already documented in various ways throughout the books, such as in Everyday Enterprise Architecture (which focusses on method in a business context) and The Disciplines of Dowsing (which looks more at ‘thinking about thinking’). The core of the latter book is the ‘four disciplines’ section (see the summary on the separate two-page reference-sheet) and the ‘seven sins of dubious discipline’ (currently listed only in the book): it wouldn’t take much work to translate those into almost any other context.

What I’ll use here is the Five Element / effectiveness framework that I use in a lot of my client-work these days (though often in somewhat covert form). It’s nothing special, in fact it’s little more than a recursive use of a pair of matched checklists. The first of these, as summarised in the ‘Five Elements’ chapter in SEMPER & SCORE, is a set of perspectives on the overall context:

• Purpose – what are we aiming to do here? and why? (see also the slidedeck ‘Vision, Role, Mission, Goal‘)
• People – who would be needed for this purpose? what skills and relations do they need? what are their mutual responsibilities?
• Preparation – what planning and logistics would be needed for this purpose? what assumptions and mindsets apply here? what are the key events that trigger action?
• Process – what needs to be done to achieve the purpose? when, how and with what would this be done? when is each process complete?
• Performance – what constitutes ‘success’, and for whom? what information and metrics are needed to keep everything on track? what would be needed to support continuous improvement?

The other checklist is a set of keywords on effectiveness, which are sort-of orthogonal yet also sort-of linked to the Five Element set. Listing these in the same order as above:

• Appropriate – is this on track towards the purpose?
• Elegant – does this support the human-factors in the context? (e.g. simplicity, ergonomics etc)
• Efficient – does this make the best (e.g. least-wasteful) use of the available resources?
• Reliable – can this be relied upon to deliver the required results?
• Integrated – does this help to link everything to everything else in a consistent way?

To assess a context, we can start from anywhere at all. The point is that we use these checklists not as linear lists, but as a reminder to keep looking round, bouncing back and forth between each of the interconnected themes in the two lists, looking at the context from every possible angle, and at every level from really-big-picture to finest-detail, building up a kind of hologram of the overall context, using one form of sensemaking to bounce off others, and so on. The book Real Enterprise Architecture provides a complete worked-example of this kind of recursive process as applied to whole-enterprise architectures.

Questioning everything

Looking back at the various areas I’ve worked in or with, there’s a fairly consistent pattern about what I’ve done and the sequence in which I’ve done it.

The first stage is just getting involved at all: taking the ideas and practices at face-value, and putting them into practice as if they are entirely ‘true’. That usually works for a while (not least because that’s what everyone else is doing).

I then allow myself to start to notice the niggles, the things that don’t quite seem to work, where ‘what it says on the tin’ doesn’t actually deliver what it says on the tin. The problem, of course, is that we can’t assess the validity of a logic from within the logic itself. Yet we also can’t actually work on the context without being inside the logic (or some form of the logic). This is where we hit Gooch’s Paradox head-on: we have to see it to believe it, yet also have to believe it to see it. The only way out of that dilemma is to start to use beliefs as tools – which can be kinda challenging…

In my experience, there are two parts to this:

• identify the big-picture theme for the overall context (the ‘vision’ or, as architects would put it, the unifying ‘parti‘)
• apply design-thinking tactics to question everything, switching beliefs in order to experience the context in different ways, and test the apparent results

The tactics to identify the key-theme(s) are usually straightforward. A classic example is the ‘Five Whys’: just keep asking “why?” until eventually we hit a ‘Because.’ – or rather, a real ‘Because.’ that makes some degree of sense, rather than one that’s just used to get people to stop asking awkward questions! These days I tend to look for a brief overview-statement – usually only about three to five words – that has a distinct three-part structure: it identifies the ‘things’ or concerns that matter to everyone in the context, what’s being done with or to those items, and why it’s deemed to be important. This gives us a stable anchor to which we know we can return, and against which we can test anything in the context.

Then, following standard ‘design-thinking’ tactics, we use a suite of ‘disruptive’ questions about the context – for example:

• what’s another version of this?
• what does this look like at a smaller scale, or a larger scale?
• what happens if we substitute something else for this?
• what happens if we invert some or all of the rules?
• is there a ‘term-hijack’ here? – does a small subset purport to be the whole, blocking the view to any other aspect of the context?

This is where things often get to be, uh, fun… – because it’s very common to find aspects of the context that a) don’t and can’t make any sense, b) clearly don’t work ‘as advertised’, in fact usually work against the nominal aims of the overall enterprise, yet c) there are key players with a lot of vested interest in ensuring that the status quo remains unquestioned and unchallenged. Don’t be surprised at this: it happens every time.

This is where a certain amount of dogged determination becomes essential… Also essential is a very clear, insistent emphasis on the big-picture, on holding to the overall vision for the shared-enterprise, because that’s often the only thing that will persuade people that there’s no ‘personal attack’ here, that instead the only purpose of the challenge and the enquiry is to make things work better, for everyone. (We have to be real about that, too: we need belief in ourselves in order to keep going, it’s true, but we need to keep questioning ourselves as well. It’s one reason why serious self-doubt is a chronic yet necessary occupational-hazard here.)

We need to keep hammering at this until we do start to get a clear separation between the mechanics of the context – which usually turn out to be surprisingly simple – and the approaches to the context – which are, by definition, individual and subjective. Then we can start to work towards new methods that work with the context under the current conditions.

The same seems to apply to just about any type of context: an individual’s personal challenges in developing their own skill, a business, a social context, a single conceptual tool, or an entire discipline.

Scattered throughout this weblog and the sister-weblog Sidewise, you’ll find examples of those techniques in use. Sometimes it’s reasonably straightforward, sometimes rather more controversial, but you’ll see in each case that’s it’s essentially the same principles, the same tactics.

I’ll also summarise here those same techniques in use in four different large-scale domains that I’ve been involved with over the decades: dowsing, desktop-publishing, domestic-violence resolution, and enterprise-architecture.

Example: Dowsing (1970s)

Big-picture theme: finding things, particularly where conventional (mechanical/physical) techniques either won’t work or are unavailable.

History: as a discipline, has been around ‘forever’, and often highly controversial – first from priests who regarded it as ‘the work of the devil’ etc, then later from would-be scientists who wanted to ‘explain’ it and couldn’t. When I first got involved, in the late 1960s, the field was pretty much moribund, with a random mixture of wild claims, erratic discipline, no formal methodology or theory-base as such, a long history of inconclusive scientific experiments, and the first flush of hype-laden New Age ‘thinking’ (if that’s the right term…). Most of the people involved were well into their sixties, seventies or more (which I, uh, wasn’t…). The key players consisted of a kind of closed ‘military club’ (water-finding being very important to an army on the move), a few variously-erratic practitioners (often with wild-eyed ideas about health and the like), a swathe of armchair-theorist camp-followers who talked a lot but did nothing, and a few people who really did know what they were doing and wisely kept themselves well away from the mess.

Conceptual mismatch: The most common assertion was that it was a special ‘innate’ skill that only certain ‘special people’ could do. Methods that often clashed or even flatly contradicted each other could lead to the same result; the same method used by different people would lead to wildly different results. Most of the theory in use – such as notions of ‘waves’ or vibrations’ or ‘radiations’ – was either meaningless or just plain wrong in terms of conventional physics. (Much of it did sort-of make sense as metaphor, but there seemed to be little understanding of the difference between active-metaphor and concrete fact.) Muddle-headed ‘New Age’ ideas merely added to the overall mess.

Vested interests: On the one side was the moribund ‘military club’, who liked the idea of being ‘special and different’, and/or the ‘right’ to tell the ‘lower ranks’ what to do, whether it made any sense or not. On the other side were the upcoming ‘New-Agers’, who were not going to let anything block their path to potential fame and fortune. (I’m being cynical, I know, but that’s exactly what happened.)

Assessment and action: Assess the purported theory, and scrap most of it: it’s meaningless. The only parts of the theory that do make sense and do have solid experimental backing revolve around perceptual psychology and physiology – particularly around weighted-sum merging of multiple channels (which is why there’s no single ‘the method’) and around edge-triggered reflex-response (which is why some experienced water-finders can’t find static water even when they’re standing on top of it). If some kind of tool is used, almost all of the tools act as some form of mechanical amplifier – if I move my hand a little, the tool moves a lot. (I’ve only ever found one case where that principle didn’t apply at all.) Materials, structures, theories and so on seemed to matter only because people believed that they did: in most cases, a simpler alternative would work just as well, if not better. Keep stripping it back to the bare essentials.

It is a true skill – but it’s not one that’s restricted to only ‘special people’. Instead, it’s a learnable skill: anyone can do it – though whether they may or will do so are entirely separate questions! (There was quite a lot of pushback from the ‘military club’ against the idea that ‘anyone can dowse’.) It’s also a skill that requires a lot of practice and a lot of discipline to get right. (Unsurprisingly, there was a lot of pushback from the ‘New-Agers’ on that point, and there still is – see the book Disciplines of Dowsing.) It’s also a skill which often requires a wide range of psychological ‘tricks’ to help people slide past Batcheldor’s ‘witness-inhibition’ and ‘ownership-resistance’ – in other words, “this isn’t happening, and if it is, it isn’t me”.

End-result: After a few months’ experimentation and subsequent practice over several years with a wide range of students, I’d stripped it down to the point where I could get most people started on the basics within less than two minutes, using two bits of fencing-wire from the garden as simple instruments. The notion that ‘anyone can dowse’ is now firmly established in the canon, and the teaching-methods that I developed (based on, self-responsibility, self-critique and continual-improvement) are still some of the most common currently in use.

Example: Desktop-publishing (1970s-80s)

Big-picture theme: getting ideas and information out into the public space.

History: I trained as a graphic-designer/typographer, and became professionally involved in typesetting in the late 1970s, with the early developments in smaller phototypesetting machines. (‘Smaller’ being a relative term here: the first system we bought required a room of its own and a separate darkroom, and cost more than my house.) The big bottleneck was keyboard input: the typesetting unit was capable of running much faster than a single operator. Although the internal technology was extremely complex, the input was not: some machines still relied on a very simple 6- or 7-channel punch-tape reader, using control-codes to extend the effective size of the character-set.

At the same time, simple but usable microcomputers were just starting to come onto the market. (My first microcomputer had only an 8-character LED display, hexadecimal keypad and 256 bytes of memory; the more usable Ohio Scientific systems that we first used for real had a proper keyboard but still only 8kbytes of memory, and the only storage was on audio-cassettes.) Almost all of these machines used a 7- or 8-channel character-set (ASCII or extended-ASCII); most also provided some form of direct data input/output for interfacing to other systems.

It seemed to me that there should at least be some way to use a basic micro as a much cheaper input-terminal, using simple code-translation and a standard hardware-interface. It also seemed probable that other people would want to do the same – taking control of their own publishing, driving a typesetter direct, or both. In the longer term, that could well be quite a large market.

Conceptual mismatch: This is best summarised by the phrase (exact quote, in fact) that “there is no interest in typesetting from microcomputers, and there never will be”. There were all manner of arbitrary demarcation-lines across the whole context, both on the pre-press side – such as between authors, publishers, unions and printers – and on the technical side – particularly between typesetter-manufacturers, computer-manufacturers and various hobbyists and hackers – most of which arose more from historical ‘turf-wars’, ‘positioning’, and mutual misunderstanding than from any concrete distinctions. On the union side especially, there were many arbitrary assumptions, based on the belief that technology could not and would not change, or if it did, it could not and would not be allowed to make any difference to existing processes or roles.

Vested interests: The entire context was riddled with vested interests, almost all of which were in conflict. A stream of intermediaries – agent, publisher, pre-press, press, retail – stood between author and audience. Typesetting-systems were expensive pieces of equipment, yet with not all that much to justify their cost: there was lot of money to made there, both from machinery-sales and from fonts and other consumables, and hence a lot of ‘need’ to protect those sources of income. Until IBM eventually stepped in, most of the microcomputer manufacturers were trying to establish themselves as ‘the manufacturer’, resulting in a plethora of mostly-proprietary, mostly-incompatible hardware and software non-’standards’ – at one point we had to buy two machines whose sole function was to read the two hundred or more different disk-formats used on the four distinct disk form-factors then in common use: 8″, 5.25″, 3.5″ and 3″. Weaving a path between all the different vested-interests and proprietary structures was, frankly, a time-wasting nightmare.

Assessment and action: On our first machine, we’d been told emphatically that it was physically impossible to connect a microcomputer; a weekend spent poring over technical specs and waving a soldering-iron around a bit on a prototype-board soon proved that ‘fact’ wrong, whilst the only software we needed at first was a straightforward lookup-table to translate between character-sets. It really was that simple. (We avoided warranty risks by using opto-isolators, so there was no electrical connection between the two machines.) For our later, larger systems – which were capable of typesetting a reasonable-sized book in less than an hour – the hardware-interfaces were already built in. This gave us ‘direct typesetting’ capability, but it still required operators to know – and use – the distinct formatting-codes for each type of machine.

The next step was to hide the complexity, using the format-code in common word-processors such as WordStar to trigger font-changes and the like. (I believe we were the first people to use style-codes, such that a single hideable code – *F1, for example – would change the entire style, including paragraphs, indents, font-family and so on.) At that point, people could use ordinary word-processors to typeset text: the first true precursor to desktop-publishing.

It worked, but there were still limitations. (Our main competitor, meanwhile, was using a mangled form of SGML which still required people to embed hard-codes in the text; in our system, all of the formatting could be invisible.) The main problem was that people couldn’t see beforehand exactly how much space any text would take up – a very important concern to two of our customers, who were producing page-spread books and partworks, Dorling-Kindersley style. Hence some serious code-hacking (all assembly-language, with multiple overlays to squeeze into no more than 40kb of memory) to create a post-processor that would copyfit line-by-line for the correct fonts and sizes, and output a symbolic result to a dot-matrix printer. This was probably the first viable attempt at a true desktop-publishing system – several years before Macintosh and, later, PageMaker.

End-result: I’m good at creating ideas and markets, and all the preliminary work that gets things going, but I’m not good at running businesses – that’s a different mindset entirely. Eventually we sold out to another pre-press company and (in an all too literal sense) I ran away, first to the US, and then onward to Australia. I believe it’s still running, and certainly made millions for the new owners. (I didn’t, of course.)

Example: Domestic-violence resolution (1980s-90s)

Big-picture theme: reducing and repairing the damage from social harm, particularly between individuals.

History: Fights and power-games between individuals in a domestic context have been part of the human story since forever, but had usually been largely covert and ignored as ‘a private matter’ for most of that time. It was brought into public notice in 1970s by women’s activists, most notably Erin Pizzey, founder of Chiswick Women’s Aid. Unlike Pizzey herself (who has always insisted that domestic-violence (DV) is a human problem, not a gendered one), most activists purport that DV is something that happens almost exclusively to women, and caused almost exclusively by men – so much so that some have called for the term ‘domestic-violence’ to be replaced always by the term ‘violence against women’. Most current law (e.g. US ‘Violence Against Women Act’), support-structures (domestic-violence help-lines) and formal theory (e.g. Duluth) reflect this assertion. I became involved in the field during the 1980s as a member of a pro-feminist men’s group who were taking up the feminist challenge that all violence was caused by men alone, and therefore men’s responsibility alone to resolve the (purportedly) ever-rising tide of men’s violence against women. The issues became more personal later when two of my lesbian friends asked me for advice after they had ended their relationship with a knife fight (without injuring each other, fortunately) but had been explicitly shut out from any help because no man could be blamed for the violence.

Conceptual mismatch: The theory was straightforward: men are the problem, women are the solution, and the only useful thing that men can do is blame themselves for everything that goes wrong in the world. Everything in my background supported that assertion, hence it seemed to make sense: self-blame had been a very deeply ingrained habit for me, going right back to earliest childhood. Yet the whole field seemed riddled with gendered special-cases: behaviours that were definitely violence if done by a man were, if done by a woman, either deemed ‘not violence’ or ‘indirectly caused by men, therefore men’s fault’. In the Duluth model, blame itself was classed as a form of violence only if done by a man, and only if the person being blamed was an adult woman: blaming of men (or in essence almost any other form of abuse of men), was explicitly not classed as violence. And the real catch was that, in terms of outcomes, it clearly wasn’t working: no matter how much we blamed ourselves, and blamed other men, the overall level of violence in the culture around us still seemed to continue to rise.

Vested interests: Looking around, it was very clear that there were a large number of players – mostly but not all women – whose identity and self-worth depended on putting men down, regardless of whether or not this actually helped women in general, or anyone in general. There were also very large sums of money, and large numbers of jobs, that depended on maintaining the assertions around women’s purported exclusive victimhood in this context.

Assessment and action: The first warning-signs appeared in one of our standard text-books, Paul Kivel’s Men’s Work: How To Stop The Violence That Tears Our Lives Apart, which is designed around a series of workshops for senior-school students. The book includes many oddly-unrealistic role-play scenarios in which an adolescent boy or young man is suddenly violent or abusive to a woman; yet the only real example of violence described in the whole book is an actual incident in which two girls had a full claws-out fight when one insulted the other in the classroom – and in which no boys were involved at all, other than to separate the warring parties.

After my lesbian friends had their knife-fight, we discovered that no violence-resolution material was available that acknowledged even the possibility that a woman could be a perpetrator of violence. The standard Duluth model defines violence as inherently ‘male’; on the Duluth Wheel, female pronouns are used exclusively throughout to indicate victim, and male pronouns exclusively for perpetrator, and mutuality (where both parties are both ‘perpetrator’ and ‘victim’ of each other and of themselves) – which clearly applied in my friends’ case – is explicitly denied. I decided to try a very simple thought-experiment: swap the gender-pronouns throughout, and see if it still makes sense in terms of real-world evidence and experience. It did: in fact for most of the Duluth categories of abuse it made more sense than the ‘official’ way round. Also – importantly – two key categories of abuse were absent from the original model: sexual abuse, and third-party-abuse. It became immediately clear that the Duluth model itself was structured as third-party abuse, primarily leveraged through other-blame – in other words, far from reducing violence and abuse, it was actually designed to increase it. (Whether that mis-design was intentional, or merely arose from incompetence and excess zeal, is a separate issue that I will not discuss here… – but the fact of its unfitness for purpose cannot be in any doubt.) A simple ‘de-gendered’ redesign resolved almost all of the structural problems, sufficient at least to satisfy my friends’ immediate needs.

That exposure of the extreme inadequacies of the original Duluth model forced our group to reassess all of our previous assumptions about gender and violence, and thence to look again at the research on whose purported facts we’d based those beliefs. I did two analyses of a much-published study on which Australian public policy was based – the first analysis on the public version of the paper and political assertions from it, and the second analysis on the original academic study, which took quite a bit of work to obtain, since it was not publicly available. Another colleague, as his MA thesis, undertook a meta-analysis of domestic-violence studies in Australia. The results were shocking. None of the original studies were based on defensible methodologies – in fact many were so riddled with basic methodological errors such as circular-reasoning that they were essentially meaningless. And in all cases, all of the methodological errors either inflated the female injury-rate or risk, diminished or denied the male injury-rate or risk, or both: there were no exceptions. In short, almost none of what we’d previously taken as ‘fact’ was fact at all. The only genuine facts we could establish was that domestic-violence was a systemic issue with some gendered overtones, and that although it that affected both sexes in different ways, overall it seemed to do so almost equally – though there were strong indications from hospital data and the like that the majority of victims were male, not female.

We then looked at public policy, and the provision of domestic-violence support-services. These too were based on the same fundamentally-flawed assumptions and the same unquestioned circular reasoning: women are the only victims, hence support-services are only available to women; and since only women use these services, this proves that women are the only victims. In some of our interviews we discovered that men who’d been abused – knifed, in one case – were referred to police for charges, simply because the models in use automatically deemed men to be the sole perpetrators, regardless of the actual context or evidence. In short, the entire domestic-violence resolution ‘industry’ it was, and still is, an unworkable and fundamentally dysfunctional mess whose structures and methods are all but guaranteed to cause far more harm than good: an archetypal example of the Shirky Principle that any institution will attempt to preserve the problem to which it purports to be the ‘solution’.

End-result: The domestic-violence ‘industry’ is the outcome of a classic example of a ‘term-hijack‘, in which a small subset of systemic issue is misframed as the whole, and strenuous efforts are made to deny or conceal any other aspect of that issue. In effect, the term-hijack converts a resolvable systemic context into a non-resolvable ‘wicked-problem‘, in which every attempt to resolve a problem is constrained by the structural myopia, inevitably making things worse with each iteration. Unfortunately, there are huge vested-interests in maintaining the term-hijack. Anyone who challenges it – as I and many others have learnt to our cost – is likely to come face to face with extreme violence from women who somehow purport that no woman is ever violent. It seems clear that resolving these structural problems would require a high level of honesty and humility from those players – an honesty that in most cases at present seems conspicuous only by its absence…

Some of the material I wrote is out there and in daily front-line use by others – with real success, according to the occasional emails I still receive on the subject. But to be blunt, after a decade of relentless ongoing abuse from almost all sides, I just gave up and literally threw away most of the work that I’d done… the structural dishonesties in this mess are so entrenched and so ‘political’ that I found it just too painful to be involved at all, and it still seems that resolving the mess would require fundamental shifts in societal attitudes and beliefs that would be unlikely to occur within my own lifetime. Oh well.

The issues are generic, though, and can be resolved at a more generic level. You’ll see how some of these exact same issues are addressed in the business-context in my book Power and Response-ability: the human side of systems and its accompanying ‘manifesto‘.

Example: Enterprise-architecture (2000s-to-present)

Big-picture theme: helping organisations and overall shared-enterprises become more efficient and effective (‘doing the right things right, on purpose’).

History: The main focus of enterprise-architecture is around the relationships between structure, purpose and business-execution.As a discipline, it’s been around for at least a century in various forms, such as Taylorism (‘scientific management’), operations-research and organisational cybernetics. I often describe it as based on a single, very simple idea: that things work better when they work together. Although my work often touched on it over the decades, I first became actively involved perhaps fifteen years ago, when trying to tackle issues around long-term knowledge-management in aircraft research. Over the past decade, most of my work has revolved around various aspects of enterprise-architectures.

Conceptual mismatch: The term ‘enterprise-architecture’ implies a very broad whole-enterprise scope. In recent decades, though, the term ‘enterprise-architecture’ has often been (mis)used to denote a very small subset of the real scope, relating to IT-infrastructure or IT-systems in general. This (mis)usage probably arose from a simple conflation of the term ‘enterprise- or organisation-wide IT-architecture’. The result, however, is a very serious term-hijack: the tiny subset of the overall enterprise represented by IT purports to be the whole, with all other aspects of the enterprise – including people, purpose, physical facilities and non-IT machines of any kind – either concealed or denied. In effect, it becomes all but impossible to discuss any aspect of enterprise-architecture without being forced to describe everything in terms of IT – even in contexts where IT-systems are either not relevant or not available.

Vested interests: There are huge vested interests in maintaining the story that ‘enterprise-architecture’ relates only to IT. Many, many billions of dollars are invested each year on IT-systems that purport to resolve inherently-complex enterprise-scale concerns such as customer-relationships, market-relationships, regulatory-compliance and the like. However, by definition, many if not most of these systems are incapable of resolving all aspects of the respective concerns, in effect converting them into non-resolvable wicked-problems; maintaining the ‘enterprise-architecture’ term-hijack makes it possible to conceal or deny the inherent dysfunctionality of the systems, instead maintaining the faith or fiction that the problems created can only be solved by yet another IT-centric system at yet further cost. There are also large vested-interests in training, certification and the like for IT-centric ‘enterprise’-architectures.

Assessment and action: The starting-point for assessment was a simple review of the term itself, deriving the natural-meaning via term-inversion. The ‘natural-meaning’ of a term is the meaning implied by the individual words of the term. The term-inversion here is ‘the architecture of the enterprise’: hence the natural-meaning is ‘anything to do with the structure and purpose [architecture] that underpin the emotional drivers and actions (the animal spirits of the entrepreneur”) in the shared context [enterprise]‘. The purported exclusive-association of enterprise-architecture with IT does not occur in the natural-meaning: in fact the role of IT in the enterprise-architecture is implied only peripherally, as a minor aspect of support for ‘the animal spirits of the entrepreneur’. In other words, what we’re dealing with here is definitely a term-hijack – and an extremely unhelpful one at that, because the constraint on the scope (i.e. ‘enterprise’-architecture constrained solely to IT aspects of the enterprise) has such a limited connection with the actual scope (which would naturally focus more around people than machines).

Most of my work in the past decade, and particularly the past five years, has been focussed on finding ways to highlight the term-hijack, to resolve the resultant problems and dysfunctionalities, and to create models, methods and frameworks to guide a true enterprise-scope architecture, in some cases all the way out to a global scale. The public outcomes of this work so far include several books, a couple of dozen conference-presentations and other slidedecks, and many, many weblog posts.

End-result: We are getting somewhere with this one. Most ‘enterprise’-architecture conferences these days do explicitly include some discussion of the enterprise-scope beyond IT, usually under a banner of ‘business-architecture’, and there’s much stronger linkage to true business-architecture models and techniques such as Business Model Canvas. The real danger now is there’s a tendency towards ‘business-centrism’ rather than ‘IT-centrism’ – in other words, where the architecture sub-domain of ‘the business of the business’ rather than the sub-domain of ‘the IT-systems’ becomes used as the base for yet another term-hijack. The crucial understanding that we’re still somewhat struggling to get across to most of the players in the field is that in a true enterprise-architecture, everywhere and nowhere is ‘the centre’.

But yes, we are getting somewhere with this one. Slowly…

Summary

So that’s what I do, and how I do it:

• explore a context that is of interest to me
• identify the conceptual mismatches that occur within that context, and that make it difficult to achieve effective results within that context
• identify the vested-interests that drive and maintain the current dysfunctionalities in the context, and, where possible, devise strategies and tactics to disarm and disengage those vested-interests
• assess the details of the dysfunctionalities in the context, and identify or design workarounds for those problems, and methods to work on the context when the dysfunctionalities are disengaged
• document the end-results in various forms, as appropriate

It’s a lot of work, and sometimes very painful work, but someone has do it?

A gentle warning on occupational-hazards

To anyone who might want to do this kind of work, I really ought to add some important caveats.

The work itself is actually not that hard. All it requires is a willingness to let go of assumptions, and tackle each of the issues with a rigorous attention to discipline, following the ever-changing rules of the different disciplines that apply at each moment whilst working in that context. Using beliefs as tools can be kind of challenging at times, but again it’s just another skill, and one that’s not that hard to build up over time.

It’s the social aspects of the work that are hard: sometimes very hard…

For starters, it’s often lonely. Very lonely. Part of that is because there aren’t many people who do this kind of work: at a guess, from what I’ve seen around the net and elsewhere, there may be as few as five or ten thousand people in the entire world who work in this space. Social-media does help to ease the loneliness a bit – the people I work most closely with are scattered literally across the entire globe – but it’s not the same as working in close proximity with close colleagues every working day.

Another part of the loneliness is that the feeling of loneliness – and likewise insistent sense of self-doubt – is actually inherent in the work. It’s almost an indicator of success: as Whitney Johnson put it in her HBR article ‘Disrupt Yourself‘, “If it feels scary and lonely, you’re probably on the right track”. To put it the other way round, the times when we feel most certain are probably the times when we’ve most likely missed the point. It’s hard, and it usually hurts, every single day: so if you can’t cope with a relentless, all-pervading feeling of failure, and yet somehow still create the required results, you really shouldn’t to do this work. There are plenty of other much easier ways to make a living, after all. (This isn’t a macho thing, “I’m tough” and that kind of garbage: in my own case, to be honest, I’m probably not suited to do most other kinds of work anyway. For me, though, there’s a real sense of ‘a calling’, an inner drive to do this work, whether I want to or not: and often that’s the only thing that keeps me going… )

Another crucial point is that whilst there’s a great need for this kind of work, there’s also a huge ‘anti-want’ for it. Every aspect of this work implies some kind of mythquake; and anyone who has a vested interest in the status-quo – which in effect that includes most of our would-be employers, amongst many, many others – will not want that mythquake to occur. It’s disruptive: it is, in a very literal sense, often anarchic. So for much if not most of the time, we’ll need to do the work ‘by stealth’, embedding it in other more conventional analysis-work or the like. Doing it ‘by stealth’ is often the only option if you’re an employee, and even then it can be risky: as one of my ProFuturist colleagues put it, “if you’re employed as a professional futurist, and you’re not being fired at least once every year or so, you’re probably not doing your job properly!”

In my own case, I’ve never been an employee: only ever a self-employed contractor, an independent consultant or running my own business. I’ve survived somehow, though often I don’t know quite know how – it’s certainly not an easy way to run one’s professional-life. But I’m well aware that’s not a viable option for many people, especially those with young families. If you are an employee, and you want or need to do this kind of work, you definitely need a Plan B – and work hard on building and maintaining your professional reputation, such that you can recover from being fired after that ‘one disruption too many’.

Another subtle problem that affects many of us arises from the fact that this work requires us to be very good generalists. The good part of being a generalist is that we’re able to learn fast and be interested in anything, at any level of the enterprise. The disadvantage is that, when people compare us to specialists, we almost always come off second-best – and the fact that we specialise in being generalists doesn’t seem to count, especially where the over-simplistic assessments of recruiters and the like so often come into play. In almost all of my contract- or consultancy-work in the past couple of decades, I’ve ended up doing a different (and much broader-scope) role than the one I was nominally employed for: the problem was that I somehow needed to employed for something in the first place, and that can be a real hurdle. So the catch for us is that we need to be at least as skilled as the typical specialist, whilst also being very skilled as a generalist. It’s not easy, and is one reason why the really good enterprise-architects tend to be older, often into their fifties or more – simply because it takes that long to build up the generalist portfolio and experience whilst embedded in what is (to be honest) often a complete waste of time and effort in a ‘required’ but irrelevant specialist role.

Overall, though, it’s probably the loneliness that hurts the most. But if you can cope with that, and with all of the other challenges of ‘the trade’, then yes, we definitely need you… come and join the club, perhaps?

If we hunt around on the net, we’ll find plenty of definitions for ‘enterprise’: “a business venture”, “a project or undertaking, typically one that is difficult or requires effort”, “initiative and resourcefulness”, “a business organisation”. That last definition is a popular one with business-folk – the organisation as ‘the enterprise’ – which leads to the quite common view that enterprise-architecture would, at most, limit its scope of interest to the boundaries of the organisation itself.

But to me this misses the whole point of enterprise, the one that comes up in so many of those other definitions: that it’s about emotion. About commitment, to some kind of action or cause. As Chris Potts would say, it’s about “the animal spirits of the entrepreneur”. Almost the antithesis, in fact, of the obsessive need for ‘control’ that pervades so many organisations…

And when we look at enterprise-architecture from that lens of ‘animal spirits of the entrepreneur’, suddenly it’s clear that there isn’t just one ‘the enterprise’ at play in our organisation or whatever: there’s dozens of them. Hundreds. Thousands. An infinity of enterprises, perhaps. Enterprises everywhere. (Sometimes showing themselves mostly by a lack of enterprise within the organisation, but that’s perhaps another story… ) And all of those different enterprises competing like crazy for every small scrap of available attention… No wonder it’s hard to keep focus!

Those ‘animal spirits’ are each person’s hopes, fears, aims, intentions. Whatever they’re each committed to in the moment, that’s their enterprise. So every customer brings their own unique enterprise to the organisation each time they connect – and it may well be a different enterprise on every occasion. Every employee brings their own enterprise – or enterprises, rather, because they bring with them the current enterprise of themselves, their family, each member of the family, the community, every concern at every timescale. Everything that holds their interest in every fleeting moment – whatever it may be, it’s all enterprise.

If it’s an interest, it’s also an enterprise. Hence pervading through every organisation are vast numbers of collective enterprises: some are somewhat imposed from outside, by the communities and governments and pressure-groups that apply in the organisation’s context; some come from a more sideways direction, as professional communities-of-interest and communities-of-practice, each with their own worldview and language and mythos and everything else. All of them colliding and clashing and competing with each other, all within this one organisation that we might now almost laughably describe as ‘the enterprise’.

And from somewhere within that chaotic cacophony, the enterprise-architects must somehow find something that will help people make sense of this ‘the enterprise’. (If not the enterprise-architects, then someone still has do this task.) Because if that still-point isn’t found – the calm within the centre of the storm – then all we’ll have is the storm. Which ain’t pretty…

We’ve all seen what happens when that kind of storm wreaks its havoc across an entire organisation. If there’s no focus, then soon the only thing that will matter is what matters for me, right here, right now: not interested in anyone else, anything else. The clashes and confusions go out of control, pulling every which way at once, yet often also covert, concealed, the impossible un-joys of knife-in-the-back office-politics and worse. The organisation first splits into silos, then fragments further and further into factions and tribes. And by that point there is no organisation left that’s worthy of the name. Or enterprise, for that matter. In short, a mess. A big mess. A mess that’s no fun for anyone.

Which is why the idea of ‘the enterprise’ is important. As one of my clients put it, what they needed most was “a totem-pole to unify the tribes” – a shared focus around which everything could coalesce, as ‘the enterprise’.

Here, of course, we hit the obvious problem: whose enterprise? Who defines ‘the enterprise’? For that matter, who owns it?

Corporate law has very definite views on that last point: the interests of ‘the owners’ are paramount above everything else. (Except taxes, perhaps.) But it’s not simple as that, because it actually doesn’t work. Sure, we could legitimately say that ‘the owners’ possess the organisation – or the assets of the organisation, rather. But the organisation operates within a much larger business context, which is also an ‘enterprise’ – whereas the most that ‘the owners’ can possess extends only up to the boundaries of the organisation. In that sense, the scope of ‘the enterprise’ that matters most to the organisation is always larger than the organisation itself. And no matter how much they might wish to do so, ‘the owners’ can never really possess ‘the animal spirits’ of the employees, the customers, the suppliers and everyone else – which is an important point in itself.

Hence we come back to the notion that ‘the enterprise’ is a shared point of focus for everyone who might do some kind of business with the organisation. An enterprise is a commitment: so this ‘the enterprise’ – whatever it might be – is a kind of declaration of commitment, the chosen answer to the question “what does this organisation stand for?”. It gives the core reason for anyone or everyone to connect with this organisation – yet also identifies or implies the criteria, the values and principles, against which the organisation expects to be judged by all.

So as enterprise-architects, how do we choose this ‘the enterprise’? The usual way is through some sort of ‘vision-descriptor‘ that summarises the context, what’s being done within that context, and why it should be important to (almost) everyone to be engaged in that vision. But it’s crucial to understand that it’s not about the organisation – but about the organisation in relation to its broader context. It’s a statement of commitment to that enterprise: about how the organisation will behave in relation to that enterprise; about why it will behave that way; about how it will add value to that broader enterprise. This is why we might say that as enterprise-architects we create an architecture for an organisation, but about a much broader extended-enterprise.

But do we define the enterprise, as such? Not really: again, it’s a bit more subtle than that. The enterprise is: it’s not something that someone could define, or, even less, control. And yet even by the act of naming it, we sort-of bring it into existence, if only as a focus for shared attention, shared commitment, shared enterprise. We choose the phrasing that defines it – and that is a real choice that is well the organisation’s own purview. And yet it’s just a choice of words: it’s not the enterprise itself. We can choose to be responsible about that enterprise, and to that enterprise – yet no-one ever possesses it. In fact the moment anyone tries to possess the enterprise, tries to make their own private possession, that’s when it will ‘softly and suddenly vanish away‘ – into nothingness, as if it never existed. That’s the paradox of enterprise – and a real trap for any overly-controlling organisation.

This chosen ‘the enterprise is very real, and – when it works well – identifiably interwoven with yet also identifiably distinct from and greater than the organisation itself. And yet perhaps the strangest part of all is that it’s only ‘the enterprise’ because the organisation says it is – as its chosen “totem-pole to unify the tribes”.

An interesting twist, yes?

Over the past while have been asked by quite a few folks – Shawn Callahan, Alan Rodriguez, Robert Phipps and others – about how to use the Business Model Canvas in an NGO, government or other non-profit context. (Shawn’s client was a well-known international charity; I understand that Alan does architecture work for an independent but government-sponsored energy-trading exchange or something similar; Robert does data-architecture and other architecture-work in a government department in the social-services sector.) Hence seems that this might be a useful excuse to do a brief how-to, also linking Business Model Canvas to enterprise-architectures and business-process management via the Enterprise Canvas model.

‘Brief’ will likely be a relative term here, so continue after the break…

Osterwalder’s Business Model Canvas – first described in the book Business Model Generation – has rightly become a staple for business-architecture worldwide:

Business Model Canvas [(cc) Osterwalder/Pigneur]

Its strength is in its simplicity: it’s easy to describe a commercial business model in these terms, easy to understand, easy to engage people in business-model design and redesign. It’s also implemented in Osterwalder’s BMTbox iPad app, making it a powerful tool for ‘cafe conversations’ about business-models. For ‘conventional’ commercial business-models and their related business-architectures, it’s excellent.

Business Model Canvas for commercial organisations

Typically, we would start from either Value Proposition or Customer Segments, and move outward from there. What is our offer to the market? Who are the customers for this offering? and so on. The Business Model Generation book includes quite a wide range of standard strategic and tactical frameworks to get us started, such a Blue Ocean, Porter Value-Chain and so on.

We then wander around the model, iteratively, looking at the implications of each option, its impacts on everything else. For example, given these Customer Segments, through what Channels would we deliver our Value Proposition? Through what means would we create Customer Relationships to connect each of those Customer Segments to our Value Proposition? What returns – Revenue Streams – would we expect from each of our Customer Segments? What are the Key Resources we need to create and Deliver our Value Proposition? What are the Key Activities through which we would do this? What supplies do we need from others, or could we outsource some of those activities? – in other words, who would we need as out Key Partners? And what impact would each change have on our Cost Structure?

We can also support multi-segment business-models, such as the classic three-way free-newspaper-as-intermediary model used in modified form online by Google and the like, with its distinct value-propositions for three distinct customer-segments: the content-providers, who are paid to provide meaningful content for the ‘consumers’, who get the product for free, all of it paid for by advertisers, who get their messages embedded in the content.

And one of the great things about the model is that we can literally start anywhere. Round and round we go, trying out all the different options, building up a picture of the whole with wads of little Post-It® notes and scrawled connection-lines.

[An aside: from an enterprise-architecture perspective, one of the really serious limitations of the current version of the BMTBox app is that it doesn't support those connection-lines - in fact to me, as an enterprise-architect rather than solely a business-model designer, that one absent-feature can sometimes render the app itself almost useless in practice. I had a long argument with Alex about this during the early development stages of the app, and lost: oh well, it is his app, after all. I didn't succeed in explaining that whilst the connection-lines are implicit on the physical Canvas - because people simply draw them in as required with a whiteboard-marker or whatever - they need to be explicit on an app, especially for any kind of multi-segment model. The point is that whilst the 'boxes' on the model describe the activities and resources, in architecture we're every bit as concerned with the 'lines' - the flows that connect between the 'boxes'. I gather that the BMTBox app will eventually support explicit connection-lines: so if more of us can nag Alex about this, perhaps we can get it to happen sooner? - because it is essential for architecture-work, as will become clear later.]

Change the building-block labels for non-profit organisations

Yet there are practical problems that arise as soon as we move outside of a commercial scope. There is still always a ‘business model’ – the means by which the organisation achieves its aims, ‘the business of the business’. Most of the ‘left-hand side’ of the model in Business Model Canvas is much the same in a for-profit and not-for-profit context, but the ‘right-hand side’ is often radically different in a not-for-profit context, where terms such as ‘Revenue Streams’, ‘Customer Segments’ or even ‘Value Proposition’ may make little apparent sense. So for a non-profit, that’s the first thing we need to fix.

This part isn’t hard. The BMTBox app does allow us to change the building-block labels as appropriate. And it’s straightforward enough to hack the standard BMCanvas template: Osterwalder generously released it under a Creative Commons licence, so it’s freely available in various formats such as PDF and PPT. (The BMTBox allows us to edit the labels, too.) Given that, we can change the labels to whatever we might need. For example, for Shawn’s strategic-review for a large charity, a few months back, we changed the labels and the supporting-text as follows:

• Customer Segments to Co-creators (using CK Prahalad’s term ‘Co-creators‘ as a generic for all ‘provided-to’ relationships and roles)
• Customer Relationships to Relations (generic to include non-customer relationships)
• Cost Structure to Value-streams – outlay and costs (to include non-monetary costs, such as investment of effort or potential costs to reputation etc)
• Revenue Streams to Value-streams – returns (to include non-monetary value, in particular success in terms of the charity’s social/environmental aims)

In essence, the process for business-model development remains much the same as above: we identify the groupings of Co-creators, and the offerings (Value-propositions) to those respective groupings of co-creators, assessing Costs and Returns in the respective forms of value. We go through the same iterative assessment: for example, how do we connect with the respective groupings – our Relations with them? Via what Channels do we deliver the respective offerings? What are Key Resources and Key Activities do we need, to make this happen? Which Key Partners do we need, assisting in which activities and resources? Round and round, iterating through all of the different options.

This is enough for a first-level review of a non-profit business-model. Yet this still doesn’t resolve the fact that some of the core concepts behind the respective business-models can be very different to those in a commercial context: and in those cases, we do need to go deeper.

[Another aside: It's perhaps important to remember here that Business Model Canvas is designed for, and optimised for, one specific purpose: developing and mapping business-models for commercial business enterprises. It is a very powerful tool for that purpose. The moment we move outside of that commercial scope, though, or if we try to use it for enterprise-architecture rather than business-architecture, we need to remember that we're asking the Canvas to do something that it wasn't designed to do. In other words, those adaptations that we need to do here are our own responsibility, not Alex's - and we can't complain about it, either!]

Connecting to vision

For government or other non-profits, the emphasis on monetary revenue is obviously an important limitation for the Business Model Canvas. Yet in going deeper, we soon discover that the Canvas has several other structural assumptions that really start to get in our way. The first of these relates to enterprise vision.

In effect, Business Model Canvas assumes that the vision – the ‘core question’ – that drives the business-model will always be ‘how do we make money?’ Hence its Value Proposition will always tend to be forced into those terms: the ‘value’ is qualitative – better, cheaper, faster – but is ultimately expressed as a monetary value. (The BMTBox app at present only allows value to be expressed in monetary terms.)

In enterprise-architectures, though, we need to lift the understanding of ‘value-proposition’ up a notch or two. (This is actually true for commercial organisations as well as government or non-profit.) We need to know what ‘value’ means within the shared-enterprise, before it gets converted to monetary terms – if it can be converted into those terms at all. Before we go any further, we need a better understanding of that shared-vision and the values that derive from it. (See, for example, the slidedeck ‘Vision, role, mission, goal‘, and the summary in slide 20 in this presentation.) In those terms, the organisation exists to satisfy some aspect of the tension between the desired aims and what actually exists at present:

Chris Potts’ aphorism is a useful reminder here: “customers do not appear in our processes, we appear in their experiences”. The vision describes the reason to connect with the organisation, and the expectations for those experiences. It’s not just a supply-chain about ‘bigger, faster, cheaper’: instead, the meaning of value – ‘that which is valued’ – is defined by the shared vision, and everything that flows around the ‘value-network’ of the shared-enterprise is assessed both in terms of its direct value to the next person in the flow, and in terms of the values of the enterprise. In that sense, everything in the enterprise is a service that works towards the same shared desired-ends.

That then has a two-fold impact on the model’s Value Proposition.

First, the focus of the value-proposition shifts to how this activity or product or service delivers value to the entire shared-enterprise – not solely about ‘bigger, faster, cheaper’ and the like. It is first about how it contributes to the non-profit’s aims, or the government-department’s Results Logic [PDF], and then the qualitative concerns such as ‘bigger, faster, cheaper’ – in that priority order. The concept of offer as ‘value-proposition’ remains: but if it does not demonstrably contribute towards the enterprise-vision, it will not be perceived as a ‘value-proposition’.

Second, it implies that the service needs some kind of value-proposition for every stakeholder-group in the shared-enterprise – even those with whom it does not have direct transactions. For a non-profit, reputation and trust are the keys here – particularly in relation to non-clients or, especially, anti-clients, who will hold the organisation to account on those values. For a government department, these will be citizens and voters, who may not have direct interactions with the department, but who will certainly influence on or react to nominal policy – even as misreported in the media. The ‘market model’ is a useful way to summarise the relationships here:

The related ‘market cycle’ helps to summarise the dependencies:

And:

Relationships with non-clients and anti-clients connect primarily with values, policies and trust – the latter in essence being a metric of the organisation’s perceived alignment with its declared or implied vision of the enterprise.

Business Model Canvas sort-of deals with this on the ‘Customer’ side: if we think of non-clients and anti-clients as ‘customers’ of the idea or ideals that the organisation purports to represent, in its association with the shared-enterprise, then we could see Customer Relations as taking on that role of interaction, yet without ever reaching the point where main-transactions occur. The real complication with the Canvas for this, though, is that it’s asymmetric: there’s no equivalent of Customer Relations on the ‘supplier-side’ of the model. It’s at this stage in modelling that we may be forced to part company with Business Model Canvas.

Asymmetry of service

The structure of Business Model Canvas is somewhat asymmetric: its focus is firmly on the relationship between the organisation and its Customer Segments, without much attention paid to the ‘supplier-side’ other than the reference to Key Partners. That’s often a fair-enough short-cut in many types of commercial business-model. Yet even in business, a business-model can make-or-brake on the supply-side as much as on the customer-side; and in non-profits and government the distinctions between ‘customer’ and ‘supplier’ are rarely clear-cut.

Instead, it’s often best to think solely in terms of value-flows – before, during and after each main-transaction – and then identify the respective ‘customer’ or ‘supplier’ roles after that assessment. In this view, the organisation is and/or provides services that deliver value in relation to the aims of the shared-enterprise – and we model the service in terms of the value-flows between players. A ‘supplier’ is thus another service from whom we primarily receive some form of value in the main-transaction flow; and a ‘customer’ is another service within the enterprise to whom we primarily provide value, much as described in the market-cycle. In that sense, ‘customer’ or ‘supplier’ is not a person or organisation, but a contextual role that any person or organisation may take – and may switch between those roles, according to context.

We can then partition our own service in terms of those relationships, on the ‘supplier-side’, ‘customer-side’, and our own activities for value-creation and value-delivery.

Given this, we can then do a cross-map from Business Model Canvas to this extended ‘Enterprise Canvas‘.

Note too that we place a strong emphasis on the flows between our service and the ‘supplier’ and ‘customer’ services – which we can’t do so easily in the ‘block’ structure of the Business Model Canvas. (This is where the lack of support for flows in the BMTBox app becomes a serious shortcoming in practice.) Nigel Green’s VPEC-T – Values, Policies, Events, Content, Trust – is a particularly useful framework through which to assess those flows (though see the post ‘More on “Not-Quite-VPEC-T”‘ for some caveats on how to use that framework with Enterprise Canvas).

Investors and beneficiaries

Finally, there’s a collection of relationships that are usually implied or glossed-over in a commercial business-model, but are often extremely important on non-profit and government business-models: the relationships with investors and beneficiaries.

Investors are a bit like suppliers, but the main flow goes the opposite way: they put value into the service, rather than retrieve it on the backchannel (the ‘after’ flow). We often need investors to ‘prime the pump’, putting value in so as to start up the relationships with the main-transaction suppliers. Further up, they also help to provide credibility – ‘trustworthiness’ – to establish the respect of prospective clients, non-clients and anti-clients.

Beneficiaries are a bit like customers, but again the main flow goes the opposite way: they retrieve value from the backchannel, rather than putting it in, as customer-roles do.

In Enterprise Canvas, we model these as roles attached to the respective side of the backchannel – investors on the ‘supplier-side’, beneficiaries on the ‘customer-side’.

An investor is anyone who invests some form of value into the organisation, in terms of the values of the shared-enterprise. So this includes employees, who invest their time and commitment; it includes the community within which the organisation operates. For a non-profit, it includes donors, volunteers, fund-raisers and the like; for a government-department, it includes, voters, citizens, often also related government-departments that work kind of in-parallel rather than with our own department. It’s a supplier-like relationship, but that which is supplied is some kind of value, usually in a fairly ‘pure’ (abstract) form.

A beneficiary is anyone who retrieves some form of value fron the organisation, in terms of the values of the shared-enterprise. For example, a community may gain a sense of pride, of satisfaction, or simply the fact of having gainful employment within a money-based economy.

In this context, it’s often very important to not view ‘value’ solely in monetary terms – otherwise many of the business-crucial investor or beneficiary relationships will not make sense, or may not even be visible at all.

One of the key concerns in modelling these relationships is that two types of relationships do need to balance somehow – otherwise anti-client problems will be created or exacerbated. There is often additional complexity in that investors and beneficiaries are not necessarily the same people, and that the forms of value in each flow may be different – for example, a community invests effort and trust, and receives a stronger sense of community in return. Again, the VPEC-T frame provides a very useful set of ‘lenses’ through which to view and assess these flows and relationships.

There’s no obvious means to model these relationships in Business Model Canvas as such: you would either do so by attaching the respective extra ‘blocks’ below Cost Structure (investors) and Revenue Streams (beneficiaries) respectively. Another, perhaps more practical option is to do preliminary modelling in Business Model Canvas, and switch over to Enterprise Canvas once the limitations of the former are reached.

Summary

Business Model Canvas, in its current form, is a very good framework on which to develop business-models for commercial organisations. It’s not such a good fit for the requirements of business-modelling for non-profits and government departments: the main limitations are in its built-in assumptions about the nature of value, its inherent asymmetry in terms of relations with customers versus suppliers, and its lack of support for modelling relationships with investors and beneficiaries. The Business Model Canvas has huge advantages in terms of simplicity and ease of understanding, whilst the Enterprise Canvas model provides a useful and largely-compatible alternative for the aspects of modelling that Business Model Canvas cannot reach.

[In the next post, I'll describe how to use Enterprise Canvas to extend a business-model in Business Model Canvas into the more detailed-modelling needed for enterprise-architecture assessments of implementation and execution of the business-model.]

The ‘conventional’ way of viewing an enterprise is that of the stock-market – and, apparently, US commercial law – which seems to regard the enterprise is as nothing more than a means of ‘making money’ from other people:

• “Our vision is to maximise our profit and maximise the returns to our shareholders”

Which is all well and good from the shareholders’ perspective, perhaps. Yet in a sense it gives prospective customers a really good reason to not engage with that organisation, because in essence the company has declared that the only thing they’re really interested in is taking as much money as possible from the customer – regardless of whether doing so is of any benefit to the customer at all… And it also doesn’t make any sense in a non-commercial or government context, where ‘value’ and ‘profit’ usually cannot be described in simple monetary terms anyway.

The other ‘conventional’ way of viewing enterprise vision and purpose is kind of ‘self-centric’, where the organisation regards itself as the totality of ‘the enterprise’:

• “Our vision is to be the leading provider of pig-nuts in the West Midlands district”

In principle, that’s all well and good too, in its own terms. Yet it still doesn’t provide customers with much of a reason to talk with the company, because the latter are, it seems, too busy talking about themselves to notice anyone else.

So what does work? What does create a connection across the broader-enterprise, such as to give the organisation and its customers and suppliers and other stakeholders some solid reasons to converse with each other? What – if anything – is the difference between ‘organisation’ and ‘enterprise’? And what is an enterprise, anyway?

This is where all that work about vision comes into the story. As I understand it, the enterprise-vision needs to be something that engages everyone in that shared-enterprise – not just the organisation. It needs to say what is of interest to everyone in that enterprise; what is being done to or with or about that ‘item of interest’; and why this is important to each of the players. To me, good examples of a valid enterprise-scope vision include that of the TED conferences – “ideas worth spreading” – and the IT-standards body The Open Group – “boundaryless information flow”, coupled with its tag-line of ‘making standards work’.

Once we get the vision right, a lot of things become a lot simpler for the organisation, and for everyone else, in their relationships with each other, within the market and beyond. For quite a long while now, I’ve been using a frame that looks like this:

The vision provides a link and reference-point for everyone in this space – including the non-clients and, especially, the anti-clients, who will hold the organisation accountable to that vision and its implicit values. If we want to understand enterprise-scope architectures – as opposed to organisation-centric or, worse, IT-centric architectures – then we’re going to need a frame like this to give us our bearings. Osterwalder’s Business Model Canvas is another good example of this kind of broader-scope frame (though with somewhat narrower scope); likewise the SCOR supply-chain model.

To me, this is the typical view for enterprise-architecture: we create an architecture for an organisation, but about the the shared-enterprise(s) in which that organisation operates.

Yet in a sense this is still organisation-centric: it’s about the whole enterprise, but from the perspective of the organisation.

At that point, when talking about this with Robert Phipps, , Chris Potts‘ phrase came to mind: “customers do not appear in our processes: we appear in their experiences”. In that sense, how do people experience our vision, our organisation’s proposed way of viewing the shared-enterprise? What is that shared-enterprise, as an experience? And where does that experience fit, in relation to all the other experience-fragments that make up a total human experience? As in so many other contexts, Chris’ more customer-oriented view turns the whole frame upside-down.

It’s here that enterprise-architecture meets up with marketing – and vice versa, of course. Each enterprise-vision represents a story; in a sense, the enterprise is that story. Yet a marketplace consists of many stories or narratives, all of them not so much ‘competing’ as in ‘co-opetition‘ with each other – because without that underlying cooperation, the market itself would probably not exist. The market, in effect, is a narrative of narratives, a story made up of multiple stories.

The usual tactics for ‘positioning’ within a market include the conventional version of a ‘value-proposition’ – cheaper, faster, more economical, makes you look good and so on – or via brands – which act as a kind of precursor to and record of reputation, a proxy for the promise of experience. But the end result tends to be a bit like a raucous competition of ‘shouters’ at a street-market: “they are lovely now, come and buy, come and buy, fresh as the day they were laid, only two quid the punnet, come and buy”. That kind of competition may seem to look good and even sound good to each of the market-stall players – and seemingly a great place to grandstand the ego, too – but it actually doesn’t help people navigate their way through the market to meet their actual needs. In other words, their experience of the market – with various of the market-stalls appearing (and disappearing) within each distinct, unique and very personal experience. More often, that kind of grandstanding gets in the way of the customer-experience – but that fact is hard to see for each of the players themselves, because they’re too busy grandstanding to notice that it actually doesn’t work very well for anyone – especially over the longer term.

Yet if we re-frame the market not as a misplaced shouting-match, but as a place of story, we can see how a vision-based enterprise-architecture also re-frames the customer-experience. Each market-stall or, on a larger scale, each company or organisation, has its own distinct vision about where it sees itself within the market. It doesn’t need to shout: all it needs to do is expose and expound the respective vision. In turn, the vision provides clarity about how each player sees its respective role within that market – its role in the overall co-opetition – and also the values to which it expects to be held accountable. The classic ‘value-proposition’ and brands and so on become adjuncts or expressions of the vision and its implied values. The end-result is much more clarity about who is doing what, and how, and why; prospective customers gain a better understanding of what they can and should expect as part of their overall experience, when their personal narrative of experience touches the business-processes of that player.

This way, the company gets customers who want to be customers – in other words, ‘pull’ rather than ‘push’ – and who are much more clear about what they expect to get. They’re engaged in the story – and hence likely to be willing to tolerate minor lapses, as long as the story itself is demonstrably upheld. Equally important, the company also dissuades the engagement of prospective customers who are not a good fit to their business-processes – hence significantly reduced risks in terms of customers disgruntled with the experience, and all the concomitant problems that would arise from that, including customer-service costs, damage to reputation and so on.

That’s the overall idea, anyway.

This is just a first testing-the-waters with this idea – there’s a lot more that needs to be done to flesh it out, to build a full cross-link with classic marketing, and so on. There’s also a lot that could perhaps be done to cross-map with Verna Allee‘s Value Networks and suchlike. But I think this slightly re-purposed version of Chris’ insight could be immensely valuable to us here: customers do not appear within a market; instead, those markets – and our organisations with them – appear in customers’ experiences.

Comments or suggestions, anyone?

Each of these conferences brings their own special brew to the enterprise-architecture party. Open Group has its solid emphasis on the detail of IT-architectures; Integrated EA focusses on real complexity in the real world; AE Rio brings its own unique Latin flavour, with a stronger emphasis on business; yet IRM-EAC’s combination of EA and BPM was a heady brew indeed – definitely looking forward to next year on this one!

My own presentation was on ‘Respect as an architectural issue’, based on a real consultancy engagement some while back for a bank in Latin America – I won’t say exactly where or who, for obvious reasons The session went very well: some nice Tweets about it, at the least – though one of them said “@tetradian is light-years ahead of us …”, which is flattering yet also somewhat scary…! Anyway, here’s the slidedeck itself:

Description: The client: a large bank in Latin America. The business problem: loss of respect of the company in the market and the broader community, plummeting from highest to lowest in the region in a matter of months, with impacts throughout all aspects of the business. This real-life case study explores, step-by-step, the actual practices and underlying architecture principles that were used to tackle a major strategic issue with enterprise-wide scope, and set the groundwork for subsequent process development.

Key takeaways:

Hope you find it useful: Share And Enjoy, perhaps?

RT @vernaallee: RT @timkastelle: Good post & important point by @jorgebarba – It matters how you play the game. Not just being first http://bit.ly/lbAi6q

Will recommend Jorge’s post – it makes some very good points about the importance of getting the business-model right. Yet the part that really caught my eye was this, right at the beginning:

A few weeks ago Techcrunch published an article about a startup that got seed money from a well known group of VC’s. And because this startup is working on a similar concept that my team and I are developing, it got my attention. I immediately sent it to my crew. Their reaction was interesting. Basically they thought that that was it for us. That we got beat to the punch. That we had spent a good amount of our time working on this and that now we got beat.

Ummmm… No.

What’s interesting here is Jorge’s attitude to the roller-coaster of emotion in business and elsewhere. His ‘crew’ seem to have gotten lost here in the roller-coaster, wildly down about an apparent ‘defeat’, as much as they would no doubt be wildly ‘up’ about some apparent ‘success’. But Jorge here seems to take it all in his stride: he keeps his focus on entrepreneurship as a whole, rather than any individual events.

In a sense we could split this into three distinct layers of emotion here: strategic, tactical and operational. For quite some while now I’ve been using a variant of the Five Elements model to describe that split, in a somewhat different way, in relation to the feel, think and do of the enterprise:

But it’s actually recursive, of course: that simple mapping above is useful, but there’s action, thought and emotion in all of those distinct domains, each with their own unique emphasis. So if, for now, we keep the attention on just the nature of emotion in each of those domains, something interesting starts to emerge from that mapping.

Emotion in the ‘Operations’ space tends to get caught up in the panic of ‘the NOW!’. (For one well-known example, go see the classic restaurant-kitchen on a busy Saturday night… ) We have systems and work-instructions and pre-planned processes and the like to try to stave off that panic: but as soon as we hit anything that doesn’t fit the structure’s assumption, panic is what will often ensue. And historically speaking, ‘panic’ is the correct word here: it’s the emotion that arises when we meet up with Pan, the place or space where everything and nothing is true at the same time, where every possibility exists and we don’t know what to do. What’s interesting is that – as we’ll see shortly – just about every tradition provides very clear instructions about how to prepare for that moment, and what to do in that moment: but unfortunately the awareness of that teaching tends to be forgotten in the panic of the moment. Especially so, it seems, in the business-context… Oh well.

Emotion in the ‘Tactics’ space tends to follow a somewhat slower-paced roller-coaster: ‘ups’ and ‘downs’ following perceptions of perceived ‘success’ or perceived ‘failure’, much as Jorge describes above. They don’t happen in-the-moment, as at the Operations layer: instead, they seem to rise and fall in response to reflection on news about seemingly ‘outside’ events. These emotions have a chance to settle in and drive tactical-decisions simply because there’s time enough to do so. But in the greater scheme of things – in other words, the concerns of strategy – these emotions are just as much of a distraction as is the panic at the Operations layer. And they’re rarely any more helpful in terms of guiding valid decision-making, either.

Emotion in the ‘Strategy’ space tends to be smoother in flow again, much more consistent – perhaps because it’s a better fit with the nature of strategy? It’s often described in something resembling meditative terms, quieter, more reflective, yet definitely ‘emotion’ in the sense of providing energy for movement. The key point is that it doesn’t seem to be subject to those wild swings: instead, the tendency towards labile reactivity is countered by a clearly-felt sense of vocation – often expressed as a vision or ‘mission’. And without those stable anchors, the strategy itself becomes unstable. Hence the very real importance of vision and the like in an enterprise-architecture.

In turn, a re-focus on vision helps to damp-out the wild swings of emotion in the tactical space, and help people to align tactical decisions with strategy. Down at the operations level, a clear vision or equivalent anchor is one of the few things that can help in managing the risk of panic: it provides a known point of certainty, a ‘centre’ or still-point of calm in the midst of the real-time chaos. That’s what every classical tradition tells us – about to reach and maintain that ‘still-point’ at the midst of the action. And again, it helps to ensure that each action is aligned with the chosen tactics and strategy.

But there is a practical problem here – an important one. This is that the emotions of the real-time panic, and those wild highs and lows at the tactical level – despite the fact that they rarely go anywhere useful – can and do become highly addictive. To be specific, it’s mainly an addiction to adrenalin, in any or all of its four modes – fight, flight, freeze or fornicate. (Watch the action at a typical stock-market trading-desk over a day or so to see all of those in action, sometimes all at the same time… ) Addiction to adrenalin provides a dangerous and often-destructive delusion of ‘feeling alive’ – whether or not what is actually being done is in any way helping towards the enterprise strategies or goals. Yet because it is an addiction, there will often be a lot of reaction against anything that would help to curb the addiction. For example, there will be lip-service paid to risk-management and so on, but in effect often passive or even active sabotage of such risk-reduction, because the resultant chaos provides opportunities for ‘hero’-style fire-fighting against metaphoric or literal fires; preventing fires is ‘boring’, not least because nothing ‘exciting’ will seem to happen.

So there’s a difficult balance here. In the enterprise-architecture, we need the vision and the like to provide a stable anchor for everything that happens in the enterprise, leading a real sense of aliveness, of collectively creating something that is meaningful and ‘greater than self’. Yet at the same time we need to allow enough space for that perhaps-illusory feeling of ‘aliveness’ that comes from the real-time roller-coaster. How to achieve that balance in real-world practice across all of a real organisation – not just a start-up, for example, but a huge multi-national corporation – is probably the hardest ‘ask’ and task any EA could face. But there are plenty of organisations where that does happen, to some identifiable degree, and with identifiable success: Zappos , Interface Inc or Ricardo Semler’s Semco are well-known examples that come to mind. So in principle at least, we should be able to do this in any organisation – by paying attention to the emotions that literally drive the enterprise.

I’ll leave the last words here to Jorge Barba, in his article cited above:

It’s easy to get caught up with emotions because some other startup appeared on TechCrunch before you did. It’s the nature of this thing called entrepreneurship. But just remember one thing:

Startups don’t become relevant by focusing on technology, they become big businesses by focusing on being better humans.

And it’s the big businesses or the startups that seem to think ‘they’ve made it‘ that consistently forget this simple principle.

Something to think about, anyway. Or, perhaps better, to feel?

In the enterprise, vision is the anchor for everything: the quality-system, the business-purpose, the enterprise itself. It’s a very human focus, literally emotive: “that which gets me out of bed in the morning”, and so on.

Behind it, though – and the driver that creates that literal emotion – is the human need to belong. To be part of something that is ‘greater than self’.

Belonging, says Helena, is about longing, about deep desire, ‘to long for’. To belong to something – to be part of something greater than self – is a way to express that longing. And, in the longing, to be. Literally, to be, in the longing; to know oneself as oneself in and through the expression of that longing.

A longing is also about or for something that does not exist, that we wish did exist. We accept that ‘that which is longed for’ may in reality never exist: yet it’s that very tension that makes us reach out for it, strive for it, do whatever we can towards it so that it might somehow exist in some unknown future.

Belonging. Longing to be.

To what do you belong? What do you long for? And how do you express that longing in your life, your work, your enterprise?

So that’s what an enterprise-vision is really about: it provides an anchor for that longing, that need to ‘belong’.

Which is why that enterprise-vision is not a trivial matter.

And if you don’t take it seriously, don’t be surprised that people show little interest in belonging to your enterprise?

The classic Taylorist solution has been to emphasise extreme sameness: to force everything – and everyone – to be the same, because it keeps things simple, controllable and easily replicable. But we now know that it’s too simple to work well with the real complexities of the real world. In fact it only ‘works’ as long as we can maintain the delusion that it does work: and whenever it fails – which eventually it always does – there’s a tendency to collapse into complete chaos. Which is not much of a ‘solution’ at all.

Yet to focus only on uniqueness all but takes us back to a pre-industrial age where everything is custom-made, everything is different, nothing is actually designed to work with anything else, there are no possible economies of scale, and no certain means to communicate with each other – all of which would seem to be the antithesis of architecture. Which is likewise not a good idea.

Clearly there is an architectural tradeoff there: and hence we need something – some conceptual framework – to help us tackle it.

For at least the past half-decade, and probably longer – see, for example, Andrew Johnston’s 2005 article ‘Architects: Masters of Order and Unorder?‘ – enterprise-architects have turned to Kurtz & Snowden’s Cynefin framework for help on this. For many of us, the Cynefin categorisation of Simple [aka 'Known'], Complicated [aka 'Knowable'], Complex and Chaotic has proven extremely valuable, such as for identifying structural themes and potential problems in conceptual misalignment. One example of the latter, as Dave Snowden has also often pointed out, is the misuse of Simple-domain techniques such as Six Sigma: by definition, these depend on very high degrees of repeatability – literally millions of identical events, in Six Sigma’s case – yet there are frequent attempts to apply them in contexts that have little or no repeatability (‘Complex’ or ‘Chaotic’ respectively, in Cynefin terms), which makes no sense at all.

Beyond that basic categorisation, though, attempting to use Cynefin in enterprise-architecture can itself be problematic, particularly where we need to tackle inherent uniqueness. The explicit focus of Cynefin, and Snowden’s Cognitive Edge consultancy, is the application of techniques derived from complexity-science to inherently-complex areas such as policy. (Which, from a cross-map of Cynefin to the ISO9000 quality-standard ‘stack’, is exactly what we should expect: ‘Complex’ maps to the ISO9000 ‘Policy’ layer, in the same way that ‘Simple’ maps to ISO9000′s ‘Work Instruction’.) Yet whilst Cynefin uses the sciences to tackle complexity, what we also need in enterprise-architecture is some means to use complexity to tackle ‘chaotic’ uniqueness – which is not the same at all. Therein lie some serious problems – and some potentially-serious mistakes – if we try to re-use Cynefin concepts in contexts for which it was not designed.

I’ll admit that I’ve probably made some of those mistakes myself. Over the past couple of years I’ve written a number of articles on Cynefin on enterprise-architectures, which made a lot of practical sense to many people, but unfortunately also led to some extremely unpleasant arguments that I have no wish to revisit. What’s become clear to me over the past few months is that the beguiling simplicity of the Cynefin categorisation can blind us to the fact that although its descriptions of the Complex and Complicated domains are essentially the same as we would use for context-space mapping in enterprise-architectures, its definitions and usage of the Chaotic and Simple domains are fundamentally different to those that are needed to tackle uniqueness and sameness in architecture. It’s like comparing a cross-head screwdriver with a flat-head one: at a cursory glance they may seem to be the same, and it’s clear that they are related in the sense that they have similar functions – but in practice they’re not interchangeable, and trying to use them as such will cause a lot of frustration and possibly a lot of damage too. Not a good idea.

So I’d like here to explore what aspects of Cynefin can be used in enterprise-architectures, how and why and where it should not be used, and what we could use as an alternative in those contexts. [I perhaps need to emphasise here that this is not a critique about Cynefin itself, but solely about certain (mis-)uses of Cynefin in enterprise-architecture.]

This again will need to be quite long – apologies – but at least this time there’ll be a fair number of diagrams to break the verbiage into more manageable chunks.

What is the Cynefin framework?

The basic ‘Cynefin framework’ is a way to categorise and interpret different types of cause-effect relationships in a given context. Starting from an initial position where we cannot identify what type of cause-effect relationships exist (the domain of ‘disorder’, shown as the unlabelled grey region in the centre of the diagram below), we categorise the relationships as follows:

The right side is about order, certainty and repeatability; the left-side is about ‘unorder’, where things do not repeat in an ordered way. (Note that this early diagram from Johnston’s ‘Masters of Order and Unorder’ article uses the original labels of ‘Known’ and ‘Knowable’ for the two ‘order’ domains; for several practical reasons, explained elsewhere by Dave Snowden, these domains are nowadays labelled ‘Simple’ and ‘Complicated’ respectively.)

One important point is that Cynefin is not a simple two-axis matrix – hence the curved lines separating the domains. But it’s also important to note that the purpose of Cynefin is to describe and act on themes that apply primarily in the Complex domain – contexts in which “cause and effect are only coherent in retrospect and do not repeat”. The ways in which we would act on those themes are familiar to architects: patterns, perspectives and the use of exploratory experiments to probe for appropriate options. This contrasts with the ‘Knowable’ or Complicated domain, in which it’s assumed that if we can identify all the factors in play – the analytical or so-called ‘hard-systems thinking’ approach – it will lead us automatically to the single repeatable ‘right answer’ to any problem.

That specific contrast is extremely important in enterprise-architectures, because there’s a very common misperception – especially amongst IT-oriented folks – that ‘complexity’ is an exact synonym for ‘very complicated’. All we have to do to remove complexity, it’s said, is to break it down into smaller, simpler parts, and the complexity will go away of its own accord. The Cynefin framework makes it clear that this is a fallacy – particularly when the system includes real people in any real, non-machine-like way, but also in many, many types of ‘network-effects’ and the like. The blunt fact is that systems that are designed solely on ‘ordered’ principles – Simple and/or Complicated – will inevitably fail in any real-world context: hence the importance of something like Cynefin.

What’s different about architecture?

As I understand it, the primary purpose and use of Cynefin is in development of policy, and related programmes of action around large-scale themes involving complex issues that engage or need inputs from a large number of people. It’s been used a lot recently in the defence and anti-terrorism contexts, for example, including new ways to work with narrative-enquiry and the like.

Enterprise-architectures do indeed work on some themes that are similar to those: yet the real point is that we’re also strongly focussed on individual responses to specific, unique requirements – which is not the same as Cynefin’s focus on policy, which is more about the collective than the individual. In architectures we also make very strong use of uniqueness in the ideation process; and for IT-architectures especially, we have a strong need for ‘solutions’ that are simple enough for IT-systems to operate in real-time.

And real-time itself is another strong focus: for much of what we do, we don’t have time for analysis or experiment – and yet whatever solutions we build have to be effective, to work well in accordance with the real needs of the context. That too is different from the needs of policy: recent work by Cognitive Edge has brought complexity-based tactics much closer to real-time, but it still is not actually operating in real-time – time is important there, but it’s not the real focus.

So there are two key distinctions here:

• real-time is a key concern in enterprise-architecture, yet much less so in Cynefin
• the Chaotic and Simple domains (real-time unorder and order) seem all but undesirable in Cynefin, yet are central to enterprise-architecture

Cynefin provides a (very) good match for enterprise-architecture’s needs in the Complex and Complicated [Knowable] domains; but it does not fit well in the Chaotic and Simple [Known] domains. Using Cynefin for enterprise-architecture in the latter types of contexts would not only yield misleading results, but would also be a misuse of Cynefin itself. Not recommended.

So there’s a strong suggestion here that we do need something else that looks much the same as Cynefin in the non-time-critical contexts, and is compatible with it in those domains – yet takes a different approach as we move closer to real-time.

Dynamics in context-space

The same themes come up when we consider Cynefin’s dynamics – the pathways via which we move between conceptual-domains. To illustrate this, I’ll again use a diagram from Johnston’s ‘Masters of Order and Unorder’ article:

As shown by the orange pathways, most new ideas arise in the Chaotic domain. The dead-ends of some of these lines in the Complex domain and the continuation of others (via blue lines) into the Knowable/Complicated domain aligns well with the classic sequence of scientific development: Idea (Chaotic) to Hypothesis (Complex) to Theory (Complicated) to Law (Simple). The back-and-forth between Chaotic and Complex (path 7), Complex and Complicated (paths 4 and 5), and Complicated and Simple (path 3), are also typical – and necessary – in scientific development. Yet the only links shown between Chaotic and Simple – the key areas of concern for real-time enterprise-architectures – are failure-modes: the collapse of the over-simplistic (path 1) or the collapse of access to new ideas (path 2).

This too is exactly what we would expect in social contexts where a probably-spurious sense of certainty (Simple order) is privileged over everything else: the cycle of scientific-development dead-ends at ‘law’, preventing any further progress or adaptation until there’s some form of catastrophic collapse (a ‘paradigm shift’, as in Kuhn’s ‘scientific revolutions’).

Snowden & Kurtz describe the opposite collapse (path 2 in the ‘dynamics’ diagram above) as ‘imposition of order’ – such as the point at which a dictator ‘takes control’ to enforce their own brand of order upon apparent social chaos. In more mundane form, we see this pattern very often in enterprise-architectures and project-management, such as in the ‘cart before house’ attempts to implement a quick pre-packaged ‘solution’ without giving sufficient space to identify the actual requirements. This particularly occurs when perceived time-constraints remove the apparent option for the more conventional requirements-to-implementation loop via pilot-projects (Complex) and analysis (Complicated).

So the standard Cynefin model above shows us only the dysfunctional pathways between Chaotic and Simple, without any functional paths as such. It also tends to describe both of these domains as context-spaces to avoid: the Chaotic because it is too unstable for any science-based cause-effect approach to sensemaking, and the Simple because it’s so often too simple – and hence dangerously simplistic. This limitation of standard Cynefin is perhaps not surprising, because the main focus of the model is on relationships and differences between Complicated and Complex (such as ‘hard-systems’ versus ‘soft-systems’), where time is important but not a key factor. Yet it does also mean that we’ll need an alternate yet related approach for architectures at near-real-time scales, that does describe both dysfunctional and functional paths between them, and that gives us a richer and perhaps more balanced view of the roles of each of the domains.

An alternate frame

One option for an alternate approach comes from classic Jungian psychology. At first glance it’s just a simple two-axis matrix: ‘truth’ (order) versus ‘value’ (unorder – or related to Cynefin’s ‘unorder’, anyway), and outer-world/’objective’ versus inner-world/’subjective’:

Yet we should also apply that key Cynefin insight that each of these domains is simply a means to ‘make sense’ of the totality of what’s going on and what we’re experiencing, and hence that there’s also a ‘none-of-the-above’ domain that precedes any form of sensemaking, which we might label ‘reality’ or ‘disorder’. And we can also derive other labels from elsewhere in the Jungian-related traditions, of which probably the most useful set are the Artist (idea/Chaotic), Technologist (hypothesis/Complex), Scientist (theory/Complicated) and Priest (law/Simple):

One of the most important points that this adds to the standard Cynefin set (Chaotic, Complex, Complicated, Simple) is that the Priest domain is not solely about the real-time simplicity of law – it’s also about certainty. Each of the domains has its own form of ‘certainty’, and its own form of passion too; but in the Simple domain, the Priest is also a passion that certain things are true – and that everything else is not ‘true’. And it’s that passion that seeks to prevent change – even when change is needed. It needs things to be simple, to be certain, to be clear, to be defined forever in some kind of ‘divine Order’ – and it guards that order and certainty with a deep, unyielding, passion that has what we could accurately describe as a religious intensity.

This is a side-effect of the push to simplify, and is also a key driver in the process by which, as Dave Snowden has again commented, valid Simple-domain techniques such as Six Sigma or BPR (Business Process Reengineering) are always at risk of becoming ‘cult-like’. Techniques become cult-like when their proponents forget that the real world cannot all be reduced to Simple rules: it will always also include components that are Complicated, Complex and/or Chaotic. It’s not just that “order is real”, as Dave Snowden asserted in one of our unfortunate arguments, because it is equally true that “unorder is real”: both are true, for a given sense of ‘true’ – which in a sense also means that there are circumstances where each of them is ‘not-true’. What often matters most, perhaps, is which of them is useful in any given context; which has more value.

And so on, and so on – which can quickly recede into a mind-bending kind of recursion. One of the real dangers that I’ve seen in techniques that place their main roots in science – such as Six Sigma or BPR, or Cynefin itself, for that matter – is that the push for Simple laws can sometimes cause a withdrawal into ’scientism’, a bizarre ‘religion of science’ that is actually closer to an antithesis of science itself. (The antics of many so-called Skeptics represent some of the more infamous examples; likewise people who consider that they’ve experienced a ‘conversion’ to Dawkins-style atheism.) Often key cues arise from language used: phrases such as “must be” or “it’s obvious” are common warnings of a collapse into the over-Simple. The recursion here means that we need to use the frame to review the frame itself: so Cynefin, for example, is oriented towards the Complex, but its roots are in complexity-science (a Complicated-domain modality), and its dependence on scientific ‘law’ (Simple) means that it must always guard itself against becoming overly-simplistic – and also against the resultant ‘natural’ tendency to regard any new ideas and interpretations (the Chaotic domain) as ‘heresy’, a ‘threat’.

Yet the Simple-domain (the Priest) is also one end – the ‘ordered’ end – of a spectrum that implements action in real-time, where there is no time available for thought and reflection. No matter how Complex or Complicated the behaviour may appear be, most real-world processes are anchored in Simple rules: that’s one of the key foundations of all the sciences – including chaos-science – and we ignore that fact at our peril. It applies just as much in business too: hence the everyday foundation of every quality-system is the plain, ordinary, everyday work-instruction, describing the routine choices in routine action. Most things are Simple; most things, most of the time, do indeed need to happen in much the same way – and we ignore that fact at our peril, too.

The Simple goes wrong – often badly wrong – when it makes the mistake of assuming that ‘most’ is the same as ‘all’, or that ‘most of the of time’ is the same as ‘always’. The point here is that there are times when we need to move to the other end – the ‘value/unorder’ end – of that real-time spectrum: and we need to move there as an intentional choice, rather than as the enforced result of an unintended collapse.

For example, every time we start a new project or a new architecture-cycle, we need to intentionally block out everything we believe to be ‘true’, so as to be able to identify the real needs and real requirements in the context. When we first start on a new design, we must deliberately face ‘the unknown’ – otherwise the best we’ll get is another iteration of the known. One excellent description of this process comes from the Indian film director Shekhar Kapur, in a presentation at TED India in late 2009:

When I go out to direct a film, every day we prepare too much, we think too much. Knowledge becomes a weight upon wisdom. You know, simple words lost in the quicksand of experience. So I come up, and I say, “What am I going to do today?” I’m not going to do what I planned to do, and I put myself into absolute panic. It’s my one way of getting rid of my mind, getting rid of this mind that says, “Hey, you know what you’re doing. You know exactly what you’re doing. You’re a director, you’ve done it for years.” So I’ve got to get there and be in complete panic. So it’s a symbolic gesture. I tear up the script. I go on to the set. I panic myself. I get scared. I’m doing it right now. You can watch me. I’m getting nervous. I don’t know what to say. I don’t know what I’m doing. I don’t want to go there.

And as I go there, of course, my AD says, “You know what you’re going to do, sir.” I say, “Of course, I do.”

And … inside … I’m allowing myself to go into chaos because out of chaos, I’m hoping some moments of truth will come. All preparation is preparation. I don’t even know if it’s honest. I don’t even know if it’s truthful. The truth of it all comes on the moment, organically, and if you get five great moments of great, organic stuff in your storytelling, in your film, your film audiences will get it. So I’m looking for those moments, and I’m standing there and saying, “I don’t know what to do”.

Here we deliberately go into the Chaotic – a structured serendipity where we use principles rather than pre-packaged ‘truths’ as our guide. The principles act as a sort-of constraint, but more as a guiding-star to a direction, rather than a boundary or ‘attractor’ as it is in the Complex domain. It creates a space in which the new, the unexpected-yet-appropriate, can happen, can create itself out of nowhere, using us as the means by which it does so – or that’s how it will typically feel, anyway. And the ‘enemy’ here – the ‘giggle-wrecker’ that destroys that bizarrely timeless state of ‘flow’ – is ‘control’, the state of possibly-spurious ‘certainty’ that’s so desirable (and, in many ways, so necessary) in the Simple.

This is very different from Cynefin, in which the Chaotic is essentially somewhere that we might perhaps visit for a brief moment, but otherwise aim to get away from as quickly as possible. Instead, for this purpose, the Chaotic is often somewhere we need to stay in for as long as possible, though it often takes a great deal of courage to rest with the ‘panic’ that this will naturally entail.

More on recursion

Recursion (and likewise its inverse, reflexion – ‘the whole seen within any part’) is a key theme in enterprise-architectures, not least because it can aid in creating simplicity without falling into the over-Simple. One of the problems we do see with careless use of Cynefin in enterprise-architecture is a failure to make appropriate use of the recursion/reflexion pair, in part because whilst recursion is a key pattern that’s used in Cynefin – especially in the Complex domain – it’s not inherent in the framework itself. In effect, the basic Cynefin diagram is often used solely as a Simple frame, as a straightforward single-layer checklist and not much more.

Yet once we introduce recursion as an inherent attribute of everything within the frame, some interesting options open up. [I perhaps need to reiterate that this is not 'standard Cynefin' here, though it is one way in which the Cynefin-style frame can be (re)used.] One example above was the recursion in which Cynefin’s focus on the Complex is based on the Complicated ‘truth’-frames of complexity-science, which in turn are grounded in scientific concepts of Simple laws, which in part loop back to the Chaotic in that there are elements of complexity-science that are inherently uncertain.

Complexity-science and its scientific siblings such as chaos-mathematics provide us with powerful tools to make sense of the uncertain at a larger scale – such as in Cognitive Edge’s work on narrative interpretation and abductive reasoning. But the closer we move towards uniqueness, the individual event, the complexity-science breaks down – or more accurately, moves outside of the scope to which it can appropriately apply. When dealing with inherently unpredictable events such as weather-systems or radioactive decay, chaos-mathematics can quantify the unpredictability, to make the degree of unpredictability more predictable, yet it still does not make any individual event any less unpredictable: we can often measure a fissile half-life, or a mean-time-between-failure, very accurately indeed, yet still have no means whatsoever to predict when an individual atom will split, or when an individual unit will fail. And it’s often those individual events that matter most in the architecture – and certainly so in the ideation or sensemaking processes at the start of a new project.

We can see much the same recursion if we use a Cynefin-like frame on methods and methodologies. For example, we could use it to categorise methods and the extent to which we could modify those methods:

• Simple (‘Priest’): the method is fixed, predetermined, invariant – ‘true for all cases’
• Complicated (‘Scientist’): the method can be configured, in accordance with predefined (Simple) parameters or (Complicated) algorithms or (Complex) usage patterns, etc
• Complex (‘Technologist’): the method must be adapted to the context, and ideally should be self-adapting (i.e. Complex Complex) to each context
• Chaotic (‘Artist’): the method cannot be predicted in advance, and may indicate itself without apparent warning, though pre-seeding with (Complex) patterns to provide direction will usually help

Also notable in many Chaotic-domain methods is the exact inverse of the warning that applies so strongly elsewhere. In the Complicated-domain, it’s (rightly) considered crazy to repeat the same action and expect different results; yet in the Complex-domain, doing the same thing will usually lead to different results, whilst in a true Chaotic-domain doing the same thing will always lead to different results. Hence in the Chaotic-domain, constant repetition of Simple actions – as typified by meditation and the like, or the musician’s endless practice of scales and sequences – will often provide ‘just-enough’ predictability to make the unpredictability usable in practice.

It’s also essential to note that whilst Complex-domain patterns are useful in all skills, ultimately every true skill is personal – in other words, must always in part be Chaotic. We cannot learn on others’ behalf; there is no substitute for personal experience. Which also leads to another key point in every architecture: it’s always in part about values – sometimes collective but also always personal – which are, by definition, ‘subjective’: so we can’t and shouldn’t expect that all of it will necessarily ‘make sense’ to anyone else. That’s one aspect of our work that will always be ‘unscientific’ – yet also a strange blend of scientific law and the science and art of inherent uncertainty.

In the actionable world, order is real, yet so is unorder: a real-world, real-time spectrum that wanders between predictability and unpredictability, engineering and imagination, sameness and difference. We can quantify uncertainty in the enterprise, but we can never make it certain. Getting that balance right across all of those multitudinous interdependencies and layers and complexities is, to me, the real essence of enterprise-architecture.