Business Rules For Metadata Governance & Stewardship

1
Course: F5A Instructor: Robert J. Abate, CBIP Course: Business Rules for Metadata, Governance, and Stewardship
Business Rules For Metadata,Business Rules For Metadata,
Governance, And StewardshipGovernance, And Stewardship
Instructor: Robert Abate, CBIP
Track: Data Integration / Data Analysis & Design
Course: F5A
Date/Time: November 10, 2006 / 8:00 AM – 11:15 AM
BusRulesMetadata
Governance

2
Business Rules For Metadata, Governance And StewardshipBusiness Rules For Metadata, Governance And Stewardship
7:15 AM – 8:00 AM Breakfast
8 :00 AM – 8:20 AM Introduction, Definitions &
History
8 :20 AM – 9:45 AM The Business Rules Approach
9:45 AM – 10:00 AM Morning Coffee Break
10:00 AM – 10:25 AM Wrapping Rules With Information
Management Policies
10:25 AM – 10:45 AM Integrating Metadata And
Advanced Usage Of
10:45 AM – 11:15 AM Questions & Answers
Course AgendaCourse Agenda

3
Business Rules For Metadata, Governance And StewardshipBusiness Rules For Metadata, Governance And Stewardship
Inserted Funny Pictures Will Keep You AwakeInserted Funny Pictures Will Keep You Awake
1. As proposed by the project sponsor
2. As defined by the requirements doc’s
3. As designed by the Senior Analyst
4. As produced by the programmers
5. As installed at the user’s site
6. What The User Really Wanted!

4
Introduction To The Business Rules ApproachIntroduction To The Business Rules Approach
“Analysts report that as many as 71% of software
projects that fail do so because of poor
requirements management, making it the single
biggest reason for project failure”
– CIO Magazine, November 15th, 2005
Failure was also defined as:
“Analysis Paralysis”
“Scope Creep”
A never ending test cycle
Redevelopment of systems after implementation
““The Importance Of A Solid Approach To Capture Of RulesThe Importance Of A Solid Approach To Capture Of Rules””

5
Introduction, Definitions & HistoryIntroduction, Definitions & History
““Business EngineeringBusiness Engineering””
Introduction To The Business Rules Approach
History
Business Engineering
What The Critics Are Saying
Definitions Of Terms
Let no man say that I have said nothing new,
the arrangement of the material is new.
Just as the same words differently arranged
form different thoughts.
- Blaise Pascal
BusRulesMetadata
Governance

6
The “Business Rules Approach” was
originally developed so that the
business could understand their model
and requirements without an IT
interpreter
Using the adage: “A Picture Is Worth
A Thousand Words” – This approach
would be ENTIRELY graphically
depicted and documented (on the
graphs themselves)
““Simplifying BusinessSimplifying Business””

7
The “Business Rules Approach” is a methodology for
the capture of business requirements
It uses a structured methodology that can be automated into a Model Driven
Development [MDD] paradigm
The source of these requirements is the business
people themselves (and IT mgmt)
This process works equally well for:
Business Intelligence Solution
Services Oriented & Event Driven Architectures
Custom Applications Development & Rules Engines
When wrapped with Governance & Metadata, it forms
the “complete picture” of solution required.
““Business EngineeringBusiness Engineering””

8
The Business Rules Approach is a combination of,
and can be projected onto the following:
Structured Analysis & Design technique set
Object Oriented Analysis & Systems Engineering technique set
Zachman© Framework
It was engineered using Methods Engineering and
was meta-modeled first to prove it works!
Techniques and drawings were derived from meta-model
Has been in use today at major corporations
““History Of (Derivation)History Of (Derivation)””

9
The approach is a holistic one
The idea that all the properties of a given system cannot be
determined or explained by the sum of its component parts alone.
Instead, the system as a whole determines in an important way how
the parts behave or "The whole is more than the sum of its parts“
Component-based approach
The methodology consists of objects/components that can be
plugged in and out of a object-oriented or component framework
Approach covers the three key components
of a solution in an integrated manner:
Business Architectural Level (What do we want to do in the
business)
Procedure Architectural Level (How do we want to do it)
Technology Architectural Level (With what infrastructure do we do it)
““The Business PerspectiveThe Business Perspective””

10
The best way of constructing an integrated method
set is to the model the methodology itself
Meta-Model (or model of a model)
Any system can be modeled by using the
techniques from a methodology – in the same way
a methodology is a system that can be modeled
with the techniques of the same methodology
The models constructed of the Business Rules Approach clearly indicate that
these techniques integrate and are reproducible
The Business Rules Approach works to document and define any system!
““Methods EngineeringMethods Engineering””

11
Translation of strategic to practical
Business Rules determine Architecture
Architecture determines data access/delivery
Business-wide requirements management and
documentation of single source of truth
Impact prediction and quantification
“Componentization” of business, processes and
architecture based upon scientific rules to ensure
Greater responsiveness to change
Agility of the business
Making the “invisible” visible and manageable
Business Plans
Processes
Architectures
““Benefits Of Business EngineeringBenefits Of Business Engineering””
Infrastructures
Organizational Structures
Timing Dependencies
Event Dependencies
Other Dependencies
Protection of investment
Very high reuse
Architecture determines Infrastructure

12
Adaptability. IT solutions need to be more adaptable to a
changing landscape of standards, technologies, products
and service producers and consumers.
Past, current & future technology investments need
to leveraged. Rewrites or replacement of legacy systems
(i.e., anything in production) is deemed as too expensive.
Multiple levels of Integration. Integration points must be
at the data, application logic and business process levels.
Security. Ensure that the right people are participating in
the right process & accessing the right data.
““Needs For Business EngineeringNeeds For Business Engineering””

13
““Business Engineering Within ContextBusiness Engineering Within Context””
Business Architecture Drives IT Architecture

14
Business Intelligence
Business Rule Encapsulation
Business Rule Engines
Metadata
Open & Product-Based Engines (ETL, etc.)
Services Oriented Architectures
Process Alignment, Service Development, Orchestration,
Choreography, etc.
““The Business Rules Approach EnablesThe Business Rules Approach Enables””

15
With the Business Rules Approach, we will be
using the following terms:
Metadata
Metadata is information about the data
Whereas, mathematics is the language of science, metadata is the
language of Data, Business, Application, and Technology
Architecture.
Metadata is the Who, the How, the Where, the When, and the Why of
things we manage and the activities performed in managing them.
Metadata is crucial to quality solution design and to maintaining data
quality and consistency in the operational environment.
““Definitions Of TermsDefinitions Of Terms””

16
Business Vocabulary (Terms)
The dictionary for all terms used within the business process, model
and diagrams
Metadata & Business Rules enforcement require the use of a
common terminology – that has to be managed
“In the opinion of many people in industry,
there is nothing more important for the
transaction of business than the use of
operational definitions. It could also be said
that nothing is more neglected.” Dr. Deming

17
The Business Perspective
Real World vs. Specialized
♦Webster Dictionary vs. Internal Company/Organization/Industry
Definition.
Synonyms
♦Two or more terms for exactly the same concept
– Shopper, Planner, Attendee, Guest
Homonyms
♦Two or more concepts for exactly the same term
– Shop: A place where merchandise is sold
– Shop: An type of interaction with a Guest prior to booking a reservation
Categorization
♦Grouping or Hierarchy

18
Taxonomy
Classification Schemes For Things: Concepts, Objects, Actions &
Events
♦ Often Times Is Hierarchical
Use An Integrated Collection Of Taxonomies – Rather Than A Single
Taxonomy
Build Using Controlled Language Sets (See previous slides on business
vocabulary & perspective)
Taxonomies Ad In Establishing:
♦ A Single Source Of The Truth
♦ An Unambiguous Starting Point For Communications Between
Groups Or Individuals
Taxonomy (from GreekTaxonomy (from Greek TaxisTaxis meaning arrangement or division andmeaning arrangement or division and nomosnomos meaning law) is the sciencemeaning law) is the science
of classification according to a preof classification according to a pre--determined system, with the resulting catalog used to provide adetermined system, with the resulting catalog used to provide a
conceptual framework for discussion, analysis, or information reconceptual framework for discussion, analysis, or information retrievaltrieval…… In practice, a good taxonomyIn practice, a good taxonomy
should be simple, easy to remember, and easy to useshould be simple, easy to remember, and easy to use…… Taxonomy Definition FromTaxonomy Definition From www.Whatis.comwww.Whatis.com

19
Semantic Consistency
Business
Domain
Domain Objects
Metadata
yields
Executables
Database
Tables
Messages,
Transactions
Implemented as
XML Schemas,
DTDs
Service
Descriptions
Dictionaries
Taxonomies
Takes the form of
Business
Domain
Business
Domain
Domain ObjectsDomain Objects
MetadataMetadata
yields
ExecutablesExecutables
Database
Tables
Database
Tables
Messages,
Transactions
Messages,
Transactions
Implemented as
XML Schemas,
DTDs
XML Schemas,
DTDs
Service
Descriptions
Service
Descriptions
DictionariesDictionaries
TaxonomiesTaxonomies
Takes the form of
Must apply To ALL
domain artifacts:
Metadata
Domain Objects
Promotes Business
Understanding That The
Underlying Data Is The
Same, View Is Different
Promotes A Common
Language For Business
& IT When Combined
With A Dictionary

20
With the Business Rules Approach, we will be
documenting the eight components (or facets)
of Business Systems:
Data
Function
Time
Organization / Responsibility
Location
Strategy
Object
Operation

21
With the Business Rules Approach, we use
drawings to exemplify relationships, and
responsibilities.
Depending upon the implementation tool /
partner chosen, symbols and notations vary
widely.
Choose an approach and get training to
understand and use a structured
methodology.

22
The Business Rules ApproachThe Business Rules Approach
““From Process To DataFrom Process To Data””
Paradigm Of Layered Architectural Abstractions
Business Rules Panels - Dimensions
Business Rules Engineering Diagrams
Attribute Dependency Diagram [ADD]
System Operation Diagram [SOD]
Functional Structure Diagram [FSD]
Data Structure Diagram [DSD]
Object Interface Diagram [OID]
Process Flow Model
Organizational Hierarchy Diagram
BusRulesMetadata
Governance

23
One way to solve a problem is to list all of the
requirements of the system and try to find an
approach that answers all the concerns (ie: Zachman©
Framework)
Another is to group the problems into layers and solve
each layers issues knowing that you can ignore the
problems in the other layers (using the engineering
paradigm of layered architectural abstractions)
In common to both, each layer is composed
(described by) eight architectural facets:
““Paradigm Of Layered Architectural AbstractionsParadigm Of Layered Architectural Abstractions””
Location
Organization
Function
Data
System Operation
Strategy
Object (Packaging)
Time

24
““Traditional Methodologies (i.e.: ZachmanTraditional Methodologies (i.e.: Zachman©© Framework)Framework)””
BUSINESS ARCHITECTURE LEVEL
APPLICATIONS ARCHITECTURE LEVEL
(Procedure)
TECHNOLOGY ARCHITECTURE LEVEL
(Infrastructure / Environment)
GOVERNANCE
ProjectManagement
ChangeManagement
DESIGN
PROCESS MANAGEMENT
WORKFLOW
APPLICATIONS
Strategy
Object
Time
Location
System
Operation
(More than just
Data Flow)
Organization
Function
Data
Example Classic MethodologyPROCESS:
Listing of all
requirements
of the system
Next,
engineer an
approach that
answers all
the
requirements
and issues
found during
the
requirements
process
FINDINGS:
Works in
most cases
Difficult to
break into
components

25
““Business Rules Engineering LayersBusiness Rules Engineering Layers””
GOVERNANCE
Security,Data,SLA’s,ServicesandITPortfolioManagement,
ChangeManagement,EnterpriseArchitecture,Process/Policies
QUALITYCONTROL
QualityAssurance,Testing,DataQualityManagement
BUSINESS ARCHITECTURE
Mission / Vision, Requirements, Business Rules,
Organizational Alignment, Critical Success Factors,
Business Process Design
APPLICATIONS ARCHITECTURE
Process Alignment, Services Definition, Services Architecture,
Enterprise Applications Integration Components
INFORMATION ARCHITECTURE
Data Delivery Architecture, Master Data Management, Metadata,
Business Intelligence, Data Integration Components
TECHNOLOGY ARCHITECTURE
(Infrastructure / Environment)
Networks, Servers / Hardware, Operating Systems,
Legacy (Non-Service Enabled) Applications
PROCESS:
Use diagrams
to describe
inter-
relationships
between
layers and
between
items
Use
mathematical
algorithm to
validate and
output
requirements
FINDINGS:
Validated
work
products
Component-
based

26
““Business Rules Engineering DiagramsBusiness Rules Engineering Diagrams””
BUSINESS ARCHITECTURE
Mission / Vision, Requirements, Business Rules,
Organizational Alignment, Critical Success Factors
Business Process Design, and Process Services Choreography
APPLICATIONS ARCHITECTURE
Process Alignment, Services Definition, Reference Architecture,
Enterprise Applications Integration Components
INFORMATION ARCHITECTURE
Data Delivery Architecture, Master Data Management, Metadata
Business Intelligence, Data Integration Components
CLIENT HARDWARE & SOFTWARE ENVIRONMENT
(INFRASTRUCTURE)
Networks, Servers / Hardware, Operating Systems,
Legacy (Non-Service Enabled) Applications
WHO WHAT WHERE WHEN HOW WHY
Organization Data Location Time Function Process Strategy
• Organization
Chart
• Roles &
Responsibilities
Chart
• Entity
Relationship
Diagram [ERD]
• Attribute
Dependency
Diagram [ADD]
• Data Structure
Diagram [DSD]
• Map To
Organization
• Map To Events
• Time Definitions
• Events
• Triggers
• Goals To
Process
• System
Operation
Diagram [SOD]
• Flow Chart
• Critical Success
Factors
• Goals / Direction
• Business
Process
Improvement
• Support
PROCESS:
Eight
dimensions of
requirements
over the four
architectural
layers
We will focus,
due to time
constraints,
on the
Business
Layer
Diagrams for
each of the
facets are
identified
FINDINGS:
Complete
business
rules

27
““Business Rule Panels For Each FacetBusiness Rule Panels For Each Facet””

28
““Business Rule Panels For Each Facet IIBusiness Rule Panels For Each Facet II””

29
““Business Rule Panels For Each Facet IIIBusiness Rule Panels For Each Facet III””

30
““Business Rules DimensionsBusiness Rules Dimensions””

31
““Business Rules Approach Key DiagramsBusiness Rules Approach Key Diagrams””
Subprocess
Workstep
Business
Activity
Process
Decompositions
are hierarchical
lists
Flow diagrams
incorporate
sequencing and
logic
PROCESS:
Approach is
to
document
the
business
rules and
the
surround-
ing views
so that we
can visually
grasp the
require-
ments.
Document
in further
detail in
each step
of process.

32
““Business Rules Approach Key Diagrams IIBusiness Rules Approach Key Diagrams II””
Using this approach, a couple of diagrams provide
a wealth of information and can ordinarily
describe a majority of the solution:
Attribute Dependency Diagram [ADD]
System Operation Diagram [SOD]
Functional System Diagram [FSD]
Data System Diagram [DSD]
Object Interface Diagram [OID]
Process Flow Model
Organizational Hierarchy Diagram
In the following slides, we will show examples of
these diagrams…

33
““Attribute Dependency Diagram [ADD]Attribute Dependency Diagram [ADD]””
Attribute
Dependency
Diagram [ADD]
An Attribute
Dependency
Diagram (ADD) is
a mathematical
representation of
the business
rules.
An ADD could be
manipulated by
mathematical
algorithms to
generate various
results.

34
““Attribute Dependency Diagram IIAttribute Dependency Diagram II””
Evolution Of The ADD
Any business can be expressed by
associating objects and events with
one another.
Events always involve the objects of
the business.
There are very specific semantic
associations between the events and
the objects of a business that we can
express mathematically with the aid of
a graphical depiction or technique.
We will define the objects and
semantics – in terms of Metadata –
creating the SINGLE SOURCE TRUTH!
EVOLUTION OFATTRIBUTEDEPENDENCYDIAGRAM
Assess
Medical
Condition
1
Man
Practice
ID# ,Date
Diagnosis
Med#
Surname Med# ,Date
HrsWorked
Pract#
ID#
Address
DateOfBirth
PracticeName
FirstName
Doctor
Practice
Person
Objects and Events Uniquely
Identified and Naturally
Related
Assess
Medical
Condition
Entity
Name
2
Entity
Unique
Identifier
ID# ,Date
Diagnosis
ID#
DateOfBirth
FirstName
Person
Simplify Notation
3
Attribute Dependency Diagram
Medical
Doctor
E
O
O
E O
Person
Manning Practice
Diagnosis
Surname
DateOfBirth
FirstName
HrsWorked
Address
PracticeName
Id#
Date
Med#
Id#
Med#
Date
Pract#

35
““Attribute Dependency Diagram IIIAttribute Dependency Diagram III””
Attribute
Dependency
Diagram
or
[ADD]
An ADD
could be
manipulated
by four
algorithms to
generate
various
results.

36
““Attribute Dependency Diagram IVAttribute Dependency Diagram IV””
Deliverables Of The ADD
Mathematically determined architectural development order of sub-systems.
Scope of all the systems. What does a system include? How big is it? What does it
exclude?
A base to normalize data from and high-level definitions of data elements (context).
It represents business semantic in one of three ways:
♦ Sub-set combinations
♦ Functional dependencies
♦ In key attribute sets
Mathematically determined system cohesion.
Determines the context of a system. Context is expressed in terms of which building
blocks the business consists of and which ones are naturally related to which
others.
It provides a base from which mathematically derived objects are defined, as in the
Object Oriented paradigm. These object definitions are in terms of which methods
are associated with the objects, and which properties are associated with which
objects.

37
““ADD Development & TipsADD Development & Tips””

38
““System Operation Diagram [SOD]System Operation Diagram [SOD]””
“A True System
Integration Diagram”
The SOD represents
the flow between data
and functions (and
checks completeness
of data and functions).
It also indicates the
responsibilities,
location, time, objects
and others.

39
““System Operation Diagram IISystem Operation Diagram II””
System Operational
Diagram [SOD]
If there is no
integration, you can
start with SOD on
Business Architectural
Level
At the Procedural
Level, the SOD
represents the flow
between data and the
“how” functions –
indicating
responsibility

40
““Functional Structure Diagram [FSD]Functional Structure Diagram [FSD]””
“Goal
Decomposition
Diagram”
Indicates
complete set of
goals needed to
achieve the
desired business
functions
Effective at
determining the
reusable areas of
business
processes and
establishes
correct context of
activities.

41
““Example Functional Structure Diagram [FSD]Example Functional Structure Diagram [FSD]””

42
““Functional Structure Diagram [FSD] TipsFunctional Structure Diagram [FSD] Tips””

43
““Data System Diagram [DSD]Data System Diagram [DSD]””
“Diagram Of The
Data Within The
System”
Derived directly from
the Attribute
Dependency Diagram
[ADD]
Logical data model
for the system
Once explained,
business users
actually grasped its
content!

44
““Object Interface Diagram [OID]Object Interface Diagram [OID]””
Diagram Of The Objects & I/F’s
Within A System

45
““Process Flow ModelProcess Flow Model””
Process Flow
Model
Displays
business
functions with
context of
process / flow
Flows show inter-
relationship
between entities
and timing
Deliver
Business
Solution
3.5
Develop
Business
Cases
3.3
Infrastructure
Mgmt
6.0
Business Unit
Direction
Business Unit
Plans
Issues,
Questions,
Requests
Cust.
Satisfaction
Svc.
Level
Reqt's
Acceptance
Criteria
Customer
Service
4.0
Business Needs/
Exceptions
Develop
Customer
Relationship
3.2
ITG
Planning
1.0
Develop
Construction
Requirements
& Plan
3.4
Recom-
mended
Business
Cases
Approved
Business
Cases & Impl.
Sched.
Detailed
Business Reqts
Construction
5.0
Detailed
System
Reqts
System
Tested
Business
Solution Delivered
Business
Solution
Training
Customer
Service
4.0
Training
Materials
Develop
Business
Unit
Liaison
3.0
ITG Improvement
Recommendations
) (
Construction
5.0
Status/Exceptions
Problem/Trends
Results
) (
Customer
Satisfaction
Tools
Acceptance
Test Failures
) (
Maintenance Change Request/Training
Business
Units
Business
Units
Processes
7 & 8
Service Requests
DAT Consulting
Level 1 Cotter Strategic
Direction
ITG Strategic
Direction
Process
Measurements
ITG
Planning
1.0
) () (
Develop
Business
Unit
Plans
3.1
SLAs
Value
of IT

46
““Organizational Hierarchy DiagramOrganizational Hierarchy Diagram””
Organizational Hierarchy
Diagram
Displays the organization and
responsibilities of groups
Can also be used to display
functionality into organizational
hierarchy.

47
Wrapping Rules With IM PoliciesWrapping Rules With IM Policies
““Covering Rules WithCovering Rules With
Governance & StewardshipGovernance & Stewardship””
Information Management
Data Governance & Stewardship
Examples Of Working Frameworks
BusRulesMetadata
Governance

48
Information Management [IM] is a PROCESS and not a technology
The aim is to ensure that individuals involved in critical business processes have the right information
To make decisions and take action quickly and effectively
Information Management is the means by which an organization plans, governs,
budgets, controls, exploits and disposes of the organization’s information resources.
The goal of information management is to maximize business value and optimize
performance
Information Management is achieved through enterprise architecture and policies
Requires alignment to corporate strategy & objectives
Corporate Strategy & Objectives is the vision of the business implemented in the form of requirements and
SLA’s and imposed constraints against the Information Technology framework including costs and needed
Information Technology services
Provides direct business value
Data storage and retrieval costs, data security costs, SOX compliance, etc.
Architected, Enterprise Information Management Frameworks have been proven to
reduce the cost of providing Information Technology [IT] support and development,
while documenting business process and reusability considerations (which in turn
increases both productivity and agility of the enterprise).
““What Is Information Management or IM?What Is Information Management or IM?””

49
The Information
Lifecycle is the
corporations
determination of how
data should be managed
& stored
A plan to handle
accordingly
““What Is The Information Lifecycle?What Is The Information Lifecycle?””

50
““What Is The Information Lifecycle GraphicallyWhat Is The Information Lifecycle Graphically””

51
Data Governance is
the development and
integration of a set of
rules (policies,
guidelines, and
standards) for
managing the
corporation’s data.
Data Stewardship is
the execution of the
policies and
procedures set forth
by the Data
Governance
Framework.
Mission
Management
Execution
Data Governance provides a
link between technology and
business.
That link is a common language
and understanding of shared
business data.
It should facilitate the
development of business
around that data.
Data Stewardship provides the
mechanism to implement the
policies and limitations imposed
by the Data Governance Plan
or management.
It should manage the
development and execution of
business data and day to day
exceptions around that data.
““What Is Data Governance & Stewardship?What Is Data Governance & Stewardship?””

52
Gaps in Legacy Life
Cycle methodologies
Traditional management
structures, project
scoping,
and organizational
communication
Lack of management
support to governance
Traditional risks.. Risk Mitigation…
Challenges to addressing Best Practices In
IM risks include: Implementations…
““Challenges To Data Integration ProjectsChallenges To Data Integration Projects””

53
Reducing
Risk In Data
Integration
Projects
REQUIREMENTS
TRANSITION
BUILD & TEST
DESIGN
DEFINE SOLUTION
Typical Life Cycle Methodology
Data Governance
Team works with
Project Team to
assess level of risk &
determine appropriate
level of involvement by
special teams.
Perform detailed
Data Analysis.
Capture & store
re-usable information
Contribute to test
criteria.
Data Governance
Team participates in
project Lessons
Learned.
Perform Issue
Resolution as
required. Balance
needs of production
systems, users of
data, standards
Additional Steps to Reduce Risk
From Data Integration Issues (Data Governance)
PLANNING
Knowledge Management Layer:
Metadata, data, information about systems, data production, data usage, projects, stewards, governance issue resolution
Add two key
steps & one
ongoing set of
activities
Implement
customized
Data
Governance /
Stewardship
program and
framework
““An Approach That Reduces RiskAn Approach That Reduces Risk””

54
““Key To SuccessKey To Success –– Checks & BalancesChecks & Balances””

55
Issue Identified Early in
Lifecycle =
Lower Cost to Resolve !
Checks & Balances
between data quality,
applications, and business
information usage.
Trigger:
Entering
design
5.Communicate
Status
Manage Process
Governance
Steps
Stewardship
Steps
ExecutiveCouncil
Othergroupsas
appropriate
Data
Governance
Manager
ProjectorFunctional
Teams,
othersasappropriate
Business
Stewards
QualityStewards
Application .
Stewards
2. Conduct Data Analysis
ProjectManagers
1. Plan.
Set Project and
Enterprise Goals,
Assess & Communicate
Required Levels of
Involvement
GovernanceManagementTeam 3. Conduct Risk Analysis.
Decide Which Risksto
Accept or Manage, Whichto
Explore Further Through
Issue Resolution Process.
Adjust Project as Needed
4. Decide How to Proceed
Adjust Expectations, Schedule,
Budgets as Needed
““Handling Data AnalysisHandling Data Analysis””

56
Recognition that a different approach or process
flow is needed for:
Responsive Mode: a project is failing in the test stages of the development
life cycle due to “bad data”
Proactive Mode: taking initiatives to ensure both integrity and quality of
data – along with PROPER USAGE of that data to mitigate need for
responsive process
Activities Include:
Supporting project teams and functional groups without disrupting them
Data Governance special team - integrating with PMO’s
Data Governance vs. Data Stewardship duties
““Governance Differentiators & ActivitiesGovernance Differentiators & Activities””

57
Info
Production
Business Units
produce data
using business
applications
Info
Production
Info
Production
Business Units
produce data
using business
applications
Info
Usage
Management, Marketing, and
other functions
use information
in reports, GDM, DWs, etc.
Info
Usage
Info
Usage
Management, Marketing, and
other functions
use information
in reports, GDM, DWs, etc.Info
Management
IT performs Data Architecture, Administration, Analysis, and
administers Standards & Policies
Checks and
Balances
Info
Production
Info
Usage
Info
Management
Data As Asset!Data As Asset!
““Traditional Vs. Synergistic Information UsageTraditional Vs. Synergistic Information Usage””

58
Repository:
A knowledge
environment
Data Quality:
Proactive
efforts to
identify
data issues
Data Governance:
Policies and Procedures
Executive
Leadership
Stewardship/Content
Management
Governance
Proactive &
Reactive Processes
Executives authorize solutions and
provide issue resolution — even if
they impact organizational structure
or project costs and timelines.
Stewards and Content Managers
represent the Business community. They
work with dedicated governance
managers through processes that
administer data based on business rules.
-Create standard definitions for data.
-Establish authority to create, read,
update and delete data.
-Ensure consistent and appropriate
usage of data.
-Provide SME in the resolution of data
issues
Governance managers are
responsible for the
development and
implementation of the
policies, guidelines, and
standards for managing the
corporation’s data.
““Creating Synergy Within The Information EnvironmentCreating Synergy Within The Information Environment””

59
Directors
Business and IT
Content ManagersData Stewards
Bus. Data
Governanc
e Mgr.
Internet
Publisher
W
orkflow
andContent
ManagementProcesses
Proactive
and
Reactive
Processes
- WEB Owner
-Governance
Process owner
-New Development
- Metadata
Business Owner
-Governance
Process owner
Leadership
Business Community
““One Method Of ImplementationOne Method Of Implementation””

60
Executive Team
•Status Reviews
•Resource Issues
•Prioritization
•Strategy Reviews
•Project Oversight/Coordination
•Risk Analysis/Management
Architecture
•XML / DTD Schema
•Guiding Principles
•Solution Templates
•Compliance
•Component / Services Framework
•Application Framework Models
•Reference Architecture
Transform Build Run Manage
Business Team Application Team Middleware Team Infrastructure Team
•Receive Logical Reqs.
•Create Build Specs.
•Build Components
•Build Services
•Testing
•Quality Assurance
•Project Planning
•Certify Components
•Stress Testing
•Reuse / IC Mgt.
•Messaging/EAI
Dictionary
•Services
•Request ID
•XML Specs
•Operations
•Data Model
•Network
•Servers
•MainFrames
•E*Way Adapters
•Database Admin.
•Vendor Relations
•Business Process
Leadership
•Business Process
Definition
•Business Use Cases
•Build Requirements
•Acceptance Testing
ReviewsReviews Reviews
PDR CDR PPR
PDR
CDR
FPR
SRR
SRR
PDR
““Example Of Working Model For Information ManagementExample Of Working Model For Information Management””

61
““Example Of Working Model For Information ManagementExample Of Working Model For Information Management””
Strategy & Definition Of Governance Framework.
Scenarios & Validation Of Data Environment.
Data Lifecycle Defined For Organization.
Formalized Organization.
Responsive Process Introduced.
Proactive Process Introduced
Business Rules Managed.
Expanded Business Involvement.
Stewardship Culture
Observed.
Strategic
Governance.
Seven Step
Maturity Model
First introduced by:
Martha Dember of CIBER

62
Integrating MetadataIntegrating Metadata
““A Single Source Of The TruthA Single Source Of The Truth””
What Is Metadata
Why Is It Valuable
Who Owns Metadata
How Do You Capture
BusRulesMetadata
Governance

63
““A Single Source Of The TruthA Single Source Of The Truth””
Metadata (GreekMetadata (Greek -- meta "after" and Latinmeta "after" and Latin -- datadata
"information") is data that describes other data."information") is data that describes other data.
Generally, a set of metadata describes a single set of data, calGenerally, a set of metadata describes a single set of data, called a resource.led a resource.
Metadata promotes agreement on nature / content ofMetadata promotes agreement on nature / content of
datadata –– ““source of the truthsource of the truth””
AA ““singlesingle”” dictionary fosters common understandingdictionary fosters common understanding
and clear communications;and clear communications; two or more breedtwo or more breed
confusionconfusion
Metadata has long been used in BI solutions to:
Define elements on a report within a BI toolset
Describe elements moved using an ETL tool (along with operational stats)
Added to the data models as artifacts

64
“Make It Easier & Faster To Adapt App’s To Changes
In Business” 1
“Metadata Remains Key Interoperability Factor For
Integrating Disparate Systems & Data” 2
Systems Cannot Be Efficiently Maintained Without
Metadata 3
Metadata Design Is in the Interest Of Reuse 4
““What Are The Critics SayingWhat Are The Critics Saying””
1 ““Services Based, Services Oriented Defined: Ready To Integrate IsServices Based, Services Oriented Defined: Ready To Integrate Is Core ValueCore Value””,, Uttam Narsu, 9/16/2002, GIGA Information Group
2 ““Metadata Market DriversMetadata Market Drivers””,, Lou Agosta, 11/13/2002, GIGA Information Group
3 ““Metadata Treated HaphazardlyMetadata Treated Haphazardly””,, Forrester Research,Forrester Research, 2/28/2003, Lou Agosta, Page 1-2
4 “Metadata Driven DesignMetadata Driven Design””,, Forrester Research,Forrester Research, 2/25/2003, Lou Agosta, Page 1

65
““The Many Benefits Of MetadataThe Many Benefits Of Metadata””
Creates an unambiguous language for a
corporation to discuss business
Required for compliance (SOX, BASIL II, …)
A centralized metadata management
architecture, allows users to assess the
downstream impact of change, before the
changes are made (Cross-Impact Analysis)
This importance is best conveyed though example: responsibilities for taking
data from acquisition, though integration, to analysis and to delivery to
business users may rest with multiple, and sometimes disconnected groups.
The data however is not disconnected. If one group makes a change to a
data model or data process / format, that change will have a ripple effect
throughout the entire data lifecycle

66
““Sample Metadata Repository Context DiagramSample Metadata Repository Context Diagram””
Metadata
Repository Tool
Data Architect/Admin Metadata Steward
Metadata Tool Admin
Solution Knowledge Worker
Business Knowledge Worker
Data
Architecture
Web Site
Other Metadata Sources
EAI Hub
<<uses>>
May invoke

67
““Sample Metadata Workflow Process & ArtifactsSample Metadata Workflow Process & Artifacts””

68
““SampleSample Meta(dataMeta(data) Model) Model””

69
Open Questions & AnswersOpen Questions & Answers
Thank you for your attention
and feel free to stay around
for answers to those
longer questions…
Faculty Contact Information:
Robert J. Abate, CBIP
rabate@rcgit.com
(212) 547-3108 Mobile
Or just blank stares…
BusRulesMetadata
Governance

Business Rules For Metadata Governance & Stewardship

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Business Rules For Metadata Governance & Stewardship

Similar to Business Rules For Metadata Governance & Stewardship (20)

More from Robert J. Abate, CBIP, CDMP

More from Robert J. Abate, CBIP, CDMP (8)

Business Rules For Metadata Governance & Stewardship