Tom Graves / Tetradian

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Many thanks, anyway.

This one’s back on the metamodel theme again, and is a follow-up to a query by Peter Bakker in his post ‘Thinking about Graeme Burnett’s questions‘, in reply to my previous post ‘EA metamodel: two questions‘.

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?

Following on from the previous work on EA metamodels, I keep coming back to those two questions from Graeme Burnett: for everything in a context, we need to be able to ask “tell me about yourself?” and “tell me what you’re associated with?”.

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?

Read more…

Following on from the previous post on ‘Simplifying the Enterprise Canvas‘, a few more notes on how to use the notation, and some practical matters on modelling.

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!

Read more…

The Enterprise Canvas is a model-type for use in enterprise-architecture, that can be used to describe any aspect of the enterprise, providing a consistent, unified view all the way from strategy to execution. But can we simplify it so as to build support for it in existing EA toolsets?

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

Read more…

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?

In the various previous posts about EA metamodels, we’ve been exploring some of the detailed structures for toolsets and the like at a very, very low-level. But what’s the big-picture here? What’s the point?

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…

Read more…

What would this ‘generic modelling metamodel’ look like? And how could we implement it?

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?

Read more…

How would this EA metamodel actually work? And why would we need it, given that we have more than enough frameworks and models already?

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.

Read more…

Moving on to more detail on that EA metamodel.

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

Read more…