In the previous chapters we discussed the different dimensions of introducing an Architecture Repository. In this chapter we discuss a number of tools that support and simplify the introduction of an architecture repository. We are working on this based on Sparx Enterprise Architect, a modeling tool for various modeling languages. This makes it extremely suitable for setting up Sparx Enterprise Architect as an architecture repository. The elaborations of these tools have all been developed based on Sparx Enterprise Architect.

When applying modeling languages and working in a repository, it is very important that there is agreement on the modeling languages and the modeling and naming conventions. This can be achieved by developing a community where this capability is jointly developed and maintained.

The architecture capabilities define the parameters, structures and processes that support the management of the architecture repository.

Different roles in the organization that use the artifacts produced by the architects and taken from the architecture repository.

Producer of artifacts, data and information that serve as input for preparing architect artifacts (in the architecture repository).

A part of the Enterprise Continuum. A repository of architectural elements with increasing detail and specialization.

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.

The architectural processes are often designed to produce, review and deploy architectural documents. By using an architecture repository, the architecture products will change and therefore the architecture process must also be designed differently.

The Architecture Repository is a software tool that stores key architectural inputs and outputs, including Architectures themselves, their constituent elements, standards, references, principles and the Governance Register. Regardless of the Architecture Framework or Architecture Language selected. An enterprise architecture repository is therefore a collection of artifacts that describes the current and intended enterprise landscape of an organization. The purpose of the enterprise architecture repository is to represent the organization's inventory of technology, data, applications, and business artifacts and to show the relationships among these components. This is achieved by creating diagrams and visualizations based on the contents of the architecture repository.

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.

When introducing an architecture repository, the architecture products will often be published in documents. Documents are characterized by the lack of connections to other documents and the architectural elements described therein. As a result, a joint, reusable and shared architecture description is lacking. This is often a reason to introduce a repository architecture

Description of the business architecture for a method with an architecture repository. A number of business processes and roles are being developed for this purpose. Because working with an architecture repository is a transition to a different working method within the architecture team, the business architecture is therefore an important part to work out in detail. The reason is that a successful enterprise architecture can determine the success or failure of the introduction of an architecture repository.

Models are centralized in the repository, which is usually a relational database. This makes it easier to gain and maintain insight into connections.

To the place in the repository tree structure based on a function under Design -} Package -} Manage -} Update. This allows you to recursively change the contents of the repository, including the diagrams and the elements, the status indicating how elements can be (re)used in the new solutions. You can then use the legend with the status colors by setting it to active to put in your diagram. This makes it easy to see what the status of an element is based on the colors.

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

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.

the introduction of an architecture repository, the associated (modeling) tool will need to be configured and set up so that the modelers can effectively work together on the architecture model and the products.

Data architecture of an architecture repository. This is relatively simple in design in this document and only involves a conceptual data model. However, the conceptual data model does provide an overview of relevant concepts within an architecture repository.

Issue registration for quality issues within a repository. An ITIL-based method is often used for this issue registration.

Deduplication is an operation on the contents of the repository that searches for duplicates of elements and relationships. It is then determined which element is considered original in the new situation and the other elements with the same characteristics are considered duplicates. Deduplication is then carried out consisting of a number of actions:

• Merging the contents of the elements
• Merging the relationships
• Updating the diagrams to point to the original
• Renaming and isolating the duplicates
li>

This is a repetitive task that fortunately can be easily automated within, for example, Sparx Enterprise Architect.

Duplications can easily occur in the repository, despite the messages generated by the IDEA AddOn. This process describes how to de-duplicate in an architecture repository in which multiple modelers work together.

Run the deduplication routine in the IDEA addon, including the subpackages if desired (enable the check mark in the screen).

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.

By using an architecture repository, a new architecture approach is introduced that makes the architecture process and the products more efficient. These goals are related to the outcome achieved by the capabilities. Diagram is based on the ArchiMate Motivation extension.

What is the baseline (document-oriented architecture) and the target (architecture repository).

When developing models and expanding the model by adding new elements in diagrams, introducing a duplicate is a risk. The toolbox is always close by in a diagram and searching in advance to see whether a concept already exists in the repository is often regarded as an extra step in the modeling process. Early detection of the emergence of a duplicate is therefore desirable and can fortunately be automated relatively easily in modeling tools such as Sparx Enterprise Architect.

Despite the many navigation and search options available in an architecture repository, a logical layout is a good way to provide modelers and reviewers with structure. Packages are used for this in Sparx Enterprise Architect. The (tree) structure of the packages in a repository is therefore an important part of setting up an architecture repository.

Determine functionalities, components and modules in the architecture repository relevant to the organization.

There are several tools on the market for repositories. A small overview in this repository.

Generic and specific requirements when deploying an architecture repository in the organization.

Which business roles are involved in the introduction of the architecture repository and its future use in the organization.

We have interests and concerns surrounding the use of an architecture repository.

Work processes supported by an architecture repository.

A diagram is a visual representation of some of the repository content. A diagram is often based on a modeling language or a combination of a number of modeling languages. Elements from the repository are placed on a diagram.

duplicate is a data element in the repository that is considered a duplicate based on a number of properties. Duplicates can occur with concepts that can be divided into elements and relationships. Elements Elements are actually the blocks on a diagram with certain properties within a modeling language and an appearance. Duplications can be considered the same based on these characteristics:

• Name of the element (possibly based on missing punctuation marks)
• Version number
• Modelling language and Object type within the language. Also referred to as a stereotype.

Relationships Relationships or connectors are actually the connecting lines on a diagram with certain properties within a modeling language and an appearance. Duplicate relationships can be considered the same based on these characteristics:

• Name of the relationship or cardinalities of the start and end points of the connectors
• Version number
• Modelling language and Object type within the language. Also referred to as stereotype

There are duplicates in the repository, this is evident when running a report or because there are warnings about duplicate elements.

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.

Move duplicates to the Trash, then create a baseline, then delete the elements from the Trash. Due to the baseline, they are still present (in XML format) but no longer visible in the repository.

Role ultimately responsible for the overall architecture for the entire organization. So has both a global and an abstract scope on the architecture and the use of the architecture repository.

A categorization mechanism useful for classifying architecture and solution artifacts, both internal and external to the Architecture Repository, as they evolve from generic Foundation Architectures to Organization-Specific Architectures.

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

Architecture models for the elaboration of stakeholders, goals, needs and principles surrounding the introduction of an architecture repository within an architecture team.

The IDEA AddOn is an open source AddOn to support modeling activities within Sparx Enterprise architect. The IDEA AddOn offers functionalities that are missed in the standard functionalities of Sparx Enterprise Architect. Particularly for architectural modeling and aspects of an architecture repository, a number of functionalities are present in this IDEA AddOn.

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.

Description of the aspects of the tooling when working with an architecture repository. On the one hand the required functionalities and on the other hand a list of various available tools.

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 architecture repository works with a shared and established metamodel, including the modeling conventions. This prevents dialects and differences in the models within the repository.

Example of a logical architecture model for a registry or MDM module. Provides an example of how you can combine application functions, interfaces and services in ArchiMate to describe the desired requirements. If you look at an architecture repository from the perspective of master data, you can actually use a number of building blocks to describe functionalities, application services and interfaces in a generic way.

This section contains a number of matrices to easily see connections between the different views of the architecture of a repository. These matrices are based on ArchiMate concepts with which the relationships based on ArchiMate elements and connectors are presented in a two-dimensional matrix.

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.

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.

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.

Every element in the repository has a life cycle of creation, use, mutation and archiving, including iterations. Due to the many connections that exist in an architecture repository, every modeler must have insight into the life cycle phase of an entity. To this end, agreements must be drawn up about the use of these elements based on the phase.

The model in the repository is developed and used jointly. Due to the many connections between the elements in the model, an adjustment to the model almost always has an effect on sub-models of other modelers. To this end, work agreements and tool functionalities are necessary to make this transparent and to prevent unauthorized model adjustments.

Responsible for the use and deployment of the models in the architecture repository. Has a coordinating and controlling task for all modeling roles involved in the architecture. Monitors the consistency of the architecture repository and provides modellers with information and training on the use of the architecture repository.

Collection of work instructions for the model manager regarding the design of the repository and the use of Sparx Enterprise Architect

The content actually becomes the collective architectural product of the community. That is why quality requirements are imposed on this joint model. To this end, this responsibility must be known to everyone and there must be a role that monitors this responsibility.

The modeling community is responsible for making a number of working agreements, such as: ul> The modeling community does this by:

• Ensuring the design and conventions for the repository
• Developing architectural and modeling conventions
• Provides training regarding the repository design and the modeling method
• Review developments
• Stimulate communication and interaction within the community

Inside the modeling community should jointly introduce the above-mentioned working agreements. Depending on the structure and culture of the organization, different scenarios can be chosen to achieve this Intervision session The modeling community jointly determines what the conventions surrounding modeling are. Within intervision sessions, all participants can submit topics, examples and modeling problems that are discussed and based on discussion, a joint decision is made about the method to be followed and, if desired, the adapted modeling conventions Characteristic of the intervision session are

• On a regular basis a session organized for all modellers
• In these sessions the various participants bring in questions, solutions and suggestions
• Works well in small teams

Model manager Another scenario is that a model manager role plays a pioneering role in introducing a modeling community. The model manager is more active and the modeling community is more passive. Characteristics of the model manager are:

• Model manager determines bottlenecks and chooses a solution approach
• Sometimes a model core team is deployed for support
• Model manager coö ordinates describing the decisions in the repository or help pages
• Works well with large teams

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.

Joint modeling is based on agreements about how the joint model is developed and maintained. To this end, the work processes and agreements must be known to all modelers and the agreements must also be monitored.

Within the conceptual model, a modeling language is a description of a number of concepts within the repository where the modeling language describes a subset. The description consists of the appearance and meaning of the concepts.

Creates models in the architecture repository such as building blocks, solution architectures and base plates etc.

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 ...

By using an architecture repository, work processes can be centralised, described and automatically supported by the available functionalities.

Package is a concept that allows you to logically structure the contents of your repository content. It can be compared to directories in a file system.

Example of a project structure based on the status of different submodels. What is characteristic of this is that the repository has a different layout for each phase. This approach indicates that the package structure does not have to be a limitation. When introducing an architecture repository, a discussion can arise about the package structure about what the correct format is. Keep the following suggestions as a starting point:

• The package layout can change for each part of the architecture repository
• The package structure can easily be changed if the working method is developed. changing insights
• Determining the layout is often managed by the model manager or custodian for the generic architecture components
• In work or project package structures, the modelers have more freedom in the design.
• For solution architectures, use a template as a starting point.
• Take into account the transfer of architectural concepts in a phasing and life cycle in the package layout.

The package structure should be aimed at the modelers who work with the architectural models. Users of these models must be supported in other ways, for example by navigation diagrams.

It seems strange to cover the database structure of a Sparx Enterprise Architect repository in a book about repositories. However, working with an architecture repository will also mean that the content must be accessed in a way that is not available in the formats already present in the tooling. That is why we discuss here the tables that contain the most essential data for accessing of the repository contents. Please note that the number of tables in a Sparx Enterprise Architect includes many more tables.

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.

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

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.

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,

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

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

A system that manages all of the data of an enterprise, including data and process models and other enterprise information.

Overview in the form of a collection of the requirements of the various stakeholders within and outside the organization. Often elaborated on the basis of the motivation extension within ArchiMate. The summary can be done in the form of a list, a matrix or a number of graphical representations of the requirements. See also the elaboration of the solution architecture repository in a previous chapter for a number of examples.

When using architectural documents you often see that partial models are copied. In an architecture repository this is not necessary and use can be made of existing (partial) models in the repository.

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.

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

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.

Based on the relevant application functions, determine which parts of the tool need to be configured in order to effectively use the tool as an architecture repository.

The first step in designing a tool as an architecture is which tool or combination of tools are we going to use. In this example, Sparx Enterprise Architect is further developed and explained as a tool.

Update the list of goals to be achieved by introducing working with an Architecture repository.

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.

This template is a package and diagram structure for an architecture document, for example a solution or project start architecture. A link has been made in the diagrams to a viewpoint elaboration so that modelers receive support with the viewpoint diagrams when developing the model. If desired, this package can be copied in EA to make it project specific. A document can then be generated from it. Use the IDEA AddOn in which you can perform a search and replace action in the package helper. This can easily be copied as a starting point for developing a new solution. The detailed example of such a template can be found as a resource in the existing example architecture repository.

Architecture model for an architecture repository approach. A number of generic architectural components have been developed in this model. On the one hand, this serves as an example for an architectural development. On the other hand, it can be expanded with organization-specific organizational components of the architecture. This makes it a starting point for an organization-wide architecture. This chapter has been elaborated on the basis of a number of architecture components that are relevant in a solution architecture. The same procedure was followed for the introduction of a method with an architecture repository. In fact, we apply an "eat your own dogfood" approach here.

A part of the Enterprise Continuum. A repository of re-usable solutions for future implementation efforts. It contains implementations of the corresponding definitions in the Architecture Continuum.

special ETL process to transform specific data from the source to the master data. For example, consider an ETL process based on XMI, AMEF or BPMN exchange formats from the architecture repository to the consuming information systems.

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.

In this document, after the solution for working with an architecture repository has been developed, a number of generic step-by-step plans are developed. These step-by-step plans provide a team with guidance on which activities need to be carried out to realize the transformation from a document-driven method to a repository-driven method. The step-by-step plans in this document consist of a number of generic activities for the introduction of an architecture repository. However, these steps can easily be extended in the specific context of your own organization. Elaboration is based on the order of developing the architecture and then a step-by-step plan for introducing the tooling of the architecture repository.

An agile approach can be supported by reusing models and using repository functionalities such as publication of content, reuse of (partial) models, etc. However, this does require a special design of the model

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

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.

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.

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.

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.

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.

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.

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

Table includes all elements present in the repository. Please note that this determines how an element looks in diagrams and which compartments become visible in the diagrams based on the object_type and stereotype.

Package is actually used for structuring the contents of the repository. It is based on packages and subpackages hence a self reference to the package table via a parent_id

The aim of architecture when introducing a repository-based architecture is to create an environment where the architecture model and the various architecture products are jointly worked on to address the imperfections of the document-driven architecture. This shared environment is called an architecture repository.

Ensure adequate training of those involved so that they have knowledge of the chosen modeling methods, the possibilities of the architecture repository and the functionalities in the chosen tool.

the limitations in a document-driven architecture method are chosen by the organization to introduce a repository-based method.

This checklist is used to ensure that the models in the repository are easy to find for different stakeholders and that they are given a logical order in the diagrams to get an idea of the solution or the established architectures.

A collection of the specifications of architecture viewpoints contained in the Reference Library portion of the Architecture Repository.

Working in an architecture repository requires different skills than working with architecture documents. Architectural documents are often realized with office automation. Working in an architecture repository often requires specific tooling and a new working method. In addition, there must be awareness of the characteristics of a repository. Consider, for example, duplicates and the reuse of architectural (partial) models and concepts.

Web based enterprise architect repository for publishing an architecture on the web

Voorbeeld uitwerking van een stappenplan voor een architectuur repository

Hoe werk je met ArchiMate modellen in een Architectuur Repository. Hierbij rekening houdend met verschillende views en viewpoints

Binnen een omvangrijke architectuur repository kan het gebruik van nummering en codering een extra dimensie zijn om de inhoud in te delen cq te categoriseren. Sparx Enterprise Architect biedt hiervoor een aantal hulpmiddelen. Deze worden uitgelegd in deze webvideo

Download van het Nederlandstalige boek architectuur repository in de praktijk. Inclusief de links naar het voorbeeld model en de online cursus

Uitleg over de voor en nadelen van een document - en repository gedreven architectuur

Script for duplicate check in a repository

This summary is a presentation of the EA User group conference in Brussels with an overview of how an ArchiMate based repository can be introduced. This gives for example a description of the role of a repository custoduian

Interview about the Architecture Repository publication.

Metadata Modelleren als repository

Metamodellen in een architectuur repository

Inzet Enterprise Architect als repository

Metamodel van ArchiMate

Doelen en principes voor een architectuur repository

Definitie van een architectuur repository vanuit Togaf, AWS en Sparx perspectief

Gelaagde architectuur voor agile werken in een architectuur repository

Rollen en processen bij een architectuur repository in een team

Samenwerken en Intervisie aanpak bij inzet van een architectuur repository

Verschil tussen document gedreven en een architectuur repository gedreven architectuur aanpak

Beschrijving alternatief voor architectuur documenten in een architectuur repository

Dia's van een presentatie gehouden op het innovation event van 2016. Architecten zetten traditioneel voornamelijk documenten in voor architectuurbeschrijvingen. Echter het inzetten van meerdere documenten voor het beschrijven van een architectuur is foutgevoelig en levert inconsistenties op, terwijl er veel beheerinspanning nodig is. Door de inzet van architectuur repositories is het mogelijk om de architectuur op een andere wijze te beschrijven, rekening houdend met de huidige eisen en wensen van de architectuurgebruikers. In deze presentatie gaan we in op het inzetten van Sparx Enterprise Architect als tool en wordt een Open Source Web Publicatie Platform getoond waarmee een Architectuur Repository op eenvoudige wijze via het web aan de gebruikers beschikbaar wordt gesteld. Na deelname aan deze sessie heeft u een duidelijk beeld van de (on)mogelijkheden van Architectuur Repositories.

Overzicht van de beschikbare video's horend bij de architectuur repository training

Voorbeeld scherm van de opzet van de repository verkenner

Description of the various parts or domains of a repository architecture. This is a generic and not complete model, but serves as a starting point for developing the organization-specific domain model. Please note that this own domain model must closely match the design of the organization. Which domains are relevant in the architecture of your own organization. Adjust this list of generic domains to achieve a correct overview . This model is therefore included in the step-by-step plans at an early stage.

Model from the baseline architecture (document driven) to the target (repository based) with a list of the required deliverables. This is based on a number of ArchiMate concepts in the implementation and migration modeling layer.

Overview of the business objects relevant when working with an architecture repository. A brief definition is given for each business object in the description.

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.

Description of the roles within an architecture repository approach. This is therefore more detailed than the overview of stakeholders. In this model, the project members or roles will also be selected. A number of generically named roles. Roles do actively participate in the activities for the introduction of the AR. Please note that this is often organization specific in nature. Therefore, feel free to adapt this model to your own context. In this diagram, the roles are related to a number of stakeholders in the model.

Around an architecture repository, an organization can define a number of capabilities and goals to determine a starting point for introducing this change in the architecture capability within the organization. This defines a point on the horizon for the target architecture.

Checklist with checks that must be taken if you want to determine components within an architecture. This is an important part of the architecture process because, just like architecture documents, (part) architectures have a status. In a repository, a process must be followed for this, just like with document-based architectures.

When working in an architecture repository, validating models is a step in the work process. A duplicate is easily introduced, especially in an architecture repository of some size. Preventing duplicates and deduplicating afterwards in the presence of duplicates is therefore a functionality that is desirable in a modeling tool to support model validation.

When developing and managing the architecture in the models and documents, keeping the repository consistent is a challenge within a repository. With a document-driven approach, keeping things consistent is actually impossible. When working with an architecture repository and using tooling, opportunities arise to automate or largely support, especially iterative, tasks. There are important advantages to be gained for architectural teams. It is therefore recommended that careful consideration be given to which activities can be automated and what requirements there are for the modeling team.

What are the goals of introducing an architecture repository into an organization. This section defines a number of generic goals, goals that apply to most organizations that are switching from a document-driven architecture method to a repository-driven approach.

Enumeration and hierarchy of relevant application functions when working with an architecture repository. In other words, necessary functionalities for a tool to be selected for a repository.

This logical application model views the architecture repository as a master data registry and names the relevant application functions and interfaces that are relevant from the master data perspective and therefore also for an architecture repository. Each element is briefly described and provides an idea of which elements are relevant in its own context. Because in the initial situation of introducing an architecture repository, not all concepts will be relevant. However, with further development of working with an architecture repository, the register will increasingly fulfill a master data function in the application landscape of the organization.

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.

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.

Working in a repository involves establishing modeling conventions. Not only a selection of the modeling languages and within them a subset of the concepts to be used is being developed. However, the modeling convention is of equal importance. After all, there is joint work on architectural models and the modeling conventions should contribute significantly to the consistency of the models and the prevention of contamination of the repository content. In this elaboration a first global elaboration of naming conventions is given. When implementing a repository, this must be worked out in more detail within the organization per language and for the hybrid modeling languages in use. In addition, a more detailed example has been worked out below the tools as an example.

The model manager plays a central role in the operation of an architecture repository. This role is very important in carrying out a number of activities in the architectural work process. In addition, the model manager realizes a number of capabilities that are necessary when introducing and working with a work process based on an architecture repository.

Dit navigatiediagram biedt een overzicht van alle architectuur onderdelen voor de introductie van een werkwijze met een architectuur repository.

Summary of a number of architectural principles relevant when working with a repository-driven approach. Please note this diagram is a simplified representation. A relationship has also been established in the repository, for example with the stakeholders and the goals. However, these are not shown in this part but can be found within the elaboration of the matrices for the motivation of using an architecture repository. Please see the sample repository where you can find all the relationships between architectural elements.

A definition of an architecture repository is given within Togaf and in the Sparx Enterprise Architect documentation. These are designated as generic components as relevant to an Architecture Repository. Try to estimate which specific components you think are relevant to your organization. You can remove the others from the diagram for your own context if you wish. In addition, you can expand or detail these components depending on the context and complexity of your own organization.

This is a list of common requirements for an architecture repository. If there are organization-specific requirements, add them to this model. If there are requirements in this overview that are not relevant to the organization, remove them from this diagram.

A number of generically named stakeholders. Stakeholders have concerns and requirements for the use of an architecture repository. However, they do not necessarily have to be a participant in the project that introduces the architecture repository. Please note that this is often organization specific in nature. In this model only a number of generic stakeholders are named. Therefore, feel free to adapt this model to your own context so that it corresponds to the stakeholders relevant within your organization.

Introducing an architecture process based on an architecture repository is actually an organizational change. It consists of a number of sequential activities. These sequential activities are generic in this document, but can easily be adapted and expanded to your own context. This step-by-step plan describes a number of steps that you can follow to approach the introduction of an architecture repository in a structured manner. The chapter on tools for introducing an architecture repository explains a number of supporting concepts and methods later in this document. This diagram details the various steps (with underlying diagrams) to arrive at a working method for an architecture repository.

A number of activities are relevant when introducing an architecture repository and the associated design of the tool. The activities are described here in a step-by-step plan in an ArchiMate diagram. The order is based on Sparx Enterprise Architect and can be done in a different order if desired.

SWOT analysis based on ArchiMate assessments. These are then related to the rest of the ArchiMate model in this repository.

List of available tools for use as an architecture repository. This is not an exhaustive list of architecture repository tools. Gartner produces a magic quadrant of these tools every year. It is strange that Sparx Enterprise Architect does not appear in these quadrants. For more details, see also https://www.gartner.com/reviews/market/enterprise-architecture-tools . In this document an elaboration has been chosen based on Sparx Enterprise Architect. However, a number of steps and the model elaboration correspond to the elaboration in this document.

Elements can appear multiple times in a repository. This is undesirable from a completeness, reuse and standardization perspective. Therefore, duplicates must be checked on a regular basis and these elements must be merged.

In the previous chapters we discussed the different dimensions of introducing an Architecture Repository. In this chapter we discuss a number of tools that support and simplify the introduction of an architecture repository. We are working on this based on Sparx Enterprise Architect, a modeling tool for various modeling languages. This makes it extremely suitable for setting up Sparx Enterprise Architect as an architecture repository. The elaborations of these tools have all been developed based on Sparx Enterprise Architect.

Description of the business architecture for a method with an architecture repository. A number of business processes and roles are being developed for this purpose. Because working with an architecture repository is a transition to a different working method within the architecture team, the business architecture is therefore an important part to work out in detail. The reason is that a successful enterprise architecture can determine the success or failure of the introduction of an architecture repository.

Data architecture of an architecture repository. This is relatively simple in design in this document and only involves a conceptual data model. However, the conceptual data model does provide an overview of relevant concepts within an architecture repository.

Architecture models for the elaboration of stakeholders, goals, needs and principles surrounding the introduction of an architecture repository within an architecture team.

Description of the aspects of the tooling when working with an architecture repository. On the one hand the required functionalities and on the other hand a list of various available tools.

Example of a logical architecture model for a registry or MDM module. Provides an example of how you can combine application functions, interfaces and services in ArchiMate to describe the desired requirements. If you look at an architecture repository from the perspective of master data, you can actually use a number of building blocks to describe functionalities, application services and interfaces in a generic way.

This section contains a number of matrices to easily see connections between the different views of the architecture of a repository. These matrices are based on ArchiMate concepts with which the relationships based on ArchiMate elements and connectors are presented in a two-dimensional matrix.

Collection of work instructions for the model manager regarding the design of the repository and the use of Sparx Enterprise Architect

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.

Example of a project structure based on the status of different submodels. What is characteristic of this is that the repository has a different layout for each phase. This approach indicates that the package structure does not have to be a limitation. When introducing an architecture repository, a discussion can arise about the package structure about what the correct format is. Keep the following suggestions as a starting point:

• The package layout can change for each part of the architecture repository
• The package structure can easily be changed if the working method is developed. changing insights
• Determining the layout is often managed by the model manager or custodian for the generic architecture components
• In work or project package structures, the modelers have more freedom in the design.
• For solution architectures, use a template as a starting point.
• Take into account the transfer of architectural concepts in a phasing and life cycle in the package layout.

The package structure should be aimed at the modelers who work with the architectural models. Users of these models must be supported in other ways, for example by navigation diagrams.

It seems strange to cover the database structure of a Sparx Enterprise Architect repository in a book about repositories. However, working with an architecture repository will also mean that the content must be accessed in a way that is not available in the formats already present in the tooling. That is why we discuss here the tables that contain the most essential data for accessing of the repository contents. Please note that the number of tables in a Sparx Enterprise Architect includes many more tables.

Overview in the form of a collection of the requirements of the various stakeholders within and outside the organization. Often elaborated on the basis of the motivation extension within ArchiMate. The summary can be done in the form of a list, a matrix or a number of graphical representations of the requirements. See also the elaboration of the solution architecture repository in a previous chapter for a number of examples.

This template is a package and diagram structure for an architecture document, for example a solution or project start architecture. A link has been made in the diagrams to a viewpoint elaboration so that modelers receive support with the viewpoint diagrams when developing the model. If desired, this package can be copied in EA to make it project specific. A document can then be generated from it. Use the IDEA AddOn in which you can perform a search and replace action in the package helper. This can easily be copied as a starting point for developing a new solution. The detailed example of such a template can be found as a resource in the existing example architecture repository.

Architecture model for an architecture repository approach. A number of generic architectural components have been developed in this model. On the one hand, this serves as an example for an architectural development. On the other hand, it can be expanded with organization-specific organizational components of the architecture. This makes it a starting point for an organization-wide architecture. This chapter has been elaborated on the basis of a number of architecture components that are relevant in a solution architecture. The same procedure was followed for the introduction of a method with an architecture repository. In fact, we apply an "eat your own dogfood" approach here.

In this document, after the solution for working with an architecture repository has been developed, a number of generic step-by-step plans are developed. These step-by-step plans provide a team with guidance on which activities need to be carried out to realize the transformation from a document-driven method to a repository-driven method. The step-by-step plans in this document consist of a number of generic activities for the introduction of an architecture repository. However, these steps can easily be extended in the specific context of your own organization. Elaboration is based on the order of developing the architecture and then a step-by-step plan for introducing the tooling of the architecture repository.