Tom Graves / Tetradian

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

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

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

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

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

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

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

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

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

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

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

Yet the real problem here is somewhat more subtle:

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

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

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

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

Comments, anyone?

This one is a pick-up from a Tweet by Bert van Lamoen:

• 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!

In designing management-structures, why is it so often assumed that responsibility-relationships only go one way?

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?

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?

Okay, I’ve moved on to a different garden: what next? What’s the plan?

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?

You what? “Say no to women’s rights” – you’re kiddin’ me, right? What kind of misogynistic claptrap is this…?!?

I’ll admit it: I’m being deliberately provocative here. (Did get your attention, though, didn’t it?  And don’t forget I did warn you that what I’m doing these days could be a lot more challenging for many folks? – well, this is what that looks like.  )

So cool it, okay? Calm down. It’s almost certainly not what you might think I’m saying. And don’t panic: ultimately this is more about a practical design-issue in ‘big-picture’ enterprise-architectures than about anything else. Serious, sure: but not misogynistic. Honest.

It’s true that there are specific problems around all closed-category ‘rights’ such as purported ‘women’s rights’ and the like – and I promise I’ll come back to those later. But that isn’t the real point here anyway. The real point is this: the whole concept of ‘rights’ could well be one of the most disastrous mistakes that humans have ever made. And we need to find a way back out from that mistake if we’re ever to achieve some kind of sustainable society.

In terms of well-meant stupidity, the notion of ‘rights’ is right up there with the toffee spear [thank you Terry Pratchett!] and the lead balloon: it doesn’t work, it’s never worked, in fact can’t work, because its cause of failure is built right into its very roots. Scrambled misunderstandings and misuses of the notion of ‘rights’ represent a huge failure-risk, right at the roots of all of our current ‘really-big-picture enterprise-architectures’. And to be blunt, the concept of ‘rights’ is so riddled with calamitous unintended-consequences that we really need to remove it, totally and permanently, from every aspect of every law in every land.

An assertion to which, at present, you might well disagree.

Which is fair enough, of course.

But perhaps allow me to explain?

(And yes, as usual, this is going to be a bit long… but I think you’ll find it worthwhile.)

Read more…

What do I do, and how do I do it? What’s the nature of my work, and the methods that I use? And for that matter, why?

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

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

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

Read more…

As the old phrase warns us, “vision without implementation is just hallucination”. That’s why all architects do some form of design, and ideally guide the implementation too. But do enterprise-architects design the enterprise? And if so, how do they do it? Or, for that matter, should they?

These are not trivial questions, as indicated well by these tweets from Chris Potts and Robert Phipps:

• chrisdpotts: @tetradian What comes first in an enterprise, and with that its architecture, is determined by the people whose enterprise it is. // You can choose whether you want be an architect of my enterprise, fair enough, but not what my enterprise is. #entarch
• Robert_Phipps: @chrisdpotts @tetradian this is almost a political resolution to the #entarch question.

The essence of a great sparring-partner is that they come up with great challenges, and these are some of the best. Chris is right: the notion that an enterprise-architect designs the enterprise itself seems at first to be a statement of incredible and unforgivable arrogance. And Robert is right, too: by its very nature, all enterprise-architecture work is intensely political – about as political as it gets, really…

And yet enterprise-architects do also do design – in the enterprise. Of the enterprise. About the enterprise.

But only design sort-of. Kinda. Ish. Y’know? That kinda thing? All a bit blurry, subtle… all about implications, edges, options, opportunities…

The real clue is in that comment of Robert’s above: it’s all political. Very. It’s all about people – so it’s not quite the kind of design-thinking that we would use in designing a machine to make toothpaste-tubes. We don’t design enterprises as such: as Chris indicates, they develop from people, as an expression of people and their choices and desires – and the notion that we should, would or even could ‘design’ people or people’s choices is an insult in the extreme. (Not that that’s an unusual insult, unfortunately…)

The enterprise is itself: “the animal spirits” of the entrepreneur and everyday people, as Chris puts it sometimes. That’s the whole point. Yet there is a specific sense in which we do sort-of design about the enterprise. The key resides in what we mean by ‘enterprise’ and ‘organisation’, and the crucial differences between them:

• an enterprise is bounded by vision, values and commitments: it is primarily about ‘Why‘
• an organisation is bounded by rules, roles and responsibilities: it is primarily about ‘How’ and ‘What’ and and ‘Who’ and ‘Where’ and ‘When’- in fact almost everything except ‘Why’

They are not the same: and if we ever make the mistake of thinking that they are the same, we’re in deep trouble. (It’s true that, by definition, the boundaries of an organisation do also coincide with the boundaries of an enterprise – but it’s a special-case, and one of which we should be very wary in enterprise-architectures.) Crucially, the nature of an organisation means that it has no ‘Why’ of its own: to make sense of its existence – to give it a reason to exist – it needs to attach itself to the ‘Why’ of an enterprise that is greater than itself. If it loses that connection, it tends to revert automatically to the dreaded metaphor of ‘organisation-as-machine’ – literally, a machine without a purpose, or at best with a non-purpose such as ‘making money’ that confuses means with ends – that has disastrous consequences for almost everyone involved. One of the key tasks of enterprise-architecture is to identify the enterprise to which the organisation is or needs to be attached, and to help guide the organisation’s responses to and relations with that enterprise. Enterprise-architects do not design the enterprise: they provide decision-support to guide the organisation in its relations with the enterprise. That’s a subtle yet very important distinction.

Enterprise-architects develop an architecture about an enterprise, for an organisation. Yet what do we mean by ‘an enterprise’, in this context? The simplest summary is that what we look for is an extended-enterprise or shared-enterprise – defined by some kind of shared and very human drive or intent – that denotes a conceptual and/or emotive space about three steps larger in scope than the organisation itself. The organisation sort-of ‘is’ an enterprise (that special-case, as above) that has a shared-enterprise with its partners – ‘customers’ and ‘suppliers’ – that exists within a broader shared-enterprise – the ‘market’ or its equivalents – that exists within a yet broader shared-enterprise of people who are emotionally or otherwise engaged in that overall aim or intent yet are not actively or directly engaged within that market.

An enterprise simply is: it cannot be ‘designed’ as such. (Nor is it anything that anyone could ‘possess’, or ‘control’ – a mistake still made by too many marketers, managers and MBAs…) Yet each enterprise is also bounded by vision, values and commitments – to which the organisation itself commits by choosing to align itself with that enterprise. The vision, the values, the commitments and even the alignment of the organisation to each of those often starts out as implicit: a key part of the role of the EA is to identify each of those implicit items, bring them into a more explicit space, and hence enable more-explicit and more-considered choices. That’s where the ‘design’ comes in: it’s not design of the enterprise, but about the enterprise, for the organisation in relation to (and relations with) that chosen enterprise.

Enterprises intersect: I’ve shown above a simple case of the organisation in relation to one enterprise, but in reality it’s more like a complex Venn-diagram, overlapping, overlaying, often arguing with each other, too. The organisation’s choice(s) of enterprise to which it chooses to align or belong – with the ‘choice’ often being either implicit and unknown, or mandated by fact of geography or social context – each bring consequences and other choices. For example, the extended-enterprise will hold the organisation accountable to the implied values and commitments of the enterprise, and will react strongly if the organisation fails to deliver on those commitments – which is where many organisations discover to their cost that there is indeed such a thing as ‘corporate social responsibility’, and that it’s not quite as simple as Milton Friedman‘s assertion that the sole social responsibility of business is to increase its profits…

I won’t go into detail on how we deal with those myriad of consequences: as usual, this post is too long already! But essentially that’s it: enterprise-architecture sort-of does and sort-of doesn’t ‘design’ the enterprise. It’s in that ‘sort-of’ where the real interest of the EA role lies.

Comments, anyone, as usual?

Most of the Yabbies novel is made up of story-fragments that in principle could come together in any sequence: we make sense of them in whatever way we choose.

What follows is perhaps my favourite story-fragment, “Mishie’. (A gentle reminder that it’s fiction? ) A bit of context first, though. The fragment takes place perhaps thirty or forty years from now, some decades after one country has shifted from a ‘conventional’ possession-based economy to a responsibility-based (‘no-money’) economy. The latter is that ‘world’ that Mishie inhabits, has grown up in – and wants, very much, to see more of the world. A few terms: ‘vizzie’ is a ‘visitor’, someone from a different country; ‘GA’ and ‘garda’ are police, ‘tucker’ is a standard current Australianism for ‘food’; the language is basic English with a fair few adaptations over time, and a lot of local slang. The reference at the end to ‘that book we did in Year Nine’ is Ursula le Guin’s sci-fi masterpiece The Dispossessed. What happens in the story-fragment is a simple contrast of before, and after…

Over to you after the ‘Read more…’ link, anyway: have fun, I hope?

Read more…

All right, I admit it: my novel Yabbies doesn’t say much about real-life yabbies. In fact they only put in one cameo appearance in the whole book:

“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.”

The real yabby is a small Australian crayfish, a kind of miniature freshwater lobster. They’re common all over Australia, particularly in the south-east, and can frequently be found burrowing into the sides of a farm dam – hence their Latin name cherax destructor. They seem to come in all kinds of colours, from muddy brown to red to white to a really startling blue, such as this fairly large one at something close to actual size:

Yet what’s the connection to the book? Uh.. not much, to be honest. What’s now come out as the book first started out more than a dozen years ago as an idea about sustainability: namely, that we won’t be able to achieve any kind of sustainable economy unless we have a system of law that supports it – which we certainly don’t have at present. The working-title for the project was ‘Yet Another Book Idea’ – hence the acronym YABI. Which had a nice ring to it, and hence kind of stayed in the mind as ‘Yabbies’. Which is what the project has been called ever since. A bit unfair on real yabbies, and yabby-farmers and the like, perhaps, but there ’tis.

The idea of story-fragments that could assembled in any order came on quite early in project – in fact the first form in which it surfaced was as an interactive website in which people could make up their own story and add their own story-fragments to build a richer picture of the YABI ‘world’. (This was in the days before social-media, so it never really went anywhere: perhaps it might be worth-while having another go at recreating that website somewhen soon?) Later on, I tried doing it as a screenplay: it worked quite well as a story, but with so many characters in so many cameos it would almost certainly be too complicated an expensive to produce as a conventional film-type story. (But it might work well with current transmedia – another avenue to explore, perhaps.) All sorts of other frames I’ve tried out over the years: one version had technical notes attached to each story-fragment, another split it into separate story-streams for distinct audiences, and so on. But this version will do for now? – enough to get the story-ideas out there, anyway.

Its real aim, I guess, is to get some pretty challenging ideas out there in a more palatable form – hence packaging it as fiction. The ideas behind it, though, are not fiction at all: they’re real issues that somehow, collectively, we must all face, and definitely sooner rather than later. Make of it what you will, perhaps?

And the yabbies themselves? Yes, they’re strange little creatures, “all in their own world at the bottom of the dam”. Feeding on whatever falls down from the surface, making sense as best they can. Linking that across to my more usual ‘world’ of enterprise-architectures and the like, that’s kind of what we do every day, isn’t it? So I kind of like yabbies as a metaphor for ourselves…