Enterprise Architecture Professional Training and Certification
(EA Phase-2 Training)
Architecture Development Model Module 4- ADM Phase D- Data Architecture
Mahindra Satyam 2009
Phase C : Data Architecture
Mahindra Satyam 2009
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
Mahindra Satyam 2009
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
Mahindra Satyam 2009
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
Mahindra Satyam 2009
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
Mahindra Satyam 2009
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 Architecture Definition Document 8. Finalize the Data Architecture 7. Conduct formal stakeholder review 6. Resolve impacts across the Architecture Landscape 5. Define roadmap components
4. Perform gap analysis
3. Develop Target Data Architecture Description
2. Develop Baseline Data Architecture Description
1. Select reference models, viewpoints, and tools
Mahindra Satyam 2009
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..
Mahindra Satyam 2009
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 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 A, Architecture Vision Stakeholder Map matrix Value Chain diagram Solution Concept 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
Mahindra Satyam 2009
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 organizations data inventory is captured as a catalog within the
Architecture Repository.
Mahindra Satyam 2009
. Continued
10
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
Mahindra Satyam 2009
11
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
Mahindra Satyam 2009
12
Step 3 Develop Target Data Architecture Description
If possible
identify the relevant Data Architecture building blocks, drawing on the Architecture Repository
If not
develop a new architecture model:
use the models identified within Step 1 as a guideline
Mahindra Satyam 2009
13
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.
Mahindra Satyam 2009
14
Step 5: Define roadmap components
This initial Data Architecture roadmap will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Opportunities & Solutions phase.
Mahindra Satyam 2009
15
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?
Mahindra Satyam 2009
16
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.
Mahindra Satyam 2009
17
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
Mahindra Satyam 2009
18
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.
Mahindra Satyam 2009
19
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
Mahindra Satyam 2009
20
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
Mahindra Satyam 2009
21
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
Mahindra Satyam 2009
22
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.
Mahindra Satyam 2009
23
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
Mahindra Satyam 2009
24
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
Mahindra Satyam 2009
25
ADM Data Architecture Catalogs, Matrices and Diagrams
Mahindra Satyam 2009
26
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
Mahindra Satyam 2009
27
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 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 A, Architecture Vision Stakeholder Map matrix Value Chain diagram Solution Concept 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
Mahindra Satyam 2009
28
Catalogs, Matrices and Diagrams
Catalogs Data Entity/Data Component catalog
Matrices Data Entity/Business Function matrix System/Data matrix
Diagrams Class diagram Data Dissemination diagram Data Security diagram Class Hierarchy diagram Data Migration diagram
The exact format of the catalogs, matrices and diagrams will depend on the tools used
Mahindra Satyam 2009
29
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
Mahindra Satyam 2009
30
Matrices
Data Entity/Business Function matrix System/Data matrix
Mahindra Satyam 2009
31
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.)
Mahindra Satyam 2009
32
Example Data Entity/Business Function Matrix
BUSINESS FUNCTION (Y-AXIS) AND DATA ENTITY (X-AXIS)
Customer Relationship Management
CUSTOMER MASTER
BUSINESS PARTNER
CUSTOMER LEADS
PRODUCT
Business partner data management service Owner Sales & Marketing business unit executive Function can Create, read, update and delete customer master data Customer Requirement Processing Service Owner Supply Chain Manager
Business partner data management service Owner of data entity (person or organization) Function can create, read, update and delete N/A
Lead Processing Service Owner Customer Relationship Manager Function can only create, read, update customer leads
N/A
Supply Chain Management
N/A
Product data management service Owner Global product development Organization
Mahindra Satyam 2009
33
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.
Mahindra Satyam 2009
34
Example System/Data Matrix
APPLICATION (YAXIS) AND DATA (X-AXIS)
CRM Commerce Engine Sales Business Warehouse
DESCRIPTION OR COMMENTS
System of record for customer master data System of record for order book Warehouse and data mart that supports North American Region
DATA ENTITY
DATA ENTITY TYPE
Customer data Sales orders Intersection of multiple data entities (e.g. All sales orders by customer XYZ and by month for 2006)
Master data Transactional data Historical data
Mahindra Satyam 2009
35
Diagrams
Class diagram Data Dissemination diagram Data Security diagram Class Hierarchy diagram Data Migration diagram Data Lifecycle diagram
Mahindra Satyam 2009
36
Example Class Diagrams
The purpose is to depict the relationships among the critical data entities (or classes) within the enterprise.
Account Information Actor Trigger Update Account Customer Profile Process
Payment
Contact
Agent
Service Request
Enquiry
Customer
Customer Information
Appeal
Compliant
Mahindra Satyam 2009
37
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.
Mahindra Satyam 2009
38
Example Data Dissemination Diagram
Warehouse
Customer Order History Stock
Online Account Self Service
Billing
Customer Account Balance Invoice History
Business Service Online Account Self Service
Data Entities Customer
Application Warehouse Billing Warehouse Warehouse Billing Billing
39
Order History Stock Account Balance Invoice History
Mahindra Satyam 2009
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 Archived Deleted
Customer Order
New New Dispatched Closed Archived Archived Deleted
Mahindra Satyam 2009
40
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.
Mahindra Satyam 2009
41
Example Data Security Diagram
Mahindra Satyam 2009
42
Example Data Security Matrix
ACTOR CLASS OF ROLES (JOB FUNCTION)
SOA Portfolio Financial Analyst Procurement Management and Control Not applicable
FUNCTION
BUSINESS SERVICE
SOA portfolio service Supplier portal Service Supplier Portal Service Supplier Portal Service
LOCATION
TYPE OF ACCESS
Physical Access Control (tables xyz only) Access control
Financial Analyst
Financial Analysis
NA (US, CA) EMEA (UK, DE) APJ NA (US Midwest) LA
Procurement & Spend Analyst WW Contracts System (application) WW Product Development (Org Unit)
WW Direct Procurement WW Direct Procurement WW Direct Procurement
Access control (system to system) Access Control
Geo Brand Managers
WW (all Geos)
Mahindra Satyam 2009
43
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.
Mahindra Satyam 2009
44
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 & Contracts
Mahindra Satyam 2009
45
Example Data Migration Mapping
SOURCE LOGICAL APPLICATION COMPONENT
ABM
SOURCE DATA ELEMENT
TARGET LOGICAL APPLICATION COMPONENT
CRM
TARGET DATA ELEMENT
Cust_Name
Cust_Street_Addr Cust_Street_Addr Cust_Street_Addr Cust_ContactName Cust_Tele
CUSTNAME
CUSTADDR_LINE1 CUSTADDR_LINE2 CUSTADDR_LINE3 CUSTCONTACT CUSTTELEPHONE
Mahindra Satyam 2009
46
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
Mahindra Satyam 2009
47
Example Class Hierarchy Diagram
Mahindra Satyam 2009
48
Thank you
mahindrasatyam.net
Safe Harbor This document contains forward-looking statements within the meaning of section 27A of Securities Act of 1933, as amended, and section 21E of the Securities Exchange Act of 1934, as amended. The forward-looking statements contained herein are subject to certain risks and uncertainties that could cause actual results to differ materially from those reflected in the forward-looking statements. Satyam undertakes no duty to update any forward-looking statements. For a discussion of the risks associated with our business, please see the discussions under the heading Risk Factors in our report on Form 6-K concerning the quarter ended September 30, 2008, furnished to the Securities and Exchange Commission on 07 November, 2008, and the other reports filed with the Securities and Exchange Commission from time to time. These filings are available at http://www.sec.gov
Mahindra Satyam 2009
49
