What are the relevant application functions to support the stated work processes. These can then be linked to modules in the architecture tool or to requirements (during a selection process).

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.

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.

Data quality dimension in accordance with the DMBoK framework.

Generic and specific requirements when deploying an architecture repository in the organization.

This is the established architecture of organization. It often includes the elaboration of the baseline architecture and sometimes also of the target architecture. It is important that the classification should be based on a consultation function. Architects use this as a register of the architecture for requirements inventories, but also for consulting the architectural landscapes and the frameworks within the architecture.

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.

A list of proposals, in the form of requirements and requirements for the architecture to be drawn up. But also for the metamodel or the modeling conventions of the architectures to be developed.

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.

Example of a logical architecture model for a registry or MDM module. Provides an example of how you can combine application functions, interfaces and services in ArchiMate to describe the desired requirements. If you look at an architecture repository from the perspective of master data, you can actually use a number of building blocks to describe functionalities, application services and interfaces in a generic way.

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.

In addition to the use of a modeling language, additional requirements and definitions are drawn up around the Architecture models and products. They are frameworks for architects who develop different types of architectures.

Description of the goals and drivers of the organization. If desired, expanded with a model of principles and/or requirements.

Changes in the organization are often introduced into the organization on a project-by-project basis. Projects determine the planning and execution of the architecture work and make use of the architecture artifacts. The projects set requirements for the support from architecture and the products to be delivered by the architecture.

More and more organizations are working web-based, making the repository content available based on HTML is a requirement.

Standardized non-functional requirements, called qualities, can be developed for the functionalities in an architecture repository.

Make connections between requirements and goals.

A statement of need that must be met by a particular architecture or work package.

Naming conventions Usage: Short title Code in attribute Alias For example: available 24/7.

Functional and non-functional requirements

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.

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.

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.

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.

User organization indicates which requirements, wishes and limitations exist regarding the artifacts to be developed within the architecture and the resulting implementations to the target architecture.

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.

This example shows in a simple manner how the characteristics/requirements can be made transparent based on requirements, constraints, qualities and principles. This example shows how the characteristics of the different xBB can be mapped based on ArchiMate concepts. This will soon become an important mechanism in the various xBB catalogues. In addition to this approach, the characteristics can also be elaborated via the internal characteristics of the entities in EA. Such as requirements, constraint and scenario. Finally, there is the option to use tagged values. The working group has determined that making associations between ArchiMate concepts is preferable. If an elaboration with ArchiMate concepts is insufficient and you want to rely on internal properties or tagged values, this must be short-circuited.

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.

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.

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.

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.

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.

This is the established architecture of organization. It often includes the elaboration of the baseline architecture and sometimes also of the target architecture. It is important that the classification should be based on a consultation function. Architects use this as a register of the architecture for requirements inventories, but also for consulting the architectural landscapes and the frameworks within the architecture.

Example of a logical architecture model for a registry or MDM module. Provides an example of how you can combine application functions, interfaces and services in ArchiMate to describe the desired requirements. If you look at an architecture repository from the perspective of master data, you can actually use a number of building blocks to describe functionalities, application services and interfaces in a generic way.

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.