Abstract Logical data entity is a hierarchical division of logical data entities. With the help of specialization, the characteristics of an abstract logical data entity are transferred to a concrete data entity. So attribute 1-3 is also an attribute of the concrete logical data entity. Multiple hierarchies can be created based on multiple specialization connections between data entities.

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.

Some attributes are characterized by the fact that they consist of a number of attributes and/or business rules. They therefore form an aggregated attribute. However, in that case this can make the notation much simpler for those involved. For example, a visiting address is an attribute of a branch but is worked out in detail in the attribute type with street, house number and place of residence, etc.

xBB know attributes. Duncan has made an initial draft of this. In addition, there is a generic model for the attributes. Elaborate in a logical object model after discussion

Naming Conventions Usage: Singular noun. For example: Invoice, policy, Fault report Logical name. Avoid technical names.

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.

concrete logical data entity is modeled in a class stereotype. A logical data entity has a name and a definition. Multiple attributes can be defined for concrete data entities. A concrete data entity inherits all the characteristics of an abstract data entity if there is a specialization between these entities.

Logical service for the import of data for other systems

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.

Naming Conventions Usage: Singular noun. For example: Search query, Search result Logical name. Avoid technical names such as file, database.

Despite the many navigation and search options available in an architecture repository, a logical layout is a good way to provide modelers and reviewers with structure. Packages are used for this in Sparx Enterprise Architect. The (tree) structure of the packages in a repository is therefore an important part of setting up an architecture repository.

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

Description of the available or desired application functions within the scope of the architecture. Usually related to the description of the application landscape.

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.

Description of the modeling and naming conventions based on a checklist. This makes naming conventions easy to introduce and maintain.

Package is a concept that allows you to logically structure the contents of your repository content. It can be compared to directories in a file system.

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

Is an extra class with the same characteristics as the Concrete Logical Data entity and has been added to keep the associations easy to read.

Modeling language for modeling software and logical data models.

This checklist is used to ensure that the models in the repository are easy to find for different stakeholders and that they are given a logical order in the diagrams to get an idea of the solution or the established architectures.

EA Global Summit 2021 sessions with subject like Logical model simulation and ArchiMate and Azure.

Goal : Providing insight into the relationship between applications and parts of applications and which application functions they realize. Obliged Landscape of the relationship between different applications. Use the Application layer of ArchiMate for this and use two types of views: the logical application view (application functions) and the implementation view with application components.

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

• Conceptual data model is for multiple stakeholders (including non-ICT professionals) and should be simple in design.
• Conceptual data model has been developed in ArchiMate (business layer).
• Only the stereotypical Business Object is used for the conceptual data model.
• The conceptual model has a hierarchical structure based on domains.
• If this reduces the complexity, multiple diagrams can be created for a domain.
• The conceptual model is related to the logical data model. See the hybrid meta data model for this.
• The conceptual model can be related to, for example, the other data management business functions within Example.

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.

Goal : Providing insight into the relationship between applications and parts of applications and which application functions they realize. Obliged Landscape of the relationship between different applications. Use the Application layer of ArchiMate for this and use two types of views: the logical application view (application functions) and the implementation view with application components.

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.

Enumeration and hierarchy of relevant application functions when working with an architecture repository. In other words, necessary functionalities for a tool to be selected for a repository.

This logical application model views the architecture repository as a master data registry and names the relevant application functions and interfaces that are relevant from the master data perspective and therefore also for an architecture repository. Each element is briefly described and provides an idea of which elements are relevant in its own context. Because in the initial situation of introducing an architecture repository, not all concepts will be relevant. However, with further development of working with an architecture repository, the register will increasingly fulfill a master data function in the application landscape of the organization.

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

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.