1. Data Architecture Context Diagram
Enterprise architecture includes many different types, such as business architecture, data architecture, application architecture and technical architecture . number of them
The main goal of a data architecture is to efficiently manage data and the systems that store and use it .
Data architecture is the foundation of data management. Since most organizations have data beyond what individuals can comprehend , it is necessary to describe an organization's data at different levels of abstraction in order to better understand the data and help management make decisions.
The most detailed data architecture design document is the formal enterprise data model, containing data names, data attribute and metadata definitions, conceptual and logical entities, relationships, and business rules .
In this chapter, the data architecture will be considered from the following aspects:
1) The results of data architecture, including different levels of models, definitions, and data flows , which are often referred to as components of data architecture.
2) Data Architecture activities to form, deploy, and achieve the goals of the Data Architecture .
3) Data Architecture Behavior, including collaboration, mindsets, and skills among the different roles that affect enterprise data architecture.
2. Business drivers
Common business drivers for data architecture are as follows:
1) Use the business advantages brought by emerging technologies to strategically help organizations rapidly change products, services and data.
2) Convert business requirements into data and application requirements to ensure that effective data can be provided for business process processing.
3) Manage complex data and information and deliver it to the entire enterprise.
4) Ensure that business and IT technologies are aligned.
5) Provide support for enterprise reform, transformation and improvement of adaptability .
Key outcomes of the data architecture include:
1) Data storage and processing requirements.
2) Design structures and plans that meet the current and long-term data needs of the enterprise.
3. Enterprise Data Architecture
Enterprise data architecture includes two parts: enterprise data model and data flow, details are as follows.
1. Enterprise data model
Enterprise Data Model: An organization's understanding of data entities, data attributes, and the relationships between them within the enterprise. Each level of model (conceptual model, logical model, physical model) is an integral part of the enterprise data model. Model links define and manage horizontal (association) and vertical (hierarchical) relationships of models.
Common enterprise data model construction methods: top-down, bottom-up or mixed mode:
Top-down is to start from the subject domain, first design the subject, and then gradually design the lower model. When adopting the bottom-up method, the subject domain structure is refined and abstracted based on the existing logical data model. It is usually recommended to combine the two methods, that is, start from the bottom-up analysis of the existing model, design the topic model from the top-down, and complete the design of the enterprise data model through the combination of the two methods .
Conceptual map of enterprise data model:
Conceptual diagram of the subject domain model:
2. Data flow
Data flow: The data processing process of recording data lineage can be presented through two-dimensional matrix and data flow diagram.
2.1. Conceptual diagram of two-dimensional matrix data flow
2.2. Conceptual diagram of data flow
4. Metrics
Commonly used enterprise data architecture metrics: architecture acceptance, implementation trends, and business value . Data architecture measurements are typically performed annually as part of the project's overall business customer satisfaction .
(1) Architecture standard acceptance rate . Measure the closeness of the project to the established data architecture, and the compliance of the project with the enterprise architecture participation process.
(2) Implementation trends . The degree to which the enterprise architecture improvement organization is able to implement projects can be tracked along at least two directions:
1) Use/reuse/replace/discard measurements . Determine the proportion of new architectural components versus reuse, replacement, or obsolescence.
2) Measurement of project execution efficiency . Measure the delivery time of the project and the delivery improvement cost of reusable components and guide components.
(3) Business value metrics . Track progress toward desired business outcomes and benefits:
1) Business agility improvement . Explain the benefits of lifecycle improvements or changes, and improve the measurement of delay costs.
2) Service quality . Measure whether the business case is completed on schedule; measure whether the project actually delivered the changes to the business based on newly created or integrated data.
3) The quality of business operations . A method of measuring improved efficiency. Examples include accuracy improvements, time reductions, error correction fees due to data errors.
4) Improvement of business environment . Examples include changes in client retention rates due to fewer data errors and reduced rates of authority comments in submissions.
5. Key concepts/tools/methods
1. The relationship between enterprise architecture
Enterprise architecture includes many different types, such as business architecture, data architecture, application architecture and technical architecture . Each architecture does not exist in isolation and either affects or is constrained by other architectures.
2. Enterprise architecture framework - Zachman framework
In a building, aircraft, enterprise, value chain, project or system, there are many stakeholders and each has a different perspective on the architecture. These concepts can be applied to different architectural types and hierarchical requirements of an enterprise.
The Zachman model can completely describe an enterprise and its relationship with each other. It doesn't define how models are created, it just shows which models should exist.
The two dimensions of the matrix framework are: query communication (such as what, how, where, who, when, and why) is displayed in columns, redefine transformation (such as identify, define, describe, specification, configuration and instance ) are displayed in the row. Framework classifications are presented per cell (intersection between queries and transformations). Each cell of the framework represents a unique design component.
When inquiring and communicating, you can ask basic questions about any entity and convert it into an enterprise architecture. Each column can be understood as follows:
1) What (What). Catalog column, representing the entity that builds the schema.
2) How (How). Process column, which represents the activity performed.
3) Where (Where). Distribution columns, representing business location and technology location.
4) Who. Responsibility column, indicating role and organization.
5) What time (When). Time columns, representing intervals, events, periods, and timetables.
6) Why (Why). Motivation column, indicating goals, strategies, and means.
Redefinition conversion is a necessary step to transform an abstract concept into a concrete instance (instantiation). Each row in the matrix represents a different role, including planner, owner, designer, builder, implementer, and user. Each role holds a different perspective on the overall process and the solution to different problems. The content corresponding to these different viewpoints is displayed in each row. For example, each perspective is intersected with the "what" column (catalog or data), indicating that it has a different relationship with each other. The specific instructions are as follows:
1) Executive perspective (business background). Business element catalogs that define different model scopes.
2) Business management perspective (business concept). Clarify the relationship between the different business concepts involved by management in the defined business model.
3) Architect perspective (business logic). As a model architect, the architect refines the system requirements and designs the system logic model.
4) Engineer perspective (business entity). Engineers, as concrete model builders, optimize and implement physical models designed for specific applications within specific technical, personnel, cost and time constraints.
5) Technician perspective (component assembly). Takes a technology-specific, out-of-context perspective to explain how configuration components are used, assembled, and implemented by configuration model technicians.
6) User perspective (operation class). The actual function instance used by the participants.