Dragon1 Standard: Meta Models

What are Meta Models?

In the Dragon1 software and 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 part of the metamodel. Suppose the enterprise model contains a business process called 'sales'. In the metamodel, there must be an entity class 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 know 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, applications, processes, and projects are administered and managed well in many organizations. The business objectives, goals, and targets are often not managed and administered.

So the case could be that more than one project is linked to goals, whereas only one of these projects 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 create high-level, medium, 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 and creating the future.

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

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 entity class 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.
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 entity class 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 uses 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, permanently, 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 expected to distinguish between classes and class types in a metamodel. And to reuse 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: