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.

Peter wrote:

I think that the most important question of all is still missing, namely:
– What do you rely on?

(The ‘you’ here is the entity-in-focus, as with Graeme’s original two questions of “tell me about yourself?” and “tell me what you’re associated with?”.)

Peter’s right, of course: it is one of the most important questions we need to ask. It’s one reason why I generally extend Graeme’s second question to “tell me what you’re associated with, and why?”. Yet there’s a practical concern here about just how where the intelligence needed to answer that question should reside – and I don’t think it belongs in the metamodel.

To explain why, we probably need to do a brief detour into modelling in general within enterprise-architecture, and in particular our modelling of dependency and resilience. As I see it, there are two key aspects to Peter’s “What do you rely on?” question:

• dependency – about what this entity relies on, within the shared-enterprise
• resilience – about what this entity needs to do, or can do, to get back on track if what it relies on isn’t there

In a systems-theory sense, the first answer to Peter’s reliance-question must be “Everything!” Any shared-enterprise represents a system, and by definition everything within that system depends on the presence of everything else within that system (otherwise it wouldn’t be part of that system). So in practice, from a modelling perspective, there are two additional aspects to the dependency-issue:

• distance from ‘self’ (where ‘self’ is the entity that’s our current focus of attention)
• criticality to self – the risk or opportunity represented by the presence or absence within the system of another entity

To illustrate distance-from-self, consider a typical biological-ecosystem: for example, the world of a dung-beetle:

• distance-1: the dung-beetle relies on the presence of dung
• distance-2: the dung-beetle relies on dung-producing-animals
• distance-3: the dung-beetle relies on fodder for dung-producing animals
• distance-4: the dung-beetle relies conditions that support appropriate fodder for the dung-producing animals in the ecosystem
• (and so on…)

So if we have an invasive species of vegetation that out-competes the existing vegetation and is either toxic or non-palatable to the local cattle, our dung-beetle could be in trouble… Yet on its own it may have no way to know this, because the connections to the critical issues are indirect, several steps distant-from-self. And the greater the distance-from-self, the more whole-of-system knowledge any given entity will need, in order to understand its contextual dependencies, opportunities and risks.

(By the way, this is one of the main reasons why I’ve been pushing so hard for a ‘notation-agnostic’ metamodel for enterprise-architecture and the like. For example, a UML diagram typically shows only the direct point-to-point connections; so we’d typically need to be able to swap out of that diagram and into, say, a Senge-style systems-dependency model or fishbone root-cause model, using the same entities, in order to understand the systemic interdependencies of each of those items. Currently we can sort-of do this in some of the EA toolsets, though typically only within a single notation-set such as UML: my point is that we need to be able to do this, cleanly and consistency, across all and any notations in the EA space. The base for all modelling should be the entities and the relations and flows between them – not the notations with which we model them.)

Criticality is closely related to specialism; and in turn, resilience is closely related to criticality. The catch is that that criticality can occur anywhere in the system. For example, our dung-beetle may need larger piles of dung for its larvae to live in. As long as it doesn’t need specific nutrients that only come from one species, it’d probably be happy with any of the larger herbivores: cows, buffalo, camels, elephants, whatever. Even forest-clearance mightn’t much affect it, because to our dung-beetle a cow is much the same as a giraffe: criticality for that kind of change is low, hence resilience might seem to be high. Yet if there’s a change from cattle or camels to ‘pellet-dung’ producers such as sheep or goats, our dung-beetle could well be in trouble, because that kind of dung is too small to work with. And without the dung-beetle, the nutrient-recycling processes within the ecosystem may be too slow for self-renewal. Hence not just the dung-beetle but its entire ecosystem may be at risk from arbitrary decisions made by humans in ‘markets’ that may be tens or hundreds or thousands of miles away.

These whole-of-system dependencies and resilience-issues are classic simulation / systems-theory territory, illustrated well by the old military adage of a century or so ago:

For want of a nail, the shoe was lost;
for want of the shoe, the horse was lost;
for want of the horse, the rider was lost;
for want of the rider, the battle was lost.

Whole-of-system resilience is also a common concern in studies on complex adaptive systems, where resilience in one area can sometimes even enhance resilience in other more apparently-fragile areas. And there can also be dependency/resilience issues between nominally-interdependent systems that are in ‘system-of-systems’ relationships with each other: these are common in military contexts, though Nick Gall gives a useful non-military example in the section ‘Models of interdependent networks‘ in his seminal ‘Panarchitecture‘ paper for Gartner.

Identifying those kinds of dependencies usually requires a lot of ‘whole-system intelligence’ – in other words, cross-mapping of dependencies and criticalities that may be many steps distant from each other. There are two classic approaches to this:

• ‘inside-out’ – each entity knows everything it needs to know about its own system-context
• ‘outside-in’ – an external observer assesses the interactions across the entire system-context

In practice, neither of these approaches work well, especially for any large real-world system. The ‘inside-out’ approaches assumes high intelligence and information-gathering capability in each entity, which certainly doesn’t apply down at the level of bacillae and bacteria in living ecosystems; the ‘outside-in’ approach requires phenomenal computing-power, and probably can’t cope with any kind of non-linear relationships anyway; and both demand vast cross-context information-flows that can rarely if ever be seen in real-world systems.

Instead, what actually works is observation of patterns of emergence: the ‘intelligence’ – so to speak – arises from the network of relationships, rather from any specific entity either within or (nominally) outside of the system.

Hence, to bring it all back to the EA-metamodel, I suspect that the question “What do you rely on?” may actually be a bit misleading here: it’s certainly a question that we need to ask, and answer, but it’s not a question we can meaningfully answer at the metamodel level. Some kind of intelligence would definitely be needed in order to assess contextual concerns such as whole-system interdependence and resilience: yet the metamodel itself doesn’t have any intelligence as such – it’s just a means to structure information.

Hence for any given entity, it would be meaningful to ask directly each of Graeme’s questions:

• “tell me about yourself” typically identifies the immediate content of the item [and in this metamodel, also the content of any items within the scope of its related-items list]
• “tell me what you’re associated with” identifies the immediate (‘distance-1′) relations in which the item is referenced
• “…and why” identifies the reasons given within those ‘distance-1′ relations

Answering those questions doesn’t require much intelligence: we could easily embed that within an object-method for entities, for example. But as soon as we step beyond that immediate ‘distance-1′ level, the relationships and dependencies become very complex, very quickly – and I don’t think we would be able to embed that within the entities as such. (Okay, we probably could do it, but I doubt that doing so would be effective enough to worthwhile in a practical sense.)

Hence I would suggest that at the metamodel level we should stick to Plan A, and keep everything as simple as possible: Graeme’s two questions (in that slightly-amended form) should be enough to cover most if not all of what we need to support an emergent view of enterprise context.

Your comments on this, of course?

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

Perhaps not quite as technical as some of the other recent posts, but I’ll admit that if enterprise-architectures and the like are not of much interest to you, you might want to skip this one. If that is of interest, though, please do read on!

Information in the Service entity

I said in the previous post that the Service entity needed a name-parameter and not much else. Which was just plain wrong: my apologies…

If we follow the principles of ‘The Metamodel To Rule Them All’, the Service-entity is going to need to carry a lot of descriptive information, about what the service does, what it is, who or what does it, what it uses, where it fits within the overall scheme of things, and so on. (Part of that was implied when I mentioned the use of the ‘single-row extended-Zachman’ to map out service-content – but all that information has to be stored somewhere.)

All of that implies that the Service-entity will need at least one more parameter, and probably several of them. The minimum requirement would be a free-form text field, probably to be used in wiki-style format. A separate and distinct description-field would be useful, too, to help build a service-glossary and service-catalogue.

It’s simple enough to add this in the toolset-metamodel: it just needs to be done from the start, that’s all.

Layers and realization-relations in Enterprise Canvas

A reminder that the layers or ‘rows’ in Enterprise Canvas parallel those in Zachman: they are layers of abstraction – not arbitrary pseudo-’layers’ of implementation, as in classic IT-centric ‘enterprise’-architecture.

The set of layers in Enterprise Canvas are a slightly-extended variant of the Zachman set:

The ‘row-0′ above the Zachman set provides compatibility with ISO-9000 and the like, and represents an unchanging permanent-anchor – specifically, the shared-enterprise Vision and its concomitant Values.

The ‘row-6′ below the Zachman set represents the past, what has actually happened within our architecture; all of the other layers represent future intent, progressively moving closer towards the real-world detail of ‘the Now’ as we move down through the rows. This gives us the support we need for architectural review following a continuous-improvement process such as PDCA or After Action Review:

• What was supposed to happen?
• What actually happened?
• What was the source of the difference?
• What can we learn from this, to do differently next time?

In Enterprise Canvas, we use realization-relations to link between rows – and only between rows. We don’t use realization-relations to connect between the pseudo-’layers’ (‘Business’, ‘Applications’, ‘Technology’ etc) in TOGAF and Archimate and the like.

In most architectural work we’ll focus on row-2 to row-4, shown here as Business-model, System-model and Design-model – otherwise known as ‘business-context’, ‘logical’ and ‘physical’. A ‘logical’ (implementation-independent) design realises – i.e. makes more concrete – the support for a business-need or business-service described in the ‘business-context’; a ‘physical’ (implementation-specific) design realises an implementation for a ‘logical’ service; and so on. (Going the other way, the ‘logical-service’ is the reason for the existence of the ‘physical-service’, the ‘business-service’ is the reason for the existence of the ‘logical-service’, and so on all the way upward to the shared-enterprise Vision.)

If we’re working only within one row, we don’t need (or use) any realization-relations in our model. We only use realization-relations to describe linkages between different layers of abstraction, such as how a specific implementation realises a business-need.

Beware of pseudo-’layers’

I know I’ve said this several times in various posts, but it needs to be hammered home: the ‘layers’ used in IT-centric frameworks such as TOGAF and Archimate are not layers of abstraction, and hence should not be used as layers in enterprise-architecture models. Those pseudo-’layers’ are highly misleading, as they blur the fundamental distinctions between abstraction and implementation-type: for example, the so-called ‘Business’-layer is often used as a random grab-bag containing a jumbled-up mess of any non-implementation-specific abstraction and anything that might be classed as ‘not-IT’. The resultant scrambling of inter-entity relationships is illustrated well in this diagram from the Archimate specification:

Archimate v1.0, Figure 39: (c) Open Group 2009

The relationship between ‘Business Object’ and ‘Data Object’ is correctly shown here as a realization: it crosses a boundary between layers of abstraction. However, all of the other links would be shown in Enterprise Canvas as variations on a theme of composition – i.e. relationships that do not cross layer-boundaries.

Be wary of implicit inter-layer transitions in ‘containment’ views

‘Containment’ is a popular space-saving technique supported by many toolsets, such as Phil Beauvoir’s excellent free Archi cross-platform toolset for Archimate (funded by UK JISC). Within the model, an entity can ‘contain’ other entities, which usually implies that the ‘child’ entities have composition-relations with the ‘parent’.

In Enterprise Canvas, this is implied in the matrix-subdivision of the core Service entity into nine subsidiary cells:

And also implied in the ‘before / during / after’ split of the inter-service flow, as represented in this metamodel by the Exchange-entity:

There’s no doubt that this is ‘cleaner’ and (usually) easier to read than doing the same thing with composition-links:

However, do beware that in some cases, the ‘containment’ may actually be a realization-link, not a composition-link. A very common example is where we would want to show an implementation-independent (row-3) service ‘containing’ the implementation-specific (row-4) services that bring that higher-level abstraction into reality. The catch is that that’s a realization relationship – a transition between rows, or layers of abstraction – rather than a simple matter of granularity within the same layer. Hence if we use ‘containment’, we need some means to distinguish between composition-relations and realization-relations for the implied links between the ‘parent’ and its ‘children’.

One way to do this is that, in keeping with the dotted-line of the realization-relation, we could use a dotted-line rather than solid-line for the boundary of a Service-entity or Exchange-entity. What’s not immediately clear, though, is to which entity we should apply the dotted-line, because the realization could be considered to go either way. One convention we could use is that if only some of the ‘children’ have realization-relations with the parent, then the dotted-line would apply to each of those children; whereas if all of the children have realization-relations with the parent, the dotted-line should apply to the parent:

It would be good if the toolset could manage this automatically for us, but in almost all cases we should be able to do this manually if need be.

Alternate modelling for Exchange entities

The Exchange-entities represent whatever passes between Service-entities in a flow-relation between each other.

In the standard modelling-usage that I described in the previous post, the Exchange is literally placed between Service entities, and the flow-relation links directly to the Exchange on both the ‘incoming’ and ‘outgoing’ side:

This is probably the best way to model Exchange-entities if there’s a strong emphasis on flow-content – as there is in VPEC-T analysis, for example, where we focus on what a service would need or provide before looking for other services that would provide or consume that inter-service content.

But if we’re more interested in relationships between services, with only secondary interest in the content of what passes between them, it may be better to attach the Exchange-entity to the respective flow-relation, rather than visibly interposing it in the flow:

The disadvantage of the ‘attached-Exchange‘ option is that it’s not well suited to showing a split into subsidiary-Exchange items linked to the attached ‘parent’ via composition-relations: visually it becomes too messy, and hard to ‘read’. If you need to show composition / decomposition, use the in-flow format instead.

Ideally, the toolset and its metamodel should be able to support both display-formats. If it can support only one variant, use the in-flow format, rather than the ‘attached’ format.

Keeping things simple

Remember that one of the key aims here is to keep things simple, without ever dropping down into the over-simplistic. If we ignore for the moment the row-0 special-case of the Vision and Value entities, there are only two entity-types in the entire notation: Service, which does something; and Exchange, which represents something that passes between services. That’s it.

Because of that principle that ‘everything is a service’, it should be straightforward to substitute a graphic or photograph for the Service-entity in a model – which should make it much easier to create variations of models that will make visual sense to executives, line-managers and other non-architects, whilst still retaining the formal rigour of the model beneath the visible surface.

And there are only three types of relationship possible between those entities, which in turn follow very simple rules:

• flow-relations (between services) or composition-relations (internal structure of services and exchanges) can only connect within a single ‘row’ or layer of abstraction
• realization-relations (from abstract to concrete) can only connect between layers of abstraction

Again, that’s it.

It would be helpful if the metamodel could also include common non-semantic items such as groups and junctions and annotations, but they’re not required as such for the notation: they’re just useful.

And because the notation is so simple, it allows the true complexity in the context to emerge and surface cleanly through the modelling process. We don’t get distracted by arbitrary pseudo-’layers’: it’s just the enterprise, as enterprise.

For many modelling-purposes, the only relation-type we’ll need is the flow-relation. For example, a simple supply-chain with switching between multiple suppliers:

Or a business-model with multiple client-segments, where we use Exchange-entities to record the different transactions and transaction-content for each client-group:

We use decomposition – modelled via composition-relations – to drill down into more details about structure. When we’re aiming to model trade-offs between implementation-options, or service-substitutions in disaster-recovery, we start to see the real value of a notation that doesn’t make arbitrary distinctions between IT-based, machine-based and manual service-implementations:

For most modelling, we won’t use realization-relations at all. The main occasions where we would use them are:

• mapping ‘logical-to-physical’ transforms, and other moves from abstract to concrete
• mapping dependencies of ‘why’ / ‘how’ between the layers – for example, showing how a specific service contributes to the overall aims of the shared-enterprise

But that’s about it, really. Very simple. And yes, best to keep it that way as much as we can.

Enterprise Canvas – the full set of service-relationships

Because the notation consists of just two main entity-types and three relation-types, it’s certainly simple when compared to other notations. And at first glance it also looks simple when compared with the original Enterprise Canvas summary of inter-service relationships:

Not quite so simple, though, when we map out in this notation the full set of relations shown in that visual-summary above, including the relative roles of each of the flow-relations and all of the implied composition-relations:

That should, I think, give some idea of the full power of the Enterprise Canvas and its underlying concepts: there’s a lot in there…

The original Enterprise Canvas is compact and concise, but it’s likely to be hard to implement in any of the existing EA toolsets. (That original notation is still probably the best for rough-sketches on paper or whiteboard, though.) This simplified version is somewhat less concise, but it would be much easier to implement in an EA toolset, and easier for us to increase its uptake and more general adoption across the EA disciplines. Ultimately, though, just choose whatever works best in the context!

Comments / suggestions as usual, if you would? Many thanks for reading this far, anyway.

The full specification for Enterprise Canvas is in my book Mapping the Enterprise, which at present you can still download for free from here; there’s also a free two-page summary-sheet in PDF format. It incorporates and unifies themes from a wide variety of other model-types in common use in EA, such as Zachman, Archimate, Business Model Canvas, VPEC-T, Viable System Model, Market Model and many others, at first glance it can often seem a fairly complex beast.

The image above summarises the core service-entity and its relationships, but in addition to that, services can be described at seven distinct levels of abstraction, services-flows take place over several distinct phases (the ‘Market Cycle’), and so on. It’s a powerful way to model what’s going on within an enterprise, but there’s a lot to it; and I’d have to admit it’ll seem a bit daunting at first…

And there’s a real problem that at present there’s no EA toolset that implements it. Hence the only way to use it at present in EA modelling is via pen and paper, and then manual transfer to other more constrained, context-specific model-types. Which kind of defeats the object of the exercise, about unifying across the whole enterprise space…

So there’s a real challenge there: compress it all down into a simplified form that can be implemented on an existing EA toolset.

And courtesy of a great meeting yesterday with Alex Yakovlev, it looks like we’ve cracked it:

• one main entity-type (Service)
• one subsidiary entity-type (Exchange)
• three relation-types (flow, composition and realization)

There are also two more subsidiary entity-types (Vision and Value) that are probably optional because they’re only used in one specific context and can be simulated anyway by other entity-types (Service and Exchange respectively).

That’s it.

And it’s all close enough to common model-types such as UML, Archimate or BPMN that it can be implemented via a few minor tweaks to entity-types and relation-types that already exist within those models. Which means that we should be able to translate automatically to and from those other model-types. That’s definitely good news. (For me, anyway. )

So, here goes: formal details for a simplified variant of Enterprise Canvas that can be implemented as a UML Profile or equivalent metamodel in any EA toolset that supports that kind of metamodelling. (Alex is aiming to get an initial UML Profile for Sparx Enterprise Architect done in the next few days – I’ll post here when it becomes available.)

Service entity-type

In Enterprise Canvas, everything is or delivers a service. One side-effect is that that means that, in a model, everything (and everyone) that does something – the service in focus, its suppliers and customers, its investors and beneficiaries, and the services that coordinate, direct and validate it – can all be represented as instances of a single entity-type, Service.

Parameters for the Service entity would depend somewhat on the abstraction-layer being represented.

At the top layer, row-0 ‘Enterprise’, a Service actually represents the shared-enterprise vision, which should be defined solely by its name. (If supported, a Vision entity should be used for this, rather than a Service.)

At the next layer, row-1 ‘Scope’, Service entities can be used (if somewhat incorrectly) as placeholders and carriers for the lists of overall enterprise-content.

At row-2 ‘Business Services’, Service entities should be used, but without much if any content, as the focus at this layer is on key relationships between enterprise-scope services.

At row-3 ‘Service-content’ and below, more detail should added, according to the needs of the respective layer (‘Logical’ implementation-independent, ‘Physical’ implementation-specific, deployment, and run-time record). Content and activity of the service should typically be described in terms of the ‘single-row extended-Zachman’ taxonomy used within Enterprise Canvas:

Toolset implementation: Start from an appropriate metamodel entity-type, such as UML or BPMN ‘Activity’, or Archimate ‘Business Service’. Rename this entity-type ‘Service’. Ensure that it has a ‘name’-parameter; other parameters are probably optional.

For conceptual compatibility with BPMN (‘Activity’), Archimate (‘Business Service’ etc) and UML Activity Diagram (‘Activity’), a Service entity should be displayed as a rounded-rectangle.

Exchange entity-type

The Exchange entity-type represents what is passed between services, or involved in relationships between those services:

Exchange entities should only be used in models representing row-3 ‘Service-content’ or below. The content of the exchange should be described in terms of the ‘Asset’-column in the single-row extended-Zachman taxonomy above.

Toolset implementation: Start from an appropriate metamodel entity-type, such as UML Activity ‘Object’ (‘Document’), BPMN ‘Data Object’, or Archimate ‘Business Object’. Rename this entity-type ‘Exchange’. Ensure that it has at least a ‘name’-parameter, and preferably a text-box and/or checklist to summarise the content of the exchange, as above.

The Exchange entity-type could be represented in several different ways, depending on the content of the exchange, and the notation used as the base for the metamodel. A suggested default would be the ‘data object’ type used in several notations, as above. Alternatively we might use different symbols to represent different asset-types used in the respective exchange: for example, a box for physical objects, a page for information, a stick-figure for relations, and a flash for brands and other aspirational-assets.

However, given that many exchanges may involve multiple asset-types or composites, it may be better to use only the default, or to allow annotation of the single entity-type, allowing one or more of the asset-type symbols as ‘decorations’, similar to the ‘decoration’ add-ons used in Archimate to distinguish between service-types.

Vision and Value entity-types

The Vision and its concomitant Values are the ultimate anchors for everything that happens in the shared-enterprise – or, to put it the other way round, every service and exchange must in some way help towards the realising of the shared-enterprise vision and its values:

The Vision and Value entities should appear only in row-0 ‘Enterprise’, and are the only content that should appear in that row. For most purposes, only one Vision should be used: multiple Vision entities should only be used for the special case of assessing clashes between multiple shared-enterprises impacting on an organisation. (If necessary, a suitably-labelled Service entity may be used as a substitute for a Vision entity.) Use of Value entities is always optional in modelling; any number of Value entities may be attached to a Vision via composition-relations.

Everything in row-1 ‘Scope’ should have a realise-relation to the Vision and, optionally, to one or more of the Value-entities (if any).

Service-entities that are used to represent (‘validation-services’ (i.e. services that deliver ‘validation’ support for other other services, via a flow-relation with a ‘validate’ role), should generally take part in realise-relation chains that ultimately link up to a respective Value entity (if present).

Toolset implementation: In both cases, start from an appropriate metamodel entity-type, such as the Archimate ‘Service’-lozenge or ‘Meaning’-cloud for Vision, and the Archimate ‘Value’-oval for Value. In both cases, the only parameter should be a name of descriptor for the respective vision or value.

For simplicity, the representation should draw on that used for the respective base-type – i.e. lozenge, cloud or oval:

Although usage of distinct Vision and Value entities would be preferred, for clearer modelling, a simpler metamodel-implementation could use a Service entity as a substitute for the Vision entity. In this case, to keep the metamodel as simple as possible, no Value entity should be defined, and hence no specific relation-type links need be defined; instead, the single Service should used as the anchor-point for realise-relations with all layers of abstraction and concretisation (‘rows’) from below.

flow relation-type

Service-entities are connected to each other by flow-relations, to which Exchange-entities may be attached or imposed to indicate what is exchanged between those services:

The flow-relations should only be used in row-2 (‘Business Services’) and below. In row-3 and below, each flow should also take on a distinct role, representing the Enterprise-Canvas inter-service relationships, as follows:

• provide: simple provision of products and services, used to link with other services in Supplier and Customer relationships to this service (a Supplier is a source for or ‘provides’ a flow; a Customer is a destination for or ‘consumes’ a flow)
• invest: a flow from a service in an Investor relationship to this service
• benefit: a flow to a service in a Beneficiary relationship to this service
• coordinate: a flow or exchange with a service in a Coordination guidance-relationship to this service
• direct: a flow or exchange with a service in a Direction guidance-relationship to this service
• validate: a flow or exchange with a service in a Validation guidance-relationship to this service

(An open or ‘unspecified’ role should generally be used in row-2 flow-relations, and in other rows for flows in which the role has not yet been determined.)

Connection-rules are as follows:

• a flow-relation may link a Service-entity to another Service-entity.
• a flow-relation may link a Service-entity to an Exchange-entity, or an Exchange-entity to a Service-entity.

Note that flows can only link ‘horizontally’ across a row (layer of abstraction). They cannot and must not be used to link between services and/or exchanges in different rows.

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘flow’. The parameters should include an optional name, an identifier for the role (e.g. via dropdown-list), and an optional text-area to describe the content (if no Exchange entity is attached), triggering-events and other relevant information.

For consistency with Archimate, BPMN and UML, the flow-relation should be represented by a dotted-line ending in a solid arrow-head, indicating the primary direction of the flow:

(For flow-relations in which there is no emphasised direction of flow, an arrow-head should be used at both ends.)

composition relation-type

In addition to layers of abstraction (‘rows’), we often also need to model layers of granularity (composition), in which we examine in finer detail of the structure and implementation of a Service or Exchange.

The nine subsidiary cells of a service within Enterprise Canvas (a matrix of inbound / self / outbound, and before / during / after the main-transaction) and the three subsidiary flows in an inter-service exchange (again, before / during / after the main-transaction) are somewhat-abstract examples of composition or decomposition. However, these are merely the standard partitionings used in Enterprise Canvas, and any appropriate alternate partitioning may be used instead.

One somewhat-confusing example of composition/decomposition is the purported ‘layering’ in TOGAF or Archimate. In that context, parts of a service may be composed of (actually, implemented by) software applications, which in turn are in part composed of (actually, hosted on) physical IT systems and networks.

All of these can be modelled by composition relations between Service-entities, and between Exchange-entities:

The composition-relations should only be used in row-2 (‘Business Services’) and below. In row-3 (‘Service Content’) and below, it may be necessary to annotate the composition to add further specifics about the nature or sub-type of the composition, for example:

• composition: the ‘child’ services or exchanges are of the same general type as the ‘parent’
• aggregation: the ‘child’ services or exchanges are a mix of structurally-different types relative to the ‘parent’
• assignment: the ‘child’ service or exchange is of a structurally-different type taking on the role of a ‘child’ to the ‘parent’
• used-by: the ‘child’ service or exchange is ‘realised by’ a structurally-different type to the ‘parent’ (e.g. business-service implemented by software-application, in turn hosted-by physical-IT) but at the same level of abstraction

(Note that in Archimate and UML these are all defined as different relation-types. For this context they are best understood as variants on a theme of composition/decomposition.)

The default meaning for a composition-relation is that the ‘child’-entity is of a structurally similar type to the ‘parent’ – i.e. a simple composition/decomposition relationship.

Connection-rules are as follows:

• a composition-relation may link a Service-entity to another Service-entity.
• a composition-relation may link an Exchange-entity to another Exchange-entity.
• a composition-relation may link a Value-entity to a Vision-entity.

Note that composition/decomposition relationships can only link within a row (layer of abstraction). They cannot and must not be used to link between services and/or exchanges in different rows. To link between rows (i.e. different layers of abstraction), always use a realization-relation – a composition-relation should never be used for this purpose.

Take especial care when emulating an Archimate ‘assigned-to’ or ‘uses/used-by’ relation: these are often used in Archimate in a very misleading way, as a kind of analogue of a realization-relation, but one that occurs at the same level of abstraction. Their main function in Archimate, TOGAF and many other IT-centric frameworks is to provide links between their purported ‘layers’ (Business, Application, Technology), which in reality are arbitrary subset-partitions of the conceptual-space. In effect, ‘Business’ is used for anything that involves purpose or human concerns; ‘Application’ is used for all information-related concerns (but for IT-maintained information only); and ‘Technology’ for anything to do with IT-hardware (with no allowance for any non-IT forms of technology). These pseudo-’layers’ have no intrinsic relationship to layers of abstraction, and again are often highly misleading in enterprise-architecture practice. “You Have Been Warned” etc…

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘composition’. The parameters should include an optional name, an identifier for the sub-type (e.g. via dropdown-list), and an optional text-area to describe the composition/decomposition context.

For consistency with Archimate, BPMN and UML, the composition-relation should be represented by a line ending in a solid diamond-arrowhead, with the arrow-head pointing to the ‘parent’:

For other Archimate variations such as aggregation, assignment and used-by, it is probably best to use the respective Archimate line-decoration (open-diamond, dot and line-arrow respectively).

realization relation-type

Links between layers of abstraction – for example, a transform between a ‘logical’ implementation-independent (‘row-3′) service and a ‘physical’ implementation-specific (‘row-4′) instantiation of that service – should be modelled via realization-relations between Service-entities and between Exchange-entities:

The realization-relations should be used between all rows, as appropriate, to create a full trail of dependencies between ‘Why’ (abstract, moving ‘upward’ between rows) and ‘How’ (concrete, moving ‘downward’ between rows).

There are no sub-types of realization-relation.

Connection-rules are as follows:

• a realization-relation may link a Service-entity to another Service-entity.
• a realization-relation may link an Exchange-entity to another Exchange-entity.
• a realization-relation may link a Service-entity ‘upward’ to a Vision-entity or Value-entity.

Note that realization relationships can only link between rows (layers of abstraction). They cannot and must not be used to link between services and/or exchanges in the same row. To link within rows (i.e. the same layer of abstraction), always use a flow-relation or composition-relation – a realization-relation should never be used for this purpose.

Take especial care when emulating an Archimate ‘realization’ relation. These are generally correct, in the sense that they usually link between different levels of abstraction (for example, Data Object realises Business Object); but note that in Archimate they can also be used to link between entities at the same level of abstraction. As usual, the problem here is the misleading pseudo-’layers’ (Business, Application, Technology) in Archimate, TOGAF and the like.

Toolset implementation: Start from an appropriate metamodel relation-type such as Archimate ‘realization’. The parameters should include an optional name and an optional text-area to describe the realisation context.

For consistency with Archimate, BPMN and UML, the realization-relation should be represented by a dotted-line ending in a open-triangle arrowhead, with the arrow-head pointing to the more abstract ‘parent’:

No sub-types are required for the realization-relation.

Some comments on modelling

This simplified version of Enterprise Canvas does incorporate all of the original features, but in somewhat different form: a significant amount of the information – particularly around relative roles of services – is now carried within the entities and flows, rather than as per the original entity-notation. There are also some potential inconsistencies in the way relations are mapped in the ‘Scope’ layer (row-1). In some ways this version is simpler to use, but a side-effect is that more responsibility for correct modelling of underlying detail is passed to the modeller rather than explicit in the notation.

By default, colours for entities and flows are not semantically significant. Use colour in any way which suits the meaning best.

A quick summary of the full simplified notation is as follows:

One crucial area of concern is around inter-layer (inter-row) relationships – i.e. via realization-relations. In common with UML and BPMN, Enterprise Canvas demands a rigorous approach to proper modelling of links between versus within the respective layers of abstraction. However, anyone whose main architecture-modelling background is via Archimate, TOGAF or the like may not be fully aware either of that rigour, or of the need for it in practice. The problem is that because of the explicit IT-orientation and implicit IT-centrism of those frameworks, separation of layers of abstraction is blurred together with pseudo-’layers’ of implementation-category, as described above: ‘Business’ for purpose and human focus, ‘Application’ for (IT-specific) information, and ‘Technology’ for (IT-specific) physical hardware. In effect, the ‘Business’ pseudo-layer includes both purpose/human implementation (row-4 and below) and most items in implementation-independent layers of abstraction (row-3 or above). This cavalier approach to layers of abstraction is a major cause of problems when trying to use Archimate and the like in any non-IT-centric context.

In short: use flow and composition-relations only within layers of abstraction (rows); use realization-relations only between rows. Don’t mix them up!

The real point behind all of this discussion (and there’ve been some really valuable comments here – many thanks indeed!) is that it’s not actually much about the metamodel at all. The structure of the metamodel itself is just a detail that we need at some stage to make things happen.

It’s not really about the model-types or models that could be constructed via such a metamodel – other than that we want this metamodel to support any type of model that would be needed in EA or strategy or the like.

It’s not even much about toolsets – other than that we need some non-proprietary method to allow us to move model-data and model-definitions from one toolset to another, and that we need toolsets that will more truly support the ways we actually work.

What it’s really about is how we use models in enterprise-architecture and other cross-domain disciplines.

The key-word there is ‘cross-domain‘. In a single-domain context – software-architecture, perhaps, or IT-oriented process-design – there are standard model-types for that domain (such as UML and BPMN respectively), and we need to be careful to follow the rules that define those model-types. Sometimes – as with UML – there are multiple model-types and multiple notations, but they all act as views into the same formally-constrained context-space. The main focus in a single-domain context is on design and implementation – on doing something, in accordance with the rules that apply within the respective part of Reality Department.

In cross-domain disciplines like enterprise-architecture or strategy or business-model development, life is a lot messier (in terms of modelling, anyway ). There is, by definition, almost an infinity of model-types and notations that could be used in different ways, all of which follow different and often conflicting rules. Most of those model-types come from specific single-domains – but often we don’t use the various model-types in the same way. Some of the emphasis is still on design – on linking the different domains together, despite the clashes between all those different rules. Yet we also need some means to map across those disparate domains: which is why – from our perspective – we need an underlying metamodel that would allow us to keep track of entities and relations and the like as they move between different models. Some structures such as UML and the underlying MOF standard will allow us to do this to some extent within a single domain – yet doing the same between domains is still something of a nightmare. Which is one reason why we need this ‘EA-metamodel’ work to happen.

Yet often, in cross-domain work, the real focus is not on design, but on sense-making, and thence to decision-making. (Design does matter, of course, and matters a lot, but it usually comes later in the process.) Peter Bakker put it well in one of his comments:

For me the goal is not to make a tool to make or adapt other models but to gain insights from a diversity of models together which you won’t get from looking at the models separately.
For that we need a sense-making tool which can translate the information from all those different senses (models) into a common “brain language” and use that common “brain language” to create new insights (patterns).

To illustrate the point, Peter indicated in other comments that he was using the ideas here in a ‘thought-experiment’ to develop context-insights by moving ideas around between four different model-types:

• mind-map
• Business Model Canvas
• tubemap
• Venn-diagram

Each of those model-types have their own distinct notations, rules and ways of working. Yet in this type of work, they’re also all merged together into a single sense-making process. Same, and different – both at the same time.

Overall, it’s a process I call ‘context-space mapping’, because we build maps and cross-maps across the whole context-space. (There are quite a lot of posts here on context-space mapping, if you’re interested; also some detailed description and practice in my book ‘Everyday Enterprise-Architecture‘.) And within that process, we tend to use models in radically different and often in intentionally-’wrong’ ways. We move things around; we compare, contrast; we break the nominal rules of the model-type (which means, though, that we need to know those rules first if we’re going to get any real value from breaking them…); we use models in very different ways from which they were originally designed – using UML or Business Model Canvas as a concept-map, for example.

What we look for in that process is not so much the certainty of following the rules, but the insights that arise between the models, behind the rules. When ‘the usual rules’ don’t seem to work, or don’t seem to make sense – which is usually the case in any sense-making exercise – we need to run the logic itself backwards, in order to derive what rules actually apply in that part of the real-world that we’re dealing with. It’s part of what I sometimes describe as the ‘business-anarchist‘ role, and which is a distinct discipline in its own right – the discipline of surfacing implications and hidden assumptions, and then reworking them into something we can actually use.

That’s what we need that type of toolset for – to support that type of cross-domain, cross-disciplinary sense-making.

That’s what we need that versatility in models for – to support the toolset in how it defines and uses and displays and cross-compares all the different types of models.

And that’s what we need that metamodel for – to support consistency and idea-tracking across the whole of that sense-making model-space, mapping across the entire context from every alternate direction and view.

So in all of this deep-technical-detail and so on, it’s essential that we never lose track of the real goal here: a means to support how we actually work with models and the like in enterprise-architectures. That metamodel-structure that I’d proposed in the previous posts is just one idea towards implementation of all of that. It’s nothing special, it’s not ‘My Preciousss’ or whatever – it’s just a way to present something that people can argue about and test out the underlying ideas. Other people who know they’re doing with the detail-work on metamodels would no doubt do it much better than I can: yet we do need somewhere to start, some way to start the ball rolling.

That’s what it’s really about. It’s not the metamodel itself that counts; it’s what we can do with it that counts. That’s the real point here.

Over to you for comments, perhaps?

So let’s step back for a moment, and look at real-world EA practice.

Much of our work consists of conversations with people, and getting people to talk together, so as to get the various things and processes and activities and everything else in the organisation and shared-enterprise to work better together.

To support those conversations, and to help sense-making and decision-making, we create models. Lots and lots of models. Different models, in different notations, for different different stakeholders, and different contexts.

Lots and lots of different ways to describe things that are often essentially the same, but happen to be seen from different directions.

Yet keeping track of the samenesses and and togethernesses and relationships and dependencies of everything in all those different portrayals is often a real nightmare.

Finding a way to resolve that nightmare is what this is all about.

A bit of context

Look around at your own context. If you’re doing any kind of architecture-work, or even just explaining things to other people, you’ll be doing lots of diagrams and drawings and models. Some will be hand-drawn, some will be done on a drawing-package such as Visio or Dia or LucidChart, and some may be done within a purpose-built modelling tool such as ArgoUML or Agilian or Sparx Enterprise Architect or Troux Metis. Lots of different ways of doing the same sort of thing with different levels of formal-rigour.

But if we look at it with a more abstract eye, what we’re using is different types of notation. Some will be too freeform to describe as a ‘notation’ as such, though the point is that it’s still used for sense-making and decision-making. Once we get to a certain level, we tend to use some fairly standard notation such as UML or BPMN or Porter Value-Chain or Business Motivation Model or Business Model Canvas, simply because it’s easier to develop shared understanding with a shared model-notation.

And again with an abstract eye, each notation consists of the following:

• a bunch of ‘things’ – the entities of the notation
• a bunch of connections-between-things – the relations
• a bunch of rules or guidelines about how and when and why and with-what things may be related to other things – the semantics that identify the meanings of things and their relations and interdependencies
• often, a graphic backplane, parts of which may be semantically significant as ‘containers‘ for things (such as the ‘building blocks’ in Business Model Canvas)

(Often a notation will also be linked to various methods of how to use the notation, or to change-management processes that relate to or guide the use of the notation. That’s something we’ll need to note and include as we go deeper into the usage of metamodels within EA and the like.)

Each notation describes entities and relations and semantics in a different way. But often they’re actually the same entities that we see in another notation. What we need, then, is a way to keep track of entities (and some of the relations and semantics) as we switch between different notations.

UML (Unified Modelling Language) does this already for software-modelling and software-architecture: a bunch of different ways to look at the ‘areas of concern’ for software-architecture and the like. That’s a very good example here: entities that we develop in a Structure Diagram can be made available (‘re-used’) in any of the other dozen or so diagram-types (notations) within the overall UML.

Yet UML only deals with the software-development aspects of the context. For example, there’s no direct means to link it to an Archimate model, to show how it maps to business processes in an architectural sense. There’s certainly no means to link it to Business Motivation Model, to show dependencies on business-drivers; there’s no means to link it Business Model Canvas, to rethink the overall business-model (and what part software might or might not play in a revised business-model). Those may not be of much concern to software-architecture – but they are of very real concern to entrprise-architecture or any other architecture that needs to intersect with software-architecture and place it within the overall business or enterprise context.

Hence what we’re talking about here is a much-larger-scale equivalent of UML. It needs to accept that every notation is different – in other words there’s no possibility of “One Notation To Rule Them All”, a single notation that would cover every possible need at every level. Instead, like UML, it would aim to be able to maintain and update entities and relations as they move between different notations – in other words, something quite close to “One Metamodel To Link Them All”.

The catch is that we need to go a long way below the surface to make it work. For UML, that underlying support is provided by MOF (OMG Meta-Object Facility), which is also shared with other OMG specifications such as BPMN (and perhaps also OMG BMM – Business Motivation Model?). Yet MOF only applies to the OMG (Object Management Group) specifications: what about all the other models and notations and everything else that’s defined and maintained by everyone else, often not even in a formal metamodel format? To link across that huge scope of ‘the everything’, we need something that goes at least one level deeper again: and that’s what this is all about.

The simplest start-point is that pair of questions from Graeme Burnett, that would apply to any entity or relation or almost anything:

• Tell me about yourself?
• Tell me what you’re associated with, and why?

I’d suggest that that’s where we need to start: with something that is integral enough to be described as ‘yourself’, and to which we could apply those questions. That’s our root-level – a kind of UML for UML-and-everything-else.

Yet that really is at a very low level – deeper than MOF, which is deeper than UML, which is deeper than the UML Structure Diagram, which is deeper than any class-structure model that we might build on that metamodel for UML Structure Diagram.

As we go down through all of those layers, it needs to get simpler and simpler, in order to identify and support the commonality between all those disparate surface-elements. At the kind of level we’re talking about here – what’s known as the ‘M3/M4 metamodel layer’ – it needs to be very simple indeed – which makes it a bit difficult to describe what’s going on, especially by the time we’ve worked our way back up all the way to the surface again.

And, yes, this is where it gets a bit technical…

Building on motes

At this point I’ll link back to a reply to a comment by Peter Bakker on the previous post ‘EA metamodel – a possible structure‘.

Some while back, someone said in a comment to one of the previous that the metamodel I’ve been describing is “like going back to assembly language”. Which, in a sense, it is – I’ll freely admit that.

The commenter didn’t mean it politely – he evidently thought that this was a fatal design flaw, one that invalidated the whole exercise.

But he’d actually missed the point: down at the root – in software, at least – everything is assembly-language. (Or machine-code, to be pedantic, but that’s described here too, of course.)

For this layer we’re talking about here – a layer even deeper than MOF, a layer that is shared across every possible notation - it is the equivalent of assembly-language. It has to be: there’s no choice about that.

And the point here is that if we don’t get the thinking right at this level, we’re not going to get the interoperability and versatility that we need at the surface-level. But this ‘M3/M4 layer’ really is the equivalent of assembly-language. M2/M3 is the equivalent of the compiler, M1/M2 (the surface-ish metamodel) is the high-level language, and M0/M1 (the modelling that we actually work with) is the equivalent of the software-application. It’s essential not to get confused about the layering here: this is a very deep level indeed, far deeper than most people would usually need to go. But we need to get it right here.

Peter said in his comment:

I pretend that I want to start my own Tubemapping Promotion Enterprise 
Therefore I will sketch three models:
1. a mindmap for the brainstorm part
2. a business model canvas for the business model derived/extrapolated from the mindmap
3. a tubemap to visualize the routes from here (the idea) to there (a running business)
I keep them as simple as possible of course.

Next step is to see if I can metamodel/model all three models together with motes following my perception of your guidelines above.

So when we’re developing a multi-notation model – such as Peter’s tubemapping ‘app’, in this case – we need to consider all those four inter-layers at once:

• at the surface layer (M0/M1) we need a notation for each of the distinct models (such as, in Peter’s example, for mind-map, Business Model Canvas, and tubemap)
• at the metamodel (M1/M2) we need a metamodel that would describe the components and interactions (entities and relations, plus the rules and parameters that define them) that make up each of those notations
• at the metametamodel layer (M2/M3) we need to identify how to move entities (and, in a few cases, relations) between each of the metamodels, without losing or damaging anything from what’s already been done at the individual (meta)model layers
• at the ‘atomic’ layer (M3/M4, the focus of this post) we need to identify the ‘assembly-language’ fine-detail of exactly what happens at each stage and with each change to each of the underlying motes, so as to verify that everything actually works and nothing is missed.

Note that for most work we shouldn’t ever need to look at the ‘atomic’ layer. We’re only doing it now because we’re roadtesting the ideas for this ‘mote’ concept, deliberately running everything backwards from the surface layer to check out the interoperability and the rest.

(In other words, yes, we’re doing a deep-dive into the ‘assembly-language’ layer, and it isn’t what we’d normally do. But if you’re a CompSci student, you’d usually expect to have to build a compiler at some stage, to prove that you know what’s going on ‘under the hood’. You’d typically start from hand-sketches that become UML diagrams that become language-specifications for the compiler that works with assembly-language. Most everyday users aren’t CompSci students mucking around with compilers – but someone has to do it if we’re to get usable surface-layer applications. Same here, really.  )

What I’ve been suggesting is that we can support all of those requirements at this layer with a single underlying entity, which I’ve nicknamed the ‘mote’. This has a very simple structure:

• unique identifier
• role-identifier (text-string) – specifies what role this mote plays in the (slightly) larger scheme of things
• parameter (raw-data) – to be interpreted as number, pointer, text, date or anything, according to context
• variable-length list of pointers to ‘related-motes’

In graphic form, it looks a bit like a bacillus:

But we need to remember that it’s tiny – again, much like a bacillus. It’s the ways that they all link together that provide it with the overall power. The mote’s parameter carries just a tiny bit of information; but when that information is placed in context with that from other motes, we can build up towards a much bigger picture.

In effect, what we have in the EA-toolset’s repository is a kind of ‘mote-cloud’:

The ways in which the motes link together I’ve summarised in the previous post, ‘EA metamodel – a possible structure‘. Many remain always as tiny little fragments of information, re-used all over the place in simple many-to-one relationships. But some motes do get large enough to notice – and that’s what we start to see further up the scale, as Entity, Relationship, Model and so on.

Interestingly, there is one context in which we do work directly at the mote-level. It’s when we ask those two questions: “tell me about yourself?” and “tell me what you’re associated with, and why?”. The information to answer those questions is carried directly within the mote, in its embedded role and parameter and via its related-mote list. The ‘yourself’-mote in this case would only be an Entity, a Relation or a Model.

Hope this helps to clarify things a bit further? Comments / suggestions requested as usual, anyway.

This continues the work from previous posts on this theme, such as ‘More detail on EA metamodel‘ and ‘EA metamodel and method‘.

The legal bit: The aim is that this should contribute towards an open standard, and should not be used in proprietary fashion. For now, a Creative Commons Attribution-NonCommercial-ShareAlike (CC BY-NC-SA) license applies to this text.

This will be, again, long, very technical, and probably with no illustrations (you’ll see later why there’s little point in trying to describe this visually – it just gets too messy). Sorry. But if this is of no interest to you, you can always skip it, can’t you?

A reminder that this is all at the M3/M4 metametametamodel layer: the layer at which we describe very simple structures that can define metamodel-families that can define metamodels that can define the structures for models. What we’re after here is something with which we can describe any metamodel or metamodel-family – UML, BPMN, Archimate, Southbeach, Cohere, mindmap, Porter supply-chain, Business Model Canvas, whatever – in the same consistent way, such that we can move entities and relations between each of them, as using each model-type as views into the same overall ‘holograph’.

The other aim is that we should end up with a single file-structure that can move this information – selected subsets of the ‘holograph’ – between toolsets across the whole of the toolset-ecosystem.

What follows here is a first attempt towards a workable way to do this.

At the moment this description is just in pseudocode. It should be implementable as-is – I’ve roughed out some ideas for a preliminary PHP/MySQL implementation, anyway – but judging from the recursive database searches that that first design implies, it would be horribly inefficient and slow. It would be valid for a text-based file-format, though (such as JSON or XML), it does maintain separation between data and presentation (hence should work with a Model-View-Controller implementation-pattern) and so far I think it should work okay with a RESTful interface-protocol – so I think it should be implementable in line with current standards. Over to you on that, anyway.

Core concepts

The ‘holograph’ consists of a cloud of information-objects – call them ‘atoms’, or ‘motes’, or ‘molecules’, or some such term. (I’ll describe them as ‘motes’ from now on.)

For security reasons, encryption could be applied to all or any part of this mote-cloud.

All motes have the same structure, as follows:

• globally-unique identifier
• mote-role (including namespace of role)
• parameter-value for this mote
• list of (pointers to) other related motes

Each mote has an identifiable role – how it should be interpreted, the purpose that it represents within the overall holograph. A namespace typically relates to a specific metamodel or metamodel-family: UML has its own namespace, as does BPMN, BMCanvas, mindmap and so on. At the file-format level, a namespace represents the equivalent of a CSS file for XHTML: in effect, loading a namespace makes the respective metamodel and notation available to the toolset.

Each mote carries one parameter, as indicated by the role. (The value may be null or NaN or some other ‘non-value’, hence in effect the mote carries 0..1 parameters.) The parameter-value is raw data: the rules for interpretation and validation of that data are specified by other motes referenced in the related-mote list for this mote.

There’s an important design-decision as to whether parameter-values for motes can ever be changed. Some cases suggest that we should allow it; others suggest that we should never delete or change anything, but simply create a new mote for each update. I suspect that we’ll end up with a mixture of both, determined by mote-role, but that’s a decision that can be put off until later.

The related-mote list represents the usage and change-history for this mote. It is unidirectional: it lists other motes that are used by this mote – not those that use this mote. It is a list of pointers to other motes – not a container for other motes, because there may often be a many-to-one relationship between motes. In effect, this mechanism allows motes to have the equivalent of any number of parameters, complete with a full version-history for each of those parameters, without actually containing those parameters.

The sequence of the related-mote list is time-linear, and accumulative: nothing is ever deleted as such. The equivalent of deletion is that an entry in the list may be marked as ‘superseded’, indicating that another item in the list has now superseded that item in its role.

Access-control for motes is defined by references to other motes that have access-control roles.

Version-management for motes is defined via references within the related-mote list to version-identifier motes. The version-identifier references and ‘superseded’ markers in the related-mote list would be read in time-order – hence the process of recreating a version would consist of reading the related-mote list up to the respective version-ID marker.

Although nothing is ever deleted, it should be possible to create ‘export’-variants of motes in which version-IDs and ‘superseded’-references are stripped out – in other words, all the information for the current version only for each mote. Likewise, we could create an archive in which appropriate subsets of known-superseded motes are moved to a permanent-archive, with all references to those motes superseded by a pointer to the archive.

In general, toolsets should be able to ignore the absence of any mote that cannot be found. (There may be a small subset of core-level mote-types to which this general rule may not apply – particularly those relating to security and access-control.) Among other things, this enables information-hiding likely to be required by access-control rules.

Some key mote-types

In the bullet-lists that follow, the mote-name or ‘role’ is shown first; then, in brackets, the meaning of the mote-parameter; followed by a brief summary of how the mote is used.

Before we get on to the mote-types that are of most obvious interest – such as entity, relation and model – we need to summarise a whole range of base-level or ‘housekeeping’ motes. These include:

• parameter-type (type-ID): how a mote-parameter should be interpreted and validated (e.g. boolean, string, integer, floating-point number, etc) – in effect, part of an API for the toolset
• parameter-name (text-string): the display-name for a mote-parameter – language is indicated by a language-mote in the related-mote list
• language-name (text-string): identifies the language to which a mote or mote-parameter applies – usually some form of language-ID
• based-on (mote-ID): the ‘type’ on which a mote (entity, relation, model, etc) is based
• tag (text-string): general-purpose tag – used as ‘hooks’ for relations, to mark namespace-affiliation, and for many other ‘tagging’ purposes
• source-tag (mote-ID for tag-mote): reference to a tag-type that may be used as a ‘hook’ within a mote for the ‘source’-end of a relation
• destination-tag (mote-ID for tag-mote): reference to a tag-type that may be used as a ‘hook’ within a mote for the ‘destination’-end of a relation
• source (mote-ID): reference to a mote used as the ‘source’-end of a relation
• destination (mote-ID): reference to a mote used as the ‘destination’-end of a relation
• presentation (presentation-info): content on how to display or represent something – related-mote list will include an identifier from the ‘presentation’ namespace, to indicate how to interpret the mote’s parameter
• media (media-info): content for associated media – related-mote list will include an identifier from the ‘media’ namespace, to indicate how to interpret the mote’s parameter
• responsibility (responsibility/access role): identifies a responsibility/access set, as per the ‘responsibility’ namespace – related-mote list for each of the instances would include any number of pointers to person and/or role motes
• role (role-name within the business): identifies a business role, as a proxy for one or more individual persons – related-mote list may include pointers to actual ‘person’-identifiers
• person (person-ID): identifies an actual person, for responsibility-mapping purposes
• version (version-ID): identifies an edit-version(or, for security-purposes, an access-version) that applies to one or more motes – related-mote list would include a date-time stamp and user-ID, and probably other parameters as required

The ‘presentation’ namespace applies to the primary presentation of the mote itself, and could include the following identifier-motes:

• mime-type (MIME-type identifier): interpret the mote-parameter in terms of the respective standard MIME-type
• draw (schema-ID): interpret the mote-parameter in terms of a non-MIME schema – for example, some toolset-specific equivalent of the Visio draw-spreadsheet

The ‘media’ namespace applies to secondary information related to the mote, but would otherwise essentially be the same as for the ‘presentation’ namespace – i.e. mime-type and suchlike.

The ‘responsibility’ namespace could include the following identifier-motes:

• mote-owner (role or person): role or person responsible for the mote itself
• mote-creator (person): person who created the mote itself
• mote-editor (person): person who last edited the mote itself
• owner (role): role and, ultimately, person who in RACI terms is responsible for (‘accountable for’) the item referenced by the mote
• actor (role or person): role or person who in RACI terms assists in (usually is a user of) the item referenced by the mote
• consulted (role or person): role or person who in RACI terms needs to be consulted about any usage or changes to the item referenced by the mote
• informed (role or person): role or person who in RACI terms needs to be informed about any changes to the item referenced by the mote
• access (role or person): role or person that may access the referencing mote
• exclude (role or person): role or person that may not access the referencing mote

(Any other suggestions for generic ‘housekeeping’ motes?)

Entity

An entity is a mote that describes a ‘thing of interest’ in modelling.

Structurally, it is just another mote – exactly as for all other motes. Its parameter will usually be a text-name for the mote. However, its related-mote list would usually include references to the following types of motes:

• description: a mote with a text-parameter and a label of ‘description’ – used as the content for a derived glossary
• discussion: a mote with a text-parameter – used as the container for a wiki-type discussion
• parameter: any number of motes that represent additional parameters for this mote
• relation-type: tag-mote that acts as the ‘hook’ for a source-tag or destination-tag mote attached to a relation
• presentation: a set of one or more presentation motes that indicate how the mote should be presented – one of these should probably be marked as the default-presentation (perhaps the first, perhaps indicated by a tag?)
• responsibility: a set of responsibility motes that identify the RACI and access-controls for this mote
• model: a set of tag-motes or other parameter-motes that identify the model(s) or notation(s) in which this mote was first created and subsequently used or changed
• based-on: a reference to another entity-mote that was used as the ‘type’ or template on which this entity was based or from which it was derived

(Any suggestions for other items needed in the ‘entity’ related-mote list?)

Note that an entity is ‘model-agnostic’: it can be used with any model or notation, subject to filtering within the toolset (usually via reference to namespaces and/or attached tag-motes).

To display an entity, a referenced presentation mote is called by the toolset.

To edit or update an entity, new references are added to the mote-list, with ‘superseded’ flags attached to the previous mote-references as required. A reference to a version-identifier mote would usually be added to the mote-list once edits are complete, preceding any updates and ‘superseded’-references so as to support the versioning-method described above.

An ‘entity-type’ is simply an entity pointed to as ‘based-on’ by some other entity-mote: every entity is an ‘instance’ of some other entity (ultimately, of the root-definition of mote), but may also be used as a ‘type’.

Relation

A relation is an entity that is used to denote a link between two other entities.

Structurally, it is just another mote. Ultimately it’s based on the ‘entity’ type of mote, and its related-mote list would be likely to include the same types of motes as for ‘entity’. However, the mote-list would also include:

• source-tag: one or more tag-motes that, when embedded in an entity (or relation, or model, since these are structurally derived from ‘entity’), identify that that entity may be used as the ‘source’-end of the relation
• destination-tag: as for source-tag, but for the ‘destination’-end of the relation
• source: mote-ID of the single mote that is linked as the ‘source’-end of the relation
• destination: mote-ID of the single mote that is linked as the ‘destination’-end of the relation

(Any suggestions for other items needed in the ‘relation’ related-mote list?)

There is no built-in constraint on source-tag or destination-tag: for example, the same tag may be used for both, indicating a non-directional relation.

Since relations link to tags rather than to entity-types, the number of relation-types and required relation-linkage definitions increases much more slowly than in a conventional entity-oriented structure (i.e. increase is almost linear, rather than near-exponential or near-factorial).

Dependent on the notation, other parameters may be needed in the related-mote list to define line-type, arrow-type, and so on.

To model flows and exchanges, it may be useful – again, notation-dependent – to attach an entity to the relation itself, to identify the content and conditions for the flow.

Some types of relations will be needed that can attach to any entity – or relation, or model – such as the ‘thesaurus’-type relations (broader-term, narrower-term, synonym, antonym, conflict etc). Another is the ‘annotation’ pattern, which would consist of a text-entity and attached relation that could be linked to anything else. For these cases, we might design this such that the absence of any source-tag or destination-tag mote (or one end only, for the ‘annotation’ pattern) would indicate that the respective relation can be attached to anything.

Display, edit and ‘based-on’ are the same as for entity-motes.

Model

A model is an entity that acts as a container for entities and relations between those entities.

Structurally, it is just another mote. As for ‘relation’, it’s ultimately based on the ‘entity’ type of mote, and its related-mote list would be likely to contain most of the same types of motes. However, the mote-list would also include:

• model-tag (tag-ID): one or more tag-motes that identify the model, and will be attached to any entity or relation created (or edited?) whilst the model is in use in the toolset
• allowed-tag (tag-ID): any number of tag-motes that can be used as filters to select entities and relations that are allowable for use within the model (also possibly excluded-tag, for items that explicitly may not be used within the model?)
• allowed-relation (relation-ID): one or more relation-types that can be used within the model, which via their embedded tag-lists in turn identifies the entity-types that can be included (possibly use allowed-tag instead for this purpose – i.e. tags attached to relation-types?)
• mapping (mapping-ID): a mote that contains a set of parameters that identify the relative positions of entities and relations in terms of some (usually graphical) modelling-schema

(Any suggestions for other items needed in the ‘model’ related-mote list?)

A model and notation will need validation-rules, modelling-constraints and many other parameters and functions. Although some of these can be embedded as parameters within the related-mote list for the ‘model’-entity, or act as triggers via a toolset API, it’s probable that not everything could be managed via configuration alone. For items that cannot be embedded directly into the ‘mote’-structure, there would need to be a separate ‘plug-in’ for the toolset, referenced by an appropriate tag or other mote within the ‘model’-entity definition.

Note that models will often need their own displayable or non-displayable parameters, such as those used in a description-box placed in one corner of the displayed model.

Display, edit and ‘based-on’ are much the same as for entity- and relation-motes. To display itself, the model ‘calls’ the presentation-functions (or rather, presentation-configuration parameters) within the respective motes. In editing, the model would also update its mapping schema, to keep track of the relative positions of its entities and relations. Every model-instance would be based on another model-instance that is used as its model-type.

Other comments

Because all motes have the same underlying structure, it should be relatively simple to implement this even within SQL, or preferably with a more polymorphic object-type database. The recursive database-calls would imply a significant impact on performance, hence at run-time – especially for a large repository – it would probably be wise to convert these to fully-encapsulated objects, but it actually is not essential other than for performance-reasons.

The simplest file-format would be a JSON- or XML-representation of the full set of motes (or selected subset of motes).

A model-definition file (in other words, a means to add a model-type or notation to a toolset) consists simply of the subset of motes that describe that model-type and its associated relations and entity- and relation-presentations, optionally including one or more tags to identify and denote a namespace.

A taxonomy-type framework such as Zachman or TOGAF/Archimate-style layering can in effect be represented very simply by a set of related tags. Graphic frameworks such as Business Model Canvas or Porter Value-Chain can be represented by a backplane image stored within a ‘presentation’ or ‘media’ mote.

— —

Okay, that’s it for now: over to you for comments, suggestions brickbats, whatever?

This follows on from the earlier post ‘More detail on EA metamodel‘, and in particular part of a comment there from Stuart Boardman:

I completely agree that method and governance should be kept separate from the meta-model. It may, however, be useful to develop those (informally) in parallel. The one can be a useful litmus test for the other.

So, let’s do just that: do a worked-example of what actually happens right now in enterprise-architecture and related work, and how a consistent ‘model-agnostic’ metamodel could make things a lot easier for all of us.

For sanity’s sake most of this will be in text form: I’ll aim to add a few illustrations, but if I tried to do it all in models with current tools it’d take me days to do it, rather than a matter of hours. (With present tools a picture can easily be a thousand words’ worth of time – in other words about two hours each. I simply don’t have that kind of time to spare: sorry… – and it’s not hard to visualise anyway, for those of us who have experience of the modelling tools generally in use in ‘the trade’.)

And, once again, this’ll be long: apologies once more… But I think (hope?) it’ll be worth it, anyway.

For this I’ll keep it simple, and keep the focus mainly on method; I’ll tackle governance-issues in another post.

Imagine, then, that we want to do some strategy-work on our organisation’s business-model. (I’m using ‘business-model’ here in a generic sense of ‘how our organisation does its its business’ – in other words conceptually the same for a commercial organisation, an NGO, a government department or anything else.)

So the first point is that we know we’re going to do an identifiable item of work, with an explicit aim: review and perhaps restructure our business-model. We could call that a ‘project’ or an ‘iteration’ or some such – the label doesn’t much matter.

Action: Within our toolset, we create a container-object for all of the work that we’ll do for this project. In doing this, the user-interface presents a list of categories that we might use, and from this we select ‘Business’ and ‘Strategy’. These tags, and a link to the project-container, will be applied to every entity and relation that we create or amend during this project.

We now want to do some kind of business-model, to map out what our organisation does, and what we might do to change it.

Action: Because we’ve said that this is about business and strategy, the user-interface suggests a range of model-types that we could use. We select Business Model Canvas: this displays a BMCanvas frame, to which we can apply ‘sticky-note’ entities and relations between them.

Following the guidelines for modelling with Business Model Canvas, we start to map out the business-model:

One option might be to map out the existing (as-is) model first; we do this by using one specific colour on sticky-notes to indicate the as-is.

Action: We specify on the user-interface that this colour will represent the as-is; this in turn will apply a tag to each object we create, to indicate that status or time-relationship. As we place ‘sticky-note’ objects onto the Canvas, the entity will also acquire a tag indicating that it belongs to Value Proposition, Customer Channels or whatever.

On the Canvas, we also draw relations between some of the ‘sticky-notes’, to indicate how the business-model actually works.

Action: As we add relations, the user-interface would also request extra information about the flows and events that drive the linkage between the respective entities in the business-model. This information would be embedded in tags attached to the relation.

This is all happening in a workshop-session, so we want to record the discussion as well, to make sure that we can review it later without losing all of the context.

Action: The user-interface can attach audio, video, images, URLs or text to any object. As we got through the exploration, we might, for example, attach an audio-stream to the overall project, but also tag particular parts of the audio-stream to the individual objects to which that part of the discussion applies. [See AudioNote and similar iPad apps for how this kind of function already works in practice.]

Having defined the as-is, we now want to start to develop ideas about the to-be business-model.

Action: Within the user-interface, we create a duplicate set of instances from the current instance-set, and attach a new tag to each of the instances to indicate that this will be the to-be.

It’s likely that we’ll want to change things round quite a bit. Before we go into this in detail, though, we want to explore a bit more about the business-context. We’ll start off with a Market Model:

Action: The user-interface displays the Market Model frame, placing the initial to-be items from the Business Model Canvas ‘Key Partners’ cell into the ‘Supplier’ cell here, and ‘Customer Segments’ into this ‘Customer’ cell. Everything else from the other cells in the Business Model Canvas is carried through into this model, within the ‘Organisation’ cell, but not displayed unless explicitly asked for.

We might at this point briefly open up a mind-map model to brainstorm ideas about other players in the overall market/extended-enterprise space.

Action: By default, the mind-map in this context would centre around the enterprise-vision. An initial entity is created for this purpose, with tags to specify the three components of the vision: the items that link everyone in the shared-enterprise, what is done to those items, and why this is of importance overall to each player. We can optionally add Values entities attached to the Vision entity, but it’s not mandatory. The mind-map then shows the ‘Supplier’ and ‘Customer’ entities in relation to the core Vision. We can then add further entities to represent other players in the overall space, perhaps with ‘child’ entities to attach notes about the business-drivers for the respective players, as in this example about the shared-enterprise of Carnaval in Rio de Janeiro:

Every path between players represents a potential direct or indirect business-relationship, focussed around the shared-enterprise vision, and guided by the respective business-drivers. We might, for example, decide to explore in more depth some aspects of those relationships, via a Southbeach-style systems-model in which we describe relations in terms of whether they are potentially useful or harmful to our own organisation or business-model.

Action: Open a Southbeach model with all of the entities (or just the first-level entities – i.e. the players in the enterprise) centred around our own organisation. Attach and set tag-attributes to indicate Southbeach ‘Useful’, ‘Harmful’ or ‘Neutral’ roles, and define Southbeach-notation relations between the entities as required.

Having gained some clarity on how we feel about our organisation’s relationships with other enterprise players, we now return to the Market Model, to clarify the nature of our relationship with each of those players. To do this, we place the entities from the mid-map into the respective region of the Market Model. For Suppliers and Customers, we have contractual relationships; for other players in the market space, the relationship is based on influence via direct engagement, in accordance with the market’s rules; whilst for those beyond the market space, the relationship is determined only by indirect influence.

Action: relations and Market Model tags are added to the ‘other-player’ entities according to where we place them within the Market Model.

We now return to the Business Model Canvas, to build and refine our to-be business-model, leveraging the enhanced clarity we’ve gained and documented about our relationships across the broader shared-enterprise.

—-

And so on, and so on: we continue bouncing between different model-types as required, until we consider that the original business-question with which we started the project has been answered. For example, we might switch into Enterprise Canvas, to explore more about the pre-transaction, transaction and post-transaction flows, or the management and coordination issues. We might expand on specific aspects of ‘Key Activities’ and ‘Key Resources’ in Business Model Canvas via an Archimate model, or explore a specific business-process via a BPMN model. It’s up to us, dependent on what we need to do: the only real restriction would be in terms of which model-types are loaded into the toolset.

At each stage, entities are created, modified, reviewed, linked, occasionally deleted. Tags are added to store attribute-values, to anchor relations and links, and to keep track of this edit-history and accumulated information; and because of the ‘safe-ignore’ rule for all models, nothing is lost, as we switch from one model-type to another.

Every entity and relation is unique; yet ultimately they also all have the same structure – which means there’s only one file-format, to enable model re-use and model exchange between toolsets.

And for every entity, for every relation, every tag, every model, we can ask the same core questions:

Tell me about yourself?

Tell me what you’re associated with, and why?

So what we have here is something that can support almost any level of complexity; yet it’s still easy to drive, easy to use, to any level of constraint (or lack of it) that we might need; and also, at root, structurally very simple.

I hope that explains it all a bit better than before? Comments/suggestions anyway, if you would.

(By the way, a quick thank-you to Nic Plum and Sally Bean for really helpful peer-reviews on this. )

The legal bit: There’s a heck of a lot of unpaid work that’s gone into this, and also a lot of my own ‘prior art’ on these themes, dating back to at least September 2008, with more detailed specification dating from at least mid-2009. Although it’d be nice if someone actually paid me for some of the work that’s gone into this it really needs to be something that’s shared in the most open way possible, such as via open-source, so consider this for now to be published under a Creative Commons Attribution-NonCommercialShareAlike (CC BY-NC-SA) license. I don’t really want to see any restrictions on it at all, but unfortunately we do need some kind of protection here: it’s definitely not okay for some commercial organisation to lift it, put a couple of minor tweaks on it, pretend that the whole thing is and always has been their own private ‘intellectual property’, and then demand money from everyone else for the privilege – because we’ve seen way too much of that already, thankyouverymuch. Sigh…

What follows is deliberately broad and abstract. It’s missing quite a few implementation-details, in part because I’ve probably missed a few key items, but even more because some is still a bit hazy and needs proper review by folks who really know what they’re doing with implementable metamodels. As all too usual, it’s also long: my apologies… Oh well!

Core concepts

Right at the root of the metamodel is a single object, with just two attributes:

• globally-unique identifier
• ‘instantiable’ boolean (if true, is ‘type’; if false, is ‘instance’)

We also create a special-purpose variant of this:

• collection – a container for objects

And, from that, another special-purpose variant:

• tag – an object that contains a collection of attributes

From this, we create our three core specialisations:

• entity – a ‘thing’, which may also contain collections or tags
• relation – an entity that may link between two tags
• model – an entity that incorporates a collection of allowable relation-types and (references to) entity/relation instances, together with any required validation-rules

Fundamentally, everything is based on the same root entity-type. This commonality enables us to have a single standard repository-structure and exchange-format that can be used for every possible notation, re-used across all model-types and toolsets.

Collections

A collection is just a container. It can contain any types of objects, including tags and other collections. A collection is always embedded within another object, which provides its identity and supports any additional attributes (via tags) that it may need.

Example: every object (certainly every entity) will need a RACI collection to identify object-owners and people or roles responsible for or affected by the real-world item represented by the model-object type or instance.

Tags

A tag is a container for attributes. At the simplest level, an attribute is a name/value pair, but it might be better to implement it with somewhat more content, to include a distinct non-editable unique-identifier, an editable name, a value-type (simple, MIME-type or other), validation-rules and the attribute-content itself.

A tag is also optionally a target for relations (links between objects). Every object will need to be able to support at least a default ‘isAssociatedWith’ link to arbitrary other objects; the target-point for this would be a default tag embedded in every object.

More explanation later of how the tag-system would work in practice, and how it could be implemented.

Versioning and ‘inheritance’

Every object would need to support in-depth versioning. As I see it, the simplest way to envision this is that every object is in effect its own wiki-page. The surface view of the object represents the current state of all the attributes and suchlike of that object, but it accretes a history of changes over time, and the entire history is always still available if required.

A ‘snapshot’ of ‘current state’ or suchlike consists simply of attaching a tag to one or more objects that signals the option to revert (usually temporarily) to the state that applied at that time.

Since there is only one root-object, with everything else defined by add-on tags, ‘multiple-inheritance’ consists simply of importing into a single ‘child’-object the tags that represent the state (attributes, relation-anchors etc) of the respective ‘parent’-objects. This may be done selectively, to enable partial-multiple-inheritance. De-inheritance can be done in much the same way, by removing or disabling selected tags within a child-object.

(One point not yet resolved is whether a ‘child’ incorporates an entire copy of its ‘parent’(s), or whether it simply points to them and builds its own versioning thereafter. In terms of data-storage, the latter is probably preferable, but does imply certain risks. However, it’s not critical at this preliminary design-stage, and decisions on this can probably be left until initial implementation.)

Entity

An entity is an object that incorporates (‘contains’) tags that define and maintain its attributes.

Attributes supported by an entity (i.e. via tags) may include any number of media-items of any appropriate type, including audio, video, images, URLs etc.

An entity will support one or more presentation-types. The default presentation-type is a summary of content in text-form (i.e. ‘wiki-page’), plus, for graphic display, a simple rectangle enclosing the entity-name. Other presentation-types may include images or bit-maps, SVG or other scalable/vector images (perhaps via a Visio-style layered-spreadsheet or equivalent). A model-type may specify a default presentation-type via an appropriate tag associated with the model-type (i.e. the presence of the tag on entities would suggest or enforce a specific presentation for that entity), such that the same entity would appear in different visual forms on BPMN or UML diagrams or concept-maps.

Relation

A relation is a specific type of entity that can connect to tags on other entities.

At present, I assume that relations can connect only between two entities (or, where the relation itself has embedded link-tags, between entities and/or other relations). A ‘one-to-many’ relation is actually a set of nominally-identical relations, but may be displayed in ‘branched’ form (as often used in concept-maps, for example) if the respective model-type supports that display-format.

Because relations connect to tags rather than to specific entity-types, the number of relation-types expands almost linearly with the complexity of the underlying metamodel, rather than exponentially or near-factorially as in conventional relation-to-entity metamodels. In general, sub-types ‘inherit’ the tag-set from their parent entity-type(s), hence no new relation-types need be created for each new sub-type.

Relation-types are typically associated with a notation, which in turn is typically associated with one or more specific model-types.

As for entities, each relation will support one or more presentation-types. The most common default graphic presentation-type for relations is a one-dimensional line, with optional arrowheads. Line-routing, collision-avoidance and the like are an aspect of user-interface and graphic display rather than a function of the relation itself: the only explicit function of the relation is to indicate that two entities are related in some way.

For some purposes, and in some user-interface contexts, creating a relation that is not anchored at one end will cause a matching null-entity to be created, according to the tag(s) associated with that relation and the applicable rules of the model-type currently in use. (See the Archi ‘Magic Connector‘ for an example of this type of user-interface functionality.)

One important optional tag for relations (e.g. ‘isFlow’) indicates that the relation also represents a ‘flow’ – a transaction or other exchange between entities. This is typically used to model simulations. The directionality, content and other aspects of the flow would be indicated by other tags, as mediated by the respective model-type within which the simulation is executed.

Model-type and model

A model (graphic, text, simulation etc) is an instance of a model-type.

A model-type is an entity that maintains a collection of tags and relation-types that define the allowable content. Note that, via this mechanism, a model-type does not need to specify the allowable entity-types – hence enabling extension of metamodels without requiring alterations to the list of relations or to the model-type.

A model-instance maintains a collection of references to entity- and relation-instances, together with any context-specific information required for graphic displays. (In some cases a model-type might also include templates for default entity- and/or relation-instances, such as for page-headers and other displayable model-identifiers.)

By default, any instances created within the model-type would be assigned all of the respective tags for that model-type or notation (i.e. initially constrained to that notation and usage). For example, a BPMN model-type would create only entities that are tag-compatible with the BPMN standard, and that can be displayed in accordance with the BPMN notation. However, since ultimately these are all still just entities with tags, and further tags can be added if required, potentially any of these entities may be re-used in any way in any other compatible notation. For example, we could re-use a BPMN Event in an Archimate model, representing the same Event in a different way for different modelling-purposes; a BPMN Swimlane entity might be re-used in Archimate as a Device, an Application or an Actor, with all of its BPMN relations carried through transparently to the Archimate model.

Full validation of models and entity-relationships is a function of the model-type, not the metamodel. This makes it possible to relax formal rigour during development or for certain types of simulation.

Crucially, a toolset and model-type must preserve any entity-tags and/or relations that it does not use or display. This is required to enable ’round-tripping’ between model-types and toolsets. Any toolset that does not support this will be able to import existing entities and relations, or export new entities and relations, but will not be able to ’round-trip’ amended entities and relations.

Model-types and models are often described in terms of views or viewpoints. For this purpose, a viewpoint or view is simply another standard entity, which is then associated with the model-type.

Models would typically display their results, in whatever form required, by ‘calling’ the appropriate presentation-type for each entity and relation in its scope (i.e. referenced within its instance-collection).

Non-semantic entities

Many types of models require or would support a variety of ‘non-semantic’ entities – in other words entities which do not in themselves add to the semantics of a model. Typical examples include:

• annotation – an arbitrary explanatory note attached to an object or relation
• group – a ‘box’ or other container to cluster a group of entities together for ease of reading
• model-caption

An annotation would typically be implemented as an instance of a fairly low-level entity (i.e. one with few tags), optionally associated only with the model or model-view, but more usually with a connected relation that may be linked to any other entity or relation. (In other words, similar to an ‘annotation’ entity in Visio or Powerpoint.)

A group may be displayed just as a box, but in fact it has an implicit relation with all of the ‘contained’ entities. (See the Archi ‘Automatic Relationship Management System‘ for an example of how this would work in practice.)

A model-caption is a container for information about a model or model-view (such as used in several of the Visio templates, and in most types of controlled-diagrams). In effect, this is an entity that is attached to the model-instance, rather than actual content for the model, but would be displayed in the normal way.

Glossary and thesaurus

The total collection of entities and relations within the repository forms the content ‘holograph’ for the respective scope.

A glossary and thesaurus represent different views into that ‘holograph’, in part to answer the questions ‘Tell me about yourself?’ (glossary) and ‘Tell me what you’re associated with?’ (thesaurus).

The glossary for the context, or for any selected subset of the context, consists of a live report derived from the ‘definition’ tags of all entities in scope.

The thesaurus consists of a report, usually starting from a single entity, of all thesaurus-type relations from that entity. These would typically include standard relations such as synonym, antonym, broader-term, narrower-term, conflicts-with and so on. (In some cases these relations between entities may be automatically generated.)

Frameworks and notations

Taxonomy frameworks such as Zachman, or the layered structures used in TOGAF or Archimate, can be represented very simply via sets of tags, and (in the case of supposed ‘layers’) explicit rules around relations that connect to those tags.

Notations consist of sets of tags that define (or extend) specific entity-types, and matching sets of representation-types.

Governance and change-management

Governance regimes such as used in the TOGAF ADM, PRINCE2, PMP and the like, and models such as Gantt-charts, can be represented by sets of entities, collections, and relations between them and other entities and/or relations within the scope covered by a particular change-project, change-programme or whatever. In short, everything is just an entity, or a relation between entities.

A governance method would in effect be the usage of a specific model-type which uses a governance-set, using the validation-rules defined within that model-type.

As described above, every entity, relation and model should have an associated RACI (responsibility-assignment) collection.

Governance-artefacts such as reference-models may be created by ‘freezing’ an existing model as a new model-type, and then enabling relations from there to other entities that represent the implementation of the respective items described in the reference-model. A waiver or dispensation (i.e. an accepted and documented breach of the validation-rules for the reference-model) in effect consists of a descriptive entity that is linked to the non-compliant item and to the respective section of the reference-model.

Toolset-ecosystem

The full toolset-ecosystem for enterprise modelling and sense-making covers a huge range, including:

• enterprise-wide repository, supporting specialist edit/moderation tools and simpler client-server interfaces (e.g. static or annotatable web-pages)
• team-based tools – essentially a smaller-scale version of the enterprise-tools, with a repository shared across the team
• single-user repository-based tools
• non-repository tools (such as Visio or Powerpoint)
• tablet-style systems with gesture-based interface, often thin-client only or with limited local repository
• handheld tools (smartphone etc) primarily used as thin-client
• pencil and paper

Given this scope and range, it is extremely unlikely that there would ever be ‘One Toolset To Rule Them All’. However, this metamodel can link between them all, by providing a means to share information and models between them. Each toolset-type could also use any of the model-types, frameworks and notations supported by the metamodel, and link between all of those as well. In that sense, not ‘One Toolset To Rule Them All’, but possibly ‘One Standard Data-Structure To Link Them All’.

Conceptually, the metamodel described here is best suited to the enterprise-wide repository. Merge and data-cleansing would be important moderator/curator activities at this level.

For team-based tools and single-user repository-based tools, these would support the metamodel directly. They would need to be able to import and export individual models and/or selected sections of the entire repository. Again, merge and data-cleansing are important activities, though this is likely to be the scope within which most actual specialist modelling takes place.

For non-repository tools, distinct import and export functions will be required. These tools do not actually have any real concept of ‘entity-type’: everything is an uncontrolled instance, in essence without any layering or depth. Import into these tools is relatively straightforward, simply by ‘flattening’ the internal structure of existing instances and selecting an appropriate representation for the respective notation; but real care will be needed when importing into a repository-based system an exported model from a non-repository tool, because much of the underlying structure may have been lost, and connection to a parent entity-type will be questionable at best.

Tablet-style tools may or may not be repository-based – the main distinction here is the interface-metaphor (gestural rather than text/visuals or keyboard/mouse) rather than the underlying metamodel. If repository-based, or thin-client only where the repository is maintained only on the source server, the usage is much the same as for a team-based or single-user tool. If essentially a non-repository-tool (equivalent to Visio or Powerpoint), then the respective constraints apply. If solely graphic (i.e. a ‘draw’ application), the image-file should be handled much as for pencil and paper.

Most handheld tools would be used as thin-client, with primarily for local consumption and with little to no original information-capture. The thin-client relationship would, however, enable update of uncontrolled sections of information – such as the free-form ‘wiki-page’ section for each entity or relation.

Pencil and paper will still remain one of the most common tools for idea-capture and initial development. Some applications already exist to scan paper-based drawings and create the respective entities and relations; these will always need subsequent moderation and data-check, but it is feasible. The layered tag-based structure for this metamodel should make that process easier than for some other existing metamodels and notations, particularly as it allows information-capture in ‘non-standard’ forms.

Implementing the metamodel

Implementation could be relatively straightforward, because at a fundamental level there is only one entity-type, and only one relation-type – everything else is created via the ‘tag’ concept, which itself should be reasonably simple to implement. The only fundamental difference between entities and relations is that relations can link to things, whilst entities cannot (in their own right, anyway). The ‘wiki-page’ concept is also fairly straightforward.

This could be implemented via a conventional relational-database, although an object-database would probably be a better choice in practice. I’ve implemented something fairly similar to this in PHP, with a MySQL back-end: it’s used as the base for several of my existing websites, such as tomgraves.org, tetradian.com, sempermetrics.com and the OS-EA Tools site. (It’s versatile, as you’ll see; but yes, as you’ll also see, it’s, uh, clunky – which is why I’m definitely not the person to be writing the code for this… )

As I see it at present, the common file-format can be a straightforward XML or JSON text-file. The core, and each notation or framework or the like (each, in effect, little more than a set of tag-definitions) would be specified as the equivalent of an XML DTD (data-type description), with a defined namespace, conceptually similar to namespaces in XML or Java.

Each notation and associated model-type is therefore a ‘plug-in’, conceptually similar to plug-ins in Eclipse and the like, except that in principle it could be possible (and in practice may indeed be possible) to implement these ‘plug-ins’ via a simple configuration-file, without requiring any embedded plug-in-specific code.

There’s a tricky area around how to specify representation-types for model-types, and how to define validation-rules within model-types, but I don’t see that it’d be a ‘deal-breaker’. It just needs someone who’s more experienced than I am about designing a configuration-language.

The other key point, though, is that because everything is in effect defined via an equivalent of a DTD, this means that any toolset that can interpret that configuration-file would also be able to implement and use any model-type or notation that can be defined via that form of DTD – and as far as I can see at present, that includes just about every notation or framework that I know of in general use in current enterprise-architecture, strategy, sense-making and the like. In other words, not quite ‘One Toolset To Rule Them All’, but in practice not far off it.

Summary

The metamodel described here can, in principle, cover just about all enterprise-architecture needs, and many other related needs, with one very simple structure.

The core of the structure is a single entity-type; a single relation-type; a very simple ‘collections’ structure that can be used within any of these; a concept of ‘tags’ that carry attributes and/or presentation-types, and to which relations may be linked; and a structure for model-types that inverts the usual structure by focussing on relation-types rather than entity-types.

Because the structures are so simple, it should be straightforward to implement in practice, for different toolsets using a range of different user-interface metaphors, across the whole of the toolset-ecosystem.

Okay, that’s it: over to you? Any comments/advice/suggestions, anyone?

(And many thanks for reading this far, of course! )