What I’ve been calling ‘Really-Big-Picture enterprise-architecture‘ is about looking at how we can apply enterprise-architecture ideas at a much larger scale, right up to a fully global scope. The simplest way to describe this is as follows:

• every society or culture is held together by mutual responsibilities
• in some (but not all) societies, there may be an overlay of personal possession
• arising from this concept of possession is a notion of property rights
• to support exchange of personal property in accordance with property-rights, we have point-to-point barter
• to resolve the point-to-point nature of barter, we introduce an intermediary currency
• to support futures in a currency-based economics, we introduce the idea of debt-based finance
• to support certain types of debt, we introduce financial-derivatives

All straightforward, all non-pejorative, a simple stack of overlays, each one built on top of the previous layers. We could summarise it visually like this:

There’s only one catch: it doesn’t work.

Most people realise by now that there are huge problems with financial-derivatives and the like: anything that is potentially-infinite that claims to have absolute rights over something that’s definitely finite is by definition going to be problematic. But that isn’t the core problem that we have to deal with.

Debt-based finance is a problem: it tends by definition to concentrate all wealth in the hands of those who control the mechanisms of debt. But that too isn’t the core problem that we have to deal with.

A lot of people argue that the problem lies with the currency: if we could switch to an alternate-currency, they say, everything would work out just fine. There are huge arguments about what kind of currency we should move to – time-based, ‘local energy’, reputation-points or whatever. But the reality is that all of those arguments are almost completely irrelevant, because currency itself isn’t the core problem that we have to deal with.

Some people say that we should drop the whole currency-thing, and go back to barter. But the point-to-point nature of barter causes huge problems, which in many ways currency does help to resolve. But in any case, barter isn’t the core problem that we have to deal with.

Quite a few people say that the real issue is around property-rights. Capitalists and communists alike will argue intensely over who has the right to possess, and who doesn’t. But this misses the point too, because property-rights in themselves aren’t the core problem that we have to deal with.

The real problem is the concept of possession – because that’s what breaks the mutuality of responsibilities on which a sustainable society and its economics depend. Possession is a literally childish view of an economy, one which asserts the primacy of ‘I’ over ‘We’. It’s a view which asserts that that the only thing that matters is my own needs and desires, that I am not responsible to others, either in the present or elsewhen – yet still insists that they are and must still be responsible to me. The reality is that the moment we allow that kind of pseudo-mutuality to exist, by definition we have a broken economy: there’s no way we can make it sustainable – especially over the longer-term.

Imagine an economy that’s run by, for and on behalf of the most childish in the society, and in which anyone who does take responsibility is punished for doing so. That would be insane, wouldn’t it? – in every sense of ‘insane’… Yet what we would have there is something remarkably similar to what we think of as ‘the economy’ in the present day – an ‘economy’ that’s ultimately based on the possessive self-centred temper-tantrums of a two-year-old…

Yet the fact is that anything based on a possession-model will tend automatically to create dysfunctional failure, to not only invent a status of ‘rich’ or ‘poor’ but an ever-widening gap between them, to always assign far higher priority to the present than to future or past, and to create a ‘trickle-up’ pyramid-game structure that can only appear to work as long as it can maintain an illusion of infinite ‘growth’ – because if the growth ever stops, its only option is to cannibalise itself into oblivion. There is no possible way to make a possession-based economy sustainable.

Which means that we have a rather serious problem. If possession doesn’t work – and not only doesn’t work, but by definition can’t work - and we need to move towards a truly sustainable economy – which, with seven billion humans and still increasing fast, we clearly do – then it means that we need to rethink not just possession itself, but everything that’s built on top of it. In short, every single one of those overlays is irrelevant, because they’re built on top of something that doesn’t work. Or, to put it in simple graphic form:

If the core problem is possession, then it should be evident that futzing around at any of the layers that are built on top of that myth of possession is not going to make any significant difference. It’s a waste of time, of effort, of everything else – a waste that we can ill afford right now, given the real inescapable all-too-literally ‘deadlines’ that we’re starting to face in the near future. Our only option is scrap the whole lot, and start again almost from scratch – because anything that retains any hint of possession in its structure will cause the whole thing to fail all over again.

And yet it’s scary just how much of our society and economics and the rest assume that possession is the only way to go. Just to give one small example: if “possession is nine-tenths of the law”, what does that tell us about what changes in law would be needed for a sustainable society? Not a trivial problem, yes…?

Yet I do believe that enterprise-architects have skills that could be genuinely useful for this type of challenge. We’re used to working at large scale, and at every scale, across every aspect of a whole system. We’re used to seeing how all of the different aspects come together to make a single unified whole. We’re used to doing roadmaps for change and suchlike – and the, uh, interesting politics that go with any large-scale change. What we have here is still enterprise-architecture, still the ‘big-picture’ – just a rather bigger picture than we’re used to, that’s all.

So that’s what I’m describing as ‘Really-Big-Picture Enterprise-Architecture’ – a form of enterprise-architecture where the ‘enterprise’ in scope is actually everything that happens and will happen in human activity on the entirety of the planet. In other words, probably the largest enterprise-architecture challenge that any of us will ever face. Interested?

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.

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?

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?

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

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

I won’t go into detail here (“hooray”, you say? ), but the quick summary is that the four axes for the tetradian are kind-of real-world analogues of the classic Four Elements:

• physical: ‘physical-domain’, tangible objects, ‘things’
• conceptual (‘virtual’): ‘mental-domain’, information, ideas
• relational: ‘emotional-domain’, feelings, desires, relations, ‘sense of connection’
• aspirational: ‘spiritual-domain’, identity, purpose, direction

It may sound a bit abstract at first, but it’s proved valuable in practice – for example, as a nice tangible metaphor to help explain to a group of logistics-executives how processes could be implemented in different ways, what the respective emphases were in each case, and also the limitations of an over-focus on IT (‘conceptual’-dimension) over everything else:

Another important twist – literally! – was that that ‘pyramid’ showed why it’s so important to rotate attention between the different dimensions: each face of the pyramid shows the relationships between three of the dimensions, but we have to rotate it to get a proper picture of the whole. In effect, that rotation – that movement – becomes a kind of fifth-dimension within that space: sometimes called ‘disorder’, but in classical terms a fifth-element, a ‘quintessence’.

(Which, yes, I know, has brought us back to the abstract again, but bear with me for a moment, okay? )

So, let’s go back to another well-known cross-map, between those four-and-a-bit dimensions and the SCCC categorisation, where the ‘and-a-bit’ dimension is how we move between the other dimensions or domains:

And link that back to the tetradian:

Now let’s flatten the whole thing out, with the ‘and-a-bit’ dimension in the middle, to keep reminding us that it’s not static, and that we need to move between the dimensions as much as explore within them:

The visible parallel with A Certain Well-Known Framework should be obvious to anyone who knows that particular framework – a fact that has gotten me into a lot of largely-unwarranted strife from certain directions over the past few years. Sigh… Oh well.

Yet there’s also a very important point that comes up in a slide by Dave Snowden, in an online seminar on sense-making and complexity-theory a couple of years of back:

Concept Lifecycles ((c) Dave Snowden / Cognitive Edge 2010)

He’s right, of course. There’s a clear S-curve for the adoption and eventual acknowledgement of the limitations of Taylor’s ‘scientific management’ and the like – which focussed primarily on the physical dimension of time and motion, the relatively-Simple rule-based aspects of work and process. And there’s another clear S-curve for ‘hard-systems theory’ – whose primary emphasis is on data and calculation and Complicated feedback-algorithms, the conceptual dimension of work and process. And then, as Snowden shows us, there’s the start of what looks like another exactly-matching S-curve, for the more Complex, emergent aspects that emphasise sense-making in the relational dimension of work and process.

The diagram suggests that we could stop at that point, and that what it really shows is that sense-making via complexity-science is the ultimate ‘The Answer’ in the business context. I won’t question anyone’s views on that: but what I will say is that, if we follow the logic of that sequence of S-curves, combined with even the briefest of glances at that flattened-out tetradian further above, we come to a rather strong hint that there might be a bit more to this story – and a very useful ‘a bit more’, too:

In other words, seems likely that there’s at least another whole dimension to explore there: the aspirational dimension, which maps above to the so-called Chaotic domain and to principle-based sensemaking and decisionmaking. And, of course, there’s that sort-of-dimension in the middle, about how we move between the various sensemaking / decisionmaking domains, according to the needs of the context.

To bring it out of the abstract somewhat, let’s use the metaphor of a mediaeval market, where we can hear and see and sense all of those themes interweaving within the bizarreness of the bazaar:

“Yeah, mate, good to see ya, d’ya wanna try some of these, new they are, special to you, only two groats to the bushel? An’ you heard the news from up the manor-house? – you reckon joinin’ up with them’s gonna change a few things round here, what with the new flag an’ all?”

If we tease apart some of those tangled-up threads, we’d end up with something that looks like this:

• markets are transactions, rule-based exchanges of ‘things’ [an aspect where Taylorism or Six Sigma might excel?]
• markets are conversations (thank you Cluetrain!), exchanges of ideas and information [an aspect that hard-systems theory would exploit in its algorithms?]
• markets are relationships, connections between people, through which emergent shared-stories can arise [an excellent application for complexity-theory and complexity-practice?]
• markets are about aspirations, individual and shared purpose, meaning, identity, yet also in-the-moment response to passing events [for which we would use... what?]
• markets are all of these, all weaving together into a single whole [for which we would use... also what?]

There’s a definite structure and sequence to this, too – what I call the market model and market-cycle:

Classic ‘scientific management’ works well with the ‘operations bit’ – the transactions. Hard-systems theory works well with identifying appropriate tactics in the planning-stage. We need complexity-theory and so on to help us work with the emergent strategic patterns out of the broader market. But as yet we don’t seem to have much – certainly in the sense of formal theory and the like – to work with the Black Swan opportunities and very-real kurtosis-risks that are further out, often beyond the nominal market itself, in the deeper shared-enterprise space from where trust and respect arise and fall. And we also don’t have much on how to work with change, with inherent-certainty – rather than futilely trying to fight against it, as business-as-usual so often tries (and fails) to do.

Conventional analytic ‘science’ won’t be much help here, because unique events are, well, unique: it’s all unorder, there’s no repetition for Simple rules or Complicated algorithms, not even enough repetition upon which we could project some Complex pattern. We’re beyond (or outside, or something) from all of that here. And yet we know it does work… somehow…

So how do we work with that Chaotic domain? Running away and asserting that it doesn’t exist other than as a source for emergence – as certain people still purport – doesn’t seem much of an answer to me: not a useful answer, anyway. More useful, perhaps, might be some of the various Agile disciplines – they look like they would have more than a few hints for us there. We know that principles and vision and values do work well here, to provide a kind of ‘guiding star’ amidst the murky chaos of the moment. Likewise there’s what I often describe as the real-time realm of the ‘business-anarchist‘: unlike analysis, it doesn’t waste time looking for rules that it already knows by definition cannot be there. But all of that is only a start: seems likely there’s a whole new discipline – maybe even a whole new science-beyond-science – waiting for all of us to explore. Interesting times indeed…

And beyond that, there’s that ‘fifth-dimension’ discipline – the true quintessence of architecture, perhaps? – about how we move between those different domains. Despite their depiction in that diagram, those S-curves don’t tell us that the respective discipline is dead and gone: far from it, in most cases. What it does tell us is that, once the hype has died down, we come to recognise that that discipline is not the longed-for final ‘The Answer To Life, The Universe, Everything’ – a fact that anyone with even an iota of sense should have known from the start… And once we get past that initial illusion, it can start to settle down into doing something useful.

So yes, Taylorism and its more modern offspring – BPR and and Six Sigma and the like – can indeed be useful, in the right context. Hard-systems theory can be very useful indeed, in the right context. Likewise complexity-science, in the right context. And, we could presume, for whatever we come up with for the Chaotic-domain: it’ll be useful in the right context. The trick, obviously, is to know the context; to know which discipline to use in which context; which disciplines to not use in that context; and how to switch between them as the context changes. And that’s what I mean by this ‘fifth-dimension’ discipline.

I’ve made a few tentative explorations for this over the past few years – such as the cross-maps associated with the SEMPER diagnostic, and the how-to-move-between-disciplines ‘cheat-sheet‘ from the book Disciplines of Dowsing. But there’s a lot more to learn, a lot more to explore – and a lot more on how to adapt it to the enterprise-architecture contexts, too. Again, some interesting challenges, to say the least – and no doubt some ‘Interesting Times’, too?

Anyway, stop there for now: over to you?

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. ]

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?

In a comment to my earlier post ‘Making plans, sort-of‘, Robert Phipps asked:

even though you do not have a plan, [...], you probably have a few themes [...] that will feature regularly, and although we can probably infer some from the tone of recent posts and discussions, perhaps you could offer a kind of ‘version 0.1 cut’ of your new programme. Is it still recognisably EA ?

To answer the last part first:

• Yes, it’s all enterprise-architecture

Whether it’s ‘recognisably EA’ is probably another question entirely… – depends on who’s doing the ‘recognising’, I guess? Main point is that it does seem to be about a much larger scope and scale than most current ‘enterprise’-architectures: a ‘really-big-picture enterprise-architecture’, if you like.

But yes, there do also seem to be some distinct themes in there. I’ll summarise them here, and then expand on them in separate posts, so that this one doesn’t get too long (and also so I might be able to get back to sleep, too…).

Quickest overall summary, to paraphrase an old Heineken advert, is that “it’s about the parts that other enterprise-architectures cannot reach”. (Probably it’d be more accurate to say that it’s more “the parts that other ‘enterprise’-architectures don’t reach”, and I don’t know why they don’t reach them, but there ’tis.)

• It’s about the ‘why’ of architecture

Almost all of the current architectures seem to focus on structure, on the ‘How’ and ‘With-What’. In Zachman terms, they also seem to focus almost exclusively on row-3 (‘Logical Model’) and row-4 (‘Physical Model’) with occasional forays up to row-2 (‘Business Model’), but that’s about it. What I want to know about is what happens in the ‘why’ above that, the reasons behind the architecture in the first place – all the stuff that goes on in row-2, row-1, the row-0 that I had to add to understand the idea of ‘the enterprise’, and the row-00 that I seem to be adding now for the ‘really-big-picture’ of where ‘the enterprise’ comes from in the first place. There’s also a strong cross-link there with an emphasis on effectiveness – rather than solely on ‘efficiency’, as in too much of current architecture-work.

• It’s about architecture-as-story

A theme that’s come up a lot for me over the past few years is on ‘the enterprise as story‘. It’s picked up even more momentum since finding building-architect Matthew Frederick’s ‘two points of view‘ about architecture, one of which was the regular view of architecture as ‘an exercise in structure’, but the other of architecture as ‘an exercise in narrative’. Story also seems to be linked both to the exploration of the ‘why’ of the architecture, and the active, living, expression of that ‘why’. Beyond that, I just know that it feels important, so keep following that thread and see where it leads.

• It’s about the architecture-as-change

In part this is what I’ve called the ‘business-anarchist‘ theme, but again it’s very tightly linked to that question of ‘why’ in an enterprise-architecture. It’s also strongly associated with the theme that way too many people still seem to avoid, namely the sense-making / decision-making space that in the SCCC-categorisation is described as the Chaotic-domain. I suspect that there’s a huge breakthrough in there somewhere, on the scale that Taylorism was back at the start of the last century, and which we’re sort of skirting around with ‘design-thinking’ and the like. Dunno quite what it is, but I can sense the general shape of it in there somewhere, and also that it’s definitely important.

• It’s about the dynamics of architecture

This one will still take quite a bit of further exploration and explanation, but it seems to be about how we move between those different sense-making / decision-making domains. It’s also about designing for change – which is going to be kinda important as we head into what’s clearly going to be a period of massive change – and also about breaking free of the dead weight of some frankly daft ideas such as ‘future state’ of an architecture.

• It’s about people in relation to architecture

This is another screamingly-obvious gap in most current ‘enterprise’-architectures: people barely come into the picture at all. Since one of the core definitions of ‘enterprise’ is that it’s all about people and people’s choices and people’s needs – “the animal spirits of the entrepreneur” – it does seem like it’s kind of an important omission, wouldn’t you think? I’ll freely admit I’m not much of a ‘people-person’, but someone has to address this point in enterprise-architectures, and since this obviously links up very strongly with all of the other themes, it may as well be me…

Enough to answer that ‘no-plan Plan’ question for now, I hope? – more detail to follow on each of these themes, anyway.

So can I go back to sleep, please?

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?