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

Definieren van eigen viewpoints voor ArchiMate

Voorbeeld uitwerking van ViewPoints in ArchiMate voor een architectuur document

Goal : Providing insight into the relationship between applications and parts of applications and which application functions they realize. Obliged Landscape of the relationship between different applications. Use the Application layer of ArchiMate for this and use two types of views: the logical application view (application functions) and the implementation view with application components.

Goal : Providing insight into the business processes and functions to be realized and the allocation to actors. Support by the underlying applications and technology. Obliged: Depending on the size, this can be combined with the application view and technology view in an overview view.

This diagram is a viewpoint for developing a conceptual data model. This viewpoint indicates which types of object types and connector types can be used when drawing up a conceptual data model. A few principles apply to the conceptual data model:

• Conceptual data model is for multiple stakeholders (including non-ICT professionals) and should be simple in design.
• Conceptual data model has been developed in ArchiMate (business layer).
• Only the stereotypical Business Object is used for the conceptual data model.
• The conceptual model has a hierarchical structure based on domains.
• If this reduces the complexity, multiple diagrams can be created for a domain.
• The conceptual model is related to the logical data model. See the hybrid meta data model for this.
• The conceptual model can be related to, for example, the other data management business functions within Example.

This diagram is a viewpoint for developing a logical data model. This viewpoint indicates which types of object types and connector types can be used when drawing up a logical data model. A few principles apply to the logical data model:

• Logical data model is for all stakeholders (ICT professionals and non-ICT professionals) and must be understood by all stakeholders after an explanation of the metamodel.
• Logical data model is developed in UML Class Modeling.
• For the logical data model, only the Class and Enumeration stereotypes are used.
• The logical model has a hierarchical structure based on abstract and concrete entities with a specialization connector.
• For a logical domain, multiple diagrams can be created if this reduces complexity.
• The logical model is related to the parent conceptual model and to the underlying physical data models. See the hybrid meta data model for this.

This diagram is a viewpoint for developing a physical data model for SQL Server RDBMS. This viewpoint indicates which tables, constraints and columns can be used when drawing up an RDBMS data model. A few principles apply to the RDBMS data model:

• Physical data model is for ICT (Database specialists).
• SQL DDL statements can be generated from the Physical data model.
• Naming conventions for the database platform (SQL Server/Oracle) serve as the basis for the Naming Conventions.

The associations show the database details for the referrer and primary keys.

Data qualities can be developed in a viewpoint using ArchiMate concepts. One deviation has been chosen here, namely the registration of issues surrounding data qualities for which a generic concept issue has been chosen in this metamodel.

Goal : Providing insight into the relationship between applications and parts of applications and which application functions they realize. Obliged Landscape of the relationship between different applications. Use the Application layer of ArchiMate for this and use two types of views: the logical application view (application functions) and the implementation view with application components.

Goal : Providing insight into links between the application and the patterns used from the reference architecture. System integration. Obliged : Only in the case that a link between applications must be established and this does not fit in the previously mentioned application view. An integration view can be realized by copying the chosen integration pattern from the reference architecture and then providing the implementation in application components, interfaces, etc.

This is a meta model for the data governance entities based on an Example specific ArchiMate data governance viewpoint. Including elements and the underlying relationships between the different elements. Please note that from the metadata perspective, this model will be expanded with detailed (meta) models for the other data management knowledge areas.

Goal: To provide insight into the principles related to elements in order to ultimately determine the right to exist of these elements. In addition, it provides insight into which solutions implement the same principles. Not required Use the motivation elements of Archimate for this. The principle element is included there. This can possibly be supplemented with requirements/constraints to indicate the implications. The principle can be linked to an Outcome, where the rationale in the association from principle to Outcome is described. In addition, if desired, the complete motivation can be elaborated in principles, drivers, etc.

The building block model consists of the generic entities building block and catalog. These form the basis of a reference architecture. Catalogs are groupings of building blocks within a specific domain. Multiple catalogs will be created that are related to each other and overlap within the visualizations. The advantage of the design of working with catalogs and building blocks is:

• Registers are created of reusable architectural components aimed at a specific field of work.
• The use of building blocks brings standardization and encourages reuse of architectural configurations.
• Building blocks makes the architecture and development process easier.
• Architectural product catalogs aimed at specific professional fields are being developed. This has a positive influence on the service provided to the rest of the organization.

The building blocks have three specializations, the definitions of which have been worked out in detail. These descriptions are elaborated in the paragraphs below. If relevant, additional information has been added to this elaboration, such as links to Togaf and examples of the implementation of these architectural concepts The model uses a pragmatic model with regard to the associations between Service and SBB. From ArchiMate perspective, the route from service is via ABB to SBB. This is characterized by the fact that the functional aspect is well embedded in the building block model. When publishing these models, a possibility is sought to generate reports and web pages that do not contain data relevant to the model for non-architecture stakeholders, which may mean that in a number of situations the ABBs do not have to be developed. Applying the direct association between service and SBB in the modeling does not meet the viewpoints.

Building blocks with an extension of a secondary scope around the requirements and characteristics that can be imposed on the various building blocks. In fact, the interpretation of the supply and demand sides for the building blocks. In the viewpoints development, a proposal has been developed as to which ArchiMate concepts are used for which building block specialization.

Goal : A high-level overview of the project or landscape at level 1. This shows in 1 diagram what the project or concern is about. The details come in the underlying views. Not required : Depending on the complexity and size, this view is necessary in a complex architecture.

Goal: Providing insight into the things that a project realizes. This view is essential for the PPM process, which aims to gain insight into which project is working on which component of the architecture at which time. Obliged Use the ArchiMate implementation layer for this. This project view is mandatory to indicate which project is working on which application or technology element. For example:

Goal: Providing insight into the underlying infrastructure of an application. Mainly use the building blocks from the reference architecture infrastructure. Obliged: The size obviously depends on the infrastructure component of the project and whether it can be sufficiently completed with standard building blocks.

This is a discussion board for the situation where a service on the application layer is elaborated in a number of ABB and SBB on the application layer. The ABB application is then completed by the functionality and implementation and ABB and SBB within an infrastructural service. In this image, an example has been developed based on the ArchiMate notation method in which the infrastructural building blocks support the ABB application via a service. This makes the model relatively extensive, but based on the ArchiMate viewpoint.

An important additional dimension when describing the xBB are the characteristics that are relevant to the communication between the provider of the xBB and the customer. This extra dimension focuses mainly on the characteristics that an xBB does or does not meet. These can be restrictions, rules or principles. The viewpoint uses three ArchiMate concepts from the motivation extension:

• Principle, often derived from national government reference architectures.
• Requirements, requirements and (non-functional) quality aspects.
• Restrictions are requirements that usually apply to the SBB, for example aimed at certain programming paradigms or languages.

For the associations between the motivation elements and the other elements, association, influence and realization can be used. With realization you can establish a positive relationship between the core elements and the motivation elements. Influence is then reserved for a negative influence from the core elements to the motivation elements. In this model, only the viewpoint building blocks within the application layer have been elaborated. Naturally, the same as described above applies to the viewpoint on the technical layer.

Primary concepts In the application layer, the three specializations of the building blocks can be relatively easily related to an ArchiMate element, namely:

• Service <-> Application_Service
• ABB <-> Application_Function, as already mentioned, another behavioral element can also be used here
• SBB <-> Application_Component

ArchiMate relationships can be defined between the elements:

• Service <-> ABB: Realization
• SBB <-> ABB: Assignment
• xBB <-> xBB: Aggregation

The last association, aggregation, is particularly important because it allows composite building blocks to be put together. In addition to the associations mentioned, several types of associations can be selected, such as dynamic associations. When developing the views within this viewpoint, you are free to apply these additional associations, provided they are elaborated in the general viewpoints already present. Secondary concepts In addition to the primary elements and associations, two elements and associations are relevant, but not in all architectural domains. These are:

• Data_Object, for example within the integration architecture, data objects are necessary for describing, for example, reusable message definitions within a building block.
• Application_Interface, also within the integration architecture, for the implementation of, for example, a web service, this concept is necessary as an additional ArchiMate element within the xBB modeling.

Primary concepts In the technical layer, the three specializations of the building blocks can be relatively easily related to an ArchiMate element, namely:

• Service <-> Technology_Service
• ABB <-> Technology_Function, as already mentioned, another behavioral element can also be used here
• SBB <-> System_Software, Node, Network, Device, Path and other technical active structure elements.

ArchiMate relationships can be defined between the elements:

• Service <-> ABB: Realization
• SBB <-> ABB: Assignment
• xBB <-> xBB: Aggregation

The last association, aggregation, is particularly important because it allows composite building blocks to be put together. In addition to the associations mentioned, several types of associations can be selected, such as dynamic associations. When developing the views within this viewpoint, you are free to apply these additional associations, provided they are elaborated in the general viewpoints already present. Secondary concepts In addition to the primary elements and associations, elements and associations are relevant, but not in all architectural domains. These are:

• Technology_Interface, also within the integration architecture, for the implementation of, for example, a web service, this concept is necessary as an additional ArchiMate element within the xBB modeling.

An introduction of an artefact is only relevant in certain sub-areas (geo). In other cases, a language with more detail will be used, such as UML class diagrams or XSD models. In the latter case, an association is made between the modeling language concepts via a trace.

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.

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.