Tom Graves / Tetradian

A kind of announcement, really: a knowledge-base wiki for whole-enterprise architecture is now available and ready for content and use.

I’ve given it a temporary home on my Sidewise server:

• http://ea.sidewise.biz

No doubt it should have a proper domain of its own, but that’ll do for now to get us started.

[By the way, this is another follow-up to my post 'Helping others make sense of my work' - the need for a wiki was a suggestion that came up several times in the comments there.]

It’s a fairly straightforward wiki, based on the WikkaWiki framework – probably the cleanest and simplest wiki-framework I’ve come across. (I’ve struggled with many such frameworks over the years, of which Wikipedia is almost the worst…) Like all wikis, though, it does have its own quirks, hence some quick comments:

– Anyone can read, write or comment. (That’s the default: there’s actually a full access-control system for read, write and comment, all the way down to individual page-level, but that’d take too long to explain here.)

– However, to write, comment or edit, you’ll need to register a user-account. (There’s no charge for this, of course, and should be no privacy-implications: it’s just to stop spam-bots using the site.) There’s a quick summary on how to do this on the wiki home-page.

– One minor ‘gotcha’ is that user-names need to be in wiki-format – what’s known as ‘CamelCase’, beginning with a capital-letter and with at least one additional capital-letter after the start. For example, my user-name is ‘TomG’; you might make yours ‘FredBloggs’ or VikusVdM’.

– Editing is straightforward: click the ‘Edit’ link on the left side of the page-footer, or double-click on the page itself. The ‘Store’ (save) and ‘Preview’ buttons are at the lower-left when you’re editing.

– Formatting is a lot simpler than most wikis: in many cases it’s two repeated-characters. See the ‘Wiki formatting guide’ that’s linked from the home-page. Links are straightforward: ‘[[', then the page wikiname (internal link) or URL (external link), then a space as separator, the link-text, and ']]’.

– Usefully, a page can include a FreeMind-format mindmap: paste the FreeMind XML into the edit-space as the page-content. Read-only, unfortunately, but it’s an easy way to share mindmaps.

– Upload of images and other files is a bit more difficult, and at present only administrators can do it. I’ll hack the code as soon as I can, to allow a broader range of users to upload, but in the meantime, if you want to upload a file, send it to me and I’ll upload it for you.

I’ve put up some initial content to get started – a few dozen definitions, a couple of articles, and a whole load of links to other posts elsewhere – and I’ll continue putting more material up there over the next few days and weeks. But the rest is up to you, really: it’s everyone’s site, not just mine.

Anyway, it’s there, and usable: over to you?

In what ways do ideology and experience inform decision-making in real-time practice? How do we bridge between the intentions we make before and after action, with the decisions we make at the point of action itself? And what implications does this have for our enterprise-architectures?

This extends the previous post on real-time decision-making, ‘Belief and faith at the point of action‘, to crosslink with the earlier ideas on SCAN and sensemaking, and especially about where there is more time available to review and reflect on action.

[A gentle warning and polite request: much of this is still 'work in progress', so do beware the rough edges and knobbly bits, and use it with some caution; and whilst I do need critique on this, please don't be too quick to kick down the scaffolding that's holding it all together. Fair enough?]

The previous post was about how options for sensemaking become more constrained as we approach real-time. Right at the point of action, the options reduce to either a Simple interpretation in terms of of true/false categories, versus a Not-simple interpretation based on a modal-logic of possibility and necessity, which is much harder to explain or even to describe to anyone else. In SCAN we’d depict that compression as follows:

In much the same way, decision-making becomes compressed down to Simple belief versus Not-simple faith – neither of which are actually explainable, and both of which, at the root, are primarily emotional rather than ‘rational’:

In both sensemaking and decision-making, the crucial distinction – indicated in SCAN by where the red-line time-axis crosses the green-line axis of decision-modality – is what I’ve termed the ‘Inverse Einstein test’. Einstein is said to have asserted that “insanity is doing the same thing and expecting different results”: but whilst that’s true in a simple rule-based world, it’s not true – or not necessarily true, anyway – in a more complex world where many things are context-specific or even inherently unique.

So our ‘horizontal’ test is this: if doing the same thing leads to the same results – or is believed to lead to the same results – then it’s a Simple decision; if doing the same thing leads to different results, or if we need to do different things to get the same results, it’s Not-simple.

[Yes, I do know that that's a Simple true/false distinction across a spectrum that in reality is fully modal. If you want to apply the appropriate recursion here, please feel free to do so: I thought it wisest here to keep it as simple as possible, because this can get complicated real fast, and unless we're careful to keep the complexities at bay we could end up with a right old chaos of confusion. Which is, yes, yet another recursion... Hence best to keep it simple for now, as best we can, acknowledge that much of it isn't Simple, and allow the recursions to come back in later when there's a bit more space to work with it.]

The crucial point about real-time is that there’s no time available for a distinct sensemaking-stage: decision links directly to action, and vice-versa. (That’s why it’s called ‘decision’: the same linguistic roots as ‘incision’, it’s literally ‘cutting away’, ‘cutting apart’, the cutting-edge for action in the ‘now’.)

For sensemaking to take place, there must be a gap in time between one decision to the next. The key to John Boyd’s ‘Observe, Orient, Decide, Act’ (OODA) loop – which, importantly, is also not a loop as such – is that it still allows distinct sensemaking (‘Orientation’) to take place, but keeps it as close to real-time as possible: that’s what’s meant by ‘getting inside the opponent’s OODA loop’.

As time-available – the red-line ‘vertical’-axis in SCAN – extends outward either side of real-time, the OODA-’loop’ can become recursive, and thence, given enough time, simplified-out to a Deming-style ‘Plan, Do, Check, Act’ (PDCA) continuous-review cycle, such as is also implied in the US Army’s ‘After Action Review‘:

• “What was supposed to happen?” – what was our Plan?
• “What actually happened?” – what did we Do?
• “What was the source of the difference?” – what do we need to Check?
• “What do we need to do different next time?” – about what do we need to Act?

As I’ve described in other posts, sensemaking-choices tend to split as described in SCAN: there’s a ‘bump’ on the path, indicated by the jump between simple true/false logic versus fully-modal logics of ‘possibility and necessity’ on the ‘horizontal’ axis, contrasted with a much smoother spectrum of choices as available-time extends in the ‘vertical’-axis. Although the ‘vertical’ boundaries are less clear-cut than the ‘horizontal’ ones, this gives us the four SCAN quadrants – Simple, Complicated, Ambiguous, Not-Known:

Those distinctions determine the appropriate tactics for sensemaking, as described in those earlier posts.

Decision-making seems to follow a similar, closely-related pattern – though that’s the part I’m having trouble pinning down right now.

[Boyd's OODA is in part another attempt to pin down the same relationships; likewise Snowden's Cynefin, if rather less so. Jung's frame of 'psychological types' is probably a closer fit than Cynefin for this: I've used a generic decision-types adaptation of it for some decades now, though it's still not quite right. Hence this exploration here.]

So again, it’s ‘work-in-progress’, but this is where I’ve come to at present:

It’s a decision-making frame based on the same horizontal (decision-modality) and vertical (time-available) axes as in SCAN, and hence the same sort-of-quadrants but with a decision-oriented re-labelling: Belief (Simple), Assertion (Complicated), Use (Ambiguous) and Faith (Not-known).

On the left-side of the Inverse-Einstein test, the mechanism that links Assertion and Belief is a drive for certainty, for ‘control’. On the right-side, linking Use or ‘usefulness’ with the real-time openness of Faith, is more a focus on experience, underpinned by a deeper kind of trust – a trust which is often conspicuously absent in any concept of ‘control’.

[For this post I'll focus more on what happens across the horizontal-axis, the relationships between theory and practice, or 'truth' versus 'usefulness'. I'll explore more closely the interactions along the vertical-axis - between what we plan to do versus what we actually do - in a following post.]

In terms of decision-making tactics:

• on the left-side, theory takes precedence over practice – or, in some contexts, ideology rules, which is much the same
• on the right-side, practice takes precedence over theory

In essence, this is CP Snow’s classic ‘The Two Cultures‘, the sciences (left-side) and the arts (right-side). Notice, though, that technology sits on the right, not the left: it uses theory, but that isn’t its actual base – hence the very real dangers in the often-misleading term ‘applied science’.

Bridging the gap, from left to right, is praxis,”the process by which a theory, lesson, or skill is enacted, practised, embodied, or realized”; and from right to left, is pragmatics, “a process where theory is extracted from practice”. As enterprise-architects would be all too aware, the latter always starts from pragma, from “what is expedient rather than technically ideal”: and it usually includes the joys of ‘realpolitik’, of carefully filtering reality to fit in with other people’s prepackaged assumptions…

That boundary denoted by the Inverse Einstein Test is all too real: whether the beliefs in question are ‘scientific’, religious, political or whatever, the ‘need’ for certainty will often trigger huge resistance against anything that doesn’t fit its assumptions. For example, there’s a very close mapping between this frame and the classic scientific-discovery sequence of idea > hypothesis > theory > law, which align with Faith, Use, Assertion and Belief respectively.

In real scientific practice, it’s not a linear sequence, there’s a lot of back-and-forth between each of the steps. And in principle, it should be a continuous-improvement cycle, a broader-scope form of PDCA. But as Thomas Kuhn and many others have documented, that same ‘need’ for certainty often places a near-absolute barrier between supposed ‘scientific law’ and any new ideas – in other words, between Belief and Faith – that brings that cycle to a sudden halt, sometimes for years, decades or even centuries. All too often, in practice, if we take the real-time ‘short-cut’ from Belief to Faith, we will be forcibly forbidden to return along the same path: instead, we’re forced to go ‘the long way round’, via Use and Assertion (hypothesis and theory) – which we may not have time to do. Which is a very real problem. And one that applies as much in enterprise-architecture as in any other field – as we’ve seen with the inane IT-centrism that has dominated the discipline for far too long.

It gets complicated…

What I’ve been seeing, as I’ve explored this frame, is a whole stream of often-subtle misunderstandings and ‘gotchas’ that I’ve noticed time and again in practice in enterprise-architecture and elsewhere. These seem to be where many unnecessary complications and confusions arise – so it’s worth noting them here.

For example, fact arises from experience: its basis is on the right-side of this frame – not the left. What’s on the left-side often purports to be fact: yet it’s not fact as such, but interpretation of fact – a very important difference. The left-side operates on information, an interpretation of raw-data – but it often has no means to identify the source or validity of that information, or its method of interpreting it. (This is the same inherent problem whereby a logic is incapable of assessing the validity of its own assumptions: by definition, it must call on something outside of itself to test those premises.) So on the left-side, there’s actually no difference between ‘real’ and ‘imaginary’ – which can lead to all manner of unpleasant problems if the left-side is allowed to over-dominate in any real-world context…

Importantly, there’s no real difference here between ‘objective’ versus ‘subjective’: that distinction is actually another dimension that’s somewhat orthogonal to this plane. What I feel, or sense, is subjective, but it’s still a fact; whereas how I interpret that feeling or sensation is not a fact – it’s an interpretation. Telling someone that they should or shouldn’t feel something is just plain daft: the feeling itself is a fact – something about which we don’t actually have any choice – whereas the ‘should’ is an interpretation arbitrarily imposed by someone else.

[What we do in response to a feeling is a choice - literally, a 'response-ability' - and is something that can be guided by 'shoulds' and the like: but not the feelings themselves. That's a very important distinction which, sadly, surprisingly few people seem to understand...]

There is a specific sense in which subjective versus objective aligns somewhat with the ‘less-time’ versus ‘more-time’ on the SCAN vertical-axis. More-time means more time available for experimentation and analysis – and that can allow us to identify what’s shared (‘objective fact’) across many people’s experience, versus experiences that are more specific and personal (‘subjective fact’).

But there seems instead to be a tendency to conflate the objective/subjective distinction with the SCAN horizontal-axis – objective-fact as ‘truth’ on the left-side, subjective-fact as ‘not-truth’ on the right-side. There are ways in which that conflation can work – it’s at the core of the Jungian frame, for example – but we need to be careful about it. Using that conflation to dismiss all subjective-fact as ‘irrelevant’ – as the classic ‘command and control’ models would do – not only makes no sense at all, but is extremely unwise in real-world practice…

There also several other key distinctions across either side of the Inverse-Einstein test:

– ‘science’ versus technology, which also parallels ideology versus practice: on the left-side, there’s an assertion that something is ‘true’, whereas on the right-side we proceed as-if it’s true – which is not the same at all.

– organisation versus enterprise: the nature of an organisation is that it’s about left-side themes such as control, beliefs, repeatability and certainty; the nature of an enterprise is that it’s not certain, “a risky venture” and suchlike – with all that that implies.

– structure versus story: most structures within current enterprise architectures will, again, have a left-side focus on providing repeatability and certainty; story and other forms of narrative-knowledge provide an alternate kind of ‘structure’ that holds many of the right-side themes together

– sameness versus uniqueness: another key enterprise-architecture theme, sameness and repeatability is very much a left-side theme, whereas uniqueness is just as much a right-side theme

– ‘best-practice’ versus ‘worst-practice’: the notion of ‘best-practice’ assumes that practice that worked well in one context will be directly applicable to another, the same success repeatable in another; by contrast, maintenance engineers and others who work extensively with unique or near-unique contexts share their learning more through ‘worst-practice’, stories of what didn’t work in a given context. (I think I first heard that one from Dave Snowden? – credit where credit’s due, anyway.)

The trade-offs across each of these dichotomies all have direct implications for the design and structure of any enterprise-architecture.

Implications for enterprise-architecture

Take a look at those dichotomies again: which side do you think is emphasised by current enterprise-architectures?

The obvious answer is that, almost invariably, the left-side is given priority over the right.

However, this has huge consequences for the effectiveness of the overall enterprise, and for the enterprise-architecture that describes it:

• interpretation takes priority over fact: never a good idea…
• theory and ideology takes priority over practice and experience: that’s almost a definition of (misused) Taylorism…
• the need for (spurious) ‘certainty’ and ‘control’ takes priority over trust of anything or anyone: ditto on Taylorism…
• the reliance on true/false decision-methods can render the organisation unable to cope with any form of uniqueness
• the need to force-fit everything into sameness of content – ‘best practice’, IT-centric BPR and the like – fails to grasp the differences of context
• the over-focus on organisation – ‘the letter of the law’ – literally kills off the spirit of enterprise…

Look at most of our existing EA toolsets, too: can you find any toolset that’s actively designed around anything other than true/false logic? Other than in rare model-types such as ORM (Object-Role Modelling), there’s no means to describe modality in relationships – hence, for example, no directly-supported way to describe a usable reference-model that allows for real-world ifs, buts and perhapses.

And whilst every toolset focusses on structure – and most do that very well, too – how many of those toolsets also help us to focus on the counterpart of story? They might support few use-cases, perhaps, but that’s about it: there’s a huge gap in capability there…

What we need, urgently, is a better balance between structure and story, between theory and practice, between organisation and enterprise. And without adequate support in the toolsets, that means that we have to create that balance ourselves.

The crucial point is that this balance is not an ‘either/or’, but a much more modal ‘both/and’:

• theory and experience
• ‘objective’ and ‘subjective’
• ‘science’ and technology
• certainty and trust
• true/false and fully-modal
• organisation and enterprise
• structure and story
• sameness and difference
• ‘sense’ and ‘nonsense‘
• certainty and uncertainty

We will only achieve a real effectiveness in the architecture via a fully-nuanced ‘both/and’ balance across all of these dimensions, and more.

So take a careful look at your own organisation, your own enterprise-architectures and the like: where is it out of balance, in this sense? In SCAN terms, how much does it over-emphasise the left-side at the expense of the right-side? And what can (and must) you do to bring it back into a better balance overall?

Comments/suggestions/experiences on this, anyone?

In enterprise-architecture, in what sense are we using the word ‘enterprise’? As adjective, or as noun? This is another point of language that turns out to be surprisingly important…

We can use ‘enterprise’ as adjective, to describe a scope for something else. That’s the sense that’s used in classic IT-oriented ‘enterprise-architecture’: the context or concern is IT-architecture, at an enterprise-wide scope.

Or we can use ‘enterprise’ as noun, to describe a context or focus of interest, which in turn implies its own scope. That’s the sense that’s used in ‘whole-enterprise architecture: the focus of the architecture is the enterprise itself, and the role of the organisation within that broader enterprise.

The adjective and the noun are related, of course, but they’re not the same. Don’t mix them up!

Ends and means are not the same: everyone knows it’s not a good idea to mix them up.

The same is true of ‘enterprise’ and ‘organisation’. The enterprise represents the ends of what we do; the organisation is part of the means. It’s really important not to mix them up.

[Apologies, but this is another one where the words we use are really important: if we don't have the right words, we can't describe the concept we need. I'll use English here, where those two words 'enterprise' and 'organisation' can draw these distinctions: but in other languages we may have to use other words entirely to convey those same meanings. Let me know what you'd use in your language, perhaps? - thanks.]

The enterprise is the ‘why’ of what we do; the organisation is part of the ‘how’. Don’t mix them up!

The enterprise is about emotion, ‘the animal spirits of the entrepreneur’; often the whole point of the organisation is that it doesn’t express emotion. Don’t mix them up!

The enterprise is inherently about something uncertain; the organisation is all about making things certain. Don’t mix them up!

If we mix them up, we confuse ends with means; the ‘how’ becomes its own ‘why’, the pre-packaged ‘solution’ itself becomes the supposed requirement. Not a good idea…

If we mix them up, we apply emotion to things about which we need to be dispassionate – oh the joys of office-politics… – and fail to use emotion and drive to get things moving again in the direction that we need.

If we mix them up, we confuse ourselves about what is certain, and what is not; we confuse activity with direction; we confuse mere repetition with purpose.

If we mix them up, we end up with an organisation that has no enterprise, whose only real belief is a narcissistic obsession with itself, vapid, emotionless, devoid of meaning, purpose or reason. “An empty thunder, signifying nothing”: how well does that fit your own organisation right now?

If you want your organisation to have enterprise – an end or purpose that means something to everyone in the organisation – then you’ll realise just how important it is to maintain a clear distinction between ‘enterprise’ and ‘organisation’.

The organisation is not the enterprise; the enterprise is not the organisation.

They’re not the same: don’t mix them up!

[Update 05dec11: In a comment below, Stuart Boardman reminds me (thanks Stuart!) that some people here may not be familiar with the way I use the word 'enterprise'. There are several standard dictionary-meanings, but the one that's most useful here is from the early days of economics: 'the animal spirits of the entrepreneur' - the sense that aligns with the usual meaning of 'to be enterprising'.

For more details, perhaps take a look at the brief slidedeck 'What is an enterprise', up on Slideshare.

The content of slide 5 from this slidedeck there may also be useful for this:

Hope this helps, anyway.]

In enterprise-architecture, how do we disentangle business-function, business-capability and business-service?

This one’s for Adam Johnson, particularly as a follow-on to his comment to the previous post ‘More on EA and asset-types [Part 4]‘:

I perceived your usage of function to be business function at a certain level of abstraction that could be perceived as a capability. Sorry..and now based on your reply I think I understand, but lets try an example…

Capability – Marketing Resource Management – What we are capable of
Function – Marketing
Service – Create Marketing Resource

Capability – Disaster Management:Alert / Notification Management
Capability:Actor – Disaster Recovery Lead
Function – Disaster Recovery:Disaster Recovery Triage
Service – Alert / Notify Disaster Recovery Team

Perhaps my take on actor is a bit off, but I’m trying not to think too much…

I’d say that both of those sets are pretty close to what I meant – thanks. The actor of ‘Disaster Recovery Lead’ makes sense as the person (in this implementation) who is able to deliver the work of Alert/Notification for Disaster Management.

It still seems worth going over all of this once more, to hammer home both why clarity is needed, and what we can do about it.

The biggest single problem here is that people tend to use ‘business-function’, ‘business-capability’, ‘business-service’ and sometimes even ‘business-process’ as either direct synonyms or near-synonyms. Sometimes they’re at the same level of abstraction, sometimes not; either way, there’s very little clarity as to which is which, the same term is used by different people to mean different things, and different terms to mean the same things. The result, unsurprisingly, is a lot of confusion – and that confusion certainly does matter when we’re trying to describe or implement an architecture.

To cut through all of this, and to try to introduce some certainty and precision, I’m using a fairly flat set of definitions for the levels of abstraction, and for certain key terms that are used within all layers of abstraction. (Okay, almost all layers – some terms aren’t needed in ‘higher’ levels of abstraction, as we’ll see later.) I’m well aware that others may define these items differently: these are just the definitions that I use with Enterprise Canvas, to manage consistency across the entire architecture space.

First, we have a set of definitions for levels of abstraction, from row-0 – the vision/values layer, ‘the unchanging future’ – to row-6, ‘the unchangeable past’. Each of the rows between those two layers – the Zachman rows 1-5 – represents a changeable future, each row coming closer to the moment of ‘the travelling-Now’; and every one of those rows adds something more to the architecture:

Note, though, that the inverse also applies: each ‘higher’ layer is less definite about the content of the architecture. So, for example, the moment we specify a particular technology, a particular type of implementation, we can’t be above row-4; the moment we specify any kind of content, we can’t be above row-3; row-2 describes relationships, between ‘relevant items’, but no content; and row-1 is just lists of ‘relevant items’.

The reason for the pedantry is that we model things in different ways at different levels of abstraction; and there are different dependencies, which don’t link well – or don’t make sense, rather – across different levels of abstraction. (Hence in Enterprise Canvas we model relationship within a layer by flow- and composition-relations, but between layers with realisation-relations.)

The catch is that what is nominally the same entity may recur in different forms at different levels of abstraction – the same name, the same overall ‘thing’, yet not actually the same entity or same type of ‘thing’ from an architectural perspective. To complicate this even further, it’s common to use an abstract ‘container’-entity at one level as an aggregation of a whole lot of other entities for the next level down – hence a business department is an aggregation of a cluster of facilities and activities, in both a metaphoric (abstract) and administrative (literal) sense.

Given all of that, when we talk about a ‘business function’, what exactly is it?

Uh… werll, ‘s a business-function, innit, know what I mean?

We can just about get away with that inclarity in a general business conversation; we definitely can’t get away with it in architecture. Hence the necessity for Mr Pedant…

In row-2 and above, Zachman’s distinction between What, How, Where, Who, When and Why work well enough. In lower rows, though, they can get seriously misleading – especially around ‘Who’, which gives us a very muddled confusion between the agent for a capability versus the person responsible for that capability. In row-3 and below, once we start to describe service-content in proper detail, we need a lot more precision – hence that service-content checklist in Enterprise Canvas:

The relationships between the asset-types and everything else – the orange section of the checklist – is what we covered in those asset-types posts; the relationships with skill-type and decision-type are essentially the territory covered by SCAN.

For this purpose, the key distinction is between function and capability.

A function is just a place-holder for “where something happens*. Think of it in the same way as for a mathematical function: what_i_get = do_something_with(this_thing,that_value). An alternate term might be ‘interface’: it’s a declaration of a protocol, with some indication of what might happen at that point.

Yet on its own, that function doesn’t do anything: it’s just a declaration of intent, a black-box marked ‘Magic Happens Here’. If we drill down into it, we’ll usually find similar declaration of sub-functions, perhaps chained into defined sub-processes, each with their own sub-sub-functions, and so on – but in effect it’s still just ‘Magic Happens Here’. So a ‘business-function’ is just the same thing at a higher level of abstraction or aggregation: a bigger box labelled ‘Magic Will Happen Here, Honest’.

A capability is the ability to make something happen. A ‘business-unit’ is a cluster of capabilities. Note, though, that on its own, a capability literally has no function: it’s able to do something, but on its own it doesn’t know what that ‘something’ might be. In other words, unrealised potential – a description that certainly applies to all too many real-world business-units…

In itself, a function is kind of like ‘vapour-ware’: we’ve described it, but that doesn’t necessarily mean that we know to do it, or even that we can do it even if we knew how. And on its own, a capability has no function: it needs some practical, useful means and direction to realise all that potential. So it’s only when we put the two together that we get something that could actually be useful: and that coupling of function and capability is what I term a service.

So a ‘business-service’ combines a ‘business-function’ and a ‘business-capability’ (more usually, a business-unit). Note that we can ‘unbundle’ this: that’s what allows us to restructure an organisation and yet still deliver the same business-services. That unbundling and rebundling is what makes outsourcing possible; and it’s the linkage between the functions, the capabilities and the broader more-abstract aims of the enterprise as a whole that determine whether or not that outsourcing is viable in practice. And that’s also why a solid understanding of architecture is so essential to any outsourcing arrangement – including cloud, of course.

There’s one very important complication here. When we’re dealing with machines, and even with IT, there’s a tendency to assume an inherent bundling of function and capability: hence there’s often no perceived difference between function, capability and service, because they’re so tightly bundled together that there’s no way to tell them apart. (For software, the ‘capability’ is actually delivered by the programming-language: from there on up, everything is bundled together.) But this isn’t what happens with real-people: capability and function are definitely separate – or, to put it the other way round, people are highly versatile, whereas machines and IT generally aren’t. This has huge implications for process-redesign, process-automation, disaster-recovery, load-balancing and much, much more in enterprise-architecture and the like.

The same assumed-bundling is echoed in modelling-languages such as BPMN and Archimate. It may be different now, but last time I worked with BPMN, it didn’t even have a realisation-relationship, so there was no way to distinguish between logical-model (row-3) and physical-model (row-4/5). Archimate does have realisation-relationships, but treats different aspects of the same process-implementation as different ‘layers’, which makes it all but impossible to show alternate implementations of the same process – especially for a disaster-recovery context where IT roles have to be taken over by real-people.

Once we disentangle that non-trivial problem, though, Archimate does sort-of distinguish between function and capability, in its distinction between ‘Behaviour’ versus ‘Active Structure’. Unfortunately, it’s the opposite way round to what we might expect: function in this sense here translates to the Archimate ‘Behaviour’ category, whilst capability sort-of translates to ‘Active Structure’, with Archimate’s ‘interface’-entities as the interface to capability, not service or function.

It doesn’t help that in Archimate, service and function (and business-unit, and even business-event) are all bundled together as sort-of-synonyms; but ‘business-actor’ and its virtual and physical equivalents of ‘application-component’ and ‘device’ do at least make some degree of sense. To be somewhat unkind, the structure of Archimate in general is a mess, with many of the entities in plainly the wrong places, in part because of that scrambled pseudo-layering of ‘Business’, ‘Application’ and ‘Technology’: but at least those key distinctions are there.

Anyway, hope that makes more sense, and that it gives you something that you can use in real-world enterprise-architecture practice?

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the first post in this series, we identified four distinct asset-dimensions:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

In the second post we looked at how these same dimensions thread through the entire architecture, as per the ‘service-content checklist’ from Enterprise Canvas, first with an emphasis on Assets and Functions:

In the third post we looked at how those asset-dimensions also apply to Locations and Events.

In this final part of the series, we’ll look at how the asset-dimensions impact on Capabilities, and then how all of those concerns come together within services.

[As before, we'll skip the Decisions and Capabilities:skill columns for now: the asset-dimensions do apply there, but only kind-of in parallel - as implied in the service-content checklist above - rather than directly as in the other columns. A topic for another post, really.]

The asset-dimensions apply to Capabilities in a somewhat more complicated way than for those columns described earlier. What we definitely need to avoid here are those endless arguments about capability versus function versus service versus process and the like, which can get very tangled indeed. So to keep everything as simple as possible, I use a very flat definition here: a capability is the ability to do something.

[If you want to extend it a bit for the business-context, a capability is the ability to do something that would be of value to the enterprise. We'll see why such a bald definition is so useful later when we look at services.]

In practice, though, this capability ends up with three distinct components:

• action: what kind of capability, what the capability can do, to what, and with what
• actor: who or what does the work implied by the capability
• skill-level: in effect, the ability to deal with real-world variation within the context of that work [which we won't explore here]

The simplest part of this is Capabilities:action. The actions of a capability act on assets, or create changes in assets, so it’s essentially the same as for assets.

We have physical-actions, which act on, use or change physical-assets, or the physical-dimension components of composite-assets.

We have virtual-actions, which act on, use or change virtual-assets, or the virtual-dimension components of composite-assets.

We have relational-actions, which act on, reference or change relational-assets, or the relational-asset components of composite-assets.

And we have aspirational-actions, which act on, reference or change aspirational-assets, or the aspirational-asset components of composite-assets.

Sadly, the real world is rarely quite that simple…

True, if everything lines up straight away – for example, we have the right type of physical-action to work on the right type of physical-asset – it actually is that simple: metal-working capability to work on metal, and so on. Remember, though, that these are dimensions, which in the real world usually occur in fairly complicated and sometimes dynamically-changing composites – both for asset-types, and for the capabilities that would act on them. Getting everything to line up properly is often a lot harder than it looks, with plenty of scope of for inefficiency, ineffectiveness and error – especially if we don’t even know about the relational-asset and aspirational-asset aspects of some task that needs to be done. Hence why we need to use the dimensions-set as a checklist – along with other checklists, of course – to make sure that nothing has been missed.

[I won't give a detailed example here: it'd take too long, and would probably only make sense in that specific context anyway. But if you do need a full example, please let me know? - preferably with some background and description from which to build the example.]

Which brings us to Capabilities:actor – that which actually enacts the required action with the required level(s) of skill and suchlike.

In a business sense, the capability is often thought of as an ‘asset’, a kind of active asset. Yet the capability doesn’t just appear from nowhere: something – or someone – will do that work, will enact the capability. That ‘something or someone’ is the actor of the capability – which in principle implies that it’s the actor, rather than the capability itself, that is the respective ‘asset’.

Which leads us once again to the asset-dimensions, because there are crucial distinctions here about the relationship between actor and asset:

• physical-dimension: actor is embedded in physical-asset (e.g. machine)
• virtual-dimension: actor is embedded in virtual-asset (e.g. as software)
• relational-dimension: actor is linked with via relational-asset (e.g. person-to-person relationship with worker)
• aspirational-dimension: actor is linked to via aspirational-asset (e.g. person-to-purpose relationship with worker)

The key point here is that whilst machines or software are real business-assets, real-people should never be described as ‘assets’. Although the person might be the actor for the capability in terms of doing the required work, it’s the relational- and aspirational-links between the organisation and that person that are the actual assets here: and if those links are lost, the effective access to the capabilities of that actor are lost as well.

This distinction becomes critical when we need to switch back-and-forth between machine, IT and manual implementations of the same nominal capability – such as is a common requirement in prototyping and process-development, in load-balancing, and in business-continuity and disaster-recovery. It’s easy enough to see that if we don’t have the right machines or the right software on the right IT-servers, it’s going to be difficult to get a job done that needs that capability. It’s also obvious that if we don’t have the machines or the IT, then we’re going to need a real person to do the work.

But it’s not as simple as swapping out one machine and plugging in another (even though classic Taylorism assumes that that is the case) – because even if we find someone with the right capability, we’re not going to be able to access that capability without providing enough reason for that person to engage in the work. That’s why the relational (person-to-person) and aspirational (person-to-purpose) links are so important: they in effect provide that person with the reason to be there, the reason to engage their capability. That’s why we need to understand that, from the organisation’s perspective, it’s the relationship that is the key asset here – and never the person as such.

[There are some other interactions we also need to take into account here, around the Capabilities:skill component. For example, skills for high-variability (Complex and Chaotic) contexts are in most cases available only in real-people, not machines or IT: at certain levels of complexity, we're going to need a real person, whether we like it not. Yet if the relationship isn't there, the person may be present, but probably not with the required skill-level: which means that if there isn't adequate attention to relational- and aspirational-assets, the capability will be unavailable, and the service or process won't work. Which makes this very important for a service- or process-architecture. Another topic for another post, though.]

Finally, Services are what bring this all together.

To me, services are the core to the architecture: everything in the enterprise is or represents a service, and every service in an enterprise exists to serve in some way the vision of that enterprise.

[Note that the meaning of 'the enterprise' here is much larger than the organisation: see 'What is an enterprise?'. In enterprise-architecture we develop an architecture for an organisation, but about the extended-enterprise in which that organisation plays its part. Don't fall for the trap of thinking that the organisation 'is' the enterprise: they're fundamentally different.]

Which leads us to another deliberately-flat definition: a service is something that serves a need within the respective context.

So how does the service serve that need? This is where we bring together all of the above work on asset-types:

– The organisation as a whole, and each of its services at every level of decomposition from ‘business-services’ right down to individual actions and web-services and the like, serve the enterprise by making appropriate changes (CRUD etc) to assets on behalf of other services.

– Assets may be of many different forms or types (such as indicated by the asset-dimensions described here), and, within a service, may be changed from one form or type to another as required.

– Assets are located at, and may be be moved between, specific locations.

– Assets are acted on in response to events.

– Assets are acted on (CRUD etc) as specified by functions and their protocols, service-level agreements, contracts etc.

– The ability to act on assets is embodied by capabilities.

– A service brings together the structure of the function and the capabilities to enact that function, to act on specific assets at specific locations in response to specific events. [Also in accordance with specific decision-types at specific skill-levels, but that's that other topic again.]

– A process is a kind of pathway – predefined, free-form, or any combination – that links services together in a sequence that delivers required overall changes to assets or to asset-status or ownership or whatever.

And the asset-dimensions weave across all of this, applying to the assets themselves, and to locations, events, functions, capabilities, services and processes, in all of the ways that we’ve explored above.

That’s it, really.

Comments, anyone?

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the first post in this series, we looked at the concept of four distinct asset-dimensions:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

In the second post we looked at how these same dimensions thread through the entire architecture, as per the ‘service-content checklist’ from Enterprise Canvas:

And we looked at how those asset-dimensions apply in practice to for the first two columns of that checklist: Assets, and Functions.

Moving on, we now apply the same logic to locations: every location, of any type, exists within a schema that incorporates any combination of the asset-type dimensions.

[As in shown the service-content checklist above, there's a fifth dimension - time - that applies primarily to locations, though potentially to specific types of events as well. The key point is that although we do treat it as a dimension here, time is not an asset in the same sense as for the other dimensions: we know this because we can't 'own' time, in any sense, and we can't create it, update it or delete it. (We can waste our own time, of course, and sometimes for or with others as well - but that's not the same as deleting time itself! )]

Obviously, we have physical-locations – locations with physical-dimension schemas – with which we would typically associate physical-assets.

We have virtual-locations, with which we would typically associate virtual and/or physical-assets. An IP-address or URL is a classic-example of a virtual-location. A street-address or room-number is actually a composite, a virtual-asset from an imaginary-schema of street-names or floor-numbers or the like, that also references a parallel schema for physical-locations. Much the same for the pairing of a network-address and rack-location for a data-server, for example.

We have relational-locations, within relational-schemas, within which we find relational-assets: the dreaded org-chart is perhaps the archetypal example of this. (Note, by the way, that it’s the relationship between people that is the asset in this context - never the person!)

[I'll admit I'm not quite sure how best to describe, within this taxonomy, the implicit relationship indicated by an 'owner'-responsibility such as process-owner, project-owner, data-owner etc. There's no person-to-person connection there, so it's probably not a relational-asset; in fact it seems to point strongly towards it being an aspirational-asset, because it's clearly person-to-abstract, even where it's a physical object that's 'owned'. The fact that such 'owner'-responsibilities only work well when there's a personal commitment involved again points to a variant on aspirational-asset. But I'd appreciate any comments you might have on this, anyway.]

Then we have aspirational-locations, within aspirational-schemas, within which we find aspirational-assets. This one’s perhaps a bit of a mindstretch too, but the most obvious example is brand-mapping, where brands are mapped in relation to each other, and demographics mapped to brands.

And, of course, we have temporal-locations, within various forms of timescales – some of which may be time-itself, others as proxies for time, such as video-framenumbers and the like. Time isn’t itself an asset, so we can’t place ‘time-assets’ within time: but we can place other assets, and other locations in other schemas, and so on, in relation to time.

As with functions and assets themselves, locations often exist within composite multiple-dimension schemas, which may intersect with other multiple- or variable-dimension schemas: it gets complicated… But again, this taxonomy does help to disentangle all the threads, which can become highly relevant as we move assets or functions or whatever between or even within different location-schemas.

By contrast, events are relatively straightforward.

We have physical-events: mechanical triggers, events in the real-world, and so on.

We have virtual-events: a signal, a numerical-value, a clock-event.

We have relational-events: something that marks the start of a beautiful relationship, we might say, or an unfortunate divorce – in a business sense, in this case, but the metaphor still holds for events that impact or are triggered by changes in relational-assets.

We have aspirational-events: anything that affects a brand, for example.

And we have composite-events, of course. “A man walks into a bar” might be the beginning of a joke, but in business terms it’s a composite of a physical event, probably a virtual-event ‘door open’ signal, possibly a relational-event, and quite likely a select-a-beer-brand aspirational-event too.

We can also see how the various asset-dimension threads weave through sequences of events, such as in what might happen after “a man walks into a bar”:

• there’s the change-of-status physical-event of no more beer in the vending-machine, which is…
• indicated by the ‘dispenser-empty’ virtual-event signal from the vending-machine, which may lead to…
• a physical-event of an angry kick at the machine from the would-be customer; thence to…
• an end-relation event with the bar-keeper, and…
• the aspirational-event of the signal of a potential beginning of an anti-client aspirational-link ‘anti-asset’ between the now-ex-customer and the bar

Disentangling all of those threads is an interesting exercise for a service-designer or solution-architect, one that really is made a lot easier through this type of taxonomy – though probably not very interesting at all to our ex-customer, who still just wants his drink!

Again, stop there for now: in the final part of this series we’ll explore how the same principle applies to capabilities, and thence to services – to me, the core of the architecture.

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

In the previous post in this series, we looked at the concept of four distinct asset-dimensions: Physical, Virtual, Relational and Aspirational.

The same dimensions carry right the way through the entire architecture. We can see this if we map it as per the ‘service-content checklist’ from Enterprise Canvas, which can also be understood as a much-extended adaptation of a single row from the Zachman taxonomy:

The asset-dimensions are kind of orthogonal to the dimensions represented by the Zachman-style ‘columns’. For this we’ll keep the emphasis on the columns to which these dimensions map directly: Assets, Functions, Locations, ‘action’ and implicit ‘actor’ component of Capabilities, and Events.

[The mapping comes out in a related but somewhat different way in the Decisions/Reasons column and the 'skill-level' component of the Capability column, which I won't go into here.]

On assets themselves, we’ve already covered the fundamentals in that bullet-list from the previous post:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

We need to handle and manage assets in accordance with the respective dimensions: management in terms of storage, security, access, natural-lifecycle, refresh, migration and so on.

It’s all fairly straightforward territory for enterprise-architects; the only real complication is that many entities are or represent composites of dimensions, which means that they need to be handled and managed in accordance with the rules for all of the respective dimensions. A printed book is one simple example:

• book as physical-asset (object): physical storage, ownership-title, inventory-control, access-control, instance-identification, maintenance, repair, physical disposal etc
• book as virtual-asset (information): data-storage, copyright, copy-control, access-control, version-control, validity, review, renewal, metadata, indexing, withdrawal, secure-deletion etc

Just to make it even more fun, the combinations of those composites can change, too, in response to events, the CRUD actions in functions, sometimes in different locations, and even through natural deterioration or depreciation within the lifecycle.

[There's a lot more to explore about the detail of this, but I'll do that in another post: for here I want to concentrate on the way the same principles go across the whole architecture.]

Hence, yes, can be a bit mind-bending at times: but taking a dimensions-approach – using the dimensions as ‘lenses’, if you like – really does help.

In the broadest sense, functions act on assets: they describe the activities that apply CRUD-type changes and the like to assets. Hence, again, we have different dimensions of functions – actually the same dimensions – that act on those respective dimensions of the assets.

We have functions that create, use, change and destroy physical objects, or physical attributes of objects.

We have functions that create, read, update and delete information and other virtual-assets or virtual attributes of entities.

We have functions that help people create relational-links with each other; remember existing relational-links; refresh those links, or provide conditions under which a link can sort-of be transferred to another person, such as in a shop, or an escalation at a call-centre; and although relational-links in effect delete themselves as soon as either party drops it, we have functions which can either assist that to happen, or to dissuade it from happening,

And we have functions that help people create aspirational-links – for example, to connect with a brand. We have many, many functions – most advertising, for example – that help people refresh and renew and reconnect with their aspirations in context of a brand or some other aspirational-link ‘target’: in other words, ‘read’ an aspirational-asset, the aspirational-link itself. We have a suite of functions to get people to ‘update’ the aspirational-asset link – for example, to get someone to change loyalty from a competitor’s brand, or to support ‘upsell’ to a more upmarket brand of our own. And for a few special cases, we have functions that aim intentionally to destroy an aspirational-asset – such as when a brand comes to the end of its life, yet we have no replacement, and we don’t want to upset existing customers of that brand.

And, as before, there will be functions that interweave any or all of these dimensions at the same time. But it’s useful to be able to tease all of the threads apart where necessary – not least because a re-implementation of a function in a different form could lose or gain key aspects of dimensions that we might otherwise not realise were there in the previous form.

Thinking of relational-links and aspirational-links as assets, in exactly the same sense as for physical- and virtual-assets, can sometimes be a bit of a mindstretch: but because it allows us to address all asset-types – and what we do to and with all types of assets – in exactly the same overall way, it really does simplify the architecture-frame a lot. And as we’ll see in a moment, it also brings a new clarity and new simplicity to service-oriented architectures, right up to a whole-enterprise scope.

Stop there for now: in the next post we’ll look at how this applies to locations and events.

What are the different types of assets that we need to deal with in an enterprise-architecture? What implications arise across the architecture from the differences between these types?

[I know I usually write too long, so as a kind of trial-run, I'm splitting up this original long-post into four smaller ones: please let me know if this works better for you? Thanks!]

This one is a sort-of follow-up to the earlier post ‘Charisma, connection and brand‘, which looked at two lesser-understood asset-types, relational and aspirational. It’s also a pick-up on the article pointed to by the following Tweet, with my explanatory comment attached:

• SAlhir: Brand vs. product: what really drives reputation? http://bit.ly/sLf4hs >actually, she says, it’s neither: it’s delivery on promise that matters most – agree.

I usually define an asset as “anything that the organisation uses and/or is of value to the organisation, and for which it is responsible”. In essence, if we can do some form of a CRUD (Create, Read, Update, Delete) to it, and the organisation ‘owns’ it in a stewardship sense at least, then it’s an organisational asset – and hence relevant to the architecture. So this is deliberately broader than the usual definitions of ‘asset’, to enable the architecture to cover the full range of assets, both tangible and intangible.

Overall, there are four different types, or more precisely, four distinct dimensions of assets:

• physical: physical ‘thing’ – independent, tangible, transferrable, alienable
• virtual: data, information, idea – independent, non-tangible, transferrable, non-alienable
• relational: two-way person-to-person connection – between, sort-of-tangible, non-transferrable
• aspirational: one-way person-to-abstract connection (e.g. to vision, value, belief, brand) – between, non-tangible, non-transferrable

So any asset may be or represent not just one of these dimensions – i.e. as an ‘asset-type’ in the same sense – but also a composite of any combination of these dimensions, a combination which may well change over time for the same nominal entity. Hence I often map this in tetradian form, the inner axes of a tetrahedron:

Most business looks only at the physical and/or virtual dimensions, because, being transferrable, that also represents something that can be sold. But it’s the interactions of all of those dimensions that makes it all happen. Consider this in terms of the market-cycle:

Almost by definition, if we’re dealing with business-type Operations, the focus is mainly on saleable, exchangeable physical and/or virtual. Yet even there, whenever real-people are involved, it’s going to imply some aspects of relational and/or aspirational.

In the Tactics space – the start and end of the core sales-process, for example – it’s definitely going to involve relational-links with real-people, and aspirational-links around desires.

Further out, into Strategy, most of the core concerns will revolve around the aspirational-links that underpin reputation and trust.

And if we don’t manage all of those less-tangible dimensions properly, and manage all of the completions properly, the cycle is going to break – yet we probably won’t be able to see or understand why it’s broken. Which means, very quickly, a dead business. Hence this isn’t some trivial ‘academic exercise’: this is absolutely fundamental to all forms of business-architecture and the like. Yet many of the nominal enterprise-architects or business-architects I meet don’t seem to know about any of this: they just point at the financials, for example, and think that that’s the answer to everything. Which I must admit I do find worrying, to say the least…

[Notice that, unlike many conventional models, there isn't a distinct category here for financial-assets. This is not an error, because in this schema we don't treat money any differently from any other asset. A financial-asset is, in effect, a composite of virtual-asset (the information carried by a monetary value, which in itself is usually stable) plus aspirational-asset (the belief in the value of that asset, which can be highly variable), plus also physical-asset if the monetary-value is expressed in the form of cash or some other physical entity.]

The point is that each of these dimensions indicates different requirements for handling: physical cash needs to be handled as a physical-asset, whereas a data-record of the same monetary-value generally doesn’t (other than in terms of its storage or transport within a disk-drive or network, which is a different physical-asset). They’re also worked on in different ways in different functions and by different capabilities, have different event-types, have their own distinct location-schemas and so on – and yet they all interweave with each other in practice in ways that can be mind-bogglingly complex.

Yet architecturally speaking, if we allow ourselves to become confused about what type of asset we’re dealing with, or which dimensions we’re dealing with in each context, we’re going to get into serious trouble. This is especially true if we build a business-model on incorrect assumptions about asset-types – as the media-industries discovered to their cost in the shift, for delivery of music and film and text, from physical/virtual-bundling (a music-manuscript or disk, a cinema-seat, a physical book) to virtual-only (digital data).

So as I understand it, it’s part of the architect’s job to sort it all out, and prevent it from twisting itself into an unmanageable tangle. Hence this post, and others like it.

In the next post, we’ll explore how this same principle of ‘asset-dimensions’ echoes across the entire scope of the architecture.

Have been struggling hard for the past few days with a truly brilliant challenge from Bulgarian enterprise-architect Ivo Velitchkov, when he dropped by for a visit near here over the weekend. And I’d have to admit I’m no nearer solving it as yet. Hmm…

His point is this: there’s a huge body of knowledge – or something like that, I guess? – that’s scattered throughout this website, in my books, on the Slideshare account, and various other places too. But there’s so much of it, spread across so many different themes and topics, with ideas developing and changing over the years: so how on earth can anyone make sense of it all? How does it all tie together? What links with what? What’s changed, what hasn’t changed? And how do we use it all, anyway?

Looking around, fact is that he’s right: I need to apply a bit more enterprise-architecture to my own enterprise-architecture here. Rather than just churning out the work, day after day, more and more new ideas, new concepts, new connections, I need to do more to help people make sense of those ideas in context, and to put them to practical use.

So I’ll make a quick start here, with a brief summary of how the various sources fit together. But for the rest, I’ll need you to help me to help you – if you see what I mean?

This weblog is where most of the visible action happens. Its main role is to present ‘work in progress’, and to ask for comment and feedback to guide that work-in-progress. The good part is that this is where you’ll find whatever I’m working on at the moment – always pushing the boundaries, which I hope is significant for a fair few people at least. The catch is that, almost by definition, what you’ll see here isn’t likely to be in ‘finished’ form. It also covers a huge scope: for example, that ‘no-plan Plan‘ for an extended view of enterprise-architecture is just one small part of it. So it’s very fragmentary, and there’s a lot of it – more than 500 distinct articles so far, excluding background admin items and the regular collections of ‘A week in Tweets’. And I’ll admit the search-tools here aren’t good: a small set of categories, a subset of tags, and a very simple text-search field. Making sense of what’s going on here isn’t easy, especially for someone who’s just dropped in for the first time: so yes, I need to do more to make it easier. Yet what do I need to do?

The books are ‘finished work’, of course. Each book addresses a single issue or theme, and can be used as a standalone item in its own right. Yet other than the barest set of categories, there’s not much there to show how they all link together – which they do, even across the categories. For example, the main purpose of the screenplays and stories is to illustrate ideas that are often too abstract – or, in some cases, too challenging – to explain other than through some form of fiction: yet in essence they’re still the same ideas as in the overall theme of enterprise-architecture. Likewise the books on dowsing: although some people don’t like the fact, they do actually describe the process and practice of sensemaking in some of its most extreme and most concrete forms. But again, making sense of those cross-connections isn’t easy or obvious: I need to do more to make it easier for it to make sense. Yet what would that be?

I probably don’t make enough use of the Sidewise weblog. It’s sort of halfway between this blog and the books: complete standalone articles that address a single theme. More like a story-bank, I guess – or an idea-bank, perhaps? It’s there, anyway: though I do need to explain more about how it links in with everything else. Yet how?

The slidedecks are likewise ‘finished’ – though without the context of the respective conference or whatever, they often seem a bit incomplete. It’s probable I ought to record a sound-track for each: perhaps you might let me know if that would help?

Then there’s the two ‘official’ websites, the Tetradian website and Tom Graves website. Both of these are literally years out of date: at present they’re useful as historical archives, but not much more than that. It’s obvious I need to update them both, and urgently: but what would be the best approach? What do those sites need? More to the point, what do you need from those two websites?

And there’s also the SEMPER Metrics website. Its purpose is to showcase the SEMPER diagnostic, that assesses organisational ‘ability to do work’, and indicates appropriate tools, techniques and tactics to address any identified problem-areas. It even includes a fully-functional implementation of the diagnostic; but since the access-permissions mechanism still doesn’t work properly at present, I’d have to admit that there’s not much point… But it’s there, and usable, sort-of, and potentially useful to quite a lot of people, too: yet what should I do to bring it up to date, and link it in to everything else?

So I’ve spent a lot of time and effort over the past few days trying to find any tools that would help me bring all of this together into a more meaningful, accessible, usable form. Fact is that I can’t find anything that would actually work. There’s CMapTools, of course, or Compendium or Cohere; yet none of them will read in a website or weblog and help me to build an automated, self-maintaining set of concept-maps across all of the articles and other items, which is what seems to be most needed here. Any suggestions, anyone?

The key item that would seem to make sense for this kind of sensemaking would be a glossary/thesaurus, coupled with annotated links to articles and other items. Would that work?

I do have a sort of ‘wiki-engine’ that I wrote some years back that I can re-use for this purpose, though it’ll take some significant hacking to get it closer to self-updating from this weblog. Would that be worth the effort?

And what else would help you to make sense of all of this body of work? And help you to put it into practice in your own context?

Anyone have any advice / comments / suggestions for me here, please?

Many thanks, anyway.