Data Modeling Enterprise Architecture

The Data Model as the Cornerstone of
Enterprise Architecture: A Case Study
RICHARD FREGGI
SENIOR SUPPLY CHAIN ARCHITECT
HP
DMZ AUSTRALIA 2015 1

About this case study
Data really is everywhere
◦ Not just for database development…
◦ But also for business processes, system architecture, solution selection, project management and
stakeholder management
The data modeler has opportunities to take on a role of critical importance
◦ The fundamental principles of data modeling still apply…
◦ However the ways and means to apply the principles must be tailored to the specific circumstances
This approach is highly effective but not well understood
◦ Most stakeholders are used to the traditional “application-centric” approach
◦ The value of the data model is becoming apparent but people need to be shown how to use it
I’d like to share and learn
◦ Who else has similar experiences and can share insights?
DMZ AUSTRALIA 2015 Page 2

Key points
Traditional architectural approach is “application-driven”. This can create problems:
◦ It’s easy to end up where you started (same set of issues, little measurable ROI)
◦ Promotes “stovepipe” systems (increasingly expensive with less flexibility to change)
◦ No objective criteria for decisions: governance for solution selection can be challenging
◦ Mapping business processes to applications is lengthy and very imprecise – therefore not done, or not done well enough
The data modeler can help resolve these problems
◦ Match data to processes and requirements
◦ Match data to IT systems (legacy and new systems)
◦ Use the data to match processes and requirements to systems!
◦ See Information Engineering, Rational Unified Process and associated methodologies
It works in real life, provided that we adapt the data modeling approach
◦ Choice of Artifacts
◦ Skills and experience in engaging stakeholders
◦ Step out of “database development” comfort zone and get involved with project managers

What do we mean by Enterprise Architecture?
Zachman Framework: architecture is “a descriptive representation” of the domain
◦ Descriptive = useful to do something important to you
◦ Domain = your business
Program code
John A. Zachman, Zachman International (810) 231-0531
DATA
what
FUNCTION
how
NETWORK
where
PEOPLE
who
TIME
when
MOTIVATION
why
CONTEXT
General
Manager
Things
important for
the business
Business
Functions
List of
business
locations
Organization
structure
Business
strategy
timeline
List of
business
priorities
CONCEPT
Line
Manager
Semantic data
dictionary
Business
Process
Business
Logistic
System
Roles and
responsibilities
Business event
timeline
Business Plan
and Budget
LOGICAL
Architect
Project Manager
Logical Data
Model
Application
Architecture
Distributed
System
Architecture
Software
interface
Processing
timing and
sequencing
Business Role
Model
PHYSICAL
IT Manager
Database
Schema
Software
Specification /
Configuration
Hardware and
network
infrastructure
Presentation
Architecture
Control
structure
System Role
Design
OUT OF CONTEXT
Subcontractor
Implementor
Database
Definition
Language
System
components
Access and
security system
Timing
definition
System Role
Configuration
Enterprise
Architecture
System
Architecture
Solution
Architecture
http://en.wikipedia.org/wiki/Zachman_Framework

What do we mean by data model?
A Semantic Data Model
◦ Documented in a Semantic Data Dictionary
Business Entity names
◦ Information as seen from the user’s point of view - not from technology point of view
Business Entity description
◦ Verbose (text)
◦ Optionally: shortlist of attributes to help users recognize how a Business Entity can/cannot
be used to perform their processes. Sometimes, Primary and Foreign Keys can help user’s
understanding of semantics
Relations
◦ Semantic level: the user’s view of where the information comes from

Traditional “application-driven” approach creates problems
It works but may result in more cost, less flexibility, duplicate effort, longer implementation
Program code
DATA
what
FUNCTION
how
NETWORK
where
PEOPLE
who
TIME
when
MOTIVATION
why
CONTEXT
General
Manager
Things
important for
the business
Business
Functions
List of
business
locations
Organization
structure
Business
strategy
timeline
List of
business
priorities
CONCEPT
Line
Manager
Semantic data
dictionary
Business
Process
Business
Logistic
System
Roles and
responsibilities
Business event
timeline
Business Plan
and Budget
LOGICAL
Architect
Project Manager
Logical Data
Model
Application
Architecture
Distributed
System
Architecture
Software
interface
Processing
timing and
sequencing
Business Role
Model
PHYSICAL
IT Manager
Database
Schema
Software
Specification /
Configuration
Hardware and
network
infrastructure
Presentation
Architecture
Control
structure
System Role
Design
OUT OF CONTEXT
Subcontractor
Implementor
Database
Definition
Language
System
components
Access and
security system
Timing
definition
System Role
Configuration

Why is the data model the cornerstone?
Use the data to match processes and requirements to systems!
Program code
DATA
what
FUNCTION
how
NETWORK
where
PEOPLE
who
TIME
when
MOTIVATION
why
CONTEXT
General
Manager
Things
important for
the business
Business
Functions
List of
business
locations
Organization
structure
Business
strategy
timeline
List of
business
priorities
CONCEPT
Line
Manager
Semantic data
dictionary
Business
Process
Business
Logistic
System
Roles and
responsibilities
Business event
timeline
Business Plan
and Budget
LOGICAL
Architect
Project Manager
Logical Data
Model
Application
Architecture
Distributed
System
Architecture
Software
interface
Processing
timing and
sequencing
Business Role
Model
PHYSICAL
IT Manager
Database
Schema
Software
Specification /
Configuration
Hardware and
network
infrastructure
Presentation
Architecture
Control
structure
System Role
Design
OUT OF CONTEXT
Subcontractor
Implementor
Database
Definition
Language
System
components
Access and
security system
Timing
definition
System Role
Configuration

Application-driven approach promotes “stovepipe” systems
Many applications to meet many requirements / constraints
Many contradicting processes, requirements and constraints make solution selection very difficult
Are we just swapping on set of issues for another?
Will the savings justify the costs?
Many projects and solutions
Many organizations, stakeholders
Legacy system limitations
Different business requirements
Differentprocesses
andrequirements
Differentcapabilities
Solution A Solution B
Solution C Solution D
Solution E Solution F
Solution G Solution H
Etc. etc.

The data modeler can help resolve these problems
Many projects and solutions
Legacy system limitations
Different business requirements
Solution A
Solution B
Solution C
Data
Model
Process
Model
System
Architect
ure
• Less applications
• Lower cost
• Faster implementation
• Less interfaces =
less latency
and better
referential integrity
Program code
DATA
what
FUNCTION
how
NETWORK
where
PEOPLE
who
TIME
when
MOTIVATION
why
CONTEXT
General
Manager
Things
important for
the business
Business
Functions
List of
business
locations
Organization
structure
Business
strategy
timeline
List of
business
priorities
CONCEPT
Line
Manager
Semantic data
dictionary
Business
Process
Business
Logistic
System
Roles and
responsibilities
Business event
timeline
Business Plan
and Budget
LOGICAL
Architect
Project Manager
Logical Data
Model
Application
Architecture
Distributed
System
Architecture
Software
interface
Processing
timing and
sequencing
Business Role
Model
PHYSICAL
IT Manager
Database
Schema
Software
Specification /
Configuration
Hardware and
network
infrastructure
Presentation
Architecture
Control
structure
System Role
Design
OUT OF CONTEXT
Subcontractor
Implementor
Database
Definition
Language
System
components
Access and
security system
Timing
definition
System Role
Configuration
Many organizations, stakeholders
The data model is the first point of consolidation / rationalization
Process model and system architecture are based on one and the same data model
Much easier to justify solutions and make decisions

Validates capacity
Provides Rules for
Caused by problem
Causes revision
Committed thru
Triggered by
Caused by decision
Recorded in
OPERATIONSPLAN
ROUGHCUTCAPAPLAN
EXCEPTION
SERVICEAGREEMENT
PUBLISHEDOPSPLAN
TRANSACTION
TRANSACTIONCOMMIT
COMMITCHANGE
EXCEPTIONREPORT
PRIORITIZEDEXCEPTIONSLIST
AUDITARCHIVE
Match data to processes and user requirements - 1
Engage key stakeholders
Explain that we need to understand WHAT
we are talking about before we decide HOW
we are going to do it
Document the result in a Semantic Data Model
The data model accounts for
◦ Viewpoints of various stakeholders / organizations
◦ Different requirements and constraints
◦ Legacy solutions, new projects
The data model is by far the best, easiest, fastest
way to consolidate these inputs

Match data to processes and user requirements - 2
Develop the process model with stakeholders, leveraging the clear understanding of
domain and common terminology
DATA MODEL
Validates capacity
Provides Rules for
Caused by problem
Causes revision
Committed thru
Triggered by
Caused by decision
Recorded in
OPERATIONSPLAN
ROUGHCUTCAPAPLAN
EXCEPTION
SERVICEAGREEMENT
PUBLISHEDOPSPLAN
TRANSACTION
TRANSACTIONCOMMIT
COMMITCHANGE
EXCEPTIONREPORT
AUDITARCHIVE
UML Sequence Diagram provides effective process definition
based on the data model!!
PROCESS / SOP
: Business
Partner
: BI Team
: Commit
Change
: Exception
: Exception
Report
: Prioritized
Exceptions
List
: Ops
Manager
1 : Detect()
2
3 : Confirm()
4 : Update()
<<create>>
5
<<create>>
6 : Update()
7
8
9

Match data to IT systems
DATA MODEL
Validates capacity
Provides Rules for
Caused by problem
Causes revision
Committed thru
Triggered by
Caused by decision
Recorded in
OPERATIONSPLAN
ROUGHCUTCAPAPLAN
EXCEPTION
SERVICEAGREEMENT
PUBLISHEDOPSPLAN
TRANSACTION
TRANSACTIONCOMMIT
COMMITCHANGE
EXCEPTIONREPORT
AUDITARCHIVE
SYSTEM ARCHITECTURE
Archive Datastore
Audit Archive
residents
Secure File Share
Service Agreement
residents
Workflow Support Tool
Exception Report
Prioritized Exceptions List
residents
Reporting Engine
Commit Change
Exception
Published Ops Plan
Transaction
Transaction Commit
residents
Planning Engine
Rough Cut Capacity Plan
Operations Plan
residents
IF4
IF2
IF3
Decisions, responsibilities, liabilities
Milestones, Events, Exceptions
Plans
IF1
Business Rules
UML Component Diagram provides system architecture
based on the data model!!

Processes and requirements are matched to solutions!
Perform a reality check / validation round with stakeholders
: Business
Partner
: BI Team
: Commit
Change
: Transaction
Exception
: Exceptions
Report
: Prioritized
Exceptions
: Ops
Manager
1 : Detect()
2
3 : Confirm()
4 : Update()
<<create>>
5
<<create>>
6 : Update()
7
8
9
PROCESS / SOP SYSTEM ARCHITECTURE
Archive Datastore
Audit Archive
residents
Secure File Share
Service Agreement
residents
Workflow Support Tool
Exception Report
Prioritized Exceptions List
residents
Reporting Engine
Commit Change
Exception
Published Ops Plan
Transaction
Transaction Commit
residents
Planning Engine
Rough Cut Capacity Plan
Operations Plan
residents
IF4
IF2
IF3
Decisions, responsibilities, liabilities
Milestones, Events, Exceptions
Plans
IF1
Business Rules

UML notation helps us leverage the data model
for key artifacts of the Enterprise Architecture
Program code
DATA
what
FUNCTION
how
NETWORK
where
PEOPLE
who
TIME
when
MOTIVATION
why
CONTEXT
General
Manager
Things
important for
the business
Business
Functions
List of
business
locations
Organization
structure
Business
strategy
timeline
List of
business
priorities
CONCEPT
Line
Manager
Semantic data
dictionary
Business
Process
Business
Logistic
System
Roles and
responsibilities
Business event
timeline
Business Plan
and Budget
LOGICAL
Architect
Project Manager
Logical Data
Model
Application
Architecture
Distributed
System
Architecture
Software
interface
Processing
timing and
sequencing
Business Role
Model
PHYSICAL
IT Manager
Database
Schema
Software
Specification /
Configuration
Hardware and
network
infrastructure
Presentation
Architecture
Control
structure
System Role
Design
OUT OF CONTEXT
Subcontractor
Implementor
Database
Definition
Language
System
components
Access and
security system
Timing
definition
System Role
Configuration
Semantic
Model
Use Case Diagram
Sequence
Diagram
ERD
Component Diagram
Deployment
Diagram
MS Excel

Role of the data modeler
Develop the data model! But also…
Promote use of the common language from the Semantic Data Model
Facilitate discussion among many stakeholders: internal, business partners,
solution vendors
Tight partnership with project managers and sponsors
Knowledge of UML or equivalent notation
Willing and able to ‘get out there’, get involved and make a difference!

Partnership with project managers is critical for success
Artifacts are used for project definition
Architectural Artifact Project Control Document
Data Model Project glossary / definition of terms
Project scope definition
Project approach
Use Case Diagrams
Sequence Diagrams
Project sponsor assignment
Project team roster
Stakeholder management plan
Test plan definition
Management of change and training plan
Component Diagram
Deployment Diagram
Project scope definition
RFP, RFQ, vendor Statement Of Work
Consolidated /
rationalized
requirements
Who will do it,
How will do it
Hardware,
Software,
Network
changes

Thank you
Who has similar experiences?
Different experiences?
Feedback?

Data Modeling Enterprise Architecture

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (9)

Similar to Data Modeling Enterprise Architecture

Similar to Data Modeling Enterprise Architecture (20)

More from Richard Freggi

More from Richard Freggi (10)

Data Modeling Enterprise Architecture