Dragon1 Standard: Meta Models

What are Meta Models?

In the Dragon1 software and in the ea method we recognize meta-meta models, metamodels, and models.

Generally speaking, organizations have an enterprise model that has generic submodels: governance model, business model, information model, technical model, and security model. Next, to these submodels, there are lots of solution metamodels. These solution metamodels are often used to upgrade the enterprise metamodel of the enterprise.

All these models contain instances of entities that are part of the metamodel. Suppose the enterprise model contains a business process called 'sales', in the metamodel, there must be an entityclass Business Process.

Metamodels are the language constructs one can create a model with. A metamodel is a coherent and consistent set of entity classes. A metamodel can be used to check (compile) a model.

Every organization should be aware of its past, present, and future enterprise-metamodel and models.

The entity classes part of the enterprise metamodel originate from the concepts that are (made) part of the enterprise architecture.

Why do Architects work with Meta Models

Working with metamodels creates a quick but solid foundation underneath architecture, engineering, transition, projects, etc.

It brings clarity on how things are related, what is managed correctly, etc.

For instance, in many organizations applications, processes, and projects are administered and managed well. The business objectives, goals, and targets are often not managed and administered.

So the case could well be that more than 1 project is actually linked to goals, whereas only one of these projects actually realizes the goal.

A Dragon1 reference model for Meta Models

We recognize the following generic metamodels:

environment metamodel
enterprise metamodel
business metamodel
information metamodel
technical metamodel
security metamodel
solution metamodel

It is wise to reuse types of classes in these metamodels and to create high-level metamodels, medium metamodels, and detailed metamodels.

The Process for creating a Metamodel

The hard part of metamodels is not the model itself but visualizing the past and present one and creating the future one.

In Dragon1, we use a PICA model to separate roles and note that it is unwise to have people with combined roles.

In Dragon1 lead architects should propose to the owner-client what metamodel to use decide upon or approve.

Lead architects consult architects for this. Architects should do this for their submodel. Also, the lead architect consults various analysts, and engineers for input.

Also every entity class must be linked to a concept where it comes from.

If architects document or draw a metamodel for every entityclass and relationship there must be a definition, justification(rationale), and status.

Note that if you draw or sketch a metamodel you make a visualization of a view of the metamodel.

Examples of Meta Models

A type model, metamodel or meta-metamodel is always the representation of an entity or system.

For instance: the business model of McDonald’s or the IT infrastructure reference model of Dutch municipalities.

A model can be generic, shared, or specific. A model can be the actual used model or a reference model.
A model can be high-level, medium, or detailed.
A model can hold one or more periods of time.
A model and its entities and relationships have a status and PICA

An example of an enterprise-metamodel is recognizing business, information facilities and IT infrastructure as entityclass and defining their relationship (enterprise-rules) as:

Business units are parts of the business
Every business unit makes use of specific business-information facilities that are provided via the enterprise-wide IT infrastructure.
The IT infrastructure provides infra-services to information facilities.
The information facilities provide IF services to the processes part of the business.

In the enterprise model (the entity-instances-relationship model), it could be the following relationships are present:

The sales business unit makes use of the IF-service 360-client view.
The 360-client view IF-services is provided by a CRM system
The CRM system uses the follow-me printing infra-service for printing reports.

On top of the meta-model always a meta-meta-model resides. In Dragon1, we defined that the entity class-types in the VEA core model: concepts, elements, components, objects, technical products, etc. form the meta-meta-model.

In our example the enterprise meta-metamodel is:

Elements are the functional and logical part of concepts
Components are the physical representation of elements
etc...

Often method-metamodels reside in the meta-meta model.

It is common to distinguish between classes and class types in a metamodel. And to re-use the classes in sub-metamodels. For instance, if in the business meta-model 'Services' are used, such as business-service and work-service (two types of services), 'Service' is also to be used as a class in the infra-submodel: as printing-service and storage-service (two types of services). Making 'layers' in the enterprise via their meta-model analog to one another reduces complexity and increases the adaptivity.

Of course of every entityclass-type and its subclasses, types, and instances in the meta-metamodel a metamodel can be created: