If you ask any experienced enterprise architect, they will tell you that having a good metamodel is essential to almost everything that they do. A metamodel will:
- Catalog each type of component in an enterprise architecture
- Provide detailed definitions
- Document the relationships between one component and another
- Define the structure and configuration of the architecture itself
- Help users understand the structure and behavior of the architecture
- Provide a summary of, or index to, the catalogs, matrices, diagrams and any other artifacts produced for the architecture
And of course, crucially, the metamodel is a high-level map of the component types that are found and used in the real world.
But there is one word that is very important in my first sentence…. It was the word ‘good’. What architects really need is a good EA metamodel.
TOGAF, of course, has a content framework and metamodel included in Part IV of its documentation: the ‘Architecture Content Framework’. But is it ‘good’ and, if not, what is it lacking? That’s what I want to write about in this blog.
Common Elements in all Enterprise Architectures
Clearly, there are a lot of elements that are common to pretty much all enterprise architectures. An enterprise has a purpose, it has people, and it needs a platform capable of helping it to achieve its goals. The people have roles to perform, they carry out functions, and they are managed through an organizational structure. There are also processes to provide products or services to customers. There may be suppliers who provide resources, as well as outputs delivered through distribution channels. Meanwhile, the supporting platform or infrastructure will include things like applications, databases, networks, buildings, equipment, and machinery.
Note that this list covers far more than just the IT components!
Conceptually, these elements will be pretty similar from one enterprise to another, and so it is certainly possible to create a metamodel that describes these generic components. It is the role of an EA metamodel to document the components or building blocks in the enterprise architecture. The TOGAF metamodel aims to give you such a metamodel as a starter kit, saving you the task of having to create a completely new one from scratch.
Limitations of a Generic Metamodel
Generic metamodels can be very useful, and they can save you a lot of time and effort because you won’t have to reinvent the wheel. At the same time, a good generic model should also be easy to adapt and tailor to your specific needs. Here is a list of some of the most common changes you may need to make to the TOGAF metamodel to make it suitable for your organization:
- The boundary between one type of component and another may differ in your enterprise. For example, in one enterprise a workflow might comprise several activities, while the workflow in another might include several processes and tasks
- The name of a component may not match the language of your enterprise. For example, words like ‘process’, ‘activity’, ‘task’, ‘procedure’, or ‘transaction’ may not mean exactly the same thing in different enterprises
- Boundaries and names may both differ. For example, a workflow might include activities, tasks, roles, inputs and outputs, or the concept might be named a ‘process flow’ and only include activities or steps
- The relationship between components may differ. For example, some relationships shown in the TOGAF metamodel might not be required in your enterprise, or additional relationships might need to be added
- The structure or configuration of components might not be the same. For example, one application might contain several services, while another might trigger separate services
- The attributes of a component or relationship may be different. For example, one process might have unique ID, name, description and duration attributes in one enterprise, but not all of these may be present in another
Going back to my point about the need for a ‘good’ metamodel, let’s address the all-important question: is the TOGAF metamodel a good one? TOGAF’s metamodel does cover quite a lot of the basic, most common constructs, though generally speaking it will usually be best to educate yourself on the concepts behind metamodels before committing to TOGAF fully. No metamodel is perfect, but having a working of knowledge of when and how to adapt the TOGAF metamodel will enable you to use it much more successfully.
In the next blog, I’ll look at some examples of customizing a metamodel.
