That distinction can sometimes seem subtle – yet it’s very important indeed…

On the surface, it always seems a lot easier to be ‘against’ something. Many NGOs define themselves this way; quite a few businesses will do so, too. Whatever it is that we’re against, it already exists – otherwise we wouldn’t be against it, would we? (In some cases what we’ll say we’re against is the risk of whatever-it-is occurring – in other words, it ‘exists’ only in imaginary form – but as we’ll see, this comes down to much the same in the end.) We want it to stop existing, or not exist: that’s the whole point. It’s real, definite, and wrong – because since we’re against it, it must be wrong. Which means in turn that, by definition, we must be right, we’re ‘in the right’. That’s a good feeling to have: certainty, righteousness, righting the wrongs of the world. Which creates a lot of emotion, a lot of drive. The kind of energy we definitely need in an enterprise-vision and the like.

But…

It’s all too easy for it to be subtly dishonest: we point the finger at others, blame others, show them up as ‘the bad guys’ – which means that, conveniently, there’s no attention placed on us, on how we also support that whatever-it-is that we say we’re ‘against’. (In fact, as Jung warns in his concept of the ‘Shadow‘, we may actually be the worst offenders here, using ‘Other-blame’ as a mechanism to avoid facing our own actions. For examples of this, look at the behaviour espoused or demanded by almost any ‘activist’-group that says it’s ‘against’ something, and compare that with the actual behaviour of that group in action…) Which also means that the only aspects of that which we’re ‘against’ is the parts that others do – not the parts that we do. After all, by definition, we’re ‘the good guys’, we couldn’t be doing anything wrong, could we?

Oops…

If we define ourselves as ‘against’ something, we then need that something to continue to exist, in order to be against it - otherwise we would have no apparent reason to exist. The more we succeed in being against it, the more we’ll find ourselves needing to re-create it, in order to still have something be against. Which, over time, leads us into the inevitable vapidity of the Shirky Principle: “Institutions will try to preserve the problem to which they are the solution“.

Oops…

In short, defining ourselves as ‘against’ something will feel strong, powerful, ‘good’; but it may well be subtly dishonest, and unfortunately it’s all but guaranteed to make things worse.

Not such a good idea, then…

Defining ourselves as ‘for’ something is usually a lot harder. For a start, it probably doesn’t exist as yet – in fact our aim would usually be to create it, to bring it into existence. But because it doesn’t exist, it’s not tangible, it’s often a bit amorphous, a bit blurry, uncertain. Because it doesn’t exist, we first have to imagine the possibility of its existence: and by definition, that can be a somewhat conceptual, abstract exercise. Which means that to make the intent emotive – which it needs to be – we first have to imagine the whatever-it-is, and then convert that imagination into emotion: which can be quite hard to do.

Tricky… definitely. But if we can do it, we can create something new, something valued, something we’re for – all literally ‘real-ised’ from nothing. It didn’t exist; yet when we succeed, it now does exist. That’s pretty impressive, when you stop to think about it.

So defining ourselves as ‘against’ something always seems the easier way: but it doesn’t work. Whereas being ‘for’ something may seem a whole lot harder, but it does work.

So whenever we define a vision or the the like, we need always to do so in terms of ‘for’, not ‘against’.

No doubt, though, that it is easier to start from a ‘being-against’. So to make it work, we need to convert – or invert – that initial ‘against’-definition into a ‘for’-type format.

For this, let’s use the example of workplace-bullying.

It’s easy to be against bullying in the workplace: very easy to see it as ‘bad’, ‘wrong’, ‘wicked’, and all the rest. Very emotive, obviously.

Yet it’s also all too easy to point to ‘Them’, ‘the bullies’ – and fail to notice how we ourselves do exactly the same… And being ‘against’ bullying typically means that the more successful we are in ‘naming and shaming’ the bullies (which, by the way, is itself a form of bullying…), the more we’ll need to keep hunting harder to find even the slightest scrap of bullying-type behaviour in others. Which leads, in time, to that style of bullying so typical of any form of ‘political correctness’; and from there, all too easily, to the workplace-equivalent of the Inquisition. Being ‘against’ slowly pushes us towards where we preserve – in fact become – the ‘problem’ to which we purport to be ‘the solution’. And yes, that really is what happens, time after time after time.

So to make it work, we need to turn it round: for, not against.

For this example of workplace-bullying, one place to start is not so much the undesirable behaviour, as the consequences of that behaviour. This is described well, for example, by Bob Sutton in his book The No-Asshole Rule: “After encountering the person, people feel oppressed, humiliated or otherwise worse about themselves”. If we’re against workplace-bullying, we would be against these consequences too, because they’re symptoms of the occurrence of bullying in the workplace.

So we now turn it round: what does a workplace look like if bullying isn’t happening? – because that’s actually what we’re ‘for’. So, for example, we might look at key themes of intrinsic-motivation, as described in Daniel Pink’s Drive: autonomy, mastery, and purpose. Or we might look at the ‘equality’ column in the gender-pronouns version or gender-neutral version of the extended-Duluth framework, for a broader range of desired behaviours and outcomes: this shows us emotive themes such as safety, trust, respect.

We can now apply to this to the three-part structure for enterprise-vision:

• a descriptor for the content or focus for this enterprise - the ‘things’ or themes that concern everyone in the shared-enterprise
• some kind of action on that content or focus - what is to be done to or with or in relation to those themes or ‘things’
• an emotive qualifier that validates and bridges between content and action - why this matters, why is this of importance and value

If we put all of that together, we’ll end up with something like “we are for creating workplaces where everyone feels safe, supported, valued and productive in their work”.

To achieve those outcomes, yes, we’ll have to address workplace-bullying and the like: but to do so we keep the focus on the desirable outcomes, and behaviours that create those outcomes (the ‘for’), rather than the undesirable behaviours that work against those outcomes (the ‘against’). And by saying that these desirable outcomes apply to everyone, we’ve also avoided the ‘Other-blame’ trap – which makes it easier to engage everyone in creating those outcomes.

[Avoiding 'Other-blame' is especially important in this case, by the way, because one of the most common causes why people indulge in bullying behaviour is because they themselves have been bullied by someone else.]

So, the one-line summary:

always frame an enterprise-vision, or any other statement of intent, in terms of what you’re for – not what you’re ‘against’.

Hope you find this useful, anyway.

Again, I’ll keep the emphasis on the ‘how-to’, and hold back on the theory this time. (Have a wander elsewhere through this blog for the theory-bit! )

A quick reminder about the context of the previous post. A colleague of mine, Alan, has found himself in a new job, company and industry. What’ he’s used to doing is IT-oriented ‘enterprise’-architecture for utilities-management. His new company is in retail and e-retail – a lot of IT, sure, but a fundamentally different type of business, for which a conventional IT-centric version of EA may well be more of a hindrance than a help.

So the recommendation in the previous post was to start off with a focus, in parallel, on five distinct themes:

• the politics and pragmatics of architecture
• setting the stage – the ‘big-picture‘
• finding allies – people who know ‘the trade’
• establishing standards
• finding the story

The post gave a quick summary on each of those themes – enough to get started, I’d hope, though obviously each could be a book (or several) just in itself.

What followed in the Twitterstream was interesting. Some of it was from Alan, some from others – I’ll paraphrase a bit to protect people’s identities and get it into a more usable sequence:

• I know I can’t get same performance as last job right now, but feeling frustrated with this low performance at start.  // I doubt they have same background, it’s new for everyone on strategy/leadership side.
• First week there: trying to find some point to start, there is no architecture there yet. //  I need some kind of quick-start to show EA value first. // I’m trying to start with TOGAF, but is so big for a people without EA culture.
• Everything depends on environment you’re in (culture, timing, IT strength) to propose a quick move
• Is dangerous trying to say something execs want, and end up doing something wrong. Get to know background first // What is the company mission/vision here? – is a good start for any EA.
• So, need to be calm, take a deep breath, do baby-steps on each thread with execs’ participation?
• Do you know why PEAF doesn’t have Security and Governance principles examples on this “starter-set” ? // Maybe new edition of the PEAF book soon with these principles?

Let’s explore each of those in a bit more detail. (From here on I’ll use a ‘you’-format rather than ‘we’, for simplicity and to make it more direct, but it’s important to realise that this is generic, not solely advice to a single person.)

First, about frustration. Yeah, that’s very real at this point. The short answer is that it’s normal, absolutely to be expected, nothing wrong with it, yet you do have to deal with it, because the bald fact is that this is going to take time.

A good enterprise-architecture is a kind of conceptual infrastructure: and without it it, you are going to get poorer performance: no doubt about that. But like all infrastructure, it’s easy to not notice it, or to forget about all the effort that went into building it. The one time you do notice it is when it suddenly isn’t there…

It’s really easy to blame yourself here for poorer performance, to think that the poor performance is somehow your fault, your responsibility. But don’t, because without that infrastructure in place, you’re in a situation of ‘reduced response-ability’ – literally, a reduced ability to respond. The responsible action at this point is to deliver the best that you can within the constraints of that inadequate infrastructure, and set out to enhance that infrastructure. Which is exactly what you’re doing. But yes, it will take time, and effort, and everything else.

Getting lost in frustration won’t help. Saying that the infrastructure ‘should’ be there already won’t help. What will help is “be calm, take a deep breath, do baby steps”, and follow the programme. Which is exactly what no-one wants to hear, I know – but unfortunately it is the only way that works.

The need for a quick-start is very real. We need quick results, but above all we need to get the interest and, if possible, real excitement, going right from Day 1. We have to make sure that EA matters to everyone, in their context, their workspace – because without that engagement and excitement, this ain’t goin’ nowhere.

I’ll have to be blunt about this: don’t try to start off straight away with TOGAF, or any of the other ‘heavyweight’ frameworks. They do have very real value, in later stages of EA (though often only in specific sub-domains of EA). But at the start, as that comment in the Twitterstream makes clear, all they’ll do is scare people off. For this earliest stage, we need something simpler.

I usually describe EA-development in terms of six distinct steps:

• Step 0: Get started (initial setup to do EA at all)
• Step 1: What business are we in? (big-picture)
• Step 2: Clean up the mess (horizontal optimisation)
• Step 3: From strategy and execution (top-down)
• Step 4: This is the real-world calling (bottom-up)
• Step 5: Resolving the pain (spiral-out)

TOGAF and the like tend to come into their own in Step 2 and Step 3: the old TOGAF 8 was excellent for Step-2 clean-up of the IT infrastructure and application-landscape, for example, whereas TOGAF 9 is more focussed on Step-3 strategy and the like. But before that happens, we need to have done the Step-1 work of establishing the enterprise-context (which TOGAF’s so-called ‘Business Architecture’ does not do well); and before that, we need to have established, in Step-0, the reason and desire for doing EA at all (which TOGAF’s ‘Vision’ is probably supposed to do, but doesn’t). And it’s in that very first proto-step that PEAF in particular comes into its own.

Do take a look at PEAF’s structure, especially its startup phase. To me at least, PEAF doesn’t compete as such with TOGAF or the like, because it describes what you need to do before going anywhere near any of the ‘heavyweights’.

And what PEAF emphasises is that the very first step after someone in the organisation decides to do something about EA is a first-stage training, education, above all communication. In PEAF, that first-stage introductory workshop includes slidedecks for each of these topics:

• EA – Why I Don’t Need It
• EA – Frameworks
• EA – Enterprise Debt
• EA – Model vs CMDB
• EA – Traits of an Enterprise Architect

It’s structured so that senior execs need be there only for the first few items: in particular “Why you don’t need EA” and the core concept of “Enterprise Debt”. The more detailed information is relevant only to those who need to be more actively involved in everyday EA.

[Notice the unusual negative, 'Why you don't need EA': it's a deliberate 'anti-sell', showing the value of something by being open about where it does not add value - and not presenting it as 'The Answer To Everything', as happens so often elsewhere...]

Perhaps the most crucial point is that there is a step-by-step process here: and it really is important to follow those steps, because that sequence and content is the end-result of a very careful study of what doesn’t work…

The ‘executive’ part of that workshop is no more than half a day; the remainder of that entire process probably doesn’t take much longer than a week of elapsed time. In other words, it’s not a lot of work. But you cannot skip it: more to the point, if you do skip it, you can can guarantee that the enterprise-architecture will be going nowhere, slowly, with a lot of frustration. Your choice, really…

Getting to know the background is also crucial, though most of it will happen after that first ‘Step-0 stage’ proto-step. In the previous post, this is what ‘setting the stage’, ‘finding allies’ and ‘finding the story’ were all about. The summaries from the previous post should be enough to get started: for example, the ‘setting the stage’ theme must include concerns such as identifying vision, values and mission – and also being clear about the crucial difference between ‘the organisation’ and ‘the enterprise’, because they’re not the same.

Another really important point here: don’t fall into the ‘TOGAF Trap’ of describing enterprise IT-architecture (EITA) as ‘enterprise-architecture’ (EA). Everything up to this point has been, and must be, about real whole-enterprise architecture – because we must establish the overall scope before we can focus in on any specific subset such as EITA or security or business-architecture or process-architecture anything else. If we constrain the scope too early, we’re then left with no adequate means to connect to the other domain-architectures – which again would guarantee architectural failure, especially over the longer term.

[This, by the way, is another reason why we don't try to use TOGAF for EA until such time as we do want to focus specifically on the IT-related domains. It's very good for EITA, but way too constrained for real-EA: it's really important to understand the difference!]

The other theme, around principles and standards, is something that we shouldn’t worry about too much until we’ve already gone some way down the track. This is why a question such as “Do you know why PEAF doesn’t have Security and Governance principles examples on this ‘starter-set’?” kind of misses the point. In its current design, PEAF’s primary role is at that Step-0 / Step-1 stage, when we’re still only just starting out: and at that point the only thing we need to say about principles and standards is that we are indeed going to need principles and standards, and how to apply those principles and standards to real-world practice. That’s it. Hence the example-principles in PEAF are just that – they’re examples.

Any competent architect – which you would be, if you’ve been in an EA role for some while elsewhere – will know that yes, we will definitely need Security and Governance principles. But in the early stages – particularly the Step-0 ‘Gain Agreement’ stage of PEAF – all you need to do is add them to that list of examples. It doesn’t need anything more that that, for that stage.

Later on, yes, you’ll need a lot more detail. And that’s the point at which we would start to use something like TOGAF, because it does have a very good descriptions of how to specify principles and define reference-architectures and their related standards. But we don’t try to do that too early: all it’ll do is confuse people, drowning them in too-much-detail and putting them off, just at the point when we need to gain their engagement.

So, quick summary: find a way to live with the frustration, because it’s going to be there for a quite a while, whatever you do; and do settle down to do everything step-by-step, because it is the only way that works.

Hope this helps, anyway.

That’s the situation my friend Alan finds himself in right now. An interesting challenge – and some very real, very practical questions to face. Right here. Right now. Today.

[I guess this post can also start to answer in part the question from the previous post, 'How do we make EA make sense?'.]

So: in essence, we start from scratch.

Which means that several threads need to start straight away, somewhat in parallel:

• the politics and pragmatics of architecture
• setting the stage – the ‘big-picture‘
• finding allies – people who know ‘the trade’
• establishing standards
• finding the story

The first point is that everything about any form of enterprise-architecture is intensely ‘political’, in several different senses – which means we need to face the politics of this straight away, right from the start. One of the best guides to this is Kevin Smith’s PEAF (Pragmatic Enterprise Architecture Framework). In essence, it’s a step-by-step guide on how to get enterprise-architecture going within an organisation: see the website and book for more details. [Disclaimer: I edited the book.] The details are all there on the website anyway, so you don’t even have to buy anything (though no doubt Kevin would like it if you did! ).

Probably the single most important concern is to get ‘buy-in’ at senior level – certainly from the respective CxO for the main focus area (e.g. the CIO, for enterprise IT-architecture), but preferably from the CEO and entire executive. To be blunt, if you don’t have that ‘buy-in’, you’ll be going nowhere: you need to get the executive on-side.

As PEAF emphasises, the key to getting the executive on-side – and everyone else on-side, too – is communication. One valuable aspect of this is to get them personally engaged in describing the big-picture of the overall ecosystem in which the organisation operates, and where the organisation fits within that ecosystem. In effect, what we would do here is identify the high-level ‘why’ for which the organisation is a ‘how’ – in other words, the ‘why’ that provides the anchor for all of the organisation’s strategy.

There’s a lot of detail on how to do this in the chapter ‘Step 1: Know your business’ in my book Doing Enterprise Architecture – that chapter is part of the ‘sample-ebook’ version that you can download for free from here. (See the post ‘Tools in action‘ for some photos of those techniques in live use in an executive-level workshop.)

What I also usually do is plough through the publicly-available sources such as the organisation’s website, publications, advertisements, intranet and annual-report. There’s usually enough information there to build some preliminary models with which to get started: or at least, enough for people to tell us that the models are wrong – which is a nicely sneaky way of getting them engaged in telling us their ideas about what it should be. :-) You’ll also notice in that ‘Tools in action’ post that we included people’s own photos on some of the larger wall-mounted models: this again is a good way to get people engaged, and to get conversations going between them about what they can do to improve their own work-context.

Whilst we’re doing this, we need to be looking for any allies – people who are already committed to other themes that connect with enterprise-architecture, and would be likely to see the value of synergy between those areas of interest. This is really important if we’ve only just started with the organisation, because – in my experience, anyway – enterprise-architectures depend greatly on person-to-person conversations and connections: knowing who to talk with, and how to talk with them, will depend in turn on backgrounds and credibility and personal-networks within that organisation that typically take at least five or more years to develop.

Those are people we need as allies: and finding them is one of our first and most urgent priorities as soon as we start work at new place. One tactic I’ve used for this is to sit in the cafe or whatever with a few interesting-looking diagrams spread out over the table: anyone who’s interested enough to stop by and chat is likely to be that kind of ‘connector’, or will at least know someone who is. Again, despite all those models and the rest, what really drives the architecture – what makes it happen, in real-world practice – is person-to-person conversations.

Another concern that those allies can help us with straight away is in identifying the standards that apply in the context. Some standards would apply to just about every industry, but we’d be likely to know those already. Other standards will be generic for the industry as a whole, but they’re usually not hard to find: for example, for this case, in retail, a quick web-search on “retail reference architecture” turned up a swathe of IT-oriented standards from Oracle, Microsoft, Cisco and IBM, together with articles on how to put them to practical use. This is also where TOGAF and the other enterprise-architecture ‘usual suspects’ will start to be of real value – though to be honest they can often be more of a hindrance than a help before this stage.

What we’re also looking for are all the other standards and guidelines and workarounds and the like that are specific to this organisation, some of which – perhaps many – may not exist anywhere in any written form. And that again is where our allies can be really helpful, because otherwise we’d have little chance to know what these are. (And yet everyone else would expect us to know them, because, after all, we are ‘the architects’, aren’t we? – we’re the ones who are supposed to know all this stuff… )

And we’ll also need to be on the lookout for standards that should be there, and aren’t. Which can be a little bit tricky, from a political perspective – not least because it tends to highlight issues that people ‘should’ have known about already, and didn’t… Once again, our allies will be invaluable here, in finding suitably-stealthy ways to introduce these ideas, and to smooth out any ruffled-feathers that may arise.

One trap to watch for is to beware of bringing too many assumptions from our previous organisation and industry: many of those assumptions will not work in this new context. The skills and experience of ‘how to do architecture‘ are probably the only part of the work that will remain unchanged: we need to able and willing to challenge ourselves on just about everything other than that.

Almost all of that above is about enterprise-architecture as structure. The other side is about about architecture as story, the second of Matthew Frederick’s ‘two points of view‘ on architecture:

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.

Although hardly acknowledged at present in mainstream ‘enterprise’-architecture, this is enormously important: story is emotive; story embeds meaning; story engages. Stories matter: in a very real sense, everything about the architecture is or represents or describes a story. Even the enterprise itself is a story. Which means that it’s well worth while to go ‘looking for the story’, much like a journalist or filmmaker or any other storyteller would.

What I usually do for this is ‘go for a walk’, either metaphorically via the website and intranet and so on, or – preferable – literally go for a walk, in person or with one of my new ‘allies’, around some of the organisation’s sites and spaces, looking for all of those interweaving stories that hold everything together. Some of these stories are straightforward enough: every transit through a business-process is a story; every customer-experience or ‘value-journey’ holds a story; every transaction is part of a story that extends far beyond the transaction itself.

Yet there are also the many stories that employees and others tell themselves, and tell each other, about what works, about what doesn’t, about what is or isn’t valued in practice within the organisation, about workarounds or special-cases that no-one’s gotten round to documenting but without which the store or warehouse or whatever won’t work. Those stories are often really important from a structure-perspective, too.

And there’s the story – or stories – that the organisation tells about itself, about how it positions itself in the market, about what it values most and would most like to share with others; and the stories that others in turn tell about the organisation – including whether they believe that the organisation holds to its purported values. Those last stories are some of the most essential real-world feedback for strategy – which in turn feeds back into changes in structure, in the what and how and where and when of the conventional enterprise-architecture.

Best stop there for now, I guess. But, yes, starting a new architecture is always a real challenge – yet always an interesting and worthwhile one!

I hope this has been useful, anyway: and good luck!

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?

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?

That focus does help to keep things simple here…

(Please remember that this is still very much a thought-experiment, but I do believe we’re getting closer now to something that really is implementable.)

To recap, we’d previously ended up with the concept of a ‘mote’, a kind of very-low-level entity that consists merely of an ID, something a bit like a role or opcode, a single optional parameter, and an optional list of related-motes. Conceptually, an individual mote looks a bit like a bacillus:

On its own, it’s tiny – really tiny, and almost meaningless. But that related-mote list turns out to be incredibly powerful – much more powerful than I thought it would be, in fact. It’s also looks like it’d be surprisingly easy to implement.

Even more interesting, it actually removes the distinction between metamodel-layers within implementations, because with this mote-structure they’re all the same: everything is a mote. Whether it’s a model, a metamodel, a metametamodel or metametametamodel, everything is either a single mote or a collection of motes, all with the exact same structure.

Everything’s a story, too: “tell me about yourself” returns a mote’s own story, whilst “tell me what you’re associated with” returns the story that this mote shares with others. The story may be very simple – as it is with a tag-mote – or very broad and complex – as it would be with a mote that represents that represents an entire model – but it’s still just a story, retrieved from each mote in the same way.

More interesting still, the mote-structure also in effect defines a file-structure that can be used both to exchange models between toolsets, and exchange model-types and notations between toolsets. And in essence, subject to a certain amount of intelligence in the toolset, all of that exchange can be done with text-files in a standard structure-format such as JSON or XML. Which gives us a fully non-proprietary file-format for just about everything we would need in an EA toolset.

(Toolsets would differentiate themselves by their user-interface and user-features: what we’re describing here is just a data-structure and file-format, and a conceptual API to drive everything within that structure – not a full features-specification for toolsets!)

And what’s perhaps most interesting of all is that all of that arises from those two questions: “tell me about yourself”, and “tell me what you’re associated with”.

Interested?

A database-structure for motes

To show that this is implementable, start with a database-structure in which to store motes. (The only data-structures that I know are flat-files – which probably won’t work well for this – and SQL relational-databases – which probably will work, if not very efficiently. I’ll use SQL-type structures, but I’ll leave it to others to translate into something more effective with current data-technologies.)

It seems that we’d need just two SQL tables for the whole repository: one for the body-section of motes (MoteBody), and the other for the related-mote lists (MoteReln).

These would need only a few minor tweaks and additions to the provisional mote-structure described earlier in the post ‘EA metamodel – a possible structure‘.

Suggested structure for the MoteBody table:

• MoteID – globally-unique ID (e.g. UUID?)
• MoteNamespace – namespace for the role/opcode (shortish text, e.g. CHAR(64))
• MoteRole – ‘role’ or opcode for the mote (shortish text, e.g. CHAR(64))
• MoteParam – parameter-value for this mote (could be anything, but type can be identified by an attached mote – i.e. could be BLOB or LONGTEXT or a self-identifying polymorphic, dependent on database type and capability)
• MoteIsReadOnly – says whether or not the parameter-value can be changed (boolean)

That’s it: the motes themselves really are tiny. (I added ‘MoteIsReadOnly’ to deal with the likelihood that some parameter-values of some mote-types would need to change, whilst many others should not: it would typically be inherited from the master-template for that mote-type, anyway.)

Namespaces possibly aren’t essential, because it could be part of the MoteRole anyway. But I can see that a lot of people would prefer to keep them separate, so as to link specific roles (opcodes) with specific model-types or notations. (We might also add a category-identifier for the same reason, particularly for parameters and for relation-types.)

What I’ve described as ‘roles’ would actually be a bit more like opcodes (as in assembler-language), or perhaps closer to root-level operators in a ‘word’-based language such as FORTH. In effect, roles would act as a kind of API (or API-interface) for the overall meta-language implied by this structure. There are quite a few examples summarised in the ‘EA metamodel – a possible structure‘ post.

Suggested structure for the MoteReln table:

• MoteRelnID – locally-unique ID (e.g. AutoNum – only needs to be locally-unique because it won’t appear in any file-transfer)
• MoteRelnParent – unique-ID of the ‘parent’-mote, the mote for which this forms part of its related-mote list (type as per MoteBody table)
• MoteRelnDest – unique-ID of the ‘attached’-mote, the mote nominally referenced in the ‘parent’s related-mote list (type as per MoteBody table)
• MoteRelnSubst – either null etc (i.e. no substitute), or unique-ID of a ‘substitute’-mote, replacing the previously-attached mote in the related-mote list (type as per MoteBody table)

Again, that’s it: it’s very simple. The table’s search-order is significant, by the way: the related-mote list develops in time-order, with new attachments appended to the end of the list. Hence we probably don’t index this by MoteRelnID – though we might well do so by MoteRelParent.

The ‘substitute’ is a suggested part of a mechanism to handle versioning. To go back to a previous version, we simply stop the search or scan when we hit an appropriate version-identifier mote, reading forward from the start of the list. The ‘substitute’ tells the scan that this entry has been replaced by the substitute. [Hmm... I may have this somewhat back-to-front? - it needs further thinking, anyway. But the overall principle of versioning via identified 'substitutes' does seem sound, and again does keep everything very simple.]

For indexes, there’s the usual trade-off between speed, efficiency and index-size. In principle we might need to index everything. In practice, it’d probably be essential to index the MoteIDs, but probably not much else.

“Tell me about yourself”

To answer the question “Tell me about yourself?” for a single mote, we do a straightforward tree-walk, starting with this mote, and then, in linear order, every member of its related-mote list, following the trees for their related-mote lists, and so on.

(Note that that would return everything related to this mote. In practice we would probably want to apply some kind of filter on what we return from the tree-walk, so as to constrain the resultant ‘story’ to whatever is meaningful in the context.)

The result would be a collection or table, very similar to the structure of MoteBody, containing only the mote-bodies (because we’ve unpacked all of the related-mote lists into this collection). We would probably need one extra field, to identify the ‘parent’ for each mote-body in the list – in other words, the mote in whose related-mote list this was referenced; the ‘parent’ for the mote with which we started is effectively itself. Note that we may well end up here with multiple copies of the same nominal mote, because they were referenced in different ‘parent’-motes’ related-mote lists.

The motes in this collection are not ‘triples’ as such – in other words entities made up of ‘subject / verb / object’ – but in practice they usually do end up being interpreted in that form. The subject is the ‘parent’-mote; the verb is implied by, or is, the role; and the object is the mote’s parameter.

If we take the simplest example, a tag-mote, which should have an empty related-mote list: its ‘story’ would be “I am a tag from the whatever namespace labelled something“.

A parameter-mote, with a related-mote list of parameter-type, and label in a specific language, might be: “I am a parameter whose integer value is 42, and my label in en-GB is ‘What do you get if you multiply six by nine?’”. [Yup, it's correct, in base-13: an inside-joke for fans of Hitchhiker's Guide To The Galaxy... ] The label’s language-identifier is in the related-mote list for the parameter-label – it didn’t need to be referenced in the parameter-mote itself, because we could find find it via the tree-walk.

It’ll get tedious if I give any more examples, but you can see how the principle works here. Because every mote ultimately has the same structure, we can do the same kind of tree-walk for any kind of mote – including much larger motes such as an entity, a relation or a model, or even the entire contents of the repository.

I know I haven’t described the exact details of where all the verbs and sentence-structures come from, but I hope it’s evident that it should be fairly straightforward to implement. For an already-existing example of the same principle being applied in real-time ‘storytelling’ interpretation of models, see the MyCreativity add-on to the Southbeach toolset.

Everything could be described in text form in this way. For a “tell me about yourself” in a graphic sense – such as in a visual model – the details on how the mote should display itself (if at all) would be in presentation-motes referenced in the mote’s related-mote list. These would usually be derived from the mote used as the base-template for this mote. This would apply primarily to entity-motes, relation-motes, model-motes and other items that would usually be presented in graphic form.

“Tell me what you’re associated with”

Deriving the same kind of story for “tell me what you’re associated with” for each mote will vary somewhat, because the meaning of ‘associated-with’ is somewhat different for each mote-type.

Again, the simplest case is a tag-mote, for which ‘associated-with’ in effect means ‘motes in which I’m referenced’. For this, all we need do is scan the MoteReln table for self-references as ‘MoteRelnDest’, and look up the details of the ‘parent’ (the referencing mote, as identified in the matching ‘MoteRelnParent’ field) in the MoteBody table – a very simple query in SQL or the respective equivalent.

A relation-mote is associated with (usually) two entity-motes (or other motes), but is also associated with a model, because the relation would itself have been defined within that model. These associations should actually be part of the “tell me about yourself” question, because the motes that denote these links should all be referenced in the relation-mote’s related-mote list.

The “tell me what you’re associated with” story is a bit more complicated for entity-motes, because an entity‘s relationships are referenced in the relation‘s related-mote list – not that of the entity-mote. In effect, we have to run the search somewhat backward: scan the MoteReln table for MoteParent of type ‘relation‘, and MoteDest of type ‘source‘ or ‘destination‘, where the parameter for that source or destination (i.e. the referenced MoteID) is that of the entity with which we started. The relation in effect gives us the verb for a triple; the fact of being either source or destination indicates whether this entity is the subject or object of the triple; and, in turn, the item that’s at the other end of the relationship. The relation would also indicate – via the parent model-mote referenced in its related-mote list – the model in which the relationship was defined.

There’s obviously a lot more detail that needs to be worked through to implement all of this for real, but the principle does seem straightforward enough.

A note on access-control

All of the above in effect assumes that everyone should be able to see and use everything. That ain’t how it works in the real world…

So to cope with that reality, I’ve assumed that, other than for fairly harmless root-level mote-types such as tags and language-identifiers, almost every mote will need some kind of access-control. The mechanism I would suggest for this would be yet another mote-type, such as described for the responsibility mote or namespace in the ‘Some key mote-types’ section of the ’EA metamodel – a possible structure‘ post.

The content of this responsibility-mote would act as a second-order filter on the results returned from the “tell me about yourself” and “tell me what you’re associated with” scans. (This assumes that the mote in question can be viewed at all under the respective access-rights, of course.) The filter in effect enacts simple information-hiding: if it can’t be seen under these access-rights, it doesn’t get returned by the scan. This is one of the reasons why relation-links are not cross-referenced in the related-mote list for entity-motes and the like. This also means that we don’t return a full count of all possible relation-links: we only return a count (or the like) of relation-links that can be shown.

Because the access-control mechanism uses the same extensible structure as for every other type of mote, it can be adapted to just about any conceivable security/access-control need. It’s also fully granular, right down to the level of individual motes.

— —

Best I stop there for now? I’ll write another post soon on how I think the mote-’role’ or opcode mechanism would work, and how it could drive or link into a toolset-API, but that can wait until later.

Anyway, comments, as usual, if you would?

[A special thank-you to Anthony Draffin, who chased me to get back to writing more on this!]