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.

The most important architectural modeling languages are configured in the architecture repository so that diagrams can be drawn up within the modeling languages based on the languages and the properties relevant to that language can be set.

Functionalities can be configured so that operation can be adapted to the specific situation of the user organization, relevant for matters such as validation, integration and publishing.

The architectural modeling languages are often extensive, which is why a subset of entities, connectors and attributes are often chosen. The repository is configurable to make the design specific to the viewpoints of the user organization.

It is possible, preferably, to activate and deactivate functionalities per authorization role. Use should be simple, especially for roles that occasionally use the architecture repository.

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

Generation of (part) architectures in the form of documents. Consider project and reference architectures for stakeholders who do not have access to the architecture repository content.

More and more organizations are working web-based, making the repository content available based on HTML is a requirement.

Many stakeholders are involved in architectures, these stakeholders must be consulted whether they agree with the elaboration within the architecture. A (standardized) review process is necessary for this.

For the standard software qualities, it can be specified to what extent they are relevant in the repository and to what extent this quality has been implemented.

For the standard data qualities, it can be specified to what extent they are relevant in the repository and to what extent this quality has been implemented.

Templates make it possible for modelers to use standardized models, and the amount of work required to draw up models is also reduced, so it is a form of reuse.

Architectures are an important input for (ICT) projects and therefore relevant for many stakeholders. Approval of these architectures by, for example, an architecture board or a Lead Architect is therefore necessary.

Configurable facilities must be available for the exchange of data (import and export), especially for incidental exchange via, for example, CSV or XLS files.

Exchange of (partial) models based on the ArchiMate exchange standard so that exchange with other (ArchiMate) modeling tools is possible.

Exchange of (partial) models based on the BPMN exchange standard so that exchange with other (BPMN) modeling tools is possible.

Exchange of (partial) models based on the UML exchange standard so that exchange with other (UML) modeling tools is possible.

In a modern application landscape, an architecture repository is not separate from other registers. Integration with other registers such as a CMDB based on modern message-oriented integration is desirable.

The content of an architecture repository must be made available to the various stakeholders in multiple forms.

Configurability is important across multiple dimensions, in addition to adjusting behavior, adjusting and expanding functionalities of the repository is also desirable.

Essential part of the repository, existing sub-models can be used for (project) specific models. This provides an important advantage compared to document-driven architecture.

Standardized non-functional requirements, called qualities, can be developed for the functionalities in an architecture repository.

A number of work processes can be defined for drawing up and managing architectures, for example for modeling, reviewing or approving. The repository must adequately support the various processes.

Creating models and views is a core functionality of an architecture repository. This should therefore be supported as much as possible with intuitive functionalities.

When drawing up architectural models, a number of generic functionalities are desirable, such as drawing, visualization and diagram functions, but also publishing content.