The Wikipedia definition of a metamodel illustrates the difficulty one can have in understanding the concept: A meta-model typically defines the language and processes from which to form a model. Huh?
The very plain English version from an Enterprise Architecture point of view is that a metamodel is a collection of all the stuff that makes up your enterprise and their relationships to one another. Basically it’s an ontology which our trusty source Wikipedia defines as: A standardized representation of knowledge as a set of concepts within a domain, and the relationships between those concepts.
As we’ve discussed, Enterprise Architecture is typically broken down into layers focusing on strategy, business and technology or business, application, data, technology depending on the framework you have chosen.
The metamodel is where the EA rubber hits the road so to speak. You populate your EA content by populating the various elements in the metamodel and the related properties which then provide you the ability to create different views of that information that are relevant to specific audiences. Let’s illustrate this with a simple example:
As you can see we have specific elements in each of layer of our EA. These layers are sometimes referred to as sub architectures. It is also critical to clearly define each of the elements so there is a shared understanding about what the terms mean. Looking at the diagram it becomes clear that our metamodel provides a structure for our content and enforces rules about which elements can be related to what. For the more technically inclined – think of the metamodel as your database schema
For example – a Business Initiative would obviously not be directly related to a Device in the Technology layer. However by navigating through the layers and elements you can see that there is an indirect relationship between the two. Having said that, this metamodel would allow us to analyze what business initiatives would be potentially impacted if there was a problem with a specific device.
As well as providing a common definition for the elements that comprise your enterprise, the metamodel and associated modelling tools also provide the ability to make a lot of the documentation that typically collects dust actionable. An example of this would be the ubiquitous Business Process diagram. You know – the one that always seems like a great idea for the business analyst to show how well they know the business and the one that doesn’t get updated as the change requests start flowing in.
Instead of using Visio or another drawing tool to create your swim lane diagrams you would open your modelling tool and create a new business process diagram and model it using BPMN. You would then link it to its related elements and voila! You now have a diagram that can be used in many more meaningful ways to the benefit of the enterprise. You can easily assess the impacts of any changes, you can quickly see where the process is used and by which groups in your enterprise and you can see which data elements are used to support the process. Therefore there is an incentive to, through your EA governance processes, to ensure that the process diagram is kept up to date.
Most EA frameworks provide a metamodel and the more advanced tooling supports the implementation. Below is an example of the TOGAF (The Open Group Architecture Framework Metamodel:
A tool such as IBM Rational System Architect supports the TOGAF metamodel by having the elements and their relationships predefined when a new TOGAF project is created. These elements are extensible in the sense that you can easily add organization specific properties to them which would be driven by the information requirements of the various stakeholders.
Another important point to note is that because the elements are related to one another you have flexibility in where you begin populating the metamodel. Again, this is driven by the requirements of the stakeholders. If your EA initiative is nascent you could begin by modelling the application and technology related elements and expanding upwards towards elements in the business architecture as your EA capability matures.
The EA artifacts you create (Swim Lane Diagrams, Node Connectivity Diagrams, Data Flow Diagrams etc.) are built from and linked to the elements in your metamodel. This makes the artifacts dynamic in the sense that they are driven by real data and you have the capability to drill-down through them to see all the related information. Multiple future states can then easily be modelled to assess the potential impacts of any changes.
In order to ensure that an organization gets the most value out of their technology investments there needs to be alignment between the technology and the business. This is a problem you hear constantly – everyone knows there needs to be alignment but very few understand practically how to do it, model it or measure it. Enterprise Architecture is one of the disciplines that will enable an organization to accomplish this. The metamodel is where you relate business and technology architectures which will allow you to make smarter, more well-informed decisions going forward.
Enterprise Architecture has the ability to make things visible that were previously hidden and this is done through choosing, extending, populating and reporting on the metamodel.