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

Enterprise Architect webviewer op basis van Form Factory CMS

Definieren van eigen viewpoints voor ArchiMate

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.

Lijsten definieren in Sparx Enterprise Architect

Matrix functionality added

Demonstration of ModelView and Searches of Sparx Enterprise Architect

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.

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.

This overview contains an extensive list of possible (partial) modeling languages. Use multiple languages sparingly. Some of ArchiMate is probably necessary. See also the examples in the documentation of modeling languages via the websites that exist around these modeling languages. The Model Wizard within EA is also suitable for further explanation. This is not an exhaustive list and may be developed differently in the context of specific organizations. This diagram provides a detailed description of the most important sub-models and diagram types to provide an idea of the scope and level of detail within the modeling languages.

Alberto wants to professionalize the job application procedure. Every applicant who applies for a job at Alberto is invited for an interview with a branch manager and an HR employee. After the interview, it is decided whether the person will be hired or not. Alberto wants a positive image, so every application is supported by correspondence about the progress. This is done by the HR employee

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.

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

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.

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.

The new application process is introduced in two phases Adjusting the process and training the employees involved in the job interviews Adapting the communication and introducing the new communication software

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

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.

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.

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:

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.

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.

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.

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.