When working in an architecture repository you see that certain roles are necessary to introduce collaborative working. However, in the context of the organization, this role must be sufficiently embedded in the team.

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.

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.

Due to various functionalities and the possibility of reusing existing (partial) models, an agile approach in a repository is easily possible.

Building blocks can be developed as templates within the repository. By using copying building blocks or relating specific parts to these building blocks, a working method with building blocks can be easily introduced.

Repositories contain various functionalities that enable version management of architecture (components). This makes it easy to visualize the differences in this version

Within architecture repositories, multiple views of an architecture can easily be created. These views can be made specific to different stakeholders in the review process. In addition, there are functionalities available in a repository to support the review process. This makes the review process easier for both the modelers and the reviewers

Because working with an architecture repository is based on standardization and reuse, this requires discipline from the modeling team in terms of modeling conventions and collaboration. This is only possible if the team works together and views the repository as a joint product.

Architectural models can always be more beautiful and detailed. This is often unnecessary and even undesirable. These overmodeled architectures must also be maintained and managed at a later stage. In addition, a detailed model is neither relevant nor clear for many stakeholders.

Due to the joint use of the elements in a repository, modelers must be alert to duplicates, homonyms and synonyms in the model. Preferably, a control process is set up to prevent this. This process is preferably supported by functionalities in the modeling tool.

Introducing repository-based working is an investment in a changing organization. Organizational change requires an investment in time from ALL architects. See also the explanation for: I am special, so for me ...

You regularly see in architecture teams that a number of architects do not find it necessary to participate in an architecture repository initiative. This is an anti-pattern and will prevent acceptance of a repository-based method at some point. Try to prevent this as much as possible.

Especially in large organizations, various parts of the architectural model will already have been developed in other tools. Partly by the architects themselves, partly by other stakeholders. Agreements must be made about the use of references or integration tools.