• transarchitect: The priority shift we make is from efficiency to effectiveness to co-creativity. #complexity

Of course. Yes. That’s obvious, the moment I look at it.

Except that I’d completely missed before now.

Oops…

I’ve long since drawn a distinction between efficiency and effectiveness. Or rather, that efficiency – ‘doing more with less’, ‘doing things right’ – is only one dimension of effectiveness – ‘doing the right things right’.

[The set of five dimensions that I've used to summarise effectiveness, if you're interested, is efficient, reliable, elegant, appropriate, integrated - see  the slidedeck 'What is effectiveness?' or my book SEMPER & SCORE: enhancing enterprise effectiveness.]

Yet that type of ‘effectiveness’ assumes that there’s some kind of pre-ordained plan – ‘effective in terms of the plan’. What if there isn’t a plan? What if we don’t know what the plan is? What if we’ll only know what the plan was – or sort-of ‘was’ – once we’ve completed it? (‘Retrospective causality’, as a certain person would put it.)

That’s where co-creativity comes into the picture. Co-creating a ‘plan that is no-plan‘, together.

And that’s what I’d missed.

[I can see why I'd missed it: to be blunt, I'm, uh, not good at anything that involves being social, and the whole point and focus of co-creativity is that it's social. But it still doesn't excuse the fact that I shouldn't have missed it. Sigh.]

Yet I’m not the only one who’s missed it: there’s a whole societal shift implied here – a completely different way of working. One that doesn’t assume that there’s ‘The Plan’. One that doesn’t assume that there’s The Person In Control, or The Person Who Knows What’s Going On. Or even that there’s anyone who knows what’s going on. Instead, there’s a trust that co-creation will take us where we want to go: an effectiveness that’s an emergent property of the collective, without any ‘plan’ or pre-certainty at all.

I don’t see this as an ‘either/or’ – either effectiveness-relative-to-a-plan, or co-creation-with-no-plan. It’s more a ‘both/and’ – it seems more an effectiveness that arises from a sort-of plan-that-is-no-plan, one that covers the entirety of the SCAN decision-making space:

The classic ‘efficiency’-based approach is mostly about the left-hand side: assertions about ‘the true metrics’ and so on leads to The Plan which leads to control of actions and decisions at real-time – the Belief ‘domain’. It’s very mechanical – often literally so.

Looking at it now, the approach I’d taken to effectiveness did incorporate a lot more of the right-hand side, with a strong acceptance of various aspects of uncertainty – particularly in the human space, the ‘elegant’-dimension of effectiveness. But it still presumes a plan, an Assertion – and hence that’s where it naturally tends to return.

Co-creativity would seem to focus more on the ‘Use’-domain – literally, “What’s the Use?”. I believe that to work well – to avoid a collapse into a dysfunctional-chaotic free-for-all, a ‘co-non-creation’ – it’d still need some kind of guiding-light or anchor or direction, a shared “What’s the purpose here?”. Yet even that would likely be co-created too – a nice recursion there.

Hmm… A lot to think about. Or, preferably, co-create? Thanks anyway, Bert!

Our organisations often place enormous attention on insubordination, a refusal or failure to follow ‘orders from above’; yet why don’t they place the same level of attention on insuperordination, the refusal or failure to respect the the same relationships and responsibilities to those ‘below’?

For that matter, why do we still prop up the misplaced myths of ‘above’ and ‘below’ anyway? After all, in a service-oriented view of the enterprise, there is no hierarchy - they’re all just mutual peer-level service-relationships, no different in nature from any other. And does anyone benefit from those myths any more? – other than people who need to prop up arbitrary and unwarranted delusions about their own importance?

This came up for me today from three different directions:

• reviewing several posts here on management-architectures, particularly ‘Rethinking the architecture of management‘, ‘Management as ‘just another service’ ‘ and ‘Rebalancing top-down management-architectures‘
• a Tweet from SystemsWiki, pointing to a brilliant HBR paper by Gary Hamel, First, Let’s Fire All The Managers‘ [PDF]
• thinking about ‘bosses’ I’ve known – some good, some not-so-good, and some just plain incompetent

I’ll happily give names to the good ‘bosses’ – Helen Mills at Australia Post, for example, or Graeme Burnett at DSTO. For the others, well, I’d best be a bit more circumspect, hadn’t I? – which is an interesting point in itself…

But there’s one of the latter that comes particularly to mind. It was on a large engineering-project a couple of decades or so ago; almost all of the team were contractors, some of them world-class level, because it was a genuinely innovative system that had to do things that had never been done before. To make it all work, and to hold the team together, we needed a manager at the same kind of skill-level. What they gave us instead was – to be blunt – an incompetent idiot, a classic civil-service time-server, eking out his last years before retirement. Not a good choice…

He was way, way out of his depth and his comfort-zone – a fact that became painfully obvious even before the first day was out. He had no experience or understanding of the inherent anarchy of innovation: as an ex-military-type, all he knew was command-and control. Which really, really, really didn’t work.

We limped on under his endless incompetence for a few months, until one day it all came to a head. At a particularly fraught team-meeting, every one of the contractors blew up at him, saying that he alone was the reason why the project was so far behind schedule; furious, he rushed out, accusing everyone of insubordination, and yelling – and I quote – that “I’ll have all of you frog-marched out of the establishment!”

At that point, the executive realised they needed to intervene, kinda urgently… The team explained to them that whilst, yes, they would perform best with a good manager, they would actually be better off with no manager at all than with this guy. And for once – hooray! – we actually had senior-management who had some real grasp of what was going on – and they agreed. So for the rest of the project, we ran as a self-organised team, without any manager at all.

In short, our incompetent manager had been fired for insuperordination – failing to deliver the required management-services to the level needed within that context.

Looking around at most management-structures, it’s clear that that needs to happen a lot more often…

And this, of course, is where it can get v-e-r-y tricky for enterprise-architects and the like. We can see what’s not working. We can see why it’s not working. We know exactly what to do to get it working again. And yet we’re supposed to pretend that the myths of management-hierarchy are somehow sacrosanct, that insubordination is real and punishable, but insuperordination and plain management-stupidity is not. We’re allowed – in fact required – to ‘fix’ anything and everything except that which is the blatant cause of the problems, namely those myopic myths of management, which we’re not allowed to challenge at all. Hmm… About time we started being honest this, don’t you think?

Implications for enterprise-architecture

Insuperordination isn’t just lack of leadership: it’s a structural failure of the management-model to support essential symmetries of responsibility in mutual service-relationships.

And as a structural flaw – one that has serious impacts on overall enterprise risk – it’s very much a concern for enterprise-architecture.

The key requirement here is to stop thinking in terms of hierarchies. If we take a service-oriented view, it’s clear that management-services have a very real function, as information-aggregators and resource-distributors, dealing with the trade-offs across a functional-silo.

Yet those types of services are not well-suited to managing end-to-end cross-silo process-flows: there needs to be a separate category of coordination-services that handles that task – a fact which immediately implies matrix-relationships of some kind.

And those matrix-relationships need to be peer-to-peer – which doesn’t fit at all with any Taylorist-style concept of top-down management-hierarchies.

In short, top-down ‘command-and-control’ hierarchy is an overlay on top of a tree-structure that arises naturally from aggregator/resource-distributor relationships. The tree-structure provides a genuine service; the hierarchy, all too often, a genuine disservice. Don’t conflate the two structures: they’re not the same.

The way to separate them is that the tree-structure could be viewed in any orientation: top-down, bottom-up, sideways-in, centre-out – it’s all the same. But the hierarchy is always described as top-down: it can’t be made to (seem to) make sense in any other way.

The top-down management-model is essentially a leftover remnant of a supposedly long-dead feudal past, in which position in that hierarchy denotes ‘rights’ to demand subservience on pain of punishment for ‘insubordination’. As a structure based entirely on ‘power-over‘ – with all the dysfunctionality that that implies – it can only be made to seem to work as long as there is no need to engage the ‘subordinates’ actually in the work: “check your brain in at the door” is how one colleague described it. But when the work does require that kind of personal engagement – as is becoming more and more common throughout almost every business context – then the overall system will either operate only at low efficiency, or even fail to operate all, if that ‘conventional’ command-and-control hierarchy is allowed to remain in place.

It’s an architectural choice. Command-and-control hierarchy will only work with low-agility: if we need to preserve command-and-control hierarchies, we will not be able to achieve high-agility in that context. If the organisation – or some part of the organisation – needs high-agility, we must define a structure in which that section of management is peer-based, as ‘just another service’ – and in which the responsibility-failures of insuperordination must be recognised as exactly symmetric with insubordination.

In any given context, we can choose one model, or the other: they don’t mix well, and we can’t have both in the same context – as even current military doctrine [PDF] now makes clear.

If we want our organisations to work, we need to stop pretending that insuperordination doesn’t exist – and instead acknowledge that it’s one of the most serious sources of organisational risk.

That’s the message that we need to give to our enterprise-architecture clients.

Challenging, yes – but it’s the only way that this is going to work.

Comments/suggestions, anyone?

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.

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?

Uh… probably that ‘The Plan’ is that there isn’t one? In fact that’s the whole point?

(Or, if you simply must have a plan, I could paraphrase a former colleague and say that the plan is to not have a specific plan.)

Why? Simple reason, really: the purpose of a plan is to control something. And since ‘control’ is itself little more than a rather forlorn myth – especially in this kind of context – then it really doesn’t make sense to have a plan, because ‘control’ doesn’t make sense either.

I do have a sense of the direction I’m headed, though. Call that ‘a plan’, if you like. Sort-of.

It’s still enterprise-architecture. But a much bigger view of enterprise-architecture than you’d normally see associated with that term.

[As an aside, one of the joys of this shift is that I won't have to waste any more time arguing with the IT-obsessed and, now, the business-obsessed, about their misuse of the term 'enterprise-architecture'. I know it's wrong, they know it's wrong, everyone knows it's wrong, and just about everyone knows the damage that that term-hijack is causing, too. But hey, if they really need to keep on 'pissin' in the pool', best to just leave 'em to it, I guess. At least when you come here, you do know that when I talk about 'enterprise architecture', I do mean 'enterprise', and 'architecture', and the way they fit together - and not some piddling point about how two IT-boxes talk to each other. Unless we do need to talk about that. Which we do sometimes, of course. ]

What I’m really aiming at is the architecture of the biggest enterprise we have: the human enterprise. All of it. Which takes place within a broader ecosystem, usually referred to as ‘this planet’ or suchlike. Which is, yes, kinda big…

[In Twitter and elsewhere I'll use the hashtag #rbpea to indicate this type of 'Really-Big-Picture Enterprise-Architecture'.]

Why? It’s because I can see there are some big, big, BIG architecture-type questions that just about no-one else seems to have addressed so far, if at all. Or even noticed, in most cases. Kind of ‘oops…’, if you like. A very big ‘oops…’.

Which means that someone needs to be doing something about that ‘very big oops…’. And I look around, and I can’t see anyone else doing it, or putting their hand up to do it. Which, uh, kinda suggests that it’s my turn to do something about it. Yikes… Yeah, kinda challenging, coming face to face with that…

It doesn’t mean I’ll necessarily be much good at it: others would probably be a lot better for this than I am, no doubt about that. But it’s clear that someone needs to hold the fort for now: and right now that ‘someone’ seems to be me. Oh well…

I certainly don’t claim to have ‘the Answers’; at the moment I’d barely claim to have more than a few good questions. But at least it’s something. And I do have some relevant skills and experience, so in that sense I do have some ’response-ability’ here. Hence, in that sense, my responsibility.

So that’s the ‘plan’, really: be responsible. See what I see, hear what I hear, feel what I feel, and then literally ‘be response-able’ about that. Be like Wangari Maathai’s hummingbird – or perhaps, in my case, more like a weary, wary old toad – just doing the best I can.

Not a big plan. Not a complicated plan, with a nice big complicated roadmap from ‘as-is’ to ‘to-be’ and crop-circles an’ all that, like what all those real, proper certififificateded enterprise-architects do.

But a plan. Sort-of.

Hmm…

There’s one part of this plan, though, that a fair few people may not like – and I perhaps ought to apologise for that in advance. (Though might be better to just stop apologising for everything anyway?) It’s just that being responsible also means being honest: and being honest about what I see is going to annoy a few folks – because to be blunt there are a heck of a lot of ideas and actions out there that are just plain dumb. Stupid: the definitely-not-a-good-idea kind of stupid. Often the darn-lucky-if-we-survive-this-one kind of really stupid, too. Sorry, but it’s true.

One example of that kind of ‘really-stupid’ is the notion of ‘rights‘, which just does not and cannot work, no matter how much people try to kludge to make it it look as if it does. It’s bullshit: it’s a ‘kiddies-anarchy’ view of the world, built around evasion of any notion of responsibility. And we need to stop pretending that it’s anything more than that – so that we then do have a chance to rebuild something that actually can and does work.

Ditto the entirety of what’s laughably called ‘economics‘. Ditto the whole notion of ‘intellectual property’ – or most any current form of so-called ‘property’, for that matter. Ditto, behind it, the entire concept of ‘possession‘. All of us know it’s all bullshit, a made-up fantasy to prop up the pretences of people whose idea of ‘making a living’ consists almost entirely of untrammelled theft – an ‘economy’ based on theft-without-end. Gosh: that’s an ‘economy’??? – doesn’t look like one to me… not in any sane sense of ‘economy’ that I’ve ever heard of, anyway… So why not say so? – before we really do all end up in drowning in this bullshit?

Sigh.

In that old fable of ‘the Emperor has no clothes’, it’s a naive kid that unknowingly calls everyone’s bluff, by saying the truth about what he see. But I’ve come to realise that in reality it isn’t some innocent kid: it’s a grumpy old toad like me. Which means that sometimes – often, perhaps – some people ain’t gonna like what I say about what I see. Too bad. Sorry, ’bout that, but there ’tis: there are only two choices here – it’s either be honest, or don’t bother, and from now on I’m a lot clearer about which one of those two I need to pick.

One thing I won’t do is put anyone else down. I’ll challenge the bullshit whenever I see it, and challenge hard about it at times (and expect others to challenge me about that, too): but it’ll always be about the ideas, the thinking, the action – not the person. I promise you that. So if you find yourself ‘taking it personally’ about something I’ve said, please look closely at yourself first, and before you come out all-guns-blazing at me – because it’s in that ‘taking it personal’ that you’re most likely to learn the most, and most likely to find out who you truly are.

Anyway, down to it. That’s the plan, sort-of. And yes, there’s a lot to do – and a lot to talk about with you, too, if you wish?

Quite a lot, as it happens. There are a fair few models that are explicitly designed to tackle this rebalance problem, and plenty of practical real-world tactics, too. In this post I’ll summarise the mechanisms that support this in Stafford Beer’s Viable System Model; a real example from the 1960s that uses some of the same principles as in the VSM; and two more recent examples, one from an engineering research-laboratory, the other from current Army doctrine and practice.

(Not too long this time, I hope?)

Viable System Model

Stafford Beer’s Viable System Model [VSM] was first developed back in the early 1970s. It’s well-established, well-proven, and applicable to any size of organisation – including the management of the economy of an entire country. At first glance, though, it looks like a straightforward Taylorist-style hierarchy, with the system-3/4/5 cluster as ‘the management’, and system-1 as ‘the workers’, each connecting in their own ways to the ‘cloud’ of the real-world:

Unfortunately this early diagram from the Wikipedia site, based on Beer’s original notes, is actually more than a bit misleading, because some of the most fundamental concepts of the model are not obvious, or not shown at all.

The first key point is that the model is fractal: the pattern repeats in a ‘self-similar’ way at every level. In that sense, everything is actually a ‘system-1′: whatever it looks like, whatever ‘system’-label it might have, it delivers some kind of service. Conversely, every ‘system’ or service contains within itself, in some form or other, the whole of this pattern: hence a ‘system-1′ delivery-service also contains its own element of ‘system-5′, ‘Decisions to maintain identity’ and purpose – in other words, more like Deming than Taylor.

Next, ‘system-2′, the set of services for inter-service coordination and ‘Tactical planning’, is not bundled into the ‘management’-cluster; and neither is ‘system-3*’, ‘Audit’ (which I usually expand to what I call ‘validation-services’). In effect, they’re orthogonal both to the ‘system-3/4/5′ management-cluster, and to each other:

If we try to hold to a strict Taylorist model of management, we would either have to subsume all of these functions into ‘management’ – where they really don’t work, because they need to be independent of management, even by law in some ‘system-3*’ cases – or else we’re likely to find ourselves with lots of fights and arguments from ‘system-3′ middle-managers about ‘insubordination’ by ‘system-2′ and ‘system-3*’.

To make this work, we need a structure that acknowledges the semi-autonomy of ‘system-2′ – particularly for cross-silo coordination and cross-domain change-programmes. It also must acknowledge the even greater autonomy of ‘system-3*’ – which does link strongly with the management-services, but usually at least one more levels ‘above’ its nominal level. In the inter-service relationships in Enterprise Canvas, this expands out a bit as the full set of services in the overall ‘Guidance’ cluster, where ‘system-3/4/5′ are the direction-services, ‘system-2′ the coordination-services, and an expanded ‘system-3*’ as the validation-services:

Yet there’s one more element in the VSM model that appears briefly in that VSM diagram earlier above, yet isn’t properly explained: a link that Beer describes as an algedonic connection. (It isn’t separately documented in Enterprise Canvas because in effect it’s just another type of inter-service connection.) The term literally means ‘pain/pleasure’, but the point is that it allows an ‘any-to-any’ connection that may bypass the ‘official-channels’ of the entire management-hierarchy, linking right from ‘bottom’ to ‘top’ if necessary. It’s typically reserved for emergencies, but it needs to be present if the overall system is to be viable.

That’s the core of the theory, anyway: let’s see how it works in practice.

Management on an aircraft-carrier

I came across this example more than forty years ago, in an article in Scientific American in the senior-school library, and it was one of the things that first got me started me thinking about enterprise-architectures.

The article was about management-structures in high-stress environments: the aircraft-carrier was one of four examples discussed. (Another was electricity power-distribution, but I can’t remember the other two.) The key point was that they all had much the same type of organisational structure, which we might describe as ‘hierarchy/flat’. Each environment maintained a very strict hierarchy, with defined ranks and roles, each with their own explicitly-defined responsibilities and reporting-relationships – so at first glance, the naval ranks on the aircraft carrier might seem little different in structure from those back in the dark days of Sir Cloudesley Shovell. Unlike in Sir Cloudesley’s time, though, the management-structures also supported ‘any-to-any’ links: even the lowest of ‘erks’ on the aircraft-carrier had not only the authority but the duty to go over the heads of their immediate officers and talk direct to the admiral if necessary – and the admiral and everyone else had an explicit duty to listen, too. In general, ‘any-to-any’ communication was reserved for emergencies only, and the ‘erk’ would need to be able to give fair reason to have bypassed ‘official channels’: but there are so many unexpected and unpredictable things that can go wrong on an aircraft-carrier that that option definitely needed to be in place – with official support and sanction.

(Another type of algedonic link common in many present-day organisations is an ‘open email-address’ for the CEO and other executives, that employees can write to, and expect an in-person answer.)

And whilst the Taylorist-style system of ‘ranks’ was strictly enforced, there were also explicit rules and rituals that emphasised that everyone was also equal. One example was that everyone – the admiral included – had to do their turn at the tedious task of ‘FOD’, or ‘foreign-object detection’: everyone in a line, shoulder-to-shoulder across the full width of the flight-deck, walking slowly along the whole length of the ship, to search for loose bolts or bits of wire that could puncture a tyre or end up in an aircraft-engine. Another example was that everyone, right down to the newest recruit, would each have their own birthday-cake baked for them by the ship’s cooks: the personal element of this was deemed so essential for morale that the admirals forcefully overruled an attempt by the Navy’s bean-counters to save money by getting the cakes pre-baked on-shore.

So that’s a ‘hierarchy/flat’ management-structure, designed to balance the need for clear command with the need to manage a wide range of largely-unpredictable emergencies. In the aircraft-carrier example it pre-dates VSM by a decade or two, but it should be clear, I think, that the same overall principles do apply.

Engineers and fitters in a research-laboratory

During one part of my aptly-named ‘career’, I worked for some years as a contract software-developer at an engineering research-lab. During that time I got to know well the fitters and toolmakers who constructed all of the test-rigs and other equipment used in the engineering experiments. I gained a lot of respect for their skills, and so did most other people at the lab – though for some of them that happened only after an interestingly subtle ‘teaching-ritual’…

Each year, the lab took on a new crop of graduate engineers. And each year, at the end of summer, they would arrive with their shiny new degree-certificates, certain that as now-qualified engineers they knew everything that there was to know about engineering. Unfortunately, almost all of them would assume that, solely because they’d had formal academic and analytic training, by definition they must know much more about engineering than any of the lowly ‘workers’ in the toolroom. Some of those new graduates were quite startlingly arrogant at first: in classic Taylorist tradition, they would give orders, and demand that others should follow those orders to the letter.

In reality, though, there are other kinds of knowledge than the purely academic: and if those new graduates were to become of any practical value as engineers, they needed to understand and respect that other knowledge. So each year, with the agreement of the lab’s senior management, the toolroom foreman would order a strange ‘work-to-rule’: the fitters were instructed to create equipment exactly as specified – even if it didn’t make sense.

The results of the work-to-rule were, often, uh, interesting… One new graduate delivered a design for a rotating component that specified a zero tolerance on both sides – which couldn’t be built on any equipment in the toolshop, and even if it could, it wouldn’t be able to rotate. Another graduate came in with a design whose components could all be made – but couldn’t be assembled, because there was no clearance to get in to tighten the bolts.

In most cases the new graduates immediately blamed the fitters for all of the problems: after all, the world should conform to our designs, shouldn’t it? The foreman would take each of the complainants aside and, uh, gently introduce them to the other side of engineering, about how to make things work in the Real World – about which the fitters knew a lot more than the new graduates did. If the graduates didn’t listen, or didn’t stop blaming everyone else… well, they soon found that it wasn’t just the foreman, the senior management were serious about this too – so serious about it that some of the graduates were politely requested by HR to find another job elsewhere.

The practical point was that the new engineers soon learnt that theory only goes so far: they needed the help and hands-on experience of the fitters in order to come up with designs that would actually work as intended. In a matter of months at most, we would see the new engineers working closely with the toolroom crew, in most cases developing strong mutual respect. Theory needs realism, and hands-on knowledge needs the support of a solid frame of theory – because in the real world, neither works well enough on its own. Overall, this was a deliberate process intended to create an appropriate balance between the two.

Officer-training in the Army

My niece’s husband is a career-soldier who’s now seen front-line service in a fair few conflict-zones. He’s now in his mid-30s, but by choice he’s still a sergeant: he’s been offered promotion, and even went on a officer-selection course at one stage, but he turned it down because, as he said, they seemed more concerned about which knife to use at a formal dinner than a knife he might have to use in combat. But he’s a good leader of ‘grunts’, and a very good trainer: and the army won’t let those skills to waste. So he now has a new job: teaching officer-cadets about the realities of the battlefield.

One of the first realities is that, despite what those officers might believe about themselves after leaving training-college, they’ll know almost nothing about the real world of the army under real-life conditions. What little they do know is often just enough to put everyone in real danger: a new lieutenant with those shiny new pips on his shoulders and an urgent need to prove himself will be a real risk to his platoon, especially out on armed patrol in unfriendly territory. That first year or so as an officer is, in essence, the first real part of his training: and it’s the troops under his nominal ‘command’ that are his trainers. And if our bright young lieutenant doesn’t get it that his job is to support them – not the other way round – then he’ll soon be pulled back to a desk-job for the rest of his life in the army – preferably before he gets anyone killed…

There’s a strong myth that the military is a rigid Taylorist-style tree-structure: generals give commands to colonels who give commands to captains, and on down to the ‘private soldier’ who must follow without question the orders of everyone else, and can never answer back. It’s true there’s still a strong element of that: but it’s there for the same reason as the ranks on the aircraft-carrier, because in a crisis – and the whole point of an army is that it does deal with crises – everyone will need to know their roles and responsibilities, and what to do to keep things on track. But the blunt fact is that rigid top-down command doesn’t work: that was the lethal lesson of the Charge of the Light Brigade. And in the complexities of current combat in counter-insurgency and the like, where every action or inaction by any soldier can have political as well as military consequences, there’s a real need to get a better balance between the aims of top-down strategy and the realities coming back up moment-by-moment from ‘the sharp end’.

Hence my nephew-in-law’s task, getting young officers ready for that reality. And hence, too, some radical revisions of military field-doctrine – such as the US Army’s ‘FM 5-0 Operations Process’ manual, using a much more fluid ‘design-thinking’ approach centred on ‘Commander’s Intent’ rather than explicit point-by-point command.

In effect, what we see now in many military command-structures is less like the old Victorian ‘command and control’, but something much more like a value-network or service-network in a service-oriented whole-enterprise architecture – the Services as literal services.

Summary

All of these are real cases where the organisation’s management, and management-structures, created a context in which top-down Taylorist theory could meet with Deming-style bottom-up practice, and together reach a mutual balance that would best serve the needs of the overall enterprise.

Yes, in each case, the hierarchy of ranks is still there: but that structure is there  for a valid reason, rather than solely as an expression of someone’s over-inflated ego… An important difference – and an important lesson that many businesses could also usefully learn?

This came up in a comment to the previous post ‘Why are the elite the elite?‘ The notion of ‘just another service’ is worth exploring more – especially as it has corollaries and implications that do have serious impacts on enterprise effectiveness.

(Just to make things clear: this is about enterprise architecture, not politics. Yes, as we’ll see, there are some significant sociopolitical ramifications from this, but that isn’t the focus here: the primary purpose is to explore some of the practical issues we encounter when scaling up a service-oriented architecture to a full whole-of-enterprise scope.)

Although I’ve said ‘enterprise’ above, what we’re dealing with here is mainly about management within ‘the organisation’ (organisation and enterprise are not the same).

What we’re actually dealing with is a paradigm-problem. On the one side, there are two fundamentally-different concepts of the organisation: organisation-as-machine, typified by Taylorism and the like; and organisation-as-living-organism, typified by various ‘systemic’ views such as those from Deming, Senge or Beer.

These two perspectives lead to two fundamentally-different views of the nature and role of management – which in turn have, as above, significant sociopolitical ramifications. But to get there, and to contrast those two views, we first need to do a couple of side-steps.

One of these side-steps is about purpose and the organisation.

In the machine-view, purpose is extrinsic: the purpose of the organisation is defined from outside the organisation. It’s just a machine: everything and everyone within it is, by definition, just another ‘purpose-free’ component of that machine. The machine itself is guided – or defined, perhaps – by the aims of the organisation’s owners, who provide the capital for ‘the enterprise’ and “the animal spirits of the entrepreneur” to set it in motion.

In the organism-view, purpose is intrinsic: the purpose of the organisation is defined from within the organisation. The biological metaphor here is the urge the survive and thrive, within a broader ‘enterprise’ represented by the ecosystem within which the entity exists. The organism is self-guided, self-directed, largely autonomous in the literal sense of ‘self-defined’ or ‘self-owned’. The classical concept of an external ‘owner’ doesn’t really make sense here – other than by stretching the view to include a metaphoric ‘farmer’, perhaps.

Which brings us to another related side-step about owners and rulers and property, because there are two fundamentally-different concepts there as well: feudal/hierarchical versus free-form/ecosystem.

(Note that this won’t suggest that one is somehow inherently ‘better’ than the other: they’re not. It’s more about ‘fit’ to the requirements of the context – ‘better’ only in a contextual sense, not an ‘absolute’ one. If you’re familiar with Spiral Dynamics model of social contexts, feudal/hierarchical is essentially Red/Blue, nowadays with a thin veneer of Orange; free-form/ecosystem requires system-awareness, and hence is in the Gold/Turquoise range. [Ignore the 'historical determinism' in Spiral Dynamics, by the way: to be blunt, it's garbage. But the core 'vMeme' model is sound, and can be very useful as a cultural-assessment frame in enterprise-architectures.])

A feudal/hierarchical culture is one in which there are strict relationships (‘fealty’) of roles that are ‘above’ or ‘below’ each other, and that identify respective authority, ‘rights’, responsibilities. A true feudal model has a single ruler (‘monarch’) at the ‘top’ of relationship-tree; a more literal hierarchy instead has some form of abstract concept (such as ‘God’, or ‘the Law’) that is nominally ‘above’ all others, but in essence and in practice comes to much the same as a feudal model. In both variants, each ‘inferior’ is the ‘subject’ of the respective ‘superior’ – literally, classed as a semi-autonomous extension of the ‘superior’, with no independent identity, existence or will.

(For an extreme near-present-day example, consider Gadaffi’s Libya, with Gadaffi himself as ‘Brother Leader’ who thinks for all, decides for all, and possesses all – and whose merest whim is Law. In principle, if fortunately not so much in practice, the Pope provides much the same role for the Catholic Church – subject only to the perceived ‘will of God’.)

‘Modern’ capitalism arose in the late 17th and early 18th centuries, in cultures that in essence were still largely feudal – in practice, at least, if not necessarily in theory. Aristocrats still held most of the land; but increasingly, the new merchant class held most of the money, and hence could claim a near-equal stake at the top of the tree-of-control. Beneath them in the tree were a wide range of agents: the bailiff, the steward, the factor, and so on. In modern-day parlance, these were the ‘managers’. And beneath them, as the ‘subjects’ of everyone else, were the ‘workers’ – the providers of Labour, to use the term from classic capitalism.

Taylorism in essence reflects and embodies exactly this type of feudal model: a rigid three-tier class-hierarchy. At the top we have the owners, who actually don’t get much of a mention in Taylorism as such: they set the purpose for the ‘machine’, issue commands accordingly, and are deemed to have the exclusive ‘right of possession’ over everything and everyone else. (Note, though, that with the invention of the ‘limited-liability company’ and other related changes in law, the old feudal mutuality of responsibilities is gone: all others are still responsible to the owners, but not the owners to their ‘vassals’ or to anyone else. In effect, the ‘social contract’ becomes one-way only: an obvious huge kurtosis-risk that few now seem willing to acknowledge…) Beneath them we have the managers, who in Taylorism do all the thinking for the ‘machine’, and maintain control: they interpret the wishes of the owners, and relay them as orders to those who in turn are ‘beneath’ them. And at the base of the tree, we have the workers, who do all of the ‘doing’ of the ‘machine’, and in essence are classed as mindless robots, subjects of everyone else’s ‘rights’ to ‘command and control’.

So in Taylorism, as in the Victorian battlefield, everyone has a fixed role in a fixed structure of top-down ‘command and control’ – owners own; managers think; workers do – and no-one can move outside of those preordained roles. Everything and everyone is a component within ‘the machine’.

By contrast to all of this, the ecosystem-model has no hierarchy at all: no-one has ‘rulership’ over anything else, there’s no command, and in many ways there’s no control either. The organism or ecosystem simply is. Sometimes there’s no real order as such – as in a colony of extremophile bacteria, for example. Often, though, there is some form of apparent order or collective purpose that emerges from the interactions in the overall context: the structure of a human body is one example of which we all have direct first-hand knowledge. Within a human body, it doesn’t make sense to use a ‘rulership’ metaphor, that “the heart rules the head”, for example, or “the kidneys rule the throat”. (Okay, people may well use such metaphors, but they don’t actually make sense in physiological terms, anyway…) Instead, the most accurate metaphor is that each cell and organ and structure offers its services in support of the whole.

So: what next? – especially in relation to the organisation and its management?

On the one side, we have the machine-metaphor. In Taylorism and the like, this aligns with a feudal-style tree-structure of ‘command and control’, a hierarchy of ‘bosses’ and ‘subordinates’. All of this is bounded by predefined rules and algorithms – hence ‘scientific management’. Everything and everyone is considered only to be a component – a nested structure of components within components within components.

On the other side, we have the living-organism metaphor. This aligns with a network-type structure, often with fluid roles and dynamic changes in relationship and connection. There is no identifiable hierarchy as such; instead, relative ‘positioning’ tends to be derived in an emergent way from the interaction of the whole. Instead of predefined roles, each entity – at every level of granularity or decomposition – offers services that contribute in some way to the emergent workings of the whole.

So how do these two models apply in the real world?

On the surface, most organisations still seem to use the machine-metaphor: there are explicit ranks, each with authority ‘over’ others, and so on. The nominal role of management is still a Taylorist ‘command and control’.

However this type of structure is very unwieldy, and slow to respond to change – certainly far too unwieldy for anything involving fast real-time action or real-time change. Even armies don’t use it any more – not on the battlefield, anyway, where ‘command and control’ has long since been replaced by a much more free-form ‘Commander’s Intent’. The same applies in Agile-style product-development, or in successful customer-service: the classic ‘command and control’ call-centre is frankly despised by almost everyone, especially those who struggle to survive within them…

So in practice, most organisations still present themselves as top-down command-and-control. But the reality is that, other than in a few quite narrow contexts, that isn’t how they actually work. Instead, to get the speed of response that’s needed in a real-time world, just about everything is structured around services – except for management, which still tries to cling on to command-and-control.

One of the real problems is that if we move to a service-oriented model – which we need in order to support the required agility and emergence in the market-’ecosystem’ – one of the crucial side-effects is that management can no longer be viewed as ‘special and different’. It’s not like the hierarchies of Taylorism: a service-architecture is a network-structure with no top, no bottom, and usually no identifiable centre either. In a true service-model, management is just another service, one that happens to provide management-type services to the whole. (I’ve described those services in some depth back in the various posts on Enterprise Canvas, hence no need to repeat it all again here?) And since in a service-architecture there’s no hierarchy-tree, no top, no bottom, no centre, management has no reason whatsoever to try to claim automatic or inherent priority over anyone or anything else: it’s just another service.

In a classic business-architecture, the first thing we usually do is try to map out the ‘org-chart’. What we discover very quickly is that that tells us almost nothing about how the work is actually organised. To get any sense of what’s really going on, and what and how and why anything connects with anything else, our best bet is to turn to a enterprise-architecture that starts from one very simple principle: that everywhere and nowhere is the centre, all at the same time. In other words, a strategy that leads naturally into a service-oriented approach to the architecture.

That’s pretty much where we’re at now with enterprise-architecture, and why a service-oriented approach to the architecture gives the best fit for most current business needs. But we keep on hitting up against that huge stumbling-block and bottleneck that we’re apparently not supposed to notice: namely that the hierarchical concept of management, that everyone seems to want to cling on to, simply does not make sense any more. Instead, the only thing that does make sense is the view that management is just another service, no different in rank or priority or the like from anything else.

Unfortunately, the political ramifications of that fact are huge. For example, if management is ‘just another service’, is there any reason why self-styled ‘senior management’ should always get the top floor and the highest pay? The short answer is no: no reason whatsoever. Oops… Think that blunt fact will be resisted – especially by those who currently claim to have the ‘right’ of command-and-control over all others? You betcha… and it won’t matter one jot that that kind of clinging-on to something that doesn’t make sense will make things worse for everyone, including themselves. It’s very, very hard to let go of privilege, of a sense of certainty in entitlement – especially when the blunt reality is that never were any real defensible grounds for that privilege in the first place. Tricky, that one… very difficult indeed…

Yet before you launch at me with some arbitrary accusation that I’m some kind of crazy ‘communist’ or ‘socialist’ or ‘anarchist’ or the like (okay, as an architect I might perhaps accept the ‘business-anarchist‘ label… ), notice that this is not about politics. It’s only about architecture – nothing else. All that I’m saying here is that a service-oriented architecture points us inevitably at the blunt fact that management is ‘just another service’. What we do with that ‘blunt fact’ is another question entirely: but that it is a fact is not in question.

Hope that makes a bit more sense, anyway?

This came up in a tweet yesterday from the Open Group Brazil’s Isabela Abreu, pointing a recent HBR article, ‘The Deepest Deficit: Trust‘:

It’s not surprising that business leaders are held in such low esteem when each and every day, it seems, brings a new corporate scandal. However, these transgressions and their impact on public perception illustrate not merely a crisis of business leadership, but something much more profound. For if Joe Public loses faith in the leadership and legitimacy more generally of our political and economic institutions, we are in deep trouble — our whole system and way of life at risk. Democratic capitalism relies upon trust in order to function, unlike authoritarian systems which substitute fear for trust. The positive challenge, then, is to re-establish the social conditions for trust and to redefine leadership in this new world.

To me that makes a lot of sense, so I sent out a re-tweet of Isabela’s post, with an addendum about the EA perspective:

• Bebela239: RT @HarvardBiz: The Deepest Deficit: Trust http://s.hbr.org/pkfWEe >trust is key in #entarch #economics – if trust is lost, so is the enterprise

To which Australian enterprise-architect Mike Aikins replied:

• AussiMike: @tetradian hmm…not clear to me why entarch is any different from the human condition..we rely on trust to interconnect..

Which, of course, is entirely true:

• tetradian: @AussiMike “not clear to me why entarch is any different from the human condition” – it isn’t. that’s the whole point. // (…or, we need to ask why biz so often thinks it is different from ‘the human condition’… )

From an enterprise-architecture perspective – with proper distinctions between ‘organisation’ and ‘enterprise’ – the functioning of the organisation’s overall business-model should run in a virtuous-cycle something like this:

Everything starts from trust – or from reputation, which in effect is secondhand trust. Each transit through the business-model should reaffirm-trust, building and maintaining that virtuous-cycle.

Yet this assumes an ‘outside-in’ perspective, where the organisation understands its subordinate relationship to the broader-scope enterprise. The danger is that in a conventional self-centric or ‘inside-out’ perspective – “What do we have that we can sell? Who can we sell it to? How can we sell it? How do we make money?” – only a subset of this cycle may be visible: and that subset doesn’t include awareness of the centrality of trust. Instead, like the schoolroom bully, it ignores the need for trust, and thinks that a crude demand for attention is an adequate substitute for real respect. Oops…

One of the problems here is that there are three distinct choice-points with the ‘Completions’ phase of the cycle: completion of the task, completion for self, and completion for the overall enterprise. A loop-back is possible at each of those choice-points – but they return to different places in the market-cycle:

In a production environment, we’re likely to want to go back straightaway to the next task as soon as the current task is complete. And much of the time, that’s fine – but not every time, otherwise we end up producing and producing for no actual purpose other than production itself.

In a business environment, there’s huge pressure to go straightaway back to the start of the next sale as soon as we’ve been paid for this one (‘completion for self’). Churning our way as fast as possible through the sales-cycle – grab the attention, do the sale, get paid – is what brings in the best short-term profit: there’s no doubt about that at all. And much of the time, that’s fine too – but not every time. The keyword there is short-term, because it doesn’t work in the long-term – in fact, on its own, this kind of tactic is often what’s known as a kurtosis-risk, in which the losses incurred when the risk eventuates in the longer-term will exceed the total of all the previous shorter-term gains. As a model for ‘the business of the business’, this could best be described as ‘pass the parcel’, where the parcel consists of a Russian-roulette time-bomb that will explode without apparent warning – a profitable game for the protected players on the stock-exchange, perhaps, but not for anyone else… Spinning through the quick-profit short-cut on the market cycle is a lot more risky than most business-folks seem to acknowledge…

(It’s true that it’s a risk that can often be mitigated to manageable levels as long as we do remember to take time-out every now and then – and often enough – to reset the timer on that time-bomb. That’s the point of what we’re exploring here. If no-one can be bothered… well, there’d be not be much reason to complain when the whole thing goes ‘boom’, would there? )

To make the business-model work as a whole, it must be constructed ‘outside-in’ – starting from the shared-enterprise, not from the perspective of the organisation alone. And it must connect with the whole of the market-cycle. To do that, the complete business-model must ensure that it establishes and verifies ‘completion for the enterprise’: not just ‘customer-satisfaction’ and the like for the organisation’s immediate business-partners, but satisfaction for the non-clients further out in the shared-enterprise, and, wherever possible, satisfaction for the organisation’s ‘anti-clients‘ too.

Trust is the key to the enterprise. Without trust, the enterprise dies – or, at the very least, the organisation’s place within that enterprise will die. Hence trust is kind of an important concern in an enterprise-architecture…

So as enterprise-architects, what can we do about this? One practical suggestion is to apply the market-cycle to the modelling of every type of transaction and process – including IT-only transactions:

• Before we start in this business-process, how do we establish trust, and reputation?
• How do we establish and maintain relationships based on real mutual respect?
• How do we establish conversations that enable genuine attention? (Note that shouting louder than anyone else – as in classic advertising and ‘marketing’ – can sort-of garner others’ attention, but in a way that usually prevents true conversation…)
• How do we establish and enact the transaction and exchange? (That part is usually well-understood in current enterprise-architectures, process-models and the like, but it often needs review in relation to everything else in the market-cycle.)
• How do we identify and verify completion and closure for the transaction itself? (Ditto, and ditto re need for architectural review.)
• How do we identify and verify completion and closure from the organisation’s perspective? For example, how do we ensure that we get paid, that compliance with all legal and regulatory responsibilities is assured, and so on? (This part is usually addressed in current architectures, but often in a very disjointed way – domain by domain – and also not integrated across the organisation or even with the related transactions.)
• How do we identify and verify completion and closure from the perspective of the overall shared-enterprise? (Seemingly rarely addressed at all – especially in relation to automated transactions.)
• How do we ensure that everything within this transit through the market-cycle will maintain and enhance the organisation’s reputation and trust within the shared-enterprise, and of the shared-enterprise as a whole?

And yes, this kind of enquiry is likely to be, uh, political… but as enterprise-architects, that’s an inescapable part of our professional responsibilities towards the organisation and the broader shared-enterprise. Sorry, but there ain’t no way to sidestep that and still do the job properly…

One of the most serious sources of ‘political’ problems here is that at present, far too often, systems and structures are built upon an assumption that ‘win/lose’ is the only game in town – or, worse, the assumption that the only way I can ‘win’ is by making you lose. In reality, there are only two choices: either everyone wins from each transaction, throughout the overall shared-enterprise; or, in the longer term, everyone loses. ‘Win/lose’ is actually an illusory form of lose/lose, in which the short-term gains for one player mask an overall longer-term loss for all – in other words, another form of kurtosis risk. ‘Win/lose’ may seem to be the norm at present, but it’s bad news for everyone…

So in every architectural assessment, watch for any point where trust is uncertain, or is at risk of being lost. In each architectural design, look for options that can maintain, protect and enhance trust, and keep the market-cycle building, in a virtuous-circle.

Simple, really. Though rarely easy, of course…

Comments, anyone?

(I perhaps ought to say ‘completed and published’, but as you’ll see, ‘completing’ isn’t quite the right word, since much of the content is made up of story-fragments that could be assembled in just about any order.)

At present you can download the full content in PDF format for free from the Tetradian Books website.

More details and background to follow, but for now, here’s the book-blurb:

“Yabbies. Funny little things, all in their own world at the bottom of the dam. A bit like us, ain’t they? Can’t see a thing for all the mud in the water; bits and pieces drift down, in any old order, all out of sequence, an’ we have to make sense of them as best we can.”

This unusual novel explores ideas about sustainability from a different angle: that we can’t achieve a sustainable world without a system of law that fully supports it. To make that happen, we would need truly revolutionary change in the way we see our world: a refocus of passion from possession to purpose. In some ways, as one of the characters here explains, we may not have much choice:

“The whole system is so fragile that there’s a real risk it could collapse at any time, in a really big way. Those problems are inherent in the system, so to speak, so that the whole thing is held together by little more than wishful thinking.”

But what would happen if only some countries made that change – and others didn’t? What would happen to trade, to international relations, to everyday living? How would they deal with each other’s business-visitors, or tourists? Yabbies explores these themes through story-fragments, each piece as if drifting down to us through the waters of time, different characters describing their own worlds and experiences each in their own unique voice. And perhaps a little magic, too.

Yabbies first appeared more than a decade ago as YABI – Yet Another Book Idea. Although it has taken many forms over the years, as an interactive website, screenplay, annotated text and more, this is its first time available as a conventional novel. This new edition includes a background section on the ideas and principles behind the story, and also a suggested timeline to link the fragments together.

Author Tom Graves is best known as a writer on a broad range of non-fiction topics – from the structure of organisations to the structure of magic, and much more besides. He applies the same perceptive eye and acerbic humour to this story, using fiction to explore some of the deep-questions and ‘undiscussable’ themes of the present day.

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?