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.

Statement An architectural building block is the logical definition of a functionality Description The abbreviation ABB is used for an architectural building block. An architecture building block describes the functionalities that are offered to a higher-level entity. An ABB describes WHAT is needed, without writing to a specific solution. The higher-level entity can be a service or a composite ABB. An ABB can be composed of one or more SBB. These SBB are the implementation of the functionality. In other words, the SBB realizes the ABB. Features

• Description of a functionality
• Description of the behavior of information provision elements without features of physical implementation
• ABB is logical, without technical specification or brand names
• Infrastructural and application layers are the most important application area in the current phase of this model.
• Architecture building blocks are related to qualities, constraints and principles.
• This is the framework within which, for example, a product manager can select a product.
• When a product is at the end of the LCM, the frameworks in the ABB can be be used again to select a new product.
• The basic principle is to prevent an ABB from being written to an available solution. This should therefore be solution and technology neutral.

Statement A building block is a defined and recognizable architectural concept that meets an information provision need. Description A building block is described in this document an abstract concept that has been developed into three concrete specializations: service, ABB and SBB. Within our definitions, building blocks are seen as synonymous with an architectural pattern. The three specializations have a hierarchy. In our model, a service is the highest level of abstraction, within which Architecture building blocks are recognized which are implemented by one or more solutions building blocks. An important characteristic of building blocks is that they can be composed. This composition can be done in two ways:

• A building block is a composition of building blocks of the same specialization (for example a service is composed of one or more subservices)
• A building block is served by a composition of one or more building blocks from the underlying layer (for example a service is realized by multiple behavioral elements in an ABB.
• Composite building blocks are seen as synonymous with an architectural pattern within our definitions.

The composition of the specializations is developed for the specializations of the building blocks. The composition within building blocks can consist of several layers. However, it is desirable that the number of levels of building blocks within a specialization (Service, ABB or SBB ) remains limited. If a catalog becomes too complex due to the number of layers and building blocks, it is better to split a catalog. Features

• A building block has a defined boundary and is recognizable as a specific architectural concept.
• A building block is reusable.
• A building block is loosely coupled.
• A building block can interact with one or more other building blocks of different types.
• A building block is part of a catalogue.
li>
• Template for a delivery that meets a combination of requirements and wishes.
• A building block can consist of other building blocks and therefore becomes a composite building block.< /li>
• A building block can be part of a composition (composite building block).
• Building blocks can be recursive and in that case they are composed.

Statement A collection of logically related building blocks of the same specialization (service, ABB or SBB). Description A catalog is a collection or register of building blocks of the same type. It is often aimed at a specific field of work, such as infrastructure, geo, integration. A catalog often contains building blocks of the same specialization, i.e. services, architecture or solution building blocks. However, the building blocks within this will often also be composed. A catalog can be seen as a showcase of generic and reusable architectural products. When these building blocks are used by a project, a number of architectural requirements, principles and requirements are met. The advantage for architecture is that these building blocks are reused. The advantage from a project perspective is that the architectural principles are met and that implementation is standardized and can probably be done faster. Due to changes in the environment (projects, LCM, innovations), the content of a catalog will regularly be adjusted, expanded or made more detailed elaborated. A catalog and the entities included in it thus become a "living" ecosystem. Initially, a supply-driven catalog model will be used. Becoming with others. Every domain architect creates a building block catalog for his domain. At a later stage this will be adapted to a demand-oriented elaboration, the so-called showcase model. architecture) concept can be included in a catalog.

Catalogs are categorized based on a scope. (e.g., infrastructure, integration, geo).

Catalogs within a scope have an owner.

Catalogs are described in a registry (managed in Sparx Enterprise Architect and published to HTML and PDF documents)

Catalogs are often hierarchical or layered in design. On the one hand due to the division into Service, ABB and SBB, and on the other hand due to the design with composite building blocks.

Solution Building Block.

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.

Discussion about services made up of ABBs or SBBs

Statement A solution building block is the physical implementation of a functionality developed in one or more ABB. Description For a solution building block, the abbreviation SBB is used. An SBB describes the implementation with which a functionality is realized. An SBB offers this implementation to a higher-level entity. In our model, an SBB is an implementation of ABB or of a composite SBB. It is relevant here that a distinction is made between architectural layers. For us, the infrastructural and application layers are the most important areas of application. An SBB at application level can therefore be a composition of SBBs at both the application and the infrastructure layer. SBB are related to qualities, constraints and principles. This is preferably elaborated to indicate which requirements are met from an implementation perspective and which are not. This in combination with the model of qualities within the ABB and the requirements as developed at service level provides a complete description of the features offered by a service. Features

• SBB is a physical implementation of one (part of) or more ABBs or functions.
• Technical and product specifications are known.
• Brand and supplier names are known.
• An SBB can often be replaced by another product or implementation.

The Solutions Landscape presents an architectural representation of the Projects and SBBs that support the Architectural Landscape and that are planned or implemented by the enterprise. They therefore form the connection between the Baseline and Target architecture.

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.

A number of things come together in this composite SBB model:

• On the one hand, the email ABB is completed by an Email component in the application layer.
• Secondly, the ABB emails are completed by a technical function and service within the infrastructural ABB and SBB.
• The example shows how a service connects the layers.
• The model includes a secondary element as an example of an interface based on a mail protocol.

Example of a solution building block for the implementation of ABB office automation and word processing. In this case based on two application components from the LibreOffice suite.

Example of a solution building block for the implementation of ABB office automation and word processing. In this case based on two application components from the Office365 suite.

Example of a solution building block on the basis of which the business layer entities for a financial activity are supported from a number of services from the application layer. So the connection point is now a number of services offered by ABB and SBB.

Example of a solution building block on the basis of which the business layer entities for a financial activity are supported from a number of services from the application layer. So the connection point is now a number of services offered by ABB and SBB.

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.

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.

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.