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.

A description of the structure and interaction of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources.

Physical storage of the data in a (relational) database.

An implementation-independent definition of the architecture, often grouping related physical entities according to their purpose and structure.

A description of a real-world entity. Physical elements in an Enterprise Architecture may still be considerably abstracted from Solution Architecture, design, or implementation views.

It seems strange to cover the database structure of a Sparx Enterprise Architect repository in a book about repositories. However, working with an architecture repository will also mean that the content must be accessed in a way that is not available in the formats already present in the tooling. That is why we discuss here the tables that contain the most essential data for accessing of the repository contents. Please note that the number of tables in a Sparx Enterprise Architect includes many more tables.

Checklist of naming conventions for relational databases based on an item on which the modeler can validate a model elaboration based on the items in the checklist.

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.

Particularly in situations where the different stakeholders do not physically work in the same space, working with collaboration functionalities such as chat and discussion or review functions is desirable. But this can also have added value in other situations.

This diagram is a viewpoint for developing a logical data model. This viewpoint indicates which types of object types and connector types can be used when drawing up a logical data model. A few principles apply to the logical data model:

• Logical data model is for all stakeholders (ICT professionals and non-ICT professionals) and must be understood by all stakeholders after an explanation of the metamodel.
• Logical data model is developed in UML Class Modeling.
• For the logical data model, only the Class and Enumeration stereotypes are used.
• The logical model has a hierarchical structure based on abstract and concrete entities with a specialization connector.
• For a logical domain, multiple diagrams can be created if this reduces complexity.
• The logical model is related to the parent conceptual model and to the underlying physical data models. See the hybrid meta data model for this.

This diagram is a viewpoint for developing a physical data model for SQL Server RDBMS. This viewpoint indicates which tables, constraints and columns can be used when drawing up an RDBMS data model. A few principles apply to the RDBMS data model:

• Physical data model is for ICT (Database specialists).
• SQL DDL statements can be generated from the Physical data model.
• Naming conventions for the database platform (SQL Server/Oracle) serve as the basis for the Naming Conventions.

The associations show the database details for the referrer and primary keys.

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

Physical data model of the package structure and the various elements present within the package such as elements, diagrams and sub-packages.

It seems strange to cover the database structure of a Sparx Enterprise Architect repository in a book about repositories. However, working with an architecture repository will also mean that the content must be accessed in a way that is not available in the formats already present in the tooling. That is why we discuss here the tables that contain the most essential data for accessing of the repository contents. Please note that the number of tables in a Sparx Enterprise Architect includes many more tables.