The Architecture metamodel describes the organization-tailored application of an architecture framework, including a metamodel for architecture content and language.

The metamodel of the Architecture models and the resulting architecture products must match the context of the organization. This will often be based on one or more modeling languages. Within these modeling languages, a subset will often be developed for the context of the organization. In addition, it must be worked out how a combination of modeling languages is realized. This forms the basis for the metamodel of the architecture repository.

Concept is an abstract entity in the metamodel of a modeling language and is characterized by the fact that it can appear in diagrams or views based on the associated stereotype. Here we recognize two specializations of a concept, namely element and connector or relationship.

In addition to the configurability of the modeling languages, there is a transcendent metamodel. This must also be configurable so that the modeling language can be configured to the wishes of the organization beyond the modeling.

An architecture tool is often already configured and set up if the (meta) model of the architecture has not yet been determined. The metamodel determines the design of the tool and the functionalities within the tool.

The metamodel determines the boundaries of an architecture. (Automated) validation of whether a (sub)architecture complies with the metamodel is desirable.

A list of proposals, in the form of requirements and requirements for the architecture to be drawn up. But also for the metamodel or the modeling conventions of the architectures to be developed.

The architecture repository works with a shared and established metamodel, including the modeling conventions. This prevents dialects and differences in the models within the repository.

Viewpoints are constraints in the architectural models based on the modeling languages. If you want to use simple architectural models, you should develop this as part of the metamodel.

Aggregation of the various registers, administration and metamodels for data management (knowledge areas).

When using an architecture repository, it is important to determine what and how the architecture is modeled. To this end, a metamodel is drawn up by this role. This includes the modeling conventions, cross-language conventions and design of the repository.

Metamodel consists of a list of various modeling languages relevant to architecture, including a number of submodels and languages. On this basis, the organization can make a selection of the architectural languages and sublanguages relevant to them. In the development of the tools, such a metamodel based on simplified viewpoints in ArchiMate is developed as an example.

A model that describes how and with what the architecture will be described in a structured way.

The metamodel describes the model of the architectures. This is often based on an architectural modeling language such as ArchiMate. These architectural modeling languages have also been developed in a metamodel

A metamodel is important for an architecture in general and essential for an architecture in a repository. Because the metamodel forms the framework for the architecture, it must be developed and maintained in a work process.

The metamodel and the chosen modeling languages are also joint in a shared environment. Therefore, there needs to be agreement on these artifacts within the modeling community. To this end, consultation forms must be set up to obtain and safeguard this agreement. In addition, the metamodel must be consultable by the entire community.

This is an example of modeling and naming conventions that can be used within an architecture repository. This elaboration is an example of how to develop a metamodel and its conventions. In this case for a data architecture development. The metamodel has been developed based on the DMBoK framework. This means that part of the framework has been developed and the others have not yet. Here, particularly from the point of view of the data architect, is an elaboration of modeling conventions and architectural models. Working with meta data requires a white paper on metadata modeling methods.

In addition to drawing up architectures, there are also roles that review and approve the architecture artifacts. For example, by testing for quality, feasibility, but also on the application of the modeling conventions and the organizational metamodel.

For the metamodel of the architecture, a number of modeling languages are often chosen in which a metamodel and modeling conventions have already been developed.

Standardization becomes more possible by using various repository standards such as the use of templates, model validation, and limiting use based on metamodels. In fact, a repository offers more opportunities to limit the modeler's freedoms.

Models in the architecture repository can (and should) be standardized in the architecture repository. This is done on the basis of an established metamodel. If this metamodel is available in the architecture repository, (automated) validation of architecture models becomes relatively easy.

Is an identification of a concept in which the definition, characteristics and appearance of a concept within that language are determined on the basis of the metamodel of a modeling language. Be aware that the appearance of a concept may be the same, but has a different definition and characteristics within a different modeling language.

When introducing an architecture, the implementation must be guided on several levels. This includes the introduction of a metamodel, the modeling methods and the use, configuration and selection of the tools.

Defining metamodels is important when using an architecture repository. On the one hand, this is done by making a selection of standard modeling languages, on the other hand, this can also mean defining your own modeling language.

In addition to review, the models must be validated. This involves checking whether the modeling conventions and metamodels have been applied correctly.

Modelers must be trained, on the one hand in the use of the tooling and on the other hand in the metamodel and the conventions and conditions that apply within it.

The modellers who jointly draw up the architectural model are trained in the use of the tool and are familiar with the established metamodel

Reviewing architecture is mainly about the content of the architecture and in this process it is mainly about handling the metamodel and applying the modeling conventions.

Het metamodel van ArchiMate uitbreiden in Enterprise Architect

Metamodellen in een architectuur repository

Metamodel van ArchiMate

Aanpassen van Enterprise Architect voor een specifiek metamodel voor de organisatie

Work process for a repository-based architecture. This includes a number of general steps, such as developing a metamodel for the architecture. It also contains a number of specific matters such as the design of the tooling. This diagram only includes the business process description. Please note that in the example repository a link has been made with other components in the solution architecture. This includes assigning the business roles for these business processes. These are then developed into a number of more detailed diagrams.

This diagram is a viewpoint for developing a logical data model. This viewpoint indicates which types of object types and connector types can be used when drawing up a logical data model. A few principles apply to the logical data model:

• Logical data model is for all stakeholders (ICT professionals and non-ICT professionals) and must be understood by all stakeholders after an explanation of the metamodel.
• Logical data model is developed in UML Class Modeling.
• For the logical data model, only the Class and Enumeration stereotypes are used.
• The logical model has a hierarchical structure based on abstract and concrete entities with a specialization connector.
• For a logical domain, multiple diagrams can be created if this reduces complexity.
• The logical model is related to the parent conceptual model and to the underlying physical data models. See the hybrid meta data model for this.

Data qualities can be developed in a viewpoint using ArchiMate concepts. One deviation has been chosen here, namely the registration of issues surrounding data qualities for which a generic concept issue has been chosen in this metamodel.

The meta modeler plays a role in drawing up a metamodel for architecture, selecting modeling languages and drawing up organization-specific modeling conventions. This role is very important in carrying out a number of activities in the architectural work process. In addition, the meta modeler realizes a number of capabilities that are necessary for modeling in an architecture repository.

This is a meta model for the data governance entities based on an Example specific ArchiMate data governance viewpoint. Including elements and the underlying relationships between the different elements. Please note that from the metadata perspective, this model will be expanded with detailed (meta) models for the other data management knowledge areas.

When introducing an architectural process based on an architecture repository, working with a modeling community becomes necessary. This community must ensure that a number of preconditions are introduced to ensure that the working method with an architecture repository realizes the goals and needs of the architecture team. When working with a repository, the metamodel and a collective view around the modeling techniques applied within the team are particularly necessary. In this view you can see that the modeling community is considered a collaboration of a number of architectural roles within the organization.

Metamodel consists of a list of various modeling languages relevant to architecture, including a number of submodels and languages. On this basis, the organization can make a selection of the architectural languages and sublanguages relevant to them. In the development of the tools, such a metamodel based on simplified viewpoints in ArchiMate is developed as an example.

This is an example of modeling and naming conventions that can be used within an architecture repository. This elaboration is an example of how to develop a metamodel and its conventions. In this case for a data architecture development. The metamodel has been developed based on the DMBoK framework. This means that part of the framework has been developed and the others have not yet. Here, particularly from the point of view of the data architect, is an elaboration of modeling conventions and architectural models. Working with meta data requires a white paper on metadata modeling methods.