Drawing up architectural models is on the one hand a creative activity, on the other hand it is a relatively error-prone process. This means that the tooling must optimally support the modeler when drawing up models.

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.

Especially in large Architecture Repositories, a simple search based on various parameters and combinations is necessary. This also has added value in smaller repositories.

Drawing diagrams is a creative process very similar to drawing. Drawing up diagrams is not always intuitive, and various supporting functions are also required for drawing up models. Such as establishing relationships, adjusting layout or searching for connections, etc.

An architecture repository needs some form of classification. The form of classification used is different for every organization. To this end, there must be an option to choose a particular format for the repository AND be able to easily change it at a later stage if desired.

Not every stakeholder can and wants access to the models via complex modeling tools. There is often a need for simple access with an intuitive navigation structure to the (partial) models.

Partial models are accessed via HTML pages. This makes it possible to use partial models in an attractive format with easy navigation for stakeholders with little knowledge about modeling tools.

Subarchitectures must be able to be delivered in a format that allows stakeholders without access to the repository to easily familiarize themselves with the models. This includes Word and PDF documents that are compiled from the Architecture Repository,

When drawing up certain partial models, the structure of the packages, diagrams and elements is predetermined. In that situation, the use of templates is desirable. These templates must be easy to manage and use.

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

Models drawn up must be reviewed for applicability and feasibility for the organization. This requires a review by various stakeholders. This must be adequately supported.

Particularly in situations where the different stakeholders do not physically work in the same space, working with collaboration functionalities such as chat and discussion or review functions is desirable. But this can also have added value in other situations.

This is both model expansion and limitation. Expansion is, for example, adding your own modeling languages and concepts, but also by adding your own element details In addition, it is desirable that restrictions can be set within a standard modeling language. Consider the viewpoints within ArchiMate

Partial models can be exported and imported to various formats. This includes general formats CSV, XLS, XML, but also more specific exchange formats such as XMI or AMEF. In addition, web service technology can also be applied to implement more interactive export and import of submodels.

For elements in the architecture repository it is necessary to be able to easily consult and modify details of the elements. In addition, in certain situations it may be desirable to add your own element details to the details of elements.

Architecture Repositories quickly become extensive (many elements, diagrams and connections). That is why there must be functionalities that make it possible to easily find relevant sub-models. This is relevant for all stakeholders.

An Architecture Repository does not stand alone in an application landscape. Data must be exchanged to and from the architecture repository. Model transformation is almost always necessary.

Generic functionalities that are often relevant to all stakeholders for the architecture repository,