| Part of the enterprise architecture work is to define a meta-model. Meta-model depict what are the architecture building blocks that we need to do our work, and their relations. Usually meta-model is one of the first task that we'll address in enterprise architecture work, following by collection of building block instances that we miss. There are many debates around enterprise architecture meta-model. Should I follow one provided by existing framework, should it be a complex or simple meta-model, what should be included in the meta-model and many other questions. In this article I'll try to address those questions.
The starting point in the journey to create your enterprise architecture meta-model is to understand important principles, which usually takes time to understand:
- Enterprise architecture is about better managing Business and IT. It's not an attempt to understand internal technology, application, information and even business architecture. The best approach to reach a good meta-model is to depict in the meta-model dependencies between different enterprise building blocks as they exist in reality. Usually IT oriented guys try to follow application or technology architecture and impose it on EA, that doesn't work. For example depicting direct relations between application and servers is bad practice. Applications are using servers via databases, products or technologies that they are using.
- Collect none exist data in the enterprise. For example if each application has internal application modules, don't add modules to your meta-model. Try to create a meta-model that will hold data and especially relations that aren't capture today (Keep building blocks that you want to capture their relations, but minimize attributes).
- What you collect must be maintained. This principle is simple but for some reason many people don't follow it. If you'll have an impressive meta-model with 33 building blocks and 119 relations (see below) you're doomed to be failed. No way that over the time you'll manage to keep up-to-date all the data in such meta-model (Regretfully, you'll reach this conclusion just after years of EA experience). Without accurate data you won't be able to reach any success. I'm not talking about the human resources and governance procedures needed to keep such meta-model data up to date.
- Metamodel can be developed in agile way. You can start from very small meta-model structure and enhanced it from EA task to EA task.
Those 4 meta-model principles are essential when you creating your EA meta-model, but the most important rule that you need to follow is that enterprise architecture meta-model should help you to do your work. Therefore the first effort in building a meta-model should be understanding what you want to reach in your EA, and if you're following an agile way of working, what you want to achieve in the next enterprise architecture task. Don't spend time to create a meta-model that will address all of your concern. Make sure that the meta-model support your next enterprise architecture work and enhanced the meta-model as your enterprise architecture become more mature. For example I managed to achieve amazing EA result from this simple meta-model: 
Following the first, second and third principles keep your meta-model in the right granularity level. Don't fall into detailed architecture trap, but on the other hand keep any data that you need to do your work or to make you as a unique group in the enterprise. As I argue in my post about the death of EA frameworks, Finding the right granularity is something that you'll learn from experience, no framework will solve this puzzle for you.
In enterprise architecture meta-model domain, big in not better. Actually the other way around, small, lean and efficient is much more better than big and complex. You can test if your meta-model efficient by running EA scenarios and mark all the building blocks that you'll use. Any unmarked building block is "fat" that you want to take off. |