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.
Interesting stuff here. My view on EA & metamodels is something like this:
First of all, my definition of Enterprise Architecture as architecture of an enterprise is (Dragon1): Enterprise Architecture the coherent set of applied (constructive, operative and decorative) concepts onto an enterprise. (Architecture is the coherent set of applied concepts onto a structure). Enterprise Architecture as the field of EA is: Enterprise Architecture is the art and science of designing, realizing, innovating and transforming enterprises. (Architecture is the art and science of designing and realizing structures).
In an EA meta meta model I would find for example the entities :”Concept”, “Concept Reference”, “Concept Application” and “Structure”.
In my EA meta-model I would find for example entity-instances like: Enterprise, Enterprise Concepts, Governance Concepts, Business Concepts, Work Concepts, Information Concepts, Application Concepts and Technology Concepts.
In my EA model for the enterprise Google I then would find concepts like “Service Orientation – Google Style”, “One Stop Shopping – Google Style”, “Process Integration – Google Style”, “Self Service – Google Style”, “Server Virtualization – Google Style”, “High Performance Workplace – Google Style”
I think it is important to distinct between model, meta model and meta meta model. There is always a meta meta model (often left implicit).
By getting your definitions right, you get your meta meta model right, which will always have impact (for the better) on your meta model and eventually on your model.
So tell me, to understand your way of thinking better:
What is your stipulative definition of Enterprise, Architecture, Enterprise Architecture, Meta Meta model, Meta Model and Model and method. And what should be their function?
(PS http://www.dragon1.org will 100% english by 10 september 2011, now it is mainly dutch)
Hi Tom,
Great article. I tubemapped* my way through the article and I think I can now “see” the simplicity behind your whole idea!
*My first sketch is (hardly) visible at https://lh4.googleusercontent.com/-ay9fy9OpSOA/TmKvlO7RH1I/AAAAAAAAATA/Q3K36pSMREY/s400/DSC_0101.jpg
In this tubemap I tried to capture the general idea without the details of your examples. I will try to make a cleaner & better visible version on my weblog with some explanation in the near future.
@Peter Bakker Forgot to say that I’ve added a dashed line with a Plugin station because I assume/advice that you can plugin new categories/models into the EA Meta-Model (I can’t recall if you mentioned it somewhere in your articles)
@Peter Bakker
Just wanted to say that my new tubemap is visible at http://bit.ly/nOnLSt
I tried to make an overview of the high-level workings from the perspective of:
– the metamodeller (the blue line)
– the modeller (the modeller)
– the program itself (the red line)
The most important station on this tubemap is the “instantiate” station. That is where you define the foundation for the project container using the categories you have choosen. And that is where you define the foundation for your, what I call, scenario models based on a frozen representation of a context model you have developed earlier.
The biggest challenge I can “see” from this tubemap is version management on all kind of levels so that changes on a higher level won’t break models on a lower level…
@Mark Paauwe – Hi Mark, and thanks. (I apologise that I know very little Dutch: it seems it’s rapidly becoming the natural-language of enterprise-architecture, given the source of ASL, BISL, SqEME, Archimate and so much else – including, now, Dragon1… 🙂 )
On “What is your stipulative definition of Enterprise, Architecture, Enterprise Architecture, Meta Meta model, Meta Model and Model and method. And what should be their function?”
Hmm… tricky… 🙂 – not least because it’s very easy to get lost in all the ‘meta’ layering… So I hope what follows makes some degree of sense?
Enterprise: see my slidedeck ‘What is an enterprise?” on Slideshare. In essence, it’s am emotive commitment: to quote Chris Potts, it can be described as “the animal spirits of the entrepreneur”. An organisations exists in part to implement an enterprise – which is not the same as saying that it is ‘the enterprise’. For the purposes of enterprise-architectures, the enterprise in scope should typically be at least three layers larger than the organisation in scope: organisation, supply-chain/value-network, market, extended-enterprise.
Architecture: not easy to define, because it’s a noun, a verb, a business-function, and quite a lot more. All of it sort-of relates to structure, and how structures are designed, created, used, both static and dynamic. There are all sorts of different architectures – probably one or more architectures for every possible context? – so it gets kind of messy trying to create a definition anywhere past that point. 😐
Enterprise Architecture: literally ‘the architecture of the enterprise’. I tend to describe it as ‘anything to do with the relation between structure and purpose’, particularly in relation to the work of some organisation: in enterprise-architectures we typically create an architecture for an organisation about the extended-enterprise or ‘ecosystem-with-purpose’ within which it operates. As a business function, I usually regard enterprise-architecture as the role that bridges across all of the distinct domain-architectures (business-architecture, IT-architectures, security-architecture, process-architecture etc) and helps them to work together as a unified whole.
Method: a way of working on a context, subject to some form of governance, and guided (explicitly or implicitly) by some sort of model of the context.
Model (M0): a description of the nature of the context, using the terms defined by a metamodel (which itself may be explicit, implicit, or both). We use models to guide sense-making and decision-making within a context. Example: a UML structure-model. (Note that there’s a ‘bootstrap problem’ here: it can be difficult or very difficult to use a model to make sense of itself, because it filters what we can see of and within the context.)
Metamodel (M1): a set of rules and assumptions about how to create a model of a context. Example: the set of permitted entities and relationships for a UML Structure-Model. (Note again the ‘bootstrap-problem’: it hasn’t gone away, it’s just moved up a level. This actually applies to all layers of models and metamodels.)
Metamodel-set (M1/M2): a set of related metamodels, which collectively describe multiple views into the same context. Example: the full UML specification.
Metametamodel (M2/M3): a set of rules and assumptions about how to create metamodels and sets of metamodels. Example: OMG MOF (MetaObject Facility).
Metametametamodel (M3/M4) a set of rules about how to create metametamodels and sets of metametamodels. Example: the primary definitions in OMG MOF.
In this sense, what you’ve described as your ‘EA meta-model’ is, yes, a metamodel. What we’re looking at here is a couple of layers above that: how to describe the structures that can be used to describe the structures that define your metamodel – and ensure that that metamodel is also compatible and interoperable / interchangeable with any other model or metamodel in that space, such as Archimate and the like.
What I’m aiming for in this series of posts is an M3/M4 whose core features such as extensibility and interoperability are still accessible right down at the M1/M0 level. In other words, a structure that on the surface appears as a set of interchangeable entity-sets that each look like an ordinary M1 metamodel – which is what people are used to working with, in UML, BPMN, Archimate etc – that in reality can be used within any relatively-conventional metamodel and model. With a few tweaks similar to those in CSS or XML-DTD, it also gives us a file-format that should be fully exchangeable between toolsets. That’s the idea, anyway.
So, how do we ensure that this would also be compatible with Dragon1?
@Peter Bakker – Yes, the ‘tubemap’ approach is definitely useful for highlighting what’s there and what is not. (I was going to ask how you would describing the linking-theme that represents each ‘tube-line’, but you’ve now done just that in the latest diagram – thanks!)
Would agree that versioning is one area we haven’t touched yet as such – I’ve mentioned it, and I’ve suggested a mechanism for it, via a combination of wiki-type structures and reference-tags, but I haven’t gone into it in detail. That’s something that does need to happen, though in some ways we could so a first-level prototype without it (or without much of it, anyway).
Another key theme we haven’t yet addressed at all – other than mentioning it – is security and access-control. That’s definitely non-trivial, though fortunately Stuart Boardman has already stepped up to the plate on that one.
I get the feeling that we’re getting close to some understanding of what this would do, and why, and some first-level ideas about how to do it. Hence it’s at this point that the really hard work starts… 🙁 🙂 – because somehow we have to do it, realise it in the real world. Which brings me back to my original request, rather too many posts ago: “I guess I need some help here”…? 🙂
@Tom G I think the problem is that most readers who will come to this page/weblog are lacking programming skills/time to help with the implementation. Especially if you choose to built it from scratch. So (I think I commented something similar earlier) best thing to do is to built a prototype/sandbox (or multiple prototypes) with the core features on existing technology. And perhaps suppliers of that technology want to help with lower-level stuff because it may be interesting for them too (possible new market!).
I saw somewhere a reference to wikis. Interesting is that there is an open source product called zAgile http://www.zagile.com/products/project-lifecycle-products.html#wikidsmart what seems to have a lot of capabilities needed to built a prototype. And they offer also a sandbox environment (I haven’t tried it, so I don’t know if that would be of some use to us). Maybe it is good to contact them to ask if there technology is capable of implementing a prototype based on the ideas we have at this moment and if they are willing to support us in some way.
I will send a link to this comment to their Twitter account (@zAgile)
This is really great Tom, through some of your comments to other people and myself you’ve given a lot of clarity on your vision. I’m starting to see the different parts you describe fall into place.
I’m really looking forward to being part of a collaboration with you and others as this work progresses. Well don!!!
This is a very interesting idea. Thank you Peter, for directing this our way. Wikidsmart leverages OWL-based ontologies. Therefore, you can formally represent the concepts in the canvas above, their interrelationships, and characteristics and attributes of those relationships. It will, however, require the development of the ontologies for capturing business model information and canvas UI. Currently, Wikidsmart could accomplish this using page templates (in Atlassian’s Confluence Wiki) although the canvas offers a richer UI context.
-Sanjiva