2.3.2 Data Architecture Models

The purpose of this section is to define the target data architecture for the domain/sub-domain. Mandatory/optional: This section is mandatory as all the domain teams need to produce a target data architecture for their respective domains. However, a degree of flexibility exists when documenting the target data architecture. The data domain team will produce a detailed set of data architecture documentation at the planning, conceptual, and logical levels, whereas the other domain teams will produce views and define information artifacts at one or more of the stated three levels depending on their requirements. The other domain teams may decide to just copy views and definitions and relationships from the master data architecture documentation. In terms of quality criteria, this section should make clear: • Relevant views (diagrams) at the planning level illustrating the information subject areas in scope for the target data architecture, as well as the relationships between them • Description of the planning-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders • Definitions for the information subject areas (in table format) in scope for the target data architecture • Descriptions of the relationships and cardinality (if relevant) between the information subject areas (in table format) in scope for the target data architecture • Relevant views (diagrams) at the conceptual level illustrating the business objects in scope for the target data architecture, as well as the relationships between them; these medium-level business objects will have been derived from the high-level information subject areas • Description of the conceptual-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders • Definitions for the business objects (in table format) in scope for the target data architecture • Descriptions of the relationships and cardinality (if relevant) between the business objects (in table format) in scope for the target data architecture • Relevant views (diagrams) at the logical level illustrating the logical data entities in scope for the target data architecture, as well as the relationships between them; these lower-level logical data entities will have been derived from the medium-level business objects • Description of the logical-level view(s) for the target data architecture in order to understand the architectural decisions that have been taken and resulting key messages for the stakeholders • Definitions for the logical data entities (in table format) in scope for the target data architecture • Characteristics of the logical data entities (in table format) in scope for the target data architecture • Descriptions of the relationships and cardinality (if relevant) between the logical data entities (in table format) in scope for the target data architecture • Any additional viewpoints and thus views that are required for this section due to new stakeholder requirements; these views will then be followed by descriptions for the views and definitions for the view artifacts • Any assumptions that have been used to define the target data architecture; for example, one assumption (recommendation) that has already been stated is that the physical data architecture is out of scope for the enterprise architecture
Value
An agreed target architecture that can be approved by decision makers and consumed by implementors.
mandatory section
Yes
risk type
Cost
Time
Quality
Security
Information Management
Risk owner
Architecture
Dependent Section
3. Architecture Requirements Specification

Data Security Diagram

Mandatory
Yes
Security related?
No
This diagram shows which data is accessed by which roles, organization units, and applications. It may be shown as a diagram or presented as a matrix. Its purpose is to: Demonstrate compliance with data privacy laws and regulations Show security threats arising as a result of data access Show which parties outside of the organization have access to data Show security measures applied to data access

Data Migration Diagram

Mandatory
No
Security related?
No
This diagram shows how data is extracted from baseline or source location(s) and loaded into target location(s). It may show where data is transformed and/or cleansed on the way. In Phase C of the ADM, the diagram is likely to be at an overview level. Later, it may be elaborated to show which source data items map to which target data items.

Data Lifecycle Diagram

Mandatory
No
Security related?
Yes
The Data Lifecycle diagram is an essential part of managing business data throughout its lifecycle from conception until disposal within the constraints of the business process. The data is considered as an entity in its own right, decoupled from business process and activity. Each change in state is represented on the diagram which may include the event or rules that trigger that change in state. The separation of data from process allows common data requirements to be identified which enables resource sharing to be achieved more effectively.

Data Dissemination Diagram

Mandatory
Yes
Security related?
Yes
The purpose of the Data Dissemination diagram is to show the relationship between data entity, business service, and application components. The diagram shows how the logical entities are to be physically realized by application components. This allows effective sizing to be carried out and the IT footprint to be refined. Moreover, by assigning business value to data, an indication of the business criticality of application components can be gained. Additionally, the diagram may show data replication and application ownership of the master reference for data.

Application/Data Matrix

Mandatory
Yes
Security related?
Yes
The purpose of the Application/Data matrix is to depict the relationship between applications (i.e., application components) and the data entities that are accessed and updated by them. Applications will create, read, update, and delete specific data entities that are associated with them. For example, a Customer Relationship Management (CRM) application will create, read, update, and delete customer entity information. The data entities in a package/packaged services environment can be classified as master data, reference data, transactional data, content data, and historical data.

Logical Data Diagram

Mandatory
Yes
The key purpose of the Logical Data diagram is to show logical views of the relationships between critical data entities within the enterprise. This diagram is developed to address the concerns of: Application developers Database designers

Data Entity/Data Component Catalog

Mandatory
Yes
This catalog identifies and maintains a list of the data used across the enterprise, relating data entities to data components showing how data entities are structured. Its purpose is to: Identify all data used in the enterprise Encourage effective data use The Data Entity/Data Component catalog contains the following metamodel entities: Data Entity Logical Data Component Physical Data Component
Subscribe to 2.3.2 Data Architecture Models