A reference architecture is an abstract architecture in which a number of generic frameworks or building blocks are described. Organization-specific (domain and solution) architectures are drawn up based on reference architectures.

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.

The XXX-wide Enterprise Data Warehouse (EDW) is modeled according to the XXX-wide Business (Data) Object Model

ArchiMate is an enterprise architecture modeling language that is used at a higher level of abstraction and is combined with other modeling languages such as BPM and UML for desired detail.

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

The core of the TOGAF framework. A multi-phase, iterative approach to develop and use an Enterprise Architecture to shape and govern business transformation and implementation projects.

The architectural representation of assets in use, or planned, by the enterprise at particular points in time.

The architectural landscape is the architectural representation of architectural concepts that have been deployed within the operational enterprise at a certain point in time. The landscape likely exists at multiple levels of abstraction to meet different architectural objectives.

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.

A succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development.

Dashboards and reports come from the central data foundation (including the Enterprise Data Warehouse). Operational, out-of-the-box reports/dashboards on operational systems/devices may also be handled locally. If data from different sources needs to be combined, this must be done via the central data foundation.

A shorthand representation of "access to integrated information to support business process improvements" representing a desired state of an enterprise’s infrastructure specific to the business needs of the organization.

A (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions.

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.

A model describing the rationale for how an enterprise creates, delivers, and captures value.

Statement A collection of logically related building blocks of the same specialization (service, ABB or SBB). Description A catalog is a collection or register of building blocks of the same type. It is often aimed at a specific field of work, such as infrastructure, geo, integration. A catalog often contains building blocks of the same specialization, i.e. services, architecture or solution building blocks. However, the building blocks within this will often also be composed. A catalog can be seen as a showcase of generic and reusable architectural products. When these building blocks are used by a project, a number of architectural requirements, principles and requirements are met. The advantage for architecture is that these building blocks are reused. The advantage from a project perspective is that the architectural principles are met and that implementation is standardized and can probably be done faster. Due to changes in the environment (projects, LCM, innovations), the content of a catalog will regularly be adjusted, expanded or made more detailed elaborated. A catalog and the entities included in it thus become a "living" ecosystem. Initially, a supply-driven catalog model will be used. Becoming with others. Every domain architect creates a building block catalog for his domain. At a later stage this will be adapted to a demand-oriented elaboration, the so-called showcase model. architecture) concept can be included in a catalog.

Catalogs are categorized based on a scope. (e.g., infrastructure, integration, geo).

Catalogs within a scope have an owner.

Catalogs are described in a registry (managed in Sparx Enterprise Architect and published to HTML and PDF documents)

Catalogs are often hierarchical or layered in design. On the one hand due to the division into Service, ABB and SBB, and on the other hand due to the design with composite building blocks.

The management of needs of stakeholders of the Enterprise Architecture practice. It also manages the execution of communication between the practice and the stakeholders and the practice and the consumers of its services.

A description of the structure and interaction of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources.

Data or information management principles set frameworks for change in the organization, often within projects within the data roadmap. Elaborated in the selection of existing standards such as DMBoK, ArchiMate. The frameworks are developed on the basis of principles based on the principles within the enterprise architecture.

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.

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.

There are several modeling languages and frameworks available for setting up an enterprise. Think of Archimate, Togaf, UML and BPMN. The search is often for a subset of these languages. To this end, a weighed choice must be made.

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.

domain architecture describes an aspect or part of the enterprise or reference architecture. Aspects can be layers or aspects, but also domains within the architectural field or the organizational structure.

The highest level (typically) of description of an organization and typically covers all missions and functions. An enterprise will often span multiple organizations.

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.

Highly abstract description of the entire organization from an architectural perspective. Often based on an existing framework.

This is the established architecture of organization. It often includes the elaboration of the baseline architecture and sometimes also of the target architecture. It is important that the classification should be based on a consultation function. Architects use this as a register of the architecture for requirements inventories, but also for consulting the architectural landscapes and the frameworks within the architecture.

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.

Service to support business functions and/or processes in the supporting domains such as within PIOFACH

Short checklist for modeling enterprise architecture with ArchiMate

Developing and managing a framework and guidelines register, such as a list of data principles, standards and possibly data requirements related to the enterprise principles.

The Governance Log provides an overview of architecture governance activities across the enterprise.

With a more extensive enterprise architecture, it is necessary to create a hierarchy to categorize the different architectures. The hierarchy often consists of a number of diagrams that represent the enterprise architecture based on different classifications and navigation paths.

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.

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

It is considered a good practice to separate the elements from the diagrams in a large enterprise architecture. It is possible to separate the objects into the different subpackages of the enterprise architecture. It has been decided to do this in the root package of the enterprise architecture. In this example, a division has been made for subpackages per ArchiMate layer and/or element type. Various other layouts are possible. Determine here the classification that works well in the context of your own organization. Sorting the elements by element type in a comprehensive collection also works well for some organizations.

An articulation of the relationships between the primary entities that make up the enterprise, its partners, and stakeholders.

Description of the structure of the organization based on business roles and/or actors. Often based on an existing enterprise architecture framework.

In many architectures, building blocks are an important part of the introduction of standardization and reuse. Here too, a design in the enterprise architecture in the form of a number of collections of building blocks that an architect can use when developing solutions to ensure that a solution contributes to the path to the target architecture. This package will also have a classification in the form of subpackages and/or the use of diagrams for the building blocks present within the organization. Navigation and overview diagrams will often be used for this. See also the section on applying building blocks within an architecture.

A description of a real-world entity. Physical elements in an Enterprise Architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.

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 Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be used to accelerate the creation of new architectures for the enterprise.

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

A detailed, formal description of areas within an enterprise, used at the program or portfolio level to organize and align change activity.

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.

Viewing an enterprise, system, or building block in terms of services provided and consumed.

Solution architecture or project architecture describes a project that introduces a change in the enterprise. This architecture describes (a series of) the changes between the baseline and the target architecture.

The Solutions Landscape presents an architectural representation of the Projects and SBBs that support the Architectural Landscape and that are planned or implemented by the enterprise. They therefore form the connection between the Baseline and Target architecture.

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.

A summary formal description of the enterprise, providing an organizing framework for operational and change activity, and an executive-level, long-term view for direction setting.

If the project that delivers a solution is completed, the baseline architecture within the enterprise architecture will change, which is the final end result of a solution or project. Therefore, the concepts present in the models of the solution architecture will have to be elaborated in the baseline architecture after delivery. The models must be adapted accordingly to the new situation or the new baseline architecture. This must be carried out in a controlled process step in the architecture process in which the model manager or custion is often involved. This package is therefore a kind of conduit through which the solutions are placed, indicating that they can be integrated with the baseline architecture in the enterprise architecture packages.

As with the solution architectures, it is possible that sub-models developed in the personal packages become part of a solution architecture or the enterprise architecture. Here too, a folder to realize a controlled architectural process with which sub-architectures are transferred to the architectures with a different (determined) status under the responsibility of the model manager.

Package in which modellers or teams can create their own elaborations of sub-models, or sub-elaborations of a solution. Within these packages, the modelers have a personal package in which they are free to choose their own layout and develop elements and diagrams. Please note: it is important that agreements are made about the reuse of elements that are present. It is often not allowed to reuse elements present in these personal packages, for example in solution architectures and not at all in enterprise architecture models.

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

Modelleren van Archimate diagrammen in Enterprise Architect

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

Webvideo over autorisaties in Sparx Enterprise Architect

Webvideo over baselines in Sparx Enterprise Architect. Kan gebruikt worden als een eenvoudige werkwijze van release management

Setting the ribbons in Sparx Enterprise Architect

Webvideo on data mappings in Sparx Enterprise Architect

Scherm inrichten van EA net behulp van panels, hide, autohide en floating panels

Description of validating Archimate models and element in Enterprise Architect

Enterprise Architect webviewer op basis van Form Factory CMS

Many organisations are investigating the possibilities of Big Data solutions, for example the Dutch and German Electricity Transport System Operator TenneT. Introducing Big Data is new and traditional approaches are of limited use. Think about introducing data-lab functionalities, innovative and agile approaches, new technologies like NoSql or Hadoop. How are you going to support these activities in an organisation as an architect and how can Enterprise Architect support you in adding architectural value. In this session we will discuss a reference architecture for the TenneT Data Platforms, modelling techniques, architectural patterns and agile approaches all supported by the use of Enterprise Architect. You will see examples of big data patterns, solutions and templates based on ArchiMate.

How to build an enterprise architect based on ArchiMate and Enterprise Architect

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

Sinds medio mei 2024 is versie 17 van Sparx Enterprise Architect beschikbaar. Op dit moment van schrijven, juli 2024, nog als beta versie. In versie 17 zitten een aantal interessante uitbreidingen voor de enterprise architect.

Het metamodel van ArchiMate uitbreiden in Enterprise Architect

Uitleg van gebruik keuzelijsten in Enterprise Architect

Lijsten definieren in Sparx Enterprise Architect

Whitepaper with the list of permissions in Sparx Enterprise Architect for administrators and modellers

Report fragments in Sparx Enterprise Architect

Demonstration of ModelView and Searches of Sparx Enterprise Architect

Inzet Enterprise Architect als repository

Webvideo over het inrichten van enterprise achitect voor ArchiMate

Uitleg van gebruik tagged values in Enterprise Architect

Aanpassen van Enterprise Architect voor een specifiek metamodel voor de organisatie

Helpers voor afgeleide relaties en nesting in ArchiMate en Sparx Enterprise Architect

Uitgebreide ArchiMate modelleertechnieken met Enteprise Architect van Sparx

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.

Videokanaal met trainingvideo's over het modelleren van architecuur met Sparx Enterprise Architect.

Introductiecursus modelleren met Sparx Enterprise Architect op basis van webvideos

Videokanaal voor het WPP van Sparx Enterprise Architect

Webvideo over connectoren op diagrammen in Sparx Enterprise Architect

Description of the components and functionalities present within Enterprise Architect related to the hierarchy of application functions. The functions are in detail described in the previous chapter.

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.

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.

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.

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.

This is the established architecture of organization. It often includes the elaboration of the baseline architecture and sometimes also of the target architecture. It is important that the classification should be based on a consultation function. Architects use this as a register of the architecture for requirements inventories, but also for consulting the architectural landscapes and the frameworks within the architecture.

With a more extensive enterprise architecture, it is necessary to create a hierarchy to categorize the different architectures. The hierarchy often consists of a number of diagrams that represent the enterprise architecture based on different classifications and navigation paths.

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

It is considered a good practice to separate the elements from the diagrams in a large enterprise architecture. It is possible to separate the objects into the different subpackages of the enterprise architecture. It has been decided to do this in the root package of the enterprise architecture. In this example, a division has been made for subpackages per ArchiMate layer and/or element type. Various other layouts are possible. Determine here the classification that works well in the context of your own organization. Sorting the elements by element type in a comprehensive collection also works well for some organizations.

In many architectures, building blocks are an important part of the introduction of standardization and reuse. Here too, a design in the enterprise architecture in the form of a number of collections of building blocks that an architect can use when developing solutions to ensure that a solution contributes to the path to the target architecture. This package will also have a classification in the form of subpackages and/or the use of diagrams for the building blocks present within the organization. Navigation and overview diagrams will often be used for this. See also the section on applying building blocks within an architecture.

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.

If the project that delivers a solution is completed, the baseline architecture within the enterprise architecture will change, which is the final end result of a solution or project. Therefore, the concepts present in the models of the solution architecture will have to be elaborated in the baseline architecture after delivery. The models must be adapted accordingly to the new situation or the new baseline architecture. This must be carried out in a controlled process step in the architecture process in which the model manager or custion is often involved. This package is therefore a kind of conduit through which the solutions are placed, indicating that they can be integrated with the baseline architecture in the enterprise architecture packages.

As with the solution architectures, it is possible that sub-models developed in the personal packages become part of a solution architecture or the enterprise architecture. Here too, a folder to realize a controlled architectural process with which sub-architectures are transferred to the architectures with a different (determined) status under the responsibility of the model manager.

Package in which modellers or teams can create their own elaborations of sub-models, or sub-elaborations of a solution. Within these packages, the modelers have a personal package in which they are free to choose their own layout and develop elements and diagrams. Please note: it is important that agreements are made about the reuse of elements that are present. It is often not allowed to reuse elements present in these personal packages, for example in solution architectures and not at all in enterprise architecture models.