Enterprise Architecture Professional Training and Certification (EA Phase-2 Training)
Architecture Development Model Module 4- ADM Phase D- Data Architecture
Phase C : Data Architecture
Phase C : Data Architecture
Module Objectives
The aim of this module is to understand: • The objectives of the Data Architecture part of Phase C • What it consists of • What inputs are needed for it
• What the outputs are
Data Architecture – Objectives The objective of the Data Architecture work is to define the types and sources of data needed to support the business, in a way that can be understood by stakeholders. The output should be complete, consistent and stable. NOT to:
• Design a database • Design logical or physical storage systems But links to legacy files and databases may be developed
Phase C: Inputs • Request for Architecture Work • Capability Assessment • Communications Plan
• Organization model for enterprise Architecture • Tailored Architecture Framework • Data principles
• Statement of Architecture Work • Continued…
Phase C: Inputs • Architecture Vision • Architecture Repository • Draft Architecture Definition Document • Draft Architecture Requirements Specification, including: – Gap analysis results – Relevant technical requirements • Business Architecture components of an Architecture Roadmap
Steps The order of the steps should be adapted to the situation. In particular you should determine whether it is appropriate to do the Baseline Data Architecture or Target Data Architecture development first
9. Create Arch itecture D e fi n i t i o n D o c u m e n t
8. Finalize th e Data Architecture 7. Condu ct form al stakehold er review 6. Resolve impacts acro ss the Architecture Landscape
5. Define roadmap com pon ents
4. Perform g ap analysis
3. Develo p Target Data A r c h i t e c t u r e D e s c r i p t i o n
2. Develop B aseline Data A r c h i t e c t u r e D e s c r i p t i o n
Step 1: Select reference models, viewpoints, and tools • Review/generate and validate data principles – see Architecture Principles • Select Data Architecture resources (reference models, patterns,…)
• Select relevant Data Architecture viewpoints • Identify appropriate tools and techniques (including forms) to be used for data capture, modeling, and analysis, in association with the selected viewpoints. • Examples of data modeling techniques are: Entity-relationship diagram Class diagrams Object role modeling .
Continued..
TOGAF 9 Viewpoints Preliminary Phase Principles catalog
Phase B, Business Architecture Organization/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog Business Interaction matrix Actor/Role matrix Business Footprint diagram Business Service/Information diagram Functional Decomposition diagram Product Lifecycle diagram Goal/Objective/Service diagram Use-Case diagram Organization Decomposition diagram Process Flow diagram Event diagram
Phase C, Data Architecture Data Entity/Data Component catalog Data Entity/Business Function matrix System/Data matrix Class diagram Data Dissemination diagram Data Security diagram Class Hierarchy diagram
Phase A, Architecture Vision Stakeholder Map matrix Value Chain diagram Solution Concept diagram
Phase C, Application Architecture Application Portfolio catalog Interface catalog System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix Application Communication diagram Application and User Location diagram System Use-Case diagram Enterprise Manageability Diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram
Phase D, Technology Architecture Technology Standards catalog Technology Portfolio catalog System/Technology matrix Environments and Locations diagram Platform Decomposition diagram Processing diagram Networked Computing/Hardware diagram
Phase E. Opportunities & Solutions Project Context diagram Benefits diagram
Requirements Management Requirements catalog
Step 1: Select reference models, viewpoints, and tools Determine Overall Modeling Process – For each viewpoint, select the models needed to support the specific view required, using the selected tool or method.
Examples of logical data models include: • The DODAF Logical Data Model • The ARTS Data Model for the Retail Industry and • The Energistics Data Model for the Petrotechnical industry • Confirm all stakeholders’ concerns are addressed • If not, create new models to address concerns not covered, or augment Existing models • Identify Required Catalogs of Data Building Blocks – The organization’s data inventory is captured as a catalog within the Architecture Repository
Step 1: Select reference models, viewpoints, and tools
• Identify Required Matrices – Matrices show the core relationships between related model entities.
• Identify Required Diagrams – Diagrams present the Data Architecture information from asset of different viewpoints
• Identify Types of Requirements to be Collected – e.g. Functional requirements, Non-functional requirements, Assumptions, Constraints, Domain-specific Business Architecture principles, Policies, Standards, Guidelines, Specifications
Step 2 Develop a Baseline Data Architecture Description If possible, identify the relevant Data ABBs, drawing on the Architecture Repository.
If not develop new architecture models :
– use the models identified within Step 1 as a guideline
Step 3 Develop Target Data Architecture Description
If possible identify the relevant Data Architecture building blocks, draw ing on the Architecture Repository
If not develop a new architecture model : – use the models identified within Step 1 as a guideline
Step 4 Perform Gap Analysis
Verify the architecture models for internal consistency and accuracy
Note changes to the viewpoint represented in the selected models from the Architecture Repository and,
Document Test architecture models for completeness against requirements
Identify gaps between the baseline and target: Create the gap matrix
Identify building blocks to be carried over, classifying them as either changed or unchanged. Identify eliminated building blocks. Identify new building blocks. Identify gaps and classify as those that should be developed and those that should be procured.
Step 5: Define roadmap components T h i s i n i t i a l D at a A r c h i t e c t u r e r o a d m a p w i l l b e u s e d a s r a w m a t er i a l t o s u p p o r t m o r e d e t ai l ed d e fi n i t i o n o f a c o n s o l i d a t ed , c r o s s - d i s c i p l i n e r o a d m a p w i t h i n t h e O p p o r t u n i t i es & S o l u t i o n s p h a s e .
Step 6: Resolve impacts across the Architecture Landscape Architecture artifacts in the Architecture Landscape should be examined to identify the following Does this Data Architecture create an impact on any pre-existing Architectures? Have recent changes been made that impact on the Data Architecture? Are there any opportunities to leverage work from this Data Architecture in other areas of the organization? Does this Data Architecture impact other projects ? Will this Data Architecture be impacted by other projects?
Step 7 Conduct Formal Stakeholder Review
Check the original motivation for the architecture project and the Statement of Architecture Work against the proposed Data Architecture. Conduct an impact analysis to: Identify any areas where the Business and Application Architecture may need to change to cater for changes in Data Architecture. If the impact is significant revisit the Business Architecture Identify any areas where the Application Architecture may need to change to cater for changes in the Data Architecture (or to identify constraints on the Application Architecture about to be designed). If the impact is significant revisit the Application Architecture. Identify any constraints on the Technology Architecture. Refine the proposed Data Architecture if necessary.
Step 8: Finalize the Data Architecture Select standards for each of the ABBs, reusing as much as possible. • Fully document each ABB . • Cross check the overall architecture against the business requirements. • Document the final requirements traceability report. • Document the final mapping of the architecture within the Architecture repository. Identify the ABBs that might be reused and publish them via the architecture repository. • Finalize all the work products, such as gap analysis
Step 9: Create Architecture Definition Document Document the rationale for all building block decisions in the architecture definition document. • Prepare the Data Architecture sections of the architecture definition document report. • If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback.
Phase C: Outputs: Data Architecture
• Statement of Architecture Work • Validated data principles, or new data principles • Draft Architecture Definition Document • Draft Architecture Requirements Specification
• Data Architecture components of an Architecture Roadmap
Architecture Definition Document –Data Architecture Components
•Baseline Data Architecture, if appropriate
•Target Data Architecture, including: – Business data model – Logical data model – Data management process models – Data Entity/Business Function matrix •Data Architecture views corresponding to the selected viewpoints addressing key stakeholder concerns
Architecture Requirements Specification – Data Architecture Components • Gap analysis results • Data interoperability requirements • Areas where the Business Architecture may need to change in order to comply with changes in the Data Architecture • Constraints on the Technology Architecture about to be designed Updated business/application/data requirements, if appropriate
Summary
The Data Architecture phase defines the types and sources of data needed to support the business, in a way that can be understood by stakeholders. The architecture team should consider existing relevant data models, such as the ARTS and Energistics models.
Test Yourself Question Q. Which of the following is not an objective of the Data Architecture part of Phase C? A To define the types of data needed B To define the sources of data needed C To design a database D To produce output that is complete E To produce output that is understandable by the stakeholders
Test Yourself Question Q. Which of the following is/are logical data model(s) which can be used during Data Architecture? A. DODAF B. ARTS C. Energistics Data Model for the Petrotechnical industry D. Zachman
ADM Data Architecture Catalogs, Matrices and Diagrams
Module Objectives The objectives of this module are to understand: • The Catalogs, Matrices and Diagrams of Phase C, Data Architecture • What they consist of • How they are used
TOGAF 9 Viewpoints Preliminary Phase Principles catalog
Phase B, Business Architecture Organization/Actor catalog Driver/Goal/Objective catalog Role catalog Business Service/Function catalog Location catalog Process/Event/Control/Product catalog Contract/Measure catalog Business Interaction matrix Actor/Role matrix Business Footprint diagram Business Service/Information diagram Functional Decomposition diagram Product Lifecycle diagram Goal/Objective/Service diagram Use-Case diagram Organization Decomposition diagram Process Flow diagram Event diagram
Phase C, Data Architecture Data Entity/Data Component catalog Data Entity/Business Function matrix System/Data matrix Class diagram Data Dissemination diagram Data Security diagram Class Hierarchy diagram
Phase A, Architecture Vision Stakeholder Map matrix Value Chain diagram Solution Concept diagram
Phase C, Application Architecture Application Portfolio catalog Interface catalog System/Organization matrix Role/System matrix System/Function matrix Application Interaction matrix Application Communication diagram Application and User Location diagram System Use-Case diagram Enterprise Manageability Diagram Process/System Realization diagram Software Engineering diagram Application Migration diagram Software Distribution diagram
Phase D, Technology Architecture Technology Standards catalog Technology Portfolio catalog System/Technology matrix Environments and Locations diagram Platform Decomposition diagram Processing diagram Networked Computing/Hardware diagram Communications Engineering diagram
Phase E. Opportunities & Solutions Project Context diagram Benefits diagram
Requirements Management Requirements catalog
Catalogs, Matrices and Diagrams
Catalogs • Data Entity/Data Component catalog
Matrices • Data Entity/Business Function matrix • System/Data matrix
The exact format of the catalogs, matrices and diagrams will depend on the tools used
Diagrams • Class diagram • Data Dissemination diagram • Data Security diagram • Class Hierarchy diagram • Data Migration diagram
Catalogs Catalog Data Entity/Data Component Catalog
Purpose To identify and maintain a list of all the data use across the enterprise, including data entities and also the data components where data entities are stored. It contains the following metamodel entities: •Data Entity •Logical Data Component •Physical Data Component
Matrices • Data Entity/Business Function matrix • System/Data matrix
Data Entity/Business Function Matrix • The purpose of the Data Entity/Business Function matrix is to depict the relationship between data entities and business functions within the enterprise. • The mapping of the Data Entity-Business Function relationship enables the following to take place: – Assignment of ownership of data entities to organizations – Understand the data and information exchange requirements business services – Support the gap analysis and determine whether any data entities are missing and need to be created – Define system of origin, system of record, and system of reference for data entities – Enable development of data governance programs across the enterprise (establish data steward, develop data standards pertinent to the business function, etc.)
Example Data Entity/Business Function Matrix BUSINESS FUNCTION (Y-AXIS) AND DATA ENTITY (X-AXIS)
CUSTOMER MASTER
BUSINESS PARTNER
Customer Relationship Management
•Business partner data management service •Owner – Sales & Marketing business unit executive • Function can Create, read, update and delete customer master data
•Business partner data management service •Owner of data entity (person or organization) •Function can create, read, update and delete
Supply Chain Management
•Customer Requirement Processing Service • Owner – Supply Chain Manager
• N/A
CUSTOMER LEADS
PRODUCT
•Lead Processing Service •Owner – Customer Relationship Manager • Function can only create, read, update customer leads
N/A
• N/A
•Product data management service • Owner – Global product development Organization
System/Data Matrix •The purpose of the System/Data matrix is to depict the relationship between systems (i.e., application components) and the data entities that are accessed and updated by them. • Systems will create, read, update, and delete specific data entities that are associated with them. For example, a CRM application will create, read, update, and delete customer entity information.
Example System/Data Matrix
APPLICATION (YAXIS) AND DATA (X-AXIS)
DESCRIPTION OR COMMENTS
DATA ENTITY
DATA ENTITY TYPE
CRM
•System of record for customer master data
•Customer data
•Master data
Commerce Engine
•System of record for order book
•Sales orders
•Transactional data
Sales Business Warehouse
•Warehouse and data mart that supports North American Region
•Intersection of multiple data entities (e.g. All sales orders by customer XYZ and by month for 2006)
•Historical data
Diagrams • Class diagram • Data Dissemination diagram • Data Security diagram • Class Hierarchy diagram • Data Migration diagram • Data Lifecycle diagram
Example Class Diagrams The purpose is to depict the relationships among the critical data entities (or classes) within the enterprise. Account
Information Actor
Update Account
Payment
Trigger
Customer Profile
Process
Contact
Agent
Customer
Customer
Service Request
Enquiry
Appeal
Compliant
Data Dissemination Diagram The purpose of the Data Dissemination diagram is to show the relationship between data entity, business service, and application components. • The diagram should show how the logical entities are to be physically realized by application components. • Additionally, the diagram may show data replication and system ownership of the master reference for data.
Example Data Dissemination Diagram Warehouse Customer Order History Stock
Online Account Self Service
Billing Customer Account Balance Invoice History
Business Service
Data Entities
Application
Online Account Self Service
Customer
Warehouse
Billing
Order History
Warehouse
Stock
Warehouse
Data Lifecycle Diagram •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. Fulfillment Order New
Fulfilled
Invoiced
Paid
Closed
Customer Order New New
Dispatched
Closed
Archived Archived
Deleted
Archived
Deleted
Data Security Diagram •The purpose of the Data Security diagram is to depict which actor (person, organization, or system) can access which enterprise data. •This relationship can also be shown in a matrix form between two objects or can be shown as a mapping.
Example Data Security Diagram
Example Data Security Matrix ACTOR
CLASS OF ROLES (JOB FUNCTION)
FUNCTION
BUSINESS SERVICE
LOCATION
TYPE OF ACCESS
Financial Analyst
SOA Portfolio Financial Analyst
Financial Analysis
SOA portfolio service
•NA (US, CA) •EMEA (UK, DE) • APJ
•Physical • Access Control (tables xyz only)
Procurement & Spend Analyst
Procurement Management and Control
WW Direct Procurement
Supplier portal Service
NA (US Midwest)
• Access control
WW Contracts System (application)
Not applicable
WW Direct Procurement
Supplier Portal Service
• LA
• Access control (system to system)
WW Product Development (Org Unit)
Geo Brand Managers
WW Direct Procurement
Supplier Portal Service
•WW (all Geos)
• Access Control
Data Migration Diagram •The purpose of the Data Migration diagram is to show the flow of data from the source to the target applications. •The diagram will provide a visual representation of the spread of sources/targets and serve as a tool for data auditing and establishing traceability.
Example Data Migration Diagram “Target” applications components
System of Record for Customer Master
System of Record for Material Master & Order history
System of Record for Vendor Master &
Example Data Migration Mapping SOURCE LOGICAL APPLICATION COMPONENT ABM
SOURCE DATA ELEMENT
Cust_Name
TARGET LOGICAL APPLICATION COMPONENT CRM
TARGET DATA ELEMENT
CUSTNAME
Cust_Street_Addr
CUSTADDR_LINE1
Cust_Street_Addr
CUSTADDR_LINE2
Cust_Street_Addr
CUSTADDR_LINE3
Cust_ContactName
CUSTCONTACT
Cust_Tele
CUSTTELEPHONE
Class Hierarchy Diagram •The purpose of the Class Hierarchy diagram is to show the technical stakeholders a perspective of the class hierarchy
•This diagram gives the stakeholders an idea of who is using the data, how, why, and when
Example Class Hierarchy Diagram