Tom Graves / Tetradian

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

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

How do we make it make sense?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Comments, anyone?

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

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

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

Next part on that expansion on my ‘no-plan Plan‘, with more detail on the theme about ‘architecture as story’.

If you’ve been watching this blog for a while, you’ll know that this theme already goes back a few years, such as with the much-referenced post ‘The enterprise is the story‘. But I’ll admit that I was somewhat floundering for an anchor that would link it more solidly into enterprise-architecture, until I came across Matthew Frederick’s ‘two points of view‘:

Two points of view on architecture

ARCHITECTURE IS AN EXERCISE IN TRUTH. A proper building is responsible to universal knowledge and is wholly honest in the expression of its functions and materials.

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

Frederick there is talking about the architecture of buildings, yet exactly the same principles also apply in enterprise-architectures.

‘Classic’ EA is almost entirely centred around the ‘exercise in truth’ view. In its own way, it is about ‘truth’: it’s all about structure, function, process – yet so much so that people barely enter the picture at, other than perhaps as literally-faceless ‘users’ in a use-case. And almost all of the existing EA toolsets reflect that orientation towards rigour and structure – so much so that, in an all too literal sense, it’s often hard to get at the story behind it. Yes, it’s a structure. Very pretty. Very impressive. Very precise. And, uh, so what?

The way we’d answer any ‘so what?’ is almost always through some kind of story. Stories provide meaning, stories are engaging, stories give people a reason to engage in the enterprise, its activities, its aims. Stories describe the ‘why’ of decisions, alongside the ‘how’ and ‘with-what’ of how these decisions are expressed and enacted in real-world practice. In a truly literal sense, the stories are the enterprise – and hence right at the core of the architecture of that enterprise. Hence the very real importance of this other view, ‘an exercise in narrative’.

Yet at present there’s almost no support for any of that ‘narrative’-view, either in existing EA frameworks or in the current generation of EA toolsets. DoDAF and MoDAF do call for a visual ‘OV-1′ overview-diagram of the context of an architecture, but that’s about it – and I don’t know of any EA toolset that links regions of that graphic into actual architecture-repository entities, to act as the high-level anchor for an architecture. And most toolsets still seem to follow the notation-standards so slavishly that there’s usually no way to attach graphics or photos to an entity, to create an architecturally-rigorous diagram that would make sense to anyone other than an architect.

And, literally, where are the stories? Equally literally, where is the human voice in this? To quote the Cluetrain Manifesto:

Markets are conversations. Their members communicate in language that is natural, open, honest, direct, funny and often shocking. Whether explaining or complaining, joking or serious, the human voice is unmistakably genuine. It can’t be faked.

Where is that voice in our architecture, or in anything that our architecture describes? It matters – and hence its absence matters too. A lot: not least because most current architecture-diagrams are an abstraction of an abstraction of an abstraction, and without the human story, the human voice, to anchor its place and time and purpose, that kind of diagram is unlikely to retain much meaning for long. We need the story in there – just as much as we need the formal descriptions of function, data, structure and so on.

Apologies, I’m ranting again… but you’ll know what I mean about this, I think? – that architecture isn’t architecture unless it includes both structure and story, two different yet complementary views brought into balance, somewhat as TS Eliot put it, quoting an earlier age:

The association of man and woman
In daunsinge, signifying matrimonie—
A dignified and commodiois sacrament.
Two and two, necessarye coniunction,
Holding eche other by the hand or the arm
Whiche betokeneth concorde.

So how about it, folks? Let’s build a new, more balanced approach to enterprise-architecture, one that does include appropriate space for the human story too. Let’s aim for a new kind of EA toolset, where each entity is its own wiki-page, can incorporate the literal human voice via audio-capture, video, photographs, sketches, drawings, yet all of it still linked in to the formal rigour and structure. Let’s find a way to merge narrative-tools such as Anecdote‘s Zahmoo or Cynthia Kurtz‘s Rakontu into our everyday EA-practice, and link those into our toolsets as well. An interesting challenge, I think?

Anyway, yes, whatever happens, it’s clear that this overall theme of ‘the enterprise as story’ is going to be important here. Watch This Space For Next-Whenever’s Thrilling Instalment?

[Update: Not clever: there's a whole bunch of key, essential, sub-themes here that I brilliantly failed to mention above... There's Verna Allee's work on value-networks, for example, or Chris Potts' comments on 'the architecture of experience', community-of-practice and community-of-interest, and the whole array of issues around service-design, collaboration-design, communication, social-business, social-media, creativity, culture, leadership and... - well, that list goes on and on and on.

In other words, if it relates to people and architecture, and people in architecture - whatever form that architecture may take within the enterprise - then yes, it belongs along with this theme here. And everywhere else, too. Which is the whole point, of course. ]

A bit more detail on what I see coming up in my ‘no-plan Plan‘, starting with the theme about ‘the ‘why’ of architecture’.

One thing I’ve always found worrying in most current ‘enterprise’-architecture is that there’s been almost no attention given to the ‘why’. It’s seemed that ‘why’ was just a given: ‘orders from above’, to be followed without question, “ours not to reason why” and so on. Like as if it didn’t matter. To give just two examples, both TOGAF and Archimate still regard modelling of motivation – the reasons why we do something, or anything at all – as an optional add-on or ‘extension’ to the architecture. (I’m not joking: go check ‘em out – and the Archimate ‘extension’ won’t even be officially released until version 2.0!) Pardon me if I say that that’s just plain daft…?

Okay, step back a bit. Point to something in current EA that does work, namely the layering of abstraction in Zachman:

(Note that the original only has five rows, 1-5, which relate to the types of views for different stakeholders responsible for making something happen. Structurally, though, these views also represent layers of abstraction, to which I’ve added a row-0 to indicate indefinite-future, and a row-6 as unchangeable-past. It seems there’s also likely to be a need for a ‘row-00′, to represent the broader context within which all enterprises exist, but I’ll expand on that point some other time.)

Whenever we look ‘upward’ to a lower-number row, we’re asking ‘Why?’; and whenever we look ‘downward’, towards the future/past boundary of the ‘Now’ that sits between row-5 and row-6, we’re implicitly asking ‘How?’ and ‘With-What?’. Row-0 represents a fully-abstract and unattainable idealised-future (the ‘Vision’ and suchlike, that drive the overall enterprise); every move ‘downward’ is a step closer towards making that vision become more tangible in the real world, until at row-6 it’s already been made as tangible as it’s ever going to be.

So what? What’s the point?

Short answer is that if we don’t know why we’re doing something, it’s easy to make inappropriate choices, or ineffective choices. Or fail to realise even that we do have choices. Which, in a period of accelerating change, might literally be a life-critical concern…

I’m one of those people cursed with a mind that balks against taking anything for granted, wants to see the logic (or reasoning, rather) behind every decision, every option. Which, in a world that seemingly lives on unquestioned assumptions, can be, uh, a bit problematic:

– “Ya gotta climb the corporate ladder!”, they told me.

– Uh, why?

– “Because everyone’s gotta climb the corporate ladder! – gotta be better’n everyone else!”

– Uh… how can everyone be better than everyone else? And what do you mean by ‘better’? – ‘better’ in what sense? And why is the ladder leaning against this wall and not that one? And what’s on the other side of the wall, anyway? What’s the purpose here? What’s the point? Why?

Silence, then:

– “Look, just shut up and go away, willya, kid? … Next! Hey, you, you other kid over there, ya see this, it’s the corporate ladder! Ya gotta climb this! Ya just gotta! – but-please-don’t-ask-me-why-cos-I-don’t-know-either…”

I never did get to climb that corporate ladder; never even been a ‘permanent’ employee, for that matter, so I never had much chance to do so anyway. But still kinda doubting that I would have wanted to do so even if I could – other than perhaps to see what was on the other side, much like that other well-known matter with a chicken and a road. Hmm…

But why that need for why?

If we don’t ask why, we don’t get to move up those layers of abstraction. And if we don’t move up those layers of abstraction, we don’t get to see new options and new choices. To make things happen, it’s true that we need everything to be complete, locked together, fully tested, fully working. But as I put it some while back, a ‘something’ is usable to the extent that it’s architecturally-complete; but it’s re-usable to the extent that it’s architecturally-incomplete. And when things change around us, we usually can’t keep going indefinitely just with ‘the way things are’: something has to change, in order to cope with the changes and still keep things sort-of-the same.

And even if things do stay much the same, we can’t know how to make something more effective unless we know its actual purpose – both in itself, and in the broader scheme of things.

To see that practical purpose, and to spy out other options, we need to able to get a broader view of things.

Which means we’ll have to go up a bit, to get that broader ‘big-picture’ view.

Which means we must be able to climb that other ladder – the ladder of abstraction, the ladder of ‘why’.

Which designers and enterprise-architects and so on do indeed do, all of the time, of course. But only sort-of. In most cases they sort-of climb about half-way up, and then come to a sudden stop, seemingly declaring that there isn’t any more ladder to climb, and yes, kid, if you happen to notice that the ladder does indeed keep on going ever upward, just shut up about it, willya? Okay, yes, fine, understood, boundaries of authority in a feudal-style cultures and all that – except, uh, I can’t help but see that that ladder of ‘why’ does keep on goin’ up, and I really really really want to know what’s up there… That kind of feeling… Really frustrating…

Which is why, sorry, but I just can’t stop asking ‘why’.

Which can, uh, cause a few problems. Especially for me. Oh well.

To put it in more visual terms, ‘classic’ ‘enterprise’-architecture sits mainly in the row-3 / row-4 range of abstraction – the interplay of ‘logical-to-physical’ – with occasional forays up into the row-2 world of big-picture business-strategy:

What I’m mostly working with, though, tends to be a fair bit further up the ladder:

Yet it is still enterprise-architecture, because it’s still the same ladder of ‘why’. But with a lot more focus on more abstract-seeming questions about the nature of the enterprise, or even the nature of enterprise itself.

Unlike the feudal mess, ‘higher’ doesn’t equate with ‘better’ here: it’s just a different kind of view, on the same continuum. In the overall scheme of things, it’s ‘just another service‘, nothing special as such. But still useful, of course, if used in the right way. Which is what I want to do: be useful, in the right way.

That more abstract view might sound, well, more abstract, y’know? Impractical an’ all that? Yet actually it’s very practical indeed: and if we turn our perspective of the ladder the other way round, with the lowest-number rows at the bottom, what that ‘abstract’ view actually describes is the bedrock on which everything else in the enterprise will stand. For example, all that ‘abstract’ stuff on vision and values:

• if you don’t know those vision and values, how else are you going to build any meaningful conversation with your prospective customers?
• if you don’t know the underlying values, how will you know what ‘quality’ means, or how to identify whether it is or isn’t there?
• if you don’t know what the shared-vision is (and every organisation will always have one, whether they know it or not), and you don’t how know you actually share it with the broader enterprise (which you do, whether you know it or not), how will you know what to do when your ‘anti-clients’ (and yes, you’ll always have those, too) start asserting that you’ve betrayed that vision, and set to work to tear you down?

Seems a bit abstract at first, yes, maybe so. But trivial, or irrelevant? – definitely not. Not if you want to be able to ride the upcoming tsunamis of change, anyway.

(And yes, that is ‘tsunamis‘. Plural. Many of them. Lots. Perhaps a fair bit more than just a metaphor, too. Coming to a business-context near you, some day real soon now. If not today, in fact… And yeah, don’t expect to survive that little lot without some serious preparation before they hit… Your choice, of course? )

Sounds good? Wish it were so… because there is, of course, a catch – for me, anyway. A little practical problem called income. Or, more precisely, the lack thereof… in fact, in the not-income stakes, it’s pretty close to a perfect storm. For a start, monetisation happens mainly at the moment of ‘now’ – the row-5/row-6 boundary. In other words, the exact opposite end of the ‘why’-ladder to that where I usually work. Oops…

And just to make this part of my economic-life even more fun, although there’s a huge need for this aspect of the kind of work that I do – as can be evidenced by about five-minutes’ worth of looking-around at just about any large organisation – there’s an even more huge ‘anti-want‘ for it. Most of what I show people may be extremely important to them, but at first it’ll often seem embarrassing, challenging, or even downright scary. Oops again…

In short, it’s difficult to explain the immediate value of much of what I do, and most people really don’t want to know anyway, no matter how important it may be to their livelihoods and suchlike. Sigh… Oh well. But this is a fundamental part of everything that I do, so just need some other way to make some kind of income, that’s all. No big deal, really.

That’s about it, I guess.

Oh yes, one other point, about tools and toolsets.

Most of the existing ‘enterprise’-architecture toolsets are… well, let’s be polite and say ‘somewhat challenged’? …when it comes to working across the whole of the real EA continuum, and perhaps especially in terms of creating linkages up into row-2 and above. Most toolsets – and, even more, most notations – are all but unusably constrained for that kind of purpose: most of them sit either in row-3 or row-4, often without being able even to link across that architecturally-essential boundary. Yes, of course there are workarounds and kludges: but that really is all that they are, and just about everyone in ‘the trade’ knows that, too. We need a better solution than this.

So here’s the challenge: to handle the whole of the ‘Why’ question – and, going the other way, the ‘How’ and ‘With-What’ and so on – we must be able to build complete derivation/realisation chains for anything, from row-6 (records of past action) or row-5 (CMDB and the like) all the way back up to row-0 (vision and values) and row-00 (context of all enterprises). Yeah, it’s huge – no question about that. It’s probable there’s no way any single notation would be able to do it, and still make sense. But I do believe that we should be able to define a single metamodel that covers that space and can bridge across any type of notation, and from previous experiments here it really does not look all that hard to do. So I reckon that the the first toolset-vendor that cracks that challenge, and the attendant usability challenge that goes with, stands to open up an absolutely huge new market for sensemaking / decisionmaking tools, and would have much of that market to themselves for quite a while, too. So if you want to know more about that? – and how we can talk business about that? – well, you know where to find me, don’t you?

Found this Volkswagen initiative via Swedish social-media expert Oscar Berg:

Notice the success-metrics: two-thirds more people used the stairs rather than the escalator.

Now: how do we apply those same principles to organisational design and enterprise-architectures?

Came across this comment whilst exploring laptop.org.au, the Australian arm of the One Laptop Per Child movement [my emphasis]:

Learning is our main goal. … Epistemologists from John Dewey to Paulo Freire to Seymour Papert agree that you learn through doing. This suggests that if you want more learning, you want more doing. Thus OLPC puts an emphasis on software tools for exploring and expressing, rather than instruction. Love is a better master than duty. Using the laptop as the agency for engaging children in constructing knowledge based upon their personal interests and providing them tools for sharing and critiquing these constructions will lead them to become learners and teachers.

So why do we think it should be any different for adults in our organisations? – that ‘duty’ will somehow necessarily be a better motivator than love of the work itself?

Then crosslink that with Daniel Pink’s summary of recent research on extrinsic versus intrinsic motivators. From that, we discover that monetary bonuses and other ‘external’ motivators not only don’t help in knowledge-work, they actually make performance worse. What does work is ‘motivation from within’ – especially a commitment to the work itself for its own sake.

Crosslink that with what we know about the skills-learning process, and especially about the need for a ‘commitment of the heart’ – a commitment to the skill itself – to enable the capability to deal with real-world complexity in the context of that skill.

Crosslink that with what we know about the role of vision as a unifying force for and within an enterprise.

Crosslink that again with one of the core themes from the current version of ITIL (IT Infrastructure Library – the key international standard on IT service-management), that people do not want products or services as such, they want “satisfaction of a perceived need”; then note that this applies to all people within the enterprise as much as to the enterprise’s clients.

Given all of that, what types of motivation are provided or applied within your own organisation? Is there much evidence of awareness that “love is a better master than duty”? And if not, what would you need to change in the business-architecture or enterprise-architecture – such as in performance-metrics, performance-appraisals and the like – to support more of ‘love’ within the work itself?