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