Exchange of (partial) models based on the ArchiMate exchange standard so that exchange with other (ArchiMate) modeling tools is possible.

Standardization of architectural models simplifies the creation, use and evaluation of these architectures. The use of templates makes this standardization possible. Introducing and maintaining templates is therefore a work process.

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.

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.

It is possible, preferably, to activate and deactivate functionalities per authorization role. Use should be simple, especially for roles that occasionally use the architecture repository.

The baseline is an architecture that describes the current architecture of the system. It is often drawn up together with the target architecture, which is the desired architecture. In this way it is possible to gain insight into the differences between the desired and current architecture.

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

There is a clear (technical) decoupling point for integration between source (supplying party) and the D&A environment (receiving party). Quality of the data supplied (completeness, accuracy, timeliness) is the responsibility of the source. Integration is standardized and follows integration architecture principles.

Indicates which conceptual data entities occur within a domain. This is modeled with the specialization or aggregation connector between a domain and a data entity. As much as possible, a conceptual data entity is prevented from falling under multiple domains A definition is given for each data entity. If desired, a list of synonyms is provided below the attributes. A domain data entity has all the characteristics of the conceptual data entity.

Possibility to correct the duplications made by the modelers before the automated deduplication is carried out.

Validation of data based on the data entered into the system and possibly on the existing data stored in the master data registration. It is essential that all data received from the acquisition/registration service is processed in these functions before being stored in the data registry

After choosing the modeling languages, it is possible to impose further restrictions on the modeling forms. Modeling languages are often so extensive that not all concepts are relevant to the organization. This can simplify use. That is why many organizations opt for further restrictions within the languages. This is done by introducing ViewPoints and Perspectives.

Depending on the domain classification of the organization, a domain architect will be ultimately responsible for the architectural development of the relevant domain.

Domain architects are responsible for the established architecture based on a classification of domains. These can be domains based on domains within the organization or domains within the architectural structuring.

duplicate is a data element in the repository that is considered a duplicate based on a number of properties. Duplicates can occur with concepts that can be divided into elements and relationships. Elements Elements are actually the blocks on a diagram with certain properties within a modeling language and an appearance. Duplications can be considered the same based on these characteristics:

• Name of the element (possibly based on missing punctuation marks)
• Version number
• Modelling language and Object type within the language. Also referred to as a stereotype.

Relationships Relationships or connectors are actually the connecting lines on a diagram with certain properties within a modeling language and an appearance. Duplicate relationships can be considered the same based on these characteristics:

• Name of the relationship or cardinalities of the start and end points of the connectors
• Version number
• Modelling language and Object type within the language. Also referred to as stereotype

Move duplicates to the Trash, then create a baseline, then delete the elements from the Trash. Due to the baseline, they are still present (in XML format) but no longer visible in the repository.

Role ultimately responsible for the overall architecture for the entire organization. So has both a global and an abstract scope on the architecture and the use of the architecture repository.

Developing and managing a framework and guidelines register, such as a list of data principles, standards and possibly data requirements related to the enterprise principles.

Data is accessed as close as possible to the original source. The leading source(s) are determined per business data object.

You regularly see in architecture teams that a number of architects do not find it necessary to participate in an architecture repository initiative. This is an anti-pattern and will prevent acceptance of a repository-based method at some point. Try to prevent this as much as possible.

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.

Exchange of (partial) models based on the BPMN exchange standard so that exchange with other (BPMN) modeling tools is possible.

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.

Because working with an architecture repository is based on standardization and reuse, this requires discipline from the modeling team in terms of modeling conventions and collaboration. This is only possible if the team works together and views the repository as a joint product.

Responsible for the use and deployment of the models in the architecture repository. Has a coordinating and controlling task for all modeling roles involved in the architecture. Monitors the consistency of the architecture repository and provides modellers with information and training on the use of the architecture repository.

The content actually becomes the collective architectural product of the community. That is why quality requirements are imposed on this joint model. To this end, this responsibility must be known to everyone and there must be a role that monitors this responsibility.

The modeling community is responsible for making a number of working agreements, such as: ul> The modeling community does this by:

• Ensuring the design and conventions for the repository
• Developing architectural and modeling conventions
• Provides training regarding the repository design and the modeling method
• Review developments
• Stimulate communication and interaction within the community

Inside the modeling community should jointly introduce the above-mentioned working agreements. Depending on the structure and culture of the organization, different scenarios can be chosen to achieve this Intervision session The modeling community jointly determines what the conventions surrounding modeling are. Within intervision sessions, all participants can submit topics, examples and modeling problems that are discussed and based on discussion, a joint decision is made about the method to be followed and, if desired, the adapted modeling conventions Characteristic of the intervision session are

• On a regular basis a session organized for all modellers
• In these sessions the various participants bring in questions, solutions and suggestions
• Works well in small teams

Model manager Another scenario is that a model manager role plays a pioneering role in introducing a modeling community. The model manager is more active and the modeling community is more passive. Characteristics of the model manager are:

• Model manager determines bottlenecks and chooses a solution approach
• Sometimes a model core team is deployed for support
• Model manager coö ordinates describing the decisions in the repository or help pages
• Works well with large teams

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.

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.

All data and information has an owner. - Rationale Structured and explicit ownership is necessary to be able to make decisions about the use and management of data and information and to set priorities. - Implication XXX-wide frameworks (policies, guidelines and standards) are necessary to deal adequately with data and information. A division of the XXX data and information landscape with recognizable boundaries is necessary to clearly organize ownership and responsibilities for data and information. Be clear about the roles (owner, user, editor) and associated tasks and authorities. Taking ownership and accepting someone else.

Parts of specific architectures such as project or domain architectures may have a generic character, making reuse desirable. This means that parts of these project architectures will propagate to a more generic architecture such as a reference architecture or architecture building block. Demotion from generic to specific is also possible.

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.

In addition to drawing up architectures, there are also roles that review and approve the architecture artifacts. For example, by testing for quality, feasibility, but also on the application of the modeling conventions and the organizational metamodel.

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

Role within the organization responsible for supporting knowledge workers in the areas of communication and task management.

Statement Services are the description of a combination of functionalities and services between provider(s) and customer(s). Description Services are a form of encapsulation of the functionality and implementation of a composition of building blocks. Services, just like ABB and SBB, are used as a means of communication between provider and customer to indicate which service will be provided by the provider to the customer. Services can also be defined internally within the organization (also in a provider and customer context), for example infrastructural services for an application service or customer. A service can be a composition of a building block that implements functionality within the ICT landscape. In addition, a service can consist of providing more structured (ICT) work processes in relation to the above-mentioned IT landscapes, for example a service desk. In this document we have limited the scope to that of the ICT architecture, ICT work processes are not elaborated here but are certainly relevant within other parts of the organization (service management). This building block model can be applied in several ways if desired and not only in the IT field. Here we limit ourselves to ICT architecture. Services can be composed of underlying services. In addition, they can be composed of one or more architectural building blocks. These compositions can create constellations of building blocks that ensure standardization of reusable applied services. Consider a standard application server with services (such as backup and restore) and ABB (for example relational storage) Services are related to requirements, constraints and principles. This is preferably elaborated to indicate which needs are met from a customer perspective and which are not. There is a lot of confusion around the term service. To avoid a discussion about the definition with each composition of persons, the term service is chosen, which is based on the characteristics below. In addition, a list of synonyms has been formulated that refer to the same characteristics below. Characteristics

• A repeatable activity or behavior that is requested to be performed.
• A service offers one or more solutions to ICT needs that are understandable to the customer.
• Combination of an implementation of a functionality in one or more ABBs.
• Possibly in combination with one or more ICT work processes as a service.
• Services are offered to customers by providers.
• Services have a commercial and a financial (cost) aspect.
• Services have conditions for use and/or implementation.

Providing services to the rest of the organization from a specific part of the organization. Here it becomes possible to ask questions and report problems when carrying out daily activities and support from ICT.

Standards Information Base.

For (master) data and information there is only 'one version of the truth'. The leading source must be identified for each root and reference entry. As much master and reference data as possible must be centrally recorded in TABS and distributed from there to user systems...

Depending on the project and domain classification of the organization, a project or solution architect will be responsible for the architectural development of one or more projects that achieve a conversion from the baseline to the target architecture.

Standardization becomes more possible by using various repository standards such as the use of templates, model validation, and limiting use based on metamodels. In fact, a repository offers more opportunities to limit the modeler's freedoms.

The Standards Information Base (SIB) establishes the standards that new architectures must meet, which may include generic architectural languages and frameworks, industry standards, selected vendor products and services, or shared services already implemented within the organization.

Creating models and views is a core functionality of an architecture repository. This should therefore be supported as much as possible with intuitive functionalities.

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.

Due to various functionalities and the possibility of reusing existing (partial) models, an agile approach in a repository is easily possible.

Table includes all elements present in the repository. Please note that this determines how an element looks in diagrams and which compartments become visible in the diagrams based on the object_type and stereotype.

The target is an architecture that describes the desired and future architecture of the system. It is often drawn up together with the baseline architecture, which is the desired architecture. In this way it is possible to gain insight into the differences between the desired and current architecture.

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.

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.

Ensure adequate training of those involved so that they have knowledge of the chosen modeling methods, the possibilities of the architecture repository and the functionalities in the chosen tool.

Transfer of files that are manually processed and possibly modified before being deployed to the data store

Templates make it possible for modelers to use standardized models, and the amount of work required to draw up models is also reduced, so it is a form of reuse.

Exchange of (partial) models based on the UML exchange standard so that exchange with other (UML) modeling tools is possible.

Many organisations are investigating the possibilities of Big Data solutions, for example the Dutch and German Electricity Transport System Operator TenneT. Introducing Big Data is new and traditional approaches are of limited use. Think about introducing data-lab functionalities, innovative and agile approaches, new technologies like NoSql or Hadoop. How are you going to support these activities in an organisation as an architect and how can Enterprise Architect support you in adding architectural value. In this session we will discuss a reference architecture for the TenneT Data Platforms, modelling techniques, architectural patterns and agile approaches all supported by the use of Enterprise Architect. You will see examples of big data patterns, solutions and templates based on ArchiMate.

Visibility of associations in ArchiMate Diagrams

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.

When developing and managing the architecture in the models and documents, keeping the repository consistent is a challenge within a repository. With a document-driven approach, keeping things consistent is actually impossible. When working with an architecture repository and using tooling, opportunities arise to automate or largely support, especially iterative, tasks. There are important advantages to be gained for architectural teams. It is therefore recommended that careful consideration be given to which activities can be automated and what requirements there are for the modeling team.

An ABB can be composed of one or more SBB. In addition, it is possible that an ABB can be completed by one of several SBB, so there is a choice. This is shown in this example. It is important to provide insight into the differences between the different SBB. See the extensive example diagram for this.

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.

One of the goals of Alberto is corporate social responsible For the job application process this means that an job applicant is content about the process and performance of the staff involved in the Job application processes This means that the employees involved have knowledge and are able to do the job application activities This means that the involved employees have sufficient knowledge about how to act in the communication with applicants

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.

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.

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.

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.

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.