Tom Graves / Tetradian

‘Tis the season for… something, probably?

For many people, it’s ‘the ‘Holiday Season’, or Christmas, or New Year, or something like that. A calendrical marker-point, anyway. Something to celebrate, perhaps.

The culture I come from is nominally Christian, hence ‘Christmas’ and suchlike, so that’s the label others around me tend to use. (Though it doesn’t quite have the same sense for me, I’ll admit: in religious terms, my family-background is in the Quaker tradition, which historically regards Christmas as ‘just another day’.)

[These days 'Christmas' in this country seems barely Christian anyway: it's much more about families - which sadly doesn't have much relevance for me - and, even more, about the real 'state-religion', the Church of Conspicuous Consumption, which I try to avoid as much as possible...]

As a perennial Outsider, my real colleagues are scattered around the globe: I have stronger connections with people in the Netherlands, Australia,Guatemala, Brazil or the US, for example, than with just about anyone in this town. Those friends and families and colleagues all follow different faiths, different traditions, different worldviews: even the Christians amongst them will celebrate their Christmas on different dates, from 1st December right through to 6th January (‘Twelfth Night’, also known in England as ‘Old Christmas’). And even a nominally-secular marker such as ‘New Year’ can be almost as problematic: there seem to be dozens of different definitions of ‘New Year’, few of which make much sense to anyone else.

So it’s kinda tricky knowing what to ‘celebrate’, or know which date-marker to use. For purely pragmatic reasons, I tend to focus on astronomical markers such as solstices and equinoxes, because they’re probably the ‘safest’ in social terms. Hence today, being the solstice closest to the most-acknowledged festival in these parts, and also closest to the New-Year point for this culture.

Even so, which solstice? It’s winter-solstice here, but summer-solstice for my friends down south; and solstices don’t mean much anyway to my friends in the tropical-regions, whose ‘summer’ and ‘winter’ and the like align with other real-world markers. Hmm… see what I mean by ‘kinda tricky’?

So what can a not-particularly-social not-particularly-anchored-anywhere soft-of-digital-native do or say these days, in terms of others’ societal celebrations?

I guess the best I can offer is that however, whatever and whenever you choose your celebrations to be, have fun, and Have A Happy Whatever!

Enjoy! – and thanks again for sharing this journey with me over the passing year.

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

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

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

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

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

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

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

What’s the point of competition, in a business-context? Perhaps more to the point, what is competition in a business-context? And why?

Another of those ‘obvious’ question-themes that turn out to be not so obvious at all… And the answers are very important in enterprise-architecture, business-architecture and business-model design: not least because if we get it wrong – as too many people still seem to do, in business and elsewhere – then we’ll likely find ourselves on a guaranteed path to business failure.

Was reminded of this by two Tweets earlier today, both from Swedish social-business specialist Oscar Berg:

• oscarberg: RT @letterpress_se: In war, there can be only one winner. Not so in business – Stop Competing to Be the Best  http://s.hbr.org/soHqME
• oscarberg: Apple, Samsung, Motorola, Nokia et al…please fight your wars in the marketplace, not in courts

The HBR article, by Joan Magretta, that’s referenced in that first Tweet, describes the key part of the point I want to make here. The second Tweet illustrates what happens when people don’t get that point: business-energy gets wasted on things that don’t actually matter, until all the players in that ‘game’ get so wasted, in various senses, that none of them can survive.

[There's one subtle yet crucial disagreement I'd have with that comment above from Joan Magretta's article, that "In war, there can only be one winner". I know it's a popular belief, but it's wrong - lethally wrong, often in an all too literal sense. No-one wins from being involved in a war: the only 'winners' are those who take care not to be involved, and the parasites who profit from picking up the pieces afterwards - and who often set up the war in the first place, for exactly that reason. No-one wins from a war: everyone loses. We'll see why that's so in a moment - and also why that fact matters a very great deal in business.]

So is competition good, or not good? For that matter, should we cooperate with others, or not? In all of those questions, the obvious answer is “It all depends…” – but what it most depends on in each case is what we understand as the nature and purpose of competition, and its apparent counterpart in cooperation. And that, in turn, depends on what we understand as the nature and purpose of power.

What’s the purpose of competition? Is it to win? If so, win what?

Is it to beat the other guy? If so, what happens next?

Or is it less about winning as such, but more about not having to face the feeling of failure, of being labelled ‘the loser’, and everything else that goes with that label in so many societies?

Yeah, that last one starts to hit a bit closer to home, doesn’t it? Oops…

Behind most of the myths of competition is a hugely tangled mess of mostly-unacknowledged feelings and fears. The details change from culture to culture, and I won’t go into much of that detail here, but the real core of it is a really simple set of mistakes about the nature of power in the workplace and elsewhere. Again, I won’t go into the detail – see my book Power and Response-ability, if you’re interested, or the associated brief ‘manifesto‘ – but in essence what it comes down to is this:

– the physics definition is that power is the ability to do work

– most social definitions are closer to the notion that power is the ability to avoid work

Therein lie the roots of some serious problems for business…

In the myths around ‘winning’ and ‘losing’, most of the work being avoided is relational and aspirational: in other words, work that can only be personal, not collective. On one side, it’s often a failure to grasp that, on a finite world, we are always in a closed, finite context where ultimately there is no convenient-scapegoat ‘Them’, but only ‘Us’ – hence there is no-one that we can ‘win’ against. On the other side, we actually can’t force others to face our own feelings for us – no matter how much we would want that to happen – because they’re actually our feelings. And in reality there’s no way to win, in any real sense, unless we find the courage to turn round and face that work – rather than wasting what little energy we have in futilely trying and, by definition, failing to ‘export’ it to everyone else.

Do we really think we can ‘win’ by making someone else ‘lose’? The reality is that the most we could achieve is a temporary respite from that ‘feeling-work’, at the cost of actually increasing the damage and the load across the overall system. At best, we gain a short-lived ‘high’ – exactly like any other form of addiction. Which is why most of the myths about ‘winning’, and most of the myths about ‘beating the competition’, are a literally deadly delusion.

[There are plenty of people who would promote such myths, of course - especially the parasites who profit from the ever-popular 'game' of 'let's you and him fight'. The point here is that those myths don't help you - even (or perhaps especially) in a business-context.]

Competition is good: we need competition if we’re to improve our skills, our competencies, our overall game.

But it’s only good – is only successful, in the longer term – if we compete with others. Not ‘against’ others.

Cooperation is good: we need cooperation if we’re to do anything that we cannot do solely on our own.

But although cooperation is always going to mean working with others in some sense or other, it’s only good – is only successful, in the longer term – if the overall aim of the cooperation is with all others. Not ‘against’ others.

There are only two choices here: either everyone wins, in some way; or everyone loses. There is no ‘win/lose’: it’s a delusory form of ‘lose/lose’, in which an apparent gain for one party masks a greater overall loss for everyone – including the nominal ‘winner’.

If we compete with others, and with ourselves, everyone wins. Sometimes one player is ‘the winner’, sometimes another: but overall, over time, everyone wins in one sense or another – and the overall ‘competing’ is a key part of what helps everyone win.

If we compete against others… – well, in short, everyone loses. No matter what it looks like in the shorter-term, everyone loses.

[Except for the scavengers and parasites, of course. And yes, we all know who they are in business. Except we're so often required to pretend that we don't, and that they're not. Oh well.]

And there’s no way round any of that: all of that comes from the real nature of power itself.

So if we’re going to compete – and in business, we’re going to want to compete, and also often have to compete - then we have to compete with others, not against them. Because if we don’t, we’re going lose – even, or perhaps most, when we seem most to ‘win’.

Which is no doubt somewhat different from what we’d hear in most everyday ideas about ‘business as usual’. But it’s also the only way that works. Which can be kinda tricky – especially in enterprise-architectures and the like, where we do need to deliver something that actually does work. Hmm…

Implications in business-architecture and enterprise-architecture

In architectural terms, what all of this comes down to is one very simple fact:

• every instance of ‘competition-against’, in any form whatsoever, represents an active source for loss of overall effectiveness, and a potential point for catastrophic-collapse of the overall architecture

That applies right up to an overall business-model, onward through design of performance-bonuses of sales, or managers’ resource-allocation, right down to real-time relationships between web-services and code-level conflicts. Competition-with is (usually) good: no doubt about that. Yet every time we allow some form of competition-against to slip through and become embedded in the system-structures, we increase the risk of total system-failure.

Which leads us to one very simple test:

• wherever the architecture includes some form of competition, is it competition-with, or competition-against?

In many cases, perhaps most, we’ll want our architecture to encourage competition-with.

Yet we must eliminate every form of competition-against – otherwise we’re designing an architecture that, by definition, is designed to fail.

And yes, this kind of design is all doable - despite all those conventional delusions about power and the like in ‘business as usual’. We just need to be rigorous about it, that’s all.

There are plenty of examples of how and why this works, at every level of the architecture. For business-architecture, see Joan Magretta’s HBR article referenced above, or Michael Porter’s work on strategy, or Tony Hsieh on customer-service. (For an interesting real-world example, see the small Welsh-border town of Hay-on-Wye, whose core business is built around a ‘competition-with’ web of specialist bookstores.) In the mid-range, see Dan Pink’s work on motivation, perhaps, or John Seddon on service-design. On the factory floor, see Deming’s classic ‘14 Points‘. I’ll admit I don’t know enough current code-level IT to give detailed examples there, but I know plenty of people who could.

It’s all doable. None of this is new, as such; and in itself, none of it is especially difficult, either.

[What is difficult is shifting the mindset - the usual myths of competition, the delusion that we can only 'win' by making others lose. That's hard, true: but it's also the only way that works.]

Architecturally, the only thing that makes it hard is artificial boundaries between segments of the overall system. This is one area where we need a whole-of-system perspective, and where the obsessive IT-centrism of conventional ‘enterprise’-architecture would be far more of a hindrance than a help. For much the same reasons, we need regular business-folk to understand that the overall enterprise runs on a great deal more than just money. But again, all of this is doable.

More to the point, it’s all been done – and proven in practice, too. And since overall it’s quite easy to prove that competition-with is more efficient and effective than competition-against – as can be seen in the bitter farce of the current fights between cellphone-manufacturers, as in Oscar Berg’s first Tweet above – there’s an interesting point that those who don’t ‘get’ the value of competition-with stand to lose ground against their nominal competitors…

There is, however, one serious structural problem of which we need to become very much aware. Competition-with is the only way that works, but sadly a lot of people still believe that they can be ‘the winner’ in any game of competition-against. (And there are plenty of parasites and predators who’ll prop them up in that belief, too. For a while, at least…) There are plenty of businesses that operate that way – as we all know all too well.

Yet unfortunately the game is naturally weighted in a way that props up those delusions. We know that win/win is the only way that works; we know that we can only win if others win too. But if they believe in win/lose, then they’ll be certain that they can only win by ‘making’ others seem to lose. In other words, whenever we come across someone like that, we want them to win, but they want us to lose – which is not a good place for us to be…

In those circumstances – to quote the old children’s-film War Games – “the only way to win is to not play”. So once we do get properly onto competition-with, we cannot engage with anyone who indulges in competition-against – because we will always lose, in one sense or another, whenever that occurs.

[In fact everyone will lose whenever that occurs - but it's our organisation for which we're designing the architecture, hence that's what needs to be our focus here.]

So that test – explicitly excluding any interaction with any form of competition-against – needs to be embedded right the way through every aspect of the architecture, without exception. And yes, that’s hard. But essential. Seriously.

And that’s what’s actually implied, in architectural terms, from those two Tweets above. Interesting, I trust?

Anyway, enough for now, I guess. Comments, anyone?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Enterprise-architecture implications

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

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

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

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

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

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

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

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

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

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

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

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

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

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

As the economy shifts ever onward from manufacturing toward services, how do marketing and market-relationships need to change with this shift? And what enterprise-architectures do we need to support this?

[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?

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

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

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

But…

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

Oops…

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

Oops…

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

Not such a good idea, then…

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

So, the one-line summary:

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

Hope you find this useful, anyway.

A follow-on to the previous post ‘Where do we start with EA? – a practical question‘, to address a number of comments and questions that came up via the Twitterstream.

Again, I’ll keep the emphasis on the ‘how-to’, and hold back on the theory this time. (Have a wander elsewhere through this blog for the theory-bit! )

A quick reminder about the context of the previous post. A colleague of mine, Alan, has found himself in a new job, company and industry. What’ he’s used to doing is IT-oriented ‘enterprise’-architecture for utilities-management. His new company is in retail and e-retail – a lot of IT, sure, but a fundamentally different type of business, for which a conventional IT-centric version of EA may well be more of a hindrance than a help.

So the recommendation in the previous post was to start off with a focus, in parallel, on five distinct themes:

• the politics and pragmatics of architecture
• setting the stage – the ‘big-picture‘
• finding allies – people who know ‘the trade’
• establishing standards
• finding the story

The post gave a quick summary on each of those themes – enough to get started, I’d hope, though obviously each could be a book (or several) just in itself.

What followed in the Twitterstream was interesting. Some of it was from Alan, some from others – I’ll paraphrase a bit to protect people’s identities and get it into a more usable sequence:

• I know I can’t get same performance as last job right now, but feeling frustrated with this low performance at start.  // I doubt they have same background, it’s new for everyone on strategy/leadership side.
• First week there: trying to find some point to start, there is no architecture there yet. //  I need some kind of quick-start to show EA value first. // I’m trying to start with TOGAF, but is so big for a people without EA culture.
• Everything depends on environment you’re in (culture, timing, IT strength) to propose a quick move
• Is dangerous trying to say something execs want, and end up doing something wrong. Get to know background first // What is the company mission/vision here? – is a good start for any EA.
• So, need to be calm, take a deep breath, do baby-steps on each thread with execs’ participation?
• Do you know why PEAF doesn’t have Security and Governance principles examples on this “starter-set” ? // Maybe new edition of the PEAF book soon with these principles?

Let’s explore each of those in a bit more detail. (From here on I’ll use a ‘you’-format rather than ‘we’, for simplicity and to make it more direct, but it’s important to realise that this is generic, not solely advice to a single person.)

First, about frustration. Yeah, that’s very real at this point. The short answer is that it’s normal, absolutely to be expected, nothing wrong with it, yet you do have to deal with it, because the bald fact is that this is going to take time.

A good enterprise-architecture is a kind of conceptual infrastructure: and without it it, you are going to get poorer performance: no doubt about that. But like all infrastructure, it’s easy to not notice it, or to forget about all the effort that went into building it. The one time you do notice it is when it suddenly isn’t there…

It’s really easy to blame yourself here for poorer performance, to think that the poor performance is somehow your fault, your responsibility. But don’t, because without that infrastructure in place, you’re in a situation of ‘reduced response-ability’ – literally, a reduced ability to respond. The responsible action at this point is to deliver the best that you can within the constraints of that inadequate infrastructure, and set out to enhance that infrastructure. Which is exactly what you’re doing. But yes, it will take time, and effort, and everything else.

Getting lost in frustration won’t help. Saying that the infrastructure ‘should’ be there already won’t help. What will help is “be calm, take a deep breath, do baby steps”, and follow the programme. Which is exactly what no-one wants to hear, I know – but unfortunately it is the only way that works.

The need for a quick-start is very real. We need quick results, but above all we need to get the interest and, if possible, real excitement, going right from Day 1. We have to make sure that EA matters to everyone, in their context, their workspace – because without that engagement and excitement, this ain’t goin’ nowhere.

I’ll have to be blunt about this: don’t try to start off straight away with TOGAF, or any of the other ‘heavyweight’ frameworks. They do have very real value, in later stages of EA (though often only in specific sub-domains of EA). But at the start, as that comment in the Twitterstream makes clear, all they’ll do is scare people off. For this earliest stage, we need something simpler.

I usually describe EA-development in terms of six distinct steps:

• Step 0: Get started (initial setup to do EA at all)
• Step 1: What business are we in? (big-picture)
• Step 2: Clean up the mess (horizontal optimisation)
• Step 3: From strategy and execution (top-down)
• Step 4: This is the real-world calling (bottom-up)
• Step 5: Resolving the pain (spiral-out)

TOGAF and the like tend to come into their own in Step 2 and Step 3: the old TOGAF 8 was excellent for Step-2 clean-up of the IT infrastructure and application-landscape, for example, whereas TOGAF 9 is more focussed on Step-3 strategy and the like. But before that happens, we need to have done the Step-1 work of establishing the enterprise-context (which TOGAF’s so-called ‘Business Architecture’ does not do well); and before that, we need to have established, in Step-0, the reason and desire for doing EA at all (which TOGAF’s ‘Vision’ is probably supposed to do, but doesn’t). And it’s in that very first proto-step that PEAF in particular comes into its own.

Do take a look at PEAF’s structure, especially its startup phase. To me at least, PEAF doesn’t compete as such with TOGAF or the like, because it describes what you need to do before going anywhere near any of the ‘heavyweights’.

And what PEAF emphasises is that the very first step after someone in the organisation decides to do something about EA is a first-stage training, education, above all communication. In PEAF, that first-stage introductory workshop includes slidedecks for each of these topics:

• EA – Why I Don’t Need It
• EA – Frameworks
• EA – Enterprise Debt
• EA – Model vs CMDB
• EA – Traits of an Enterprise Architect

It’s structured so that senior execs need be there only for the first few items: in particular “Why you don’t need EA” and the core concept of “Enterprise Debt”. The more detailed information is relevant only to those who need to be more actively involved in everyday EA.

[Notice the unusual negative, 'Why you don't need EA': it's a deliberate 'anti-sell', showing the value of something by being open about where it does not add value - and not presenting it as 'The Answer To Everything', as happens so often elsewhere...]

Perhaps the most crucial point is that there is a step-by-step process here: and it really is important to follow those steps, because that sequence and content is the end-result of a very careful study of what doesn’t work…

The ‘executive’ part of that workshop is no more than half a day; the remainder of that entire process probably doesn’t take much longer than a week of elapsed time. In other words, it’s not a lot of work. But you cannot skip it: more to the point, if you do skip it, you can can guarantee that the enterprise-architecture will be going nowhere, slowly, with a lot of frustration. Your choice, really…

Getting to know the background is also crucial, though most of it will happen after that first ‘Step-0 stage’ proto-step. In the previous post, this is what ‘setting the stage’, ‘finding allies’ and ‘finding the story’ were all about. The summaries from the previous post should be enough to get started: for example, the ‘setting the stage’ theme must include concerns such as identifying vision, values and mission – and also being clear about the crucial difference between ‘the organisation’ and ‘the enterprise’, because they’re not the same.

Another really important point here: don’t fall into the ‘TOGAF Trap’ of describing enterprise IT-architecture (EITA) as ‘enterprise-architecture’ (EA). Everything up to this point has been, and must be, about real whole-enterprise architecture – because we must establish the overall scope before we can focus in on any specific subset such as EITA or security or business-architecture or process-architecture anything else. If we constrain the scope too early, we’re then left with no adequate means to connect to the other domain-architectures – which again would guarantee architectural failure, especially over the longer term.

[This, by the way, is another reason why we don't try to use TOGAF for EA until such time as we do want to focus specifically on the IT-related domains. It's very good for EITA, but way too constrained for real-EA: it's really important to understand the difference!]

The other theme, around principles and standards, is something that we shouldn’t worry about too much until we’ve already gone some way down the track. This is why a question such as “Do you know why PEAF doesn’t have Security and Governance principles examples on this ‘starter-set’?” kind of misses the point. In its current design, PEAF’s primary role is at that Step-0 / Step-1 stage, when we’re still only just starting out: and at that point the only thing we need to say about principles and standards is that we are indeed going to need principles and standards, and how to apply those principles and standards to real-world practice. That’s it. Hence the example-principles in PEAF are just that – they’re examples.

Any competent architect – which you would be, if you’ve been in an EA role for some while elsewhere – will know that yes, we will definitely need Security and Governance principles. But in the early stages – particularly the Step-0 ‘Gain Agreement’ stage of PEAF – all you need to do is add them to that list of examples. It doesn’t need anything more that that, for that stage.

Later on, yes, you’ll need a lot more detail. And that’s the point at which we would start to use something like TOGAF, because it does have a very good descriptions of how to specify principles and define reference-architectures and their related standards. But we don’t try to do that too early: all it’ll do is confuse people, drowning them in too-much-detail and putting them off, just at the point when we need to gain their engagement.

So, quick summary: find a way to live with the frustration, because it’s going to be there for a quite a while, whatever you do; and do settle down to do everything step-by-step, because it is the only way that works.

Hope this helps, anyway.

You’re an experienced enterprise-architect, having spent most your working life in one industry. You now have a new job, in a new company, in an industry that’s entirely new to you. And the company at present has no architecture at all: you’re ‘it’. Where on earth do you start?

That’s the situation my friend Alan finds himself in right now. An interesting challenge – and some very real, very practical questions to face. Right here. Right now. Today.

[I guess this post can also start to answer in part the question from the previous post, 'How do we make EA make sense?'.]

So: in essence, we start from scratch.

Which means that several threads need to start straight away, somewhat in parallel:

• the politics and pragmatics of architecture
• setting the stage – the ‘big-picture‘
• finding allies – people who know ‘the trade’
• establishing standards
• finding the story

The first point is that everything about any form of enterprise-architecture is intensely ‘political’, in several different senses – which means we need to face the politics of this straight away, right from the start. One of the best guides to this is Kevin Smith’s PEAF (Pragmatic Enterprise Architecture Framework). In essence, it’s a step-by-step guide on how to get enterprise-architecture going within an organisation: see the website and book for more details. [Disclaimer: I edited the book.] The details are all there on the website anyway, so you don’t even have to buy anything (though no doubt Kevin would like it if you did! ).

Probably the single most important concern is to get ‘buy-in’ at senior level – certainly from the respective CxO for the main focus area (e.g. the CIO, for enterprise IT-architecture), but preferably from the CEO and entire executive. To be blunt, if you don’t have that ‘buy-in’, you’ll be going nowhere: you need to get the executive on-side.

As PEAF emphasises, the key to getting the executive on-side – and everyone else on-side, too – is communication. One valuable aspect of this is to get them personally engaged in describing the big-picture of the overall ecosystem in which the organisation operates, and where the organisation fits within that ecosystem. In effect, what we would do here is identify the high-level ‘why’ for which the organisation is a ‘how’ – in other words, the ‘why’ that provides the anchor for all of the organisation’s strategy.

There’s a lot of detail on how to do this in the chapter ‘Step 1: Know your business’ in my book Doing Enterprise Architecture – that chapter is part of the ‘sample-ebook’ version that you can download for free from here. (See the post ‘Tools in action‘ for some photos of those techniques in live use in an executive-level workshop.)

What I also usually do is plough through the publicly-available sources such as the organisation’s website, publications, advertisements, intranet and annual-report. There’s usually enough information there to build some preliminary models with which to get started: or at least, enough for people to tell us that the models are wrong – which is a nicely sneaky way of getting them engaged in telling us their ideas about what it should be. :-) You’ll also notice in that ‘Tools in action’ post that we included people’s own photos on some of the larger wall-mounted models: this again is a good way to get people engaged, and to get conversations going between them about what they can do to improve their own work-context.

Whilst we’re doing this, we need to be looking for any allies – people who are already committed to other themes that connect with enterprise-architecture, and would be likely to see the value of synergy between those areas of interest. This is really important if we’ve only just started with the organisation, because – in my experience, anyway – enterprise-architectures depend greatly on person-to-person conversations and connections: knowing who to talk with, and how to talk with them, will depend in turn on backgrounds and credibility and personal-networks within that organisation that typically take at least five or more years to develop.

Those are people we need as allies: and finding them is one of our first and most urgent priorities as soon as we start work at new place. One tactic I’ve used for this is to sit in the cafe or whatever with a few interesting-looking diagrams spread out over the table: anyone who’s interested enough to stop by and chat is likely to be that kind of ‘connector’, or will at least know someone who is. Again, despite all those models and the rest, what really drives the architecture – what makes it happen, in real-world practice – is person-to-person conversations.

Another concern that those allies can help us with straight away is in identifying the standards that apply in the context. Some standards would apply to just about every industry, but we’d be likely to know those already. Other standards will be generic for the industry as a whole, but they’re usually not hard to find: for example, for this case, in retail, a quick web-search on “retail reference architecture” turned up a swathe of IT-oriented standards from Oracle, Microsoft, Cisco and IBM, together with articles on how to put them to practical use. This is also where TOGAF and the other enterprise-architecture ‘usual suspects’ will start to be of real value – though to be honest they can often be more of a hindrance than a help before this stage.

What we’re also looking for are all the other standards and guidelines and workarounds and the like that are specific to this organisation, some of which – perhaps many – may not exist anywhere in any written form. And that again is where our allies can be really helpful, because otherwise we’d have little chance to know what these are. (And yet everyone else would expect us to know them, because, after all, we are ‘the architects’, aren’t we? – we’re the ones who are supposed to know all this stuff… )

And we’ll also need to be on the lookout for standards that should be there, and aren’t. Which can be a little bit tricky, from a political perspective – not least because it tends to highlight issues that people ‘should’ have known about already, and didn’t… Once again, our allies will be invaluable here, in finding suitably-stealthy ways to introduce these ideas, and to smooth out any ruffled-feathers that may arise.

One trap to watch for is to beware of bringing too many assumptions from our previous organisation and industry: many of those assumptions will not work in this new context. The skills and experience of ‘how to do architecture‘ are probably the only part of the work that will remain unchanged: we need to able and willing to challenge ourselves on just about everything other than that.

Almost all of that above is about enterprise-architecture as structure. The other side is about about architecture as story, the second of Matthew Frederick’s ‘two points of view‘ on architecture:

ARCHITECTURE IS AN EXERCISE IN NARRATIVE. Architecture is a vehicle for the telling of stories, a canvas for relaying societal myths, a stage for the theater of everyday life.

Although hardly acknowledged at present in mainstream ‘enterprise’-architecture, this is enormously important: story is emotive; story embeds meaning; story engages. Stories matter: in a very real sense, everything about the architecture is or represents or describes a story. Even the enterprise itself is a story. Which means that it’s well worth while to go ‘looking for the story’, much like a journalist or filmmaker or any other storyteller would.

What I usually do for this is ‘go for a walk’, either metaphorically via the website and intranet and so on, or – preferable – literally go for a walk, in person or with one of my new ‘allies’, around some of the organisation’s sites and spaces, looking for all of those interweaving stories that hold everything together. Some of these stories are straightforward enough: every transit through a business-process is a story; every customer-experience or ‘value-journey’ holds a story; every transaction is part of a story that extends far beyond the transaction itself.

Yet there are also the many stories that employees and others tell themselves, and tell each other, about what works, about what doesn’t, about what is or isn’t valued in practice within the organisation, about workarounds or special-cases that no-one’s gotten round to documenting but without which the store or warehouse or whatever won’t work. Those stories are often really important from a structure-perspective, too.

And there’s the story – or stories – that the organisation tells about itself, about how it positions itself in the market, about what it values most and would most like to share with others; and the stories that others in turn tell about the organisation – including whether they believe that the organisation holds to its purported values. Those last stories are some of the most essential real-world feedback for strategy – which in turn feeds back into changes in structure, in the what and how and where and when of the conventional enterprise-architecture.

Best stop there for now, I guess. But, yes, starting a new architecture is always a real challenge – yet always an interesting and worthwhile one!

I hope this has been useful, anyway: and good luck!

Why is it that some mornings start off with such a flood of ideas and connections that there’s no way to get it all down and done in the day? Hmm…

[One urgent point first: this is not about Cynefin. I'm not going there: don't worry. It's in the title only because I thought that if you're a Cynefin practitioner, and you don't already know Inayatullah's 'Causal Layered Analysis', you may well want to add it to your complexity-toolbox. If so, the SCCC categorisation (Simple, Complicated, Complex, Chaotic) may help you to hook that technique into what you already do. That's it: you can ignore everything else here. Just a friendly Public Service Announcement for you, that's all. ]

As you may have noticed, I’ve been doing a lot of thinking lately about ‘the wrongs of rights‘, and why I think they’re seriously problematic at every scale of an enterprise-architecture.

On Causal Layered Analysis

What came up this morning was a thought that Causal Layered Analysis [CLA] might be a useful tool for ‘the rights problem’. CLA was originally developed by Sohail Inayatullah around a decade ago, and has since expanded into a sizeable body of theory and practice, especially in the futures-domain. For more detail on the practical technique and the ideas behind it, see Sohail’s original paper on CLA (as published in Futures, October 1998) and the Wikipedia article. Here’s the introduction to the paper:

Causal layered analysis is offered as a new futures research method. Its utility is not in predicting the future but in creating transformative spaces for the creation of alternative futures. Causal layered analysis consists of four levels: the litany, social causes, discourse/worldview and myth/metaphor. The challenge is to conduct research that moves up and down these layers of analysis and thus is inclusive of different ways of knowing.

The way that CLA works in practice is indicated by the paper’s subtitle, ’poststructuralism as method’: we apply academic-style ‘deconstruction’ (from linguistic-analysis etc) at each those four layers, or four ‘ways of knowing’, moving up and down the layers to elicit more information and experiences about and views on the overall context.

[Before reading any further here, I'd strongly suggest having a wander through those various materials on CLA - not least because without doing so, much of what follows may not make much sense. ]

The view within ‘the litany’ tends to be a bit simplistic, a very polarised, rule-based and often Other-oriented view of the world – “they should”, “they shouldn’t be allowed to…” and so on - a relentless ‘litany of complaint’. The ‘social causes’ view tends to be a bit more nuanced, more aware of real-world complications; the ‘discourse/worldview’ more complex again; and… Well, you can see where where this is headed, because it obviously suggests a crossmap with the SCCC categorisation of ‘ways of knowing’:

Which is kind of interesting. And which suggests a whole stream of other potentially-useful crossmaps.

[Cynefin practitioners might want to stop reading at this point, because everything onward from here is an exercise in context-space mapping - a different technique. Some of it may look familiar at times, but I should emphasise that it's not 'legitimate Cynefin'. (Probably not 'legitimate CLA' either, but I doubt Sohail would mind as much.)]

Context-space mapping with domains of Causal Layered Analysis

To extend this context-space mapping [CSM], we can identify distinct ‘phase-boundaries’ between the domains in this ‘stack’, such as:

And we can also crossmap those domains with other views – for example, a Jungian-derived set of categories that align well with the CLA set, the set of sensemaking/decisionmaking tactics from the Cynefin framework, and another matching set of decision-drivers:

• ‘the litany’ : Simple : inner-truth (‘Priest’) : “sense, categorise, respond” : rule-based
• ‘social causes’ : Complicated : outer-truth (‘Scientist’) : “sense, analyse, respond” : algorithms
• ‘discourse/worldview’ : Complex : outer-value (Technologist/Magician) : “probe, sense, respond” : experiment, patterns, guidelines
• ‘myth/metaphor’ : Chaotic : inner-value (Artist) : “act, sense, respond” : principles, values

This suggests, for example, that ‘the litany’ would have a strong tendency towards over-certain and over-simplified notions of ‘the Truth’, endless blaming of ‘the Other’ without any form of self-reflection or self-analysis, and knee-jerk responses via over-simple categories, usually predefined by some self-appointed ‘Priest of The Truth’ in an opaque and often literally-unprincipled way. Which might kinda suggest a new verb, ‘to murdoch’, as in ‘to murdoch the truth’? (for which the shorthand might be ‘Fox News’? )

[I'm not saying that's 'the truth', by the way: that would itself be an overly-Simple view. Context-space mapping is more a Chaotic-domain technique, a way to elicit ideas that may be of value in a given context, but they may also not be of value in that context. That's the whole key to understanding CSM: its usefulness, but also its risk, is that it depends on having the skills and experience to determine what is or is not of potential value in a context. Please do take care, because misplaced notions about 'true' or 'not-true' can be disastrously misleading here.]

This crossmap also conflicts quite a bit with the standard Cynefin description of the Chaotic domain that kind-of implies the Chaotic is somewhere we’d usually need to get away from as quickly as possible. The CLA mapping here suggests instead that the Chaotic is a valid and important domain in its own right – somewhere that might well be challenging at a deep personal level, but also where we might want to stay and explore for a while, until the depths get a bit too much and we need to come back elsewhere for air. But notice that in context-space mapping, that kind of apparent-conflict is perfectly okay: both views are ‘true’, the concern is more about which view is useful for a given purpose.

Anyway, at present, this is still a single-axis ‘vertical stack’; yet that last crossmap suggests it’s also a kind of two-axis matrix. To resolve that, we can twist the ‘stack’ into a Cynefin-like layout, with a central ‘the-everything’ domain to remind us that both perspectives are ‘true’:

Which is interesting in itself – for me, at least, because it brings up more ideas about how and where and in what contexts to use CLA, and when to switch between the different types of deconstruction that apply in the respective CLA layers.

Causal Layered Analysis, time-compression and social stress

Previous experience with this type of context-space map also suggests another crossmap-overlay, in this case another vertical axis of timescale, from real-time at the base to infinity at the top:

Which for me is a bit of an eye-opener, with important implications for CLA. The point is that any sensemaking and decisionmaking in the Complex or Complicated domains – ‘discourse/worldview’ or analysis of ‘social causes’ – will take time: a fact that will be painfully obvious to anyone who works in those domains. So as the available time gets squeezed – whether because we’re moving towards real-time anyway, or because of social-panic and similar pressures – we end up being forced more and more into the sensemaking/decisionmaking spaces of the Simple and the Chaotic: otherwise known as CP Snow’s ‘Two Cultures‘, the classic worldviews of the sciences and the arts respectively. (We might also note, using CLA recursively, that the assertions of their respective paradigms become more and more extreme as we move towards real-time.)

What this also suggests is that when a culture is under stress, it will automatically tend towards this kind of ‘Two Cultures’ dichotomy between ‘Truth’ (Simple) versus ‘Value’ (Chaotic) - which, yes, is a dichotomy that itself often becomes over-Simple. The ‘Truth’-meme will tend to dismiss anything ‘not-True’ as ‘anarchic’, but its inherently constrained set of categories will, almost by definition, never be sufficient to deal with inherent-uncertainty: hence the kind of ‘collapse into chaos’ described in the Cynefin model. On the other side, the ‘Value’-meme is – again almost by definition – seemingly unlikely to generate any kind of stable categorisation via which a Simple-domain mode can make sense.

What we see in practice is that as the social stress increases and the links between people fragment, those Simple categories of shared ‘inner-truths’ – “what is True for we” - tend to separate out into self-specific ‘inner-truths’ – “what is True for me‘. This also leads a loss of awareness of the necessary mutuality of responsibilities that underpins all social constructs such as ‘rights’, such that ‘our rights’ becomes reframed solely in terms of ‘my rights’: “we hold these truths to be self-evident” morphs into a self-centred demand to the Other to “hold my truths to be self-evident”, and so on.

And without shared-categories, any social structure based on a Simple ‘sense / categorise / respond’ will by definition start to break down. The usual result is a spiralling descent into an out-of-control litany of complaint, first to ‘What’s in it for me?’, then ‘Me first!’, to a fully self-centred ‘Me-only!’, and eventually a truly chaotic cacophony of ’Me! Me! Me!’ – otherwise known as ‘kiddies’-anarchy’. In a very literal sense, the Simple inherently becomes chaotic. And there doesn’t seem to be any direct ‘truth’-based path back from there, other than via some forceful imposition of rule and rules: either the ‘dictator’s gambit’ or, in rarer cases, the ‘Truth of the Prophet’.

Yet from the opposite side of the ‘truth/value’ dichotomy, what does seem to work is a re-focus on ‘inner-value’, on deep-principles and, especially, deep-myth. It has a surface appearance of the Chaotic, but actually develops its own simplicity: a functional and, often, highly-disciplined form of anarchy, rather than a dysfunctional one. Given that sensemaking/decision-making pattern of ‘act / sense / respond’, the very act of expression often means that whatever arises automatically takes on a social form.

Again, from practical experience, these context-specific images seem to act as ‘seeds’ around which directed action can coalesce – much as would happen in a more usual move into the Complex-domain, except that the time-pressures or social-context pressures mean that it actually remains within the ‘pressure-cooker’ of the Chaotic. The more that the focus can be held in this mode of the Chaotic-domain, te more ideas can be created – and the more the emphasis is held on the decision-making guides of the respective principles and values, the more likely it is that these ideas and images will be experienced as ‘of value’ within that context. The ways in which directed-action can coalesce around these ‘seeds’ can sometimes – perhaps often – lead to enough of a structure to enable a Simple-type ‘sense / categorise / respond’ mode of decisionmaking: in other words, something that is more generally actionable than a highly-personal ‘inner-value’. Which, in turn, can provide enough of an anchor for a more balanced and principles-guided way out of the crisis – a ‘values‘-based way back to ‘truth’.

To summarise this in much shorter form, what this suggests is that the key people in a major social crisis are the artists and the storytellers. The military-commanders and managers and the priests – the ‘truth-holders’ who maintain order – may come to the fore before the collapse, or after the recovery has started: but in the midst of the crisis it is those who normally live close to Chaos to whom the baton must be passed.

A practical summary

Cross-mapping Causal Layered Analysis with the SCCC-categorisation and the ‘now’-to-’infinity’ timescale can deliver some useful insights about how to address high-stress social contexts – such as the kind of ‘mess’ that our entire global economics seems likely to be heading into at present. The main points I see arising from the cross-map include:

• Causal Layered Analysis in likely to be a useful technique in whole-enterprise architecture
• time-compression (reduced time for decisionmaking, often combined with high-contextual stress) is likely to squeeze sensemaking-decisionmaking into a tight dichotomy between Simple and Chaotic SCCC-domains
• Simple delivers consistency under high social-stress, up to a critical collapse-point, and the Chaotic appears to be a potentially-dangerous distraction
• under very high social-stress, Simple tends to collapse into dysfunctional-chaos, whereas Chaotic is usually able to regenerate sufficient basis for rule-structures that restabilise the Simple
• use CLA in the Simple domain (‘the litany’) to identify risk of collapse: the risk increases with increasing social-fragmentation from ‘we’ to ‘me’
• use CLA in the Chaotic-domain (‘myth/metaphor’) to identify and support principles and values that can guide directed action during the peak of the crisis

Some points specific to whole-enterprise architectures:

• identify Chaotic-domain ‘natives’ (people who naturally work at the CLA ‘deep-myth/metaphor’ layer) such as design-thinkers, artists and, especially, story-tellers within the shared-enterprise
• work with these people to identify and express key principles and values within the shared-enterprise that would be viewed as ‘normative’ – i.e. a ‘preferred direction’
  [warning: these principles and values must be allowed to emerge from the collective shared-space, and must be respected as such - they will fail if imposed, or even appear to be imposed, from 'outside']
• ensure that the usual ‘truth-holders’ are aware of and accept that there is a critical point at which they must let go of ‘control’, must allow the Chaotic domain to be what it is, must relinquish authority to the ‘story-tellers’, and must accept and renegotiate with the ‘new order’ that arises out of the ‘guided-chaos’
  [warning: refusal to follow this long-proven success-pattern, or attempts to 'take control' too early in the transit through the Chaotic-domain, will guarantee failure for everyone concerned, including the 'truth-holders']

In effect, this is a method to define a governance-process for use in contexts where a conventional rule-based approach to governance will naturally break down – an interesting architectural recursion!

Anyway, enough for now: over to you for comments/suggestions etc?