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.

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

Details van Service

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.

Details van Catalog

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.

Details van Architecture Building Block

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.

Details van Solution Building block

Requirements are the descriptive characteristics that are provided in the building block by the provider or requested by the provider. Consider:

• Requirements.
• Principles.
• Constraints.
• Functional qualities.
• Non functional qualities.

Details van Requirement