Dragon1 Meta Models

From Dragon1 | wiki
Jump to: navigation, search


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, informationmodel, technical model and securitymodel. Next to these submodels there are lots of solutionmetamodels. these solution metamodels are often used to upgrade the enterprise metamodel of the enterprise.

All these models contains 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 entity-class class Business Process.

Metamodels are the language constructs one can create a model with. A metamodel is the 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 enteprise-metamodel and models.

The entityclasses part of the enterprise metamodel originate from the concepts that are (made) part of the enteprise 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, whats is managed correctly etc..

For instance: in many organization applications and processes and porjects are adminsitered and managed well. The business objectives, goals and targets often not managed and administered.

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

A Dragon1 reference model for Meta Models

We recognize thene 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 highlevel metamodels, medium metamodel and detailled metamodels.

The Process for creating a Metamodel

The hard part of metamodels is no the model it self but visualizing the past and present one and creating the future one.

In Dragon1 we use a PICA-model to seperate 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 variuos analists, advisors, engineers for input.

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

If an architect documents or draws a metamodel, for every entittyclass and relatiosnhios 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 Mc Donalds or the IT-infrastructure referencemodel of dutch municipalities.

  • a model can be generic, shared of specific. A model can be the actual used or a reference model.
  • A model can be high level, medium or detailled.
  • 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 there relationship (enterprise-rules) as

  • business units are parts of the business
  • every businessunit makes use of specific business-informationfacilities that are provided via the enterprise wide IT-infrastructure.
  • The IT-Infrastructure provides infra-services to informationfacilities.
  • 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-systeme 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 techinical 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 mteamodel. 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.

Offcourse 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