Catalog of Architecture Building Blocks with which a number of services can be realized. The catalog functions as an additional form of navigation for future users

This is the development of a products and services catalog for application services that are offered to the environment within and outside the organization.

An encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, provides services, and makes them available through interfaces.

Naming Conventions Usage: Noun. Example: Search Gui, VM—search service Web service.

The collection of technology components of hardware and software that provide the services used to support applications.

Naming Conventions Usage: Noun in the ing form. For example: Transaction processing, Indexing.

Naming Conventions Usage: Noun. For example: GUI, REST API, Web Service.

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.

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.

Naming Conventions Usage: verb. Example: Support, Manage Service.

Naming Conventions Usage: Noun. For example: Collaboration, Message Exchange Extra: Name from the PDC (ing form).

Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.

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.

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.

Logical service for the import of data for other systems

Transformation of data into various protocols, for example for the implementation of web services, REST, but also into a format that can be read for reporting

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

Service to support business functions and/or processes in the supporting domains such as within PIOFACH

Technology service for exchanging electronic content including messages

Partial models can be exported and imported to various formats. This includes general formats CSV, XLS, XML, but also more specific exchange formats such as XMI or AMEF. In addition, web service technology can also be applied to implement more interactive export and import of submodels.

1. A discrete behavior requestable from an application (e.g., log in, book train seat, transfer money).
2. The automated elements of a business service.

1. The lifecycle management of information and related technology used by an organization.
2. An umbrella term that includes all or some of the subject areas relating to the computer industry, such as Business Continuity, Business IT Interface, Business Process Modeling and Management, Communication, Compliance and Legislation, Computers, Content Management, Hardware, Information Management, Internet, Offshoring, Networking, Programming and Software, Professional Issues, Project Management, Security, Standards, Storage, Voice and Data Communications. Various countries and industries employ other umbrella terms to describe this same collection.
3. A term commonly assigned to a department within an organization tasked with provisioning some or all of the domains described in (2) above.
4. Alternate names commonly adopted include Information Services, Information Management, et al.

Naming: {name of service} Customer For example: Relationship_SRV Customer

Refers to the interface within the integration layer that provides access to the source. This can be an IMH or ORCH. Naming: {name of the service} Source For example: Relationship_SRV Source

1. The ability to share information and services.
2. The ability of two or more systems or components to exchange and use information.
3. The ability of systems to provide and receive services from other systems and to use the services so interchanged to enable them to operate effectively together.

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

Office automation is an application service that supports almost every role in an organization in their daily work. Namely offering functionalities such as word processing, creating presentations and the like.

This is about an application service and the link to a business function

Logical services that publish the data from the register to various register data consumers

Data and information has an appropriate level of security - Rationale Adequate security of data and information prevents unauthorized use, supports the integrity of XXX and guarantees the continuity of business processes and services. - Implication Complying with the XXX policy on the security of data and information. This consists of a framework for Information Security, a risk-driven approach and a classification system to determine the desired level of security, and sets of measures appropriate to the importance (for XXX and for individuals) of the data and information.

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.

1. A repeatable activity; a discrete behavior that a building block may be requested or otherwise triggered to perform.
2. An element of behavior that provides specific functionality in response to requests from actors or other services.

Discussion about services made up of ABBs or SBBs

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.

Viewing an enterprise, system, or building block in terms of services provided and consumed.

A collection of services, potentially an interface definition.

An architectural style that supports service orientation.

Service-Oriented Architecture.

SOAP/XML web services including JSON/REST

SOAP/XML web services including JSON/REST

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.

Message-based transfer of geo data, for example based on AMEF, BPMN, XMI via web services

Web services based on specific exchange formats such as AMEF, BPMN and XMI for sending data to consuming systems

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.

A database of standards that can be used to define the particular services and other components of an Organization-Specific Architecture.

A description of the structure and interaction of the technology services and technology components.

1. A technology building block. A generic infrastructure technology that supports and enables application or data components (directly or indirectly) by providing technology services.
2. An encapsulation of technology infrastructure that represents a class of technology product or specific technology product.

A technical capability required to provide enabling infrastructure that supports the delivery of applications.

Naming Conventions Usage: Noun in the ing form. For example: Messaging, Broadcasting.

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.

XXX data and information is of value to business operations - Rationale Data and information is used to improve the performance of XXX and the services provided to travelers. It is therefore an asset and is therefore controlled, secured and managed like other business assets: based on risk assessment and cost consideration. - Implication Data and information is managed adequately, with the measures appropriate to the value assigned and the risk associated with it.

Application service for creating, managing and editing texts and documents.

This model is relatively simple in design, there is an application service that is completed by one logical application function. However, in other situations this can be a more complex composition. If a register or portfolio is drawn up for the architectural building blocks, this is an additional form of aggregation. An alternative is to aggregate and group via the service portfolio. Is a point of discussion.

Example of an Architecture Building Block starting from the application catalog of building blocks. This provides a recognizable example of office automation and part of it, namely word processing as a service that can be offered to parts of the organization.

A service can consist of multiple ABBs. In this example a service that is provided by a number of ABB. The composition is also a point of attention here. An aggregation can be added from a composite ABB that aggregates the other ABB and offers this as a composite service. Depends on the context of the building blocks, but it is a point to create a work instruction. A join can also be applied if desired.

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.

This first example is an elaboration of the services. Characteristic of this is that the service is a means of communication between provider and customer. It is important that an understandable portfolio of services is created.

The composite service model shows how a service at a higher level of abstraction is composed of smaller services with a more specific character. This office automation model includes an intermediate layer of services, but that is not necessary, you could also make a direct link to Microsoft Office, depending on the context. In this elaboration, only application services are modeled and included in the composition. However, in addition to application services, you can also define business services here. Consider the combination of the implementation of Office and a service desk for questions in case of problems. That is currently out of scope, but will become relevant at some point. Relevant here is that this creates a bottleneck in the ArchiMate modeling. If desired, this bottleneck can be resolved with serving relationships. Embedding ICT business services in the lower architectural layers.

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.

For the application landscape Giovanna wants to develop a supporting technology architecture The technology solution is a Cloud based Infrastructure as a Service in Azure It is typical that a Virtual Machine is designed for a windows application and a relational database For a webbased implementation webforms via HTTP is used Create an ArchiMate diagram of this technology architecture

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.

Alberto expects a lot of job application procedures and decides to set up a mail room for mail processing, with a sorting, folding and franking machine. The letters are printed in the mailroom and as an extra service, a vanilla essence is placed in the envelope

The business process for applications is supported by a service oriented application landscape. There is a logical service for getting a list of applicants and a list of job requests. The applicants are introduced via a webform interface. The application component used here is beaufort a COTS HR system

For effective use of the collected time registration data the data must have sufficient quality to use this as input for the Key Performance indicators Alberto wants to introduce So all employees must be aware of the effect of their registration The manager approving the hours has knowledge about when hour registration is correct or not The projects and activities to use for registration should be up to data at all times There employees are trained and the HR department is able to keep the configuration of the projects and activities When problems occur employees are helped by the service desk

Create a service oriented model for system integration Use services and interfaces to demonstrate how the components interact Model how the HR system and the Webform system exchange information Create an ArchiMate diagram of this service orientation

For the application landscape Giovanna wants to develop a supporting technology architecture. The technology solution is a Cloud based Infrastructure as a Service in Azure It is typical that a Virtual Machine is designed for a windows application and a relational database. For a webbased implementation webforms via HTTP is used Create an ArchiMate diagram of this technology architecture Extend the model with a legend and coloring and eventually a standardized layout

Hierbij hebben we alleen de service en de interface gemodelleerd. Je zou hiermee kunnen volstaan in een cloud situatie. Echter je wilt binnen Azure waarschijnlijk meer weten, bijvoorbeeld welke virtual machines en welk deel van het dotnet raamwerk

How is the application layered serviced by the infrastructure

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.

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.

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.

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