Search for content

Aids for an Architecture Repository

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.

Repository package

Alberto Enteprise Architecture Cases

Repository package

Alternatieven bij {project}

Repository package

Alternatives to Example

Repository package

Analytics

Repository package

Analytics

Repository package

App Services

Repository package

Applicatie architectuur {project}

Repository package

Application architecture Example

Repository package

Application layer

Repository package

Application_Component

Repository package

Application_Event

Repository package

Application_Function

Repository package

Application_Interface

Repository package

Application_Process

Repository package

Application_Service

Repository package

Applying architecture building blocks

Introduction Applying building blocks describes the design and definition of building blocks. Building blocks are introduced to an organization from the perspective of:

Reuse.
Decoupling
Generalization and specialization.
Interaction between providers and consumers of information provision. concepts (currently applications and infrastructure, but this must also be applicable to business architecture).
Specification of costs and revenues.
Improve (accelerate) services.
Information security.

This document consists of the following parts:

Model: describes the definition, characteristics and relationships of the concept building block and the associated specializations
ArchiMate viewpoints: development of the viewpoints for the building blocks. These viewpoints are composed of a limited set of ArchiMate elements and associations.
Examples of elaboration of the various building blocks within the ArchiMate viewpoints defined above
Sparx implementation, how this is done is implemented in Sparx and how it is communicated/published to the various stakeholders.

Repository package

ArchiMate viewpoints

Here the viewpoints are described for solution architectures in particular, based on a different approach than the method with Viewpoints as described in the ArchiMate documentation. This is an elaboration of an organization that has determined a number of viewpoints for its own context. It is important that the viewpoints are related to each other. Within the viewpoints we work with:

Primary elements (green border), these are elements that in principle must be elaborated in these diagrams.

be used in these diagrams

It is important that we keep the number of concepts relatively limited and that the different viewpoints are related to the project package template for project or solution architectures.

Repository package

ArchiMate Viewpoints for building blocks

This section proposes a number of ArchiMate viewpoints for modeling the various building blocks and their mutual relationships. In the diagrams, the viewpoints are only elaborated on the basis of the elements and the relevant mutual associations. A description of the concepts themselves is not provided. We adopt definitions and possible associations as defined within the ArchiMate modeling language itself. ArchiMate has three layers in the core model, namely Business, Application and Technology layer. xBB can be applied in the three layers mentioned above. However, because the perspective in this document for the xBB is mainly on application and infrastructure, the viewpoints have only been developed for these two layers. For the ABB, ArchiMate uses the Behavior column. Since ArchiMate 3, there have been multiple elements within this column. When elaborating in the viewpoints, only the Application_Function and Technology_Function are used. If another concept, for example an Application_Process or Technology_Process, is relevant in an elaboration, this can of course also be applied. For the SBB, ArchiMate uses the Active Structure column. Many different concepts are available, especially within the technology layer. Only the System_Software is used for the implementation in the viewpoints. If another concept is relevant for an elaboration in this dimension, it can of course also be applied.

Repository package

Architecture principles

Overview of the architectural principles and possible constraints. With extensive collections of principles, a hierarchy can be introduced here, for example based on basic and derived principles. In the case of extensive collections, the principles are often visually represented in the form of a number of diagrams.

Repository package

Architecture Repository

Repository package

Architecture Repository Navigation

Repository package

Architecture ViewPoints

Description of the organization's architectural viewpoints. See the architecture viewpoints section in this chapter.

Repository package

Artifact

Repository package

Azure Ecosystem

Repository package

Azure Icons and Images

Repository package

Azure Stack

Repository package

Azure VMWare Solution

Repository package

Bedrijfsarchitectuur {project}

Repository package

Bert Dingemans

Example of a personal package from a modeller.

Repository package

Blockchain

Repository package

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

Repository package

Business Architecture Example

Repository package

Business Layer

Repository package

Business Layer Target

Repository package

Business_Object

Repository package

Business_Role

Repository package

Business_Service

Repository package

CnE_Enterprise

Repository package

CnE_GeneralSymbols

Repository package

CnE_Intune

Repository package

CnE_System_Center

Repository package

Compute

Repository package

Compute

Repository package

Container

Repository package

Contract

Repository package

Core

Repository package

Data Architecture

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.

Repository package

Data architecture Example

Repository package

Data architectuur {project}

Repository package

Data_Object

Repository package

Databases

Repository package

Databases

Repository package

Demo Case Solution architecture {project}

Dit sjabloon is een package en diagram structuur voor een architectuurdocument, bijvoorbeeld een solution - of project start architectuur. Hierbij is in de diagrammen een koppeling gemaakt naar een viewpoint uitwerking zodat modelleurs ondersteuning krijgen bij het uitwerken van het model. Desgewenst kan dit package gekopieerd worden in EA om het projectspecifiek te maken. Vervolgens kan er een document van gegenereerd worden. Maak daarbij gebruik van de IDEA AddOn waarin je in de package helper een zoek en vervang actie kunt uitvoeren

Repository package

Descriptive architecture

The descriptive architecture as the name suggests describes the architecture. This is based on the target architecture and the baseline architecture. Within this package you often see an elaboration of the various dimensions of the organization based on subpackages to structure the descriptive architecture according to domain, layers and other organization-specific divisions. In this book a division based on a layer division for the organization

Repository package

Device

Repository package

DevOps

Repository package

DevOps

Repository package

Duplicates

Repository package

Enterprise Architecture

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.

Repository package

Examples of building blocks

These examples elaborate on a number of aspects of modeling based on building blocks. Consider this example without thinking about the design of the catalogs and the granularity of the building blocks. In addition, only an explanation is given for the diagrams, not for the concepts elaborated in them.

Repository package

Extra

Repository package

Fysiek data model (Sparx)

Repository package

General

Repository package

General

Repository package

Goals and needs

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

Repository package

Hierarchy

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.

Repository package

Identity

Repository package

Identity

Repository package

Implementation

Repository package

Implementation & Migration

Repository package

Information system architecture

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.

Repository package

Integratie architectuur {project}

Repository package

Integration

Repository package

Integration

Repository package

Integration architecture Example

Repository package

Internet of Things

Repository package

Intune

Repository package

Intune

Repository package

IoT

Repository package

IoT

Repository package

Job application solution

Repository package

Location

Repository package

Logical Application model based on Master data

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.

Repository package

Management + Governance

Repository package

Management and Governance

Repository package

Matrices

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.

Repository package

Media

Repository package

Metamodel

Metamodel consists of a list of various modeling languages relevant to architecture, including a number of submodels and languages. On this basis, the organization can make a selection of the architectural languages and sublanguages relevant to them. In the development of the tools, such a metamodel based on simplified viewpoints in ArchiMate is developed as an example.

Repository package

Migrate

Repository package

Migrate

Repository package

Mixed Reality

Repository package

Model manager work instructions

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

Repository package

Modeling convention for data architecture

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.

Repository package

Monitor

Repository package

Motivatie Waarom {project}

Repository package

Motivation

Repository package

Motivation

Repository package

Motivation Why Example

Repository package

Networking

Repository package

Networking

Repository package

New Icons

Repository package

Node

Repository package

Object model Building blocks

The object model describes the building block concept as defined within the architectural process. Building blocks are communicative concepts between architects themselves and between architecture and the various stakeholders such as developers and administrators. In addition, also internal services and possibly external stakeholders such as suppliers or chain partners. The model consists of a limited set of concepts with mutual relationships. This model has been developed into an ArchiMate business object diagram. The concepts in the objects and definition diagram are then worked out in detail and thus describe the frameworks of the building blocks.

Repository package

Objecten binnen solution {project}

Repository package

Objects

Listing of all objects within the architecture sorted by type and name.

Repository package

Objects

Repository package

Objects

Repository package

Objects at Viewpoints

Repository package

Objects enterprise architecture

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.

Repository package

Objects ViewPoints building blocks

Repository package

Objects within solution Example

Repository package

Objects work instruction model manager

Repository package

Onder handen werk

Repository package

Other

Repository package

Other

Repository package

Other

Repository package

Overview of building blocks

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.

Repository package

Overview of landscapes

Overview of the architectural landscapes that have been developed. Often based on multiple diagrams and classified on the basis of the layers in the core model of ArchiMate, if desired, further divided into domains in an organization or architecture. In this document, the overview of the landscapes is classified and classified. This can be done on the basis of packages and one or more diagrams within them, but the use of a naming convention for the diagrams is also an adequate method. It is necessary that the architects can easily find the concepts within the established architecture. On the one hand in the package structure and on the other hand by using search and sorting functionalities.

Repository package

Package structure

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.

Repository package

Path

Repository package

Physical data model Sparx

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.

Repository package

Physical layer

Repository package

Prescriptive architecture

The framework-setting architecture is of great importance for steering the change in an organization to transform from the baseline architecture to the target architecture. Setting frameworks is often developed on the basis of architectural principles or nowadays also called binding architecture agreements. You can also find the description of the viewpoints because they can also be considered as setting the framework.

Repository package

Principle

Repository package

Project and solution Example

Repository package

Project en solution {project}

Repository package

Publicatie

Repository package

Requirements

Repository package

Requirements overview

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.

Repository package

Resources

Repository package

Reusable Objects

Repository package

Security

Repository package

Security

Repository package

Sipoc

SIPOC is a simple modeling method for modeling business processes, objects and roles. A number of examples have been given. Copy one of the diagrams and adapt it to the new SIPOCs for a company-specific elaboration.

Repository package

Solution architecture example

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.

Repository package

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

Repository package

Solution architectures

These packages develop the solutions that currently implement the change of the organization from the baseline to the target architecture. Depending on the size of the organization, you will find several descriptions of solution architectures here.

Repository package

Step-by-step plans

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.

Repository package

Storage

Repository package

Storage

Repository package

Strategy

Repository package

Submodel from project

Repository package

System_Software

Repository package

TargetArchitecture

Repository package

Technical layer

Repository package

Technologie architectuur {project}

Repository package

Technology architecture Example

Repository package

Technology_Interface

Repository package

Technology_Service

Repository package

Time registration solution

Repository package

To enterprise architecture

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.

Repository package

TOGAF & ArchiMate

Repository package

Towards Solution/Enterprise Architecture

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.

Repository package

VM

Repository package

Web

Repository package

Web

Repository package

Workareas and projects

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.

Repository package