Tom Graves / Tetradian

A bit more detail on what I see coming up in my ‘no-plan Plan‘, starting with the theme about ‘the ‘why’ of architecture’.

One thing I’ve always found worrying in most current ‘enterprise’-architecture is that there’s been almost no attention given to the ‘why’. It’s seemed that ‘why’ was just a given: ‘orders from above’, to be followed without question, “ours not to reason why” and so on. Like as if it didn’t matter. To give just two examples, both TOGAF and Archimate still regard modelling of motivation – the reasons why we do something, or anything at all – as an optional add-on or ‘extension’ to the architecture. (I’m not joking: go check ‘em out – and the Archimate ‘extension’ won’t even be officially released until version 2.0!) Pardon me if I say that that’s just plain daft…?

Okay, step back a bit. Point to something in current EA that does work, namely the layering of abstraction in Zachman:

(Note that the original only has five rows, 1-5, which relate to the types of views for different stakeholders responsible for making something happen. Structurally, though, these views also represent layers of abstraction, to which I’ve added a row-0 to indicate indefinite-future, and a row-6 as unchangeable-past. It seems there’s also likely to be a need for a ‘row-00′, to represent the broader context within which all enterprises exist, but I’ll expand on that point some other time.)

Whenever we look ‘upward’ to a lower-number row, we’re asking ‘Why?’; and whenever we look ‘downward’, towards the future/past boundary of the ‘Now’ that sits between row-5 and row-6, we’re implicitly asking ‘How?’ and ‘With-What?’. Row-0 represents a fully-abstract and unattainable idealised-future (the ‘Vision’ and suchlike, that drive the overall enterprise); every move ‘downward’ is a step closer towards making that vision become more tangible in the real world, until at row-6 it’s already been made as tangible as it’s ever going to be.

So what? What’s the point?

Short answer is that if we don’t know why we’re doing something, it’s easy to make inappropriate choices, or ineffective choices. Or fail to realise even that we do have choices. Which, in a period of accelerating change, might literally be a life-critical concern…

I’m one of those people cursed with a mind that balks against taking anything for granted, wants to see the logic (or reasoning, rather) behind every decision, every option. Which, in a world that seemingly lives on unquestioned assumptions, can be, uh, a bit problematic:

– “Ya gotta climb the corporate ladder!”, they told me.

– Uh, why?

– “Because everyone’s gotta climb the corporate ladder! – gotta be better’n everyone else!”

– Uh… how can everyone be better than everyone else? And what do you mean by ‘better’? – ‘better’ in what sense? And why is the ladder leaning against this wall and not that one? And what’s on the other side of the wall, anyway? What’s the purpose here? What’s the point? Why?

Silence, then:

– “Look, just shut up and go away, willya, kid? … Next! Hey, you, you other kid over there, ya see this, it’s the corporate ladder! Ya gotta climb this! Ya just gotta! – but-please-don’t-ask-me-why-cos-I-don’t-know-either…”

I never did get to climb that corporate ladder; never even been a ‘permanent’ employee, for that matter, so I never had much chance to do so anyway. But still kinda doubting that I would have wanted to do so even if I could – other than perhaps to see what was on the other side, much like that other well-known matter with a chicken and a road. Hmm…

But why that need for why?

If we don’t ask why, we don’t get to move up those layers of abstraction. And if we don’t move up those layers of abstraction, we don’t get to see new options and new choices. To make things happen, it’s true that we need everything to be complete, locked together, fully tested, fully working. But as I put it some while back, a ‘something’ is usable to the extent that it’s architecturally-complete; but it’s re-usable to the extent that it’s architecturally-incomplete. And when things change around us, we usually can’t keep going indefinitely just with ‘the way things are’: something has to change, in order to cope with the changes and still keep things sort-of-the same.

And even if things do stay much the same, we can’t know how to make something more effective unless we know its actual purpose – both in itself, and in the broader scheme of things.

To see that practical purpose, and to spy out other options, we need to able to get a broader view of things.

Which means we’ll have to go up a bit, to get that broader ‘big-picture’ view.

Which means we must be able to climb that other ladder – the ladder of abstraction, the ladder of ‘why’.

Which designers and enterprise-architects and so on do indeed do, all of the time, of course. But only sort-of. In most cases they sort-of climb about half-way up, and then come to a sudden stop, seemingly declaring that there isn’t any more ladder to climb, and yes, kid, if you happen to notice that the ladder does indeed keep on going ever upward, just shut up about it, willya? Okay, yes, fine, understood, boundaries of authority in a feudal-style cultures and all that – except, uh, I can’t help but see that that ladder of ‘why’ does keep on goin’ up, and I really really really want to know what’s up there… That kind of feeling… Really frustrating…

Which is why, sorry, but I just can’t stop asking ‘why’.

Which can, uh, cause a few problems. Especially for me. Oh well.

To put it in more visual terms, ‘classic’ ‘enterprise’-architecture sits mainly in the row-3 / row-4 range of abstraction – the interplay of ‘logical-to-physical’ – with occasional forays up into the row-2 world of big-picture business-strategy:

What I’m mostly working with, though, tends to be a fair bit further up the ladder:

Yet it is still enterprise-architecture, because it’s still the same ladder of ‘why’. But with a lot more focus on more abstract-seeming questions about the nature of the enterprise, or even the nature of enterprise itself.

Unlike the feudal mess, ‘higher’ doesn’t equate with ‘better’ here: it’s just a different kind of view, on the same continuum. In the overall scheme of things, it’s ‘just another service‘, nothing special as such. But still useful, of course, if used in the right way. Which is what I want to do: be useful, in the right way.

That more abstract view might sound, well, more abstract, y’know? Impractical an’ all that? Yet actually it’s very practical indeed: and if we turn our perspective of the ladder the other way round, with the lowest-number rows at the bottom, what that ‘abstract’ view actually describes is the bedrock on which everything else in the enterprise will stand. For example, all that ‘abstract’ stuff on vision and values:

• if you don’t know those vision and values, how else are you going to build any meaningful conversation with your prospective customers?
• if you don’t know the underlying values, how will you know what ‘quality’ means, or how to identify whether it is or isn’t there?
• if you don’t know what the shared-vision is (and every organisation will always have one, whether they know it or not), and you don’t how know you actually share it with the broader enterprise (which you do, whether you know it or not), how will you know what to do when your ‘anti-clients’ (and yes, you’ll always have those, too) start asserting that you’ve betrayed that vision, and set to work to tear you down?

Seems a bit abstract at first, yes, maybe so. But trivial, or irrelevant? – definitely not. Not if you want to be able to ride the upcoming tsunamis of change, anyway.

(And yes, that is ‘tsunamis‘. Plural. Many of them. Lots. Perhaps a fair bit more than just a metaphor, too. Coming to a business-context near you, some day real soon now. If not today, in fact… And yeah, don’t expect to survive that little lot without some serious preparation before they hit… Your choice, of course? )

Sounds good? Wish it were so… because there is, of course, a catch – for me, anyway. A little practical problem called income. Or, more precisely, the lack thereof… in fact, in the not-income stakes, it’s pretty close to a perfect storm. For a start, monetisation happens mainly at the moment of ‘now’ – the row-5/row-6 boundary. In other words, the exact opposite end of the ‘why’-ladder to that where I usually work. Oops…

And just to make this part of my economic-life even more fun, although there’s a huge need for this aspect of the kind of work that I do – as can be evidenced by about five-minutes’ worth of looking-around at just about any large organisation – there’s an even more huge ‘anti-want‘ for it. Most of what I show people may be extremely important to them, but at first it’ll often seem embarrassing, challenging, or even downright scary. Oops again…

In short, it’s difficult to explain the immediate value of much of what I do, and most people really don’t want to know anyway, no matter how important it may be to their livelihoods and suchlike. Sigh… Oh well. But this is a fundamental part of everything that I do, so just need some other way to make some kind of income, that’s all. No big deal, really.

That’s about it, I guess.

Oh yes, one other point, about tools and toolsets.

Most of the existing ‘enterprise’-architecture toolsets are… well, let’s be polite and say ‘somewhat challenged’? …when it comes to working across the whole of the real EA continuum, and perhaps especially in terms of creating linkages up into row-2 and above. Most toolsets – and, even more, most notations – are all but unusably constrained for that kind of purpose: most of them sit either in row-3 or row-4, often without being able even to link across that architecturally-essential boundary. Yes, of course there are workarounds and kludges: but that really is all that they are, and just about everyone in ‘the trade’ knows that, too. We need a better solution than this.

So here’s the challenge: to handle the whole of the ‘Why’ question – and, going the other way, the ‘How’ and ‘With-What’ and so on – we must be able to build complete derivation/realisation chains for anything, from row-6 (records of past action) or row-5 (CMDB and the like) all the way back up to row-0 (vision and values) and row-00 (context of all enterprises). Yeah, it’s huge – no question about that. It’s probable there’s no way any single notation would be able to do it, and still make sense. But I do believe that we should be able to define a single metamodel that covers that space and can bridge across any type of notation, and from previous experiments here it really does not look all that hard to do. So I reckon that the the first toolset-vendor that cracks that challenge, and the attendant usability challenge that goes with, stands to open up an absolutely huge new market for sensemaking / decisionmaking tools, and would have much of that market to themselves for quite a while, too. So if you want to know more about that? – and how we can talk business about that? – well, you know where to find me, don’t you?

Okay. Seems there are indeed times when I have to accept that, yes, it is 3am, and I have indeed been woken up by an idea that isn’t going to let me sleep until I’ve written it down. Oh well. So best just get on with it, I guess.

In a comment to my earlier post ‘Making plans, sort-of‘, Robert Phipps asked:

even though you do not have a plan, [...], you probably have a few themes [...] that will feature regularly, and although we can probably infer some from the tone of recent posts and discussions, perhaps you could offer a kind of ‘version 0.1 cut’ of your new programme. Is it still recognisably EA ?

To answer the last part first:

• Yes, it’s all enterprise-architecture

Whether it’s ‘recognisably EA’ is probably another question entirely… – depends on who’s doing the ‘recognising’, I guess? Main point is that it does seem to be about a much larger scope and scale than most current ‘enterprise’-architectures: a ‘really-big-picture enterprise-architecture’, if you like.

But yes, there do also seem to be some distinct themes in there. I’ll summarise them here, and then expand on them in separate posts, so that this one doesn’t get too long (and also so I might be able to get back to sleep, too…).

Quickest overall summary, to paraphrase an old Heineken advert, is that “it’s about the parts that other enterprise-architectures cannot reach”. (Probably it’d be more accurate to say that it’s more “the parts that other ‘enterprise’-architectures don’t reach”, and I don’t know why they don’t reach them, but there ’tis.)

• It’s about the ‘why’ of architecture

Almost all of the current architectures seem to focus on structure, on the ‘How’ and ‘With-What’. In Zachman terms, they also seem to focus almost exclusively on row-3 (‘Logical Model’) and row-4 (‘Physical Model’) with occasional forays up to row-2 (‘Business Model’), but that’s about it. What I want to know about is what happens in the ‘why’ above that, the reasons behind the architecture in the first place – all the stuff that goes on in row-2, row-1, the row-0 that I had to add to understand the idea of ‘the enterprise’, and the row-00 that I seem to be adding now for the ‘really-big-picture’ of where ‘the enterprise’ comes from in the first place. There’s also a strong cross-link there with an emphasis on effectiveness – rather than solely on ‘efficiency’, as in too much of current architecture-work.

• It’s about architecture-as-story

A theme that’s come up a lot for me over the past few years is on ‘the enterprise as story‘. It’s picked up even more momentum since finding building-architect Matthew Frederick’s ‘two points of view‘ about architecture, one of which was the regular view of architecture as ‘an exercise in structure’, but the other of architecture as ‘an exercise in narrative’. Story also seems to be linked both to the exploration of the ‘why’ of the architecture, and the active, living, expression of that ‘why’. Beyond that, I just know that it feels important, so keep following that thread and see where it leads.

• It’s about the architecture-as-change

In part this is what I’ve called the ‘business-anarchist‘ theme, but again it’s very tightly linked to that question of ‘why’ in an enterprise-architecture. It’s also strongly associated with the theme that way too many people still seem to avoid, namely the sense-making / decision-making space that in the SCCC-categorisation is described as the Chaotic-domain. I suspect that there’s a huge breakthrough in there somewhere, on the scale that Taylorism was back at the start of the last century, and which we’re sort of skirting around with ‘design-thinking’ and the like. Dunno quite what it is, but I can sense the general shape of it in there somewhere, and also that it’s definitely important.

• It’s about the dynamics of architecture

This one will still take quite a bit of further exploration and explanation, but it seems to be about how we move between those different sense-making / decision-making domains. It’s also about designing for change – which is going to be kinda important as we head into what’s clearly going to be a period of massive change – and also about breaking free of the dead weight of some frankly daft ideas such as ‘future state’ of an architecture.

• It’s about people in relation to architecture

This is another screamingly-obvious gap in most current ‘enterprise’-architectures: people barely come into the picture at all. Since one of the core definitions of ‘enterprise’ is that it’s all about people and people’s choices and people’s needs – “the animal spirits of the entrepreneur” – it does seem like it’s kind of an important omission, wouldn’t you think? I’ll freely admit I’m not much of a ‘people-person’, but someone has to address this point in enterprise-architectures, and since this obviously links up very strongly with all of the other themes, it may as well be me…

Enough to answer that ‘no-plan Plan’ question for now, I hope? – more detail to follow on each of these themes, anyway.

So can I go back to sleep, please?

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…

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…

Time to get back to the themes from the post ‘More on that enterprise-architecture ‘help wanted’‘, with a focus on toolsets and metamodels.

The usual approach to toolsets – just about any kind of toolset, as far as I can tell – is to describe the overall context, knock up a metamodel, and then build a toolset that works with that metamodel.

That’s fine as long as we don’t need to use the content for anything else, in any other way, or (in all too many cases) in any other toolset. If we do need to do anything like that – and frankly, most of us do – well, then, we have a problem…

What we actually need is a toolset that can do any kind of modelling and simulation that we could possibly want. Given the nature of Reality Department, we’re not likely to get it… Oh well. But if we can’t have that One Toolset To Rule Them All, then perhaps a good second-best is a metamodel (or metametamodel, or whatever layer we need to go to) that underpins a file-format that can move anything that we need to share across all the disparate toolsets. And that, I believe, is doable. Hence this series of posts.

Let’s start right at the roots.

(And please watch for anything that I’ve missed, or that I seem to have got wrong – because that’s the way we’ll get this to work right, for everyone.)

Let’s start with the idea of a ‘thing’. This ‘thing’ could be or represent anything at all: an object, a piece of information, a perceived connection, an idea, a question, whatever. It’s just, well, something. Anything.

Given a collection of ‘things’, we then might want to describe perceived relationships between various of those ‘things’.

And we then might want to model those ‘things’ and relationships between ‘things’ in a structured or semi-structured way, to aid in sense-making and decision-making. (We then might also want to describe explicit viewpoints and views that determine the scope and role of models, as per IEEE1471 / ISO42010.)

This gives us the core of what we need to support here: entities (‘things’), relations, and model-types.

(I think that part is straightforward, but if not, please say so?)

Way back when, whilst we were designing an information-system for an aircraft tear-down, my colleague Graeme Burnett said that for anything of interest, anything in scope, we need to be able to ask of each ‘thing’:

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

Which in a sense leads us to the usual metamodel set, but with a few extra twists:

• entities and their attributes
• relationships and their attributes
• lifecycles and other types of change of entities
• flows and other types of change between entities
• questions about entities, relationships, attributes, flows, lifecycles and other changes

(What else needs to be added to this list? What have I missed so far?)

We need these items to be able to be portrayed in any representation (in both the visual sense and technical sense), including plain-text. This means that any representation needs to be separate from any entity or relationship or other item, yet needs to be associatable with it. In other words, we can’t link a metamodel rigidly with a notation, or vice versa, as with UML or BPMN or Archimate, for example – we must be able to re-use the same entities and relations and so on in multiple notations.

Some examples of how we might want to re-use the same entities might include:

• enterprise-architecture notation such as Archimate in Archi, or other notations such as UML, BPMN and so on
• enterprise-architecture metamodels such as in Troux Semantics
• systems models such as in Southbeach
• narrative questions such as in Southbeach MyCreativity
• context-maps such as in CMapTools
• social-networks for shared-concepts such as in Cohere
• personal sensemaking such as in Compendium
• support ‘barely repeatable processes’ such as in Thingamy
• partial-duplication for what-if experiments and for as-is versus to-be comparisons
• modelling of flows between entities

(Any other items that we ought to add to this list?)

As indicated in that list, we need to be able to support a wide variety of views and model-types. But the key point here is that there’s actually only one type of entity – or rather, every different entity is based on and resolves to the same core entity-type. The same applies to relationships: although there are many different apparent types, ultimately they all resolve back to the same core relationship-entity. That’s what would enable their portability between views, notations, model-types and applications.

This also implies that there’s no fundamental distinction between a ‘type’ and an ‘instance’. The only difference is that a type is instantiable, and an instance isn’t: we convert an instance to a type by making it instantiable, and we create an instance by making a non-instantiable copy of a type.

(Is there any part of the above that seems unworkable or doesn’t make sense?)

We need to be able to support several different levels of model-validation:

• free-form (no validation), as in Visio
• partial or variable validation, as in Archimate (or most forms of architecture-development)
• strict formal validation, as in BPMN to BPEL conversion

(Free-form and strict are relatively easy to implement; partial or variable validation can be a lot harder! Partial or variable-validation also means that we need to support null-entities or placeholders to indicate ‘dangling’ relations or items that have yet to be defined.)

We need to support to keep the information clean, including:

• explicit identifiers (distinct from editable names)
• standardised explicit change/lifecycle, as per CRUD or REST
• versioning
• deduplication, merge and split
• change of base-type for entity or entity-instance
• resolve of dangling links (i.e. links where the ‘far-end’ entity has been deleted)
• entity owner(s) – or preferably a complete RACI set for each entity

(What have I missed here?)

If I’ve got this right – and I’ll admit it’s a big ‘if’ – then conceptually we need only one core entity-type, and one core-relation-type, to cover all potential uses.

If so, then that would open an enormous range of possibilities for enterprise-architecture and for many other disciplines as well.

There are a number of tweaks and tricks to make this work in practice – particularly the concept of ‘tags’, which I’ll explain in the next post, and likewise a fundamental reorientation of the relationship between entity-types, relation-types and model-types – but in essence that seems to be enough to get started.

Comments, anyone, please?

What do I do, and how do I do it? What’s the nature of my work, and the methods that I use? And for that matter, why?

That’s perhaps the shortest summary to a request by Anthony Draffin, in a comment to my previous post ‘Not quite bus-pass day‘:

On a selfish note… It’s apparent that the common thread to dowsing, printing and enterprise architecture is your ability to look at a field holistically and apply logical thought to extract inconsistencies and errors, as well as looking at new ways of doing something more efficiently to meet the original aims. That’s a rare skill. Have you given thought to documenting how you go about doing this? While I imagine it’s the application of a number of taught skills, the way you put these together must be far from ubiquitous. Have you considered teaching this? Personally, as a 27 year old, I want to soak up as much of your approach and thought process as you’re willing to offer.

(Warning, this is going to be another (very) long one, mainly because there’ll be several case-studies.)

Read more…