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 the next part of that expansion on my ‘no-plan Plan‘ (or ‘manifesto for whole-enterprise architecture’, or whatever it is): this time on the dynamics of architecture. In other words, it’s a focus on how we handle changes to the architecture itself, rather than mainly about changes that that architecture needs to address.

Most of this will be painfully familiar to every experienced enterprise-architect – whatever type of enterprise-architecture we do. It’ll be especially painfully-familiar to those who’ve had to struggle with the current crop of EA toolsets, which – to be blunt – seem to range between mostly-useless and worse-than-useless for almost anything to do with architecture-dynamics. Oh well.

So, first: what do I mean by ‘architecture-dynamics’?

In essence, it’s about how we keep track of change within the architecture itself – in particular, versioning, transitioning, lifecycles and dependency-dynamics. Let’s look briefly at each in turn.

Versioning

In principle, this should be simple: keep track of edit-changes to anything. In practice, it’s a bloomin’ nightmare: doing it properly requires some seriously clever thinking in the design of the architecture-repository, and some equally clever tricks in user-interface design so that we can actually retrieve the older versions in any comprehensible way. (For example, take a look at Apple’s Time Machine for some good ideas on version-access, though in a context that’s actually a lot simpler than what’s needed for an EA-repository.)

How do existing EA toolsets do this? In way too many cases, they ‘solve’ the problem by doing nothing about it: there’s no version-management at all. Instead, it’s just been tossed into the ‘too-hard basket’, and then rather carefully forgotten in the forlorn hope that somehow we won’t notice it’s missing. (We do.) Sure, there are various kludges and workarounds: for example, one vendor’s recommended ‘method’ for versioning is to clone the entire repository and save it as a named backup somewhere. Okay, a few vendors do do a reasonable job of it – Troux comes to mind here – but even that is mostly done by a clone-and-relabel at an instance-level, which still seems pretty clunky in practice, and definitely error-prone if we were ever to risk letting inexperienced users loose on the system.

What’s absurd is that it shouldn’t be all that hard to do. As I remember, versioning-support is defined right down at the root MOF metametamodel level for the OMG notations such as UML and BPMN, so for that at least there ought to be a swathe of different implementations, surely? For my own work I haven’t gone down into implementation fine-detail as yet, but the ‘mote’ metamodel structure that I described in a series of posts a couple months back had all of that built in as well. The design-concept was based on a really simple yet fully-versioned wiki-engine that’s been around for over a decade: and if I can describe it, surely someone more competent at system-design than I am – which is just about anyone in ‘the trade’, I would have thought – should be able to do it a lot better than that?

Overall, though, versioning is still a ridiculous mess in most (all?) EA toolsets, and we need to be a lot more vocal about saying so, and demanding a better deal on this.

Transitioning

This is about keeping track of the process of change: from what to what, how, when, who, why, and so on. Again, should be straightforward. And usually isn’t. Sigh…

One of the things that really confuses everything here is the myth of ‘architecture state’. We all know how it’s supposed to work: there’s the current-state (the ‘as-is’), the future-state (the ‘to-be’), and, perhaps, various intermediate-states. Everything nice, neat, tidy, well-defined and all. There’s only catch: there is no ‘state’.

‘State’ is a myth, made up by project-managers – and, hence, toolset-vendors – to make their life seem simpler and prop up the happy delusion that they’re ‘in control’ of something that, by definition, cannot be controlled as such. The idea is that, once we reach that perfectly-planned end-point of the project, we’ll have ‘got there’ – all finished, all done, all over bar the congratulations at a job well done. But by the time we ‘get there’, the ‘future-state’ that we’d predicted in the plan isn’t ‘there’ any more: to quote Gertrude Stein, “there is no there there”. The same is true even for ‘current-state’: in any dynamic environment, change happens all the time, so even ‘now’ isn’t ‘now’ any more, either. There is no state.

Except, of course, all those EA toolsets assume that there is. Well, for those that can actually conceive of the idea of change, that is: for several toolsets that I’ve seen, their ‘method’ for describing difference is, again, to clone a copy of the repository and save it somewhere with a label of ‘current-state’ or ‘future-state’. (Except, again of course, there’s no way to create links between those two different repositories, so we have no way to describe, within a single repository-based report, what will change between those two ‘states’, and what won’t. Real helpful. Oh well.)

Much like versioning, we need to be able to define arbitrary labels for planned time-points and such-like, and attach them to any entities as we choose within the repository. And create cross-reference links between ‘as-is’ and ‘to-be’, to mark a state that isn’t a state because nothing is static anyway. And describe all the other aspects of transitioning – responsibilities, temporary bypasses, timings, dependencies and all the other transitory mechanics of the tasks – in any way that even the most pernickety of project-managers might need. All within the same EA toolset. Please?

Again, what we have on offer at present is mostly just another ridiculous mess, and again we need to be a lot more vocal about saying so, too.

Lifecycles

Everything has its own lifecycle: things change within the architecture, whether we plan to change them or not. Call it self-versioning, if you like: except that some of it may happen behind our back, whilst we’re not looking, and it still affects the viability of architecture, whether we know about it or not. T-r-i-c-k-y…

Some of our toolsets – particularly those that have developed out of a CMDB background or equivalent – do seem to have a fairly good handle on this point; most others, uh, don’t. At all. Or worse.

That’s about all that needs to be said about that, really. Except that, again, it’s something we probably need to make some noise about to the vendors. Or perhaps make that a lot of noise? Again? Loudly? Sigh…

Dependency-dynamics

Okay, this one is a serious challenge, though the toolset-vendors really ought to be up for it if they want to keep our business.

In principle, it’s a straightforward follow-on from all of the above: if something changes, other things that depend on it may be affected too. But that means that each of those items may also need new versions, new transitions, and new changes to their lifecycles. Which then affects anything else that may be dependent on that, which then affects anything dependent on that, and so on, and so on, sometimes with odd, unexpected, untraced, looped, delay-ridden, reciprocal-and-everything-else complexities. This can get to be real tangled, real quickly… Oh joys…

Again in principle, this is little different from the usual ripple-effects in a plain old bog-standard spreadsheet. Except that most spreadsheets don’t deal with versions, transition and lifecycles along with all those supposed-to-be-relatively-straightforward ripple-effects. And a repository is not the same as a spreadsheet anyway (unless you happen to build it that way). Which means that this is a lot trickier than it looks at first glance. Which is why most toolset-vendors seem to take the easy way out, and don’t bother to do anything about it at all.

Which would be fine if we didn’t need it. Which unfortunately we do. And will need a lot more once people start to realise just how powerful a well-populated holographic whole-enterprise architecture can be. Oops…

So yes, something else about which we again need to be vocal. Lots.

(And lots more that could be said about all that, no doubt, but again best leave it at that for now?)

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?

A long post-TOGAF conversation on Friday with enterprise architect and academic Erik Proper brought up the question of what I’ve been calling ‘bindedness’ in metamodels and compliance reference models for enterprise architecture.

In conventional models and metamodels, links between items are kind of binary: if they exist, they apply every time, and if they aren’t in the model, they’re deemed not to apply at all. It fits well with the standard rule-based world of IT, which is why we see them so often in all manner of IT-type models, from data-models to process-models to ArchiMate layered models, and so on.

The catch is that that isn’t how things work in the real world. The reality is described well in Volere requirements modelling: rather than a simple true/false or ‘is-required’ / ‘is-not-required’, the template allows for at least five levels of ‘bindedness’, in two different directions (satisfaction if present, and dissatisfaction if absent). Even the old-style requirements techniques allowed for at least two levels, described via ‘shall’ (mandatory) and ‘should’ (desirable or highly-desirable). Yet another variable bindedness is the ‘MoSCoW’ set applied to requirements in some Agile software development styles:

• Must – mandatory
• Should – highly desirable, strongly recommended
• Could – desirable, recommended, an option known to work in this kind of context
• can Wait – a ‘nice-to-have’ that can wait until a later iteration (known as ‘Waiting Room’ in Volere)

Much the same applies to reference-models: these too need similar contextual bindedness. Compliance to some parts of the reference model may be mandatory in law; we don’t have any choice about that, and these are the same straightforward true/false links as in standard software models and the like. But for the rest, it’s really about risk-management and levels of risk: we can move away from the standards specified in the reference-model if we must – perhaps because of practical constraints, or because what we need simply isn’t available and can’t be bought or built within reasonable cost at the present time – but every deviation from the standard represents increased risk. High bindedness indicates high risk from any deviation from the standard; low bindedness indicates low risk. In enterprise architecture, we document the deviation by a formal ‘dispensation’ or some other equivalent risk management mechanism.

Which brings us back to models and metamodels, because in the standard rather IT-oriented approaches to modelling, there’s no way to describe this variability of bindedness: we’re stuck with true/false, mandatory or not-required-at-all. The OMG’s Semantics of Business Vocabulary and Business Rules specification is one existing definition that goes part of the way there, but it uses horrible formal-logic terminology such as ‘modality’ (meaning bindedness, but a word which has many entirely different meanings in other contexts) and ‘alethic’ versus ‘deontic’ (true/false versus slightly more variable than true/false), and I haven’t seen any modelling technique – with the possible exception of ORM, or Object Role Modelling – which actually applies it. Even then, it still doesn’t carry through either the simplicity or richness of the bindedness of a reference model, but instead again drowns us in the impenentrable rigidity of formal-logic.

To me it’s just laziness that we’ve stuck with the crude true/false links for so darn long, because they don’t fit what we actually need, and they’re often dangerously misleading in practice. It shouldn’t be hard to define and implement variable bindedness in a metamodel: at its simplest it’s just a straightforward categorisation of link-strength, and could be displayed in a modelling notation by thickness of line or by colour-coding or the like. I’ll have a go at building it into the metamodel for enterprise architecture that I’m working on at present, but it would be good to avoid reinventing the wheel if someone else has done it already.

Advice / suggestions, please?