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.

Architectural models can always be more beautiful and detailed. This is often unnecessary and even undesirable. These overmodeled architectures must also be maintained and managed at a later stage. In addition, a detailed model is neither relevant nor clear for many stakeholders.

The Architecture requirements and requirements collection provides an overview of all authorized architecture requirements and requirements that have been agreed with the stakeholders within the architecture board.

Team that will use the architecture tool in the architecture processes. They are therefore not only stakeholders but also play an important role in the processes.

A representation of holistic, multi-dimensional business views of: capabilities, end-to-end value delivery, information, and organizational structure; and the relationships among these business views and strategies, products, policies, initiatives, and stakeholders.

Elaborated Conceptual data model in a (meta data) register in a representation accessible to stakeholders.

Informing the relevant stakeholders about the adjustments in the content of the production package in the established new architectural concepts.

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.

An interest in a system relevant to one or more of its stakeholders.

An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders.

XXX justifies the handling of data and information and is demonstrably in control - Rational Supervisors and stakeholders want certainty about the quality and careful handling of data and information. - Implication Data and information is auditable in design, existence and operation, whereby the measures taken are appropriate to the value that data and information represents.

We have interests and concerns surrounding the use of an architecture repository.

This is a process that consists of a number of sub-steps to organize the chosen tool in such a way that modelers can easily work in it and other stakeholders can easily find the material relevant to them.

Generic functionalities that are often relevant to all stakeholders for the architecture repository,

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

Completeness is important to give the various stakeholders a complete picture of the (sub)architecture or the solution. This is only possible by creating explanatory texts for diagrams and the elements in these diagrams.

Data and information are handled with care, taking into account the applicable values, standards and laws and regulations - Rationale XXX is at the heart of society. The stakeholders expect XXX to comply with all relevant regulations and handle all data and information from all involved with care. Careful use of this can positively influence the image of XXX. - Implication XXX has laid down the rules for handling data and information in the XXX code of conduct for all employees. Relevant legislation and regulations (including those regarding privacy and competition) are identified and included in XXX standards frameworks and policies.

With project architectures in particular, the inventory of the baseline, impact of the project, the requirements of the various stakeholders and the solution directions to be selected is an important work process.

I regard legislators and compliance institutions as invisible stakeholders. However, they set frameworks for the architectures within the organization. This makes them highly relevant stakeholders. Consider, for example, the GDPR.

Drawing up architectures is usually done by several different stakeholders. In addition, work in architecture is not always project-based. This can cause the architectural model to become inconsistent. Reason to prevent these inconsistencies by monitoring the architectural model in a process.

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.

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

Especially in large organizations, various parts of the architectural model will already have been developed in other tools. Partly by the architects themselves, partly by other stakeholders. Agreements must be made about the use of references or integration tools.

The content of an architecture repository must be made available to the various stakeholders in multiple forms.

Generation of (part) architectures in the form of documents. Consider project and reference architectures for stakeholders who do not have access to the architecture repository content.

Subarchitectures must be able to be delivered in a format that allows stakeholders without access to the repository to easily familiarize themselves with the models. This includes Word and PDF documents that are compiled from the Architecture Repository,

Partial models are accessed via HTML pages. This makes it possible to use partial models in an attractive format with easy navigation for stakeholders with little knowledge about modeling tools.

Not every stakeholder can and wants access to the models via complex modeling tools. There is often a need for simple access with an intuitive navigation structure to the (partial) models.

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.

A specialization of an inventory within the architecture is drawing up the requirements for the target architecture for the various stakeholders within and outside the organization within which the architecture is drawn up.

Within architecture repositories, multiple views of an architecture can easily be created. These views can be made specific to different stakeholders in the review process. In addition, there are functionalities available in a repository to support the review process. This makes the review process easier for both the modelers and the reviewers

Established architectures must be reviewed by a number of stakeholders for feasibility, content and elaboration of the architecture.

An individual, team, organization, or class thereof, having an interest in a system.

More and more organizations are opting for standard solutions for the design of the various architectures. In this case, the supplier of these solutions involved is a stakeholder from the perspective of supplying certain solutions and a customer of the architectural artifacts.

Particularly in situations where the different stakeholders do not physically work in the same space, working with collaboration functionalities such as chat and discussion or review functions is desirable. But this can also have added value in other situations.

Architectures are an important input for (ICT) projects and therefore relevant for many stakeholders. Approval of these architectures by, for example, an architecture board or a Lead Architect is therefore necessary.

Models drawn up must be reviewed for applicability and feasibility for the organization. This requires a review by various stakeholders. This must be adequately supported.

Architecture Repositories quickly become extensive (many elements, diagrams and connections). That is why there must be functionalities that make it possible to easily find relevant sub-models. This is relevant for all stakeholders.

Many stakeholders are involved in architectures, these stakeholders must be consulted whether they agree with the elaboration within the architecture. A (standardized) review process is necessary for this.

Data and information may be shared within legal and policy frameworks - Rationale Sharing unless, both internally and externally. XXX is at the center of society. The external stakeholders expect transparency and openness and internal transparency contributes to improving services. - Implication The confidentiality classification determines with whom and how information may be shared with others. The person who edits the information is responsible for complying with the policy on handling the information.

This checklist is used to ensure that the models in the repository are easy to find for different stakeholders and that they are given a logical order in the diagrams to get an idea of the solution or the established architectures.

A representation of an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end user.

Dama biedt een aantal mooie onderdelen doe goed ingezet kunnen worden voor de uitwerking van architectuur. Dit document geeft een voorbeeld. Dit document geeft een uitwerking van een workshop om data kwaliteiten met een groep stakeholders te inventariseren

Image library for visualization in EA

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.

Sub model for the data governance model containing the roles that stakeholders fulfill around a data domain or a data entity within a conceptual data 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.

Alberto wants his ice cream parlors to be well known in terms of product quality but also from a CSR perspective There are three rules of thumb for this:

• Satisfied customers
• Happy employees
• Satisfied legislators and enforcers

Alberto would like to identify a number of stakeholders of the latter

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.

Summary of a number of architectural principles relevant when working with a repository-driven approach. Please note this diagram is a simplified representation. A relationship has also been established in the repository, for example with the stakeholders and the goals. However, these are not shown in this part but can be found within the elaboration of the matrices for the motivation of using an architecture repository. Please see the sample repository where you can find all the relationships between architectural elements.

A number of generically named stakeholders. Stakeholders have concerns and requirements for the use of an architecture repository. However, they do not necessarily have to be a participant in the project that introduces the architecture repository. Please note that this is often organization specific in nature. In this model only a number of generic stakeholders are named. Therefore, feel free to adapt this model to your own context so that it corresponds to the stakeholders relevant within your organization.

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.

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

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.

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.