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.

Versie 1.0
Creatie datum 16-09-2021

Packages

  • 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.
    • < li>Standardization.
    • 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.
    • li>
    • 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.
  • 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.
    • < li>Secondary elements (orange border) are elements that may 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.

Copyright © Interactory Template by ColorLib

Ingelogd als 1 | NL