Meta Models

What are Meta Models ?

In Dragon1 we recognize meta-metamodels, 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 class Business Process.

Metamodels are the language constructs one can create a model with. A metamodel is the coherent and consistent set of entityclasses. 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 entityclasses 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 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 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 metamodel 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 noting 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 to approve.

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

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

If an architect documents or draws 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 of 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 examples 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-informationfacilities that are provided via the enterprise wide IT-infrastructure.
  • The IT-Infrastructure provides infra-services to information-facilities.
  • The information-facilities provides 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-clientview.
  • the 360-clientview 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 entityclass-types in the VEA-core model: concepts, elements, components, objects and 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-metamodel.

It is common to distinct between classes and classtypes in a metamodel. And to re-use the classes in submetamodels. 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 class in the infra-submodel: as printing-service and storage-service (two types of services). Making 'layers' in the enterprise via their meta-model analogue to one another reduces complexity and increases the adaptivity.

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

  • concept-metamodel
  • element-metamodel
  • component-metamodel
  • etc ...

See Also


External Links