What’s the point of this ‘EA metamodel’?

I’ve been writing a lot recently about metamodels for enterprise-architecture and the like: but what’s the point? Why bother? Why all this fuss about something that’s way too technical to be of interest to almost anyone in the real workaday world?

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?