7 years, 7 months ago

EA metamodel and method

Link: http://weblog.tetradian.com/2011/09/03/ea-metamodel-and-method/

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.

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.