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, CBIPTrack: Data Integration / Data Analysis & DesignCourse: F5ADate/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 15 th, 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 Be tween

Groups Or Individuals

Taxonomy (from Greek Taxonomy (from Greek Taxis Taxis meaning arrangement or division and meaning arrangement or division and nomosnomos meaning law) is the sciencemeaning law) is the scienceof 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 aconceptual framework for discussion, analysis, or information reconceptual framework for discussion, analysis, or information retrievaltrieval…… In practice, a good taxonomyIn practice, a good taxonomyshould be simple, easy to remember, and easy to useshould be simple, easy to remember, and easy to use…… Taxonomy Definition From Taxonomy 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

Semantic Consistency

Business DomainBusiness Domain

Domain ObjectsDomain Objects

MetadataMetadata

yields

ExecutablesExecutables

Database Tables

Database Tables

Messages, TransactionsMessages,

Transactions

Implemented as

XML Schemas, DTDs

XML Schemas, DTDs



DictionariesDictionaries

TaxonomiesTaxonomies

Takes the form of

�Semantic Consistency�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 so lve

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)

GO

VE

RN

AN

CE

Pro

ject

Man

agem

ent

Cha

nge

Man

agem

ent

DE

SIG

N

PROCESS MANAGEMENT

WORKFLOW

APPLICATIONS

Str

ate

gy

Ob

jec

t

Tim

e

Lo

ca

tio

n System

Operation

(More than just

Data Flow)

Org

aniz

ati

on

Fu

nc

tio

n

Da

ta

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””

GO

VE

RN

AN

CE

Sec

urity

, Dat

a, S

LA’s

, Ser

vice

s an

d IT

Por

tfolio

Man

agem

ent,

Cha

nge

Man

agem

ent,

Ent

erpr

ise

Arc

hite

ctur

e, P

roce

ss /

Pol

icie

s

QU

AL

ITY

CO

NT

RO

LQ

uality Assurance, T

esting, Data Q

uality Managem

ent

BUSINESS ARCHITECTUREMission / Vision, Requirements, Business Rules,

Organizational Alignment, Critical Success Factors,Business Process Design

APPLICATIONS ARCHITECTUREProcess Alignment, Services Definition, Services Architecture,

Enterprise Applications Integration Components

INFORMATION ARCHITECTUREData 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 ARCHITECTUREMission / Vision, Requirements, Business Rules,

Organizational Alignment, Critical Success FactorsBusiness Process Design, and Process Services Chore ography

APPLICATIONS ARCHITECTUREProcess Alignment, Services Definition, Reference A rchitecture,

Enterprise Applications Integration Components

INFORMATION ARCHITECTUREData 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

BusinessActivity

ProcessDecompositions 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 OF ATTRIBUTE DEPENDENCY DIAGRAM

AssessMedicalCondition

1

ManPractice

ID# ,Date

Diagnosis

Med#

Surname Med# ,Date

HrsWorked

Pract#

ID#

Address

DateOfBirth

PracticeName

FirstName

Doctor

Practice

Person

Objects and Events UniquelyIdentified and Naturally

Related

AssessMedicalCondition

EntityName

2

Entity

UniqueIdentifier

ID# ,Date

Diagnosis

ID#

DateOfBirth

FirstName

Person

Simplify Notation

3Attribute Dependency Diagram

Medical

Doctor

E

O

O

E O

Person

Manning Practice

Diagnosis

Surname

DateOfBirthFirstName

HrsWorkedAddressPracticeName

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

DeliverBusinessSolution

3.5

DevelopBusiness

Cases

3.3

InfrastructureMgmt6.0

Business UnitDirection

Business Unit Plans

Issues,Questions,Requests

Cust.Satisfaction

Svc.LevelReqt's

AcceptanceCriteria

CustomerService

4.0

Business Needs/Exceptions

DevelopCustomer

Relationship

3.2

ITGPlanning

1.0

DevelopConstructionRequirements

& Plan

3.4

Recom-mendedBusiness

Cases

ApprovedBusiness

Cases & Impl.Sched.

DetailedBusiness Reqts

Construction5.0

DetailedSystemReqts

SystemTested

BusinessSolution Delivered

BusinessSolution

Training

CustomerService

4.0

TrainingMaterials

DevelopBusiness

UnitLiaison

3.0

ITG ImprovementRecommendations

) (

Construction5.0

Status/Exceptions

Problem/Trends

Results

) (

CustomerSatisfaction

Tools

AcceptanceTest Failures

) (

Maintenance Change Request/Training

BusinessUnits

BusinessUnits

Processes7 & 8

Service Requests

DAT Consulting

Level 1 Cotter StrategicDirection

ITG StrategicDirection

ProcessMeasurements

ITGPlanning

1.0

) () (

DevelopBusiness

UnitPlans

3.1

SLAs

Valueof 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 With Covering 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 InIM 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 GovernanceTeam works withProject Team to

assess level of risk &determine appropriatelevel of involvement by

special teams.

Perform detailedData Analysis.

Capture & storere-usable information

Contribute to testcriteria.

Data GovernanceTeam participates in

project LessonsLearned.

Perform IssueResolution as

required. Balanceneeds of productionsystems, users ofdata, standards

Additional Steps to Reduce RiskFrom 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 Success Key To Success –– Checks & BalancesChecks & Balances””

55


Issue Identified Early inLifecycle =

Lower Cost to Resolve !Checks & Balances

between data quality,applications, and business

information usage.

Trigger:Enteringdesign

5. CommunicateStatusManage Process

GovernanceSteps

StewardshipSteps

Executive CouncilOther groups asappropriate

DataGovernance

Manager

Project or FunctionalTeams,

others as appropriate

Business Stewards

Quality Stewards

Application .Stewards

2. Conduct Data Analysis

Project Managers

1. Plan.

Set Project andEnterprise Goals,

Assess & CommunicateRequired Levels of

Involvement

Governance Management Team 3. Conduct Risk Analysis.

Decide Which Risks toAccept or Manage, Which to

Explore Further ThroughIssue 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 Unitsproduce data

using business applications

Info Production

Info Production

Business Unitsproduce data

using business applications

Info

Usage

Management, Marketing, and other functionsuse information

in reports, GDM, DWs, etc.

Info

Usage

Info

Usage

Management, Marketing, and other functionsuse 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:Proactiveefforts 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

Workflow

and Content

Managem

ent ProcessesProa

ctive

and

Rea

ctive

Proc

esse

s

- 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 ManageBusiness 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

PD

R

CD

R

FP

R

SRR

SRR

PD

R


““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 IntroducedBusiness Rules Managed.

Expanded Business Involvement.

Stewardship CultureObserved.

StrategicGovernance.

Seven Step

Maturity ModelFirst 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 (Greek Metadata (Greek -- meta "after" and Latin meta "after" and Latin -- data data "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 of Metadata promotes agreement on nature / content of data data –– ““ source of the truthsource of the truth ””

�� A A ““ singlesingle ”” dictionary fosters common understanding dictionary fosters common understanding and clear communications; and clear communications; two or more breed two 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 Group2 ““ Metadata Market DriversMetadata Market Drivers ”” ,, Lou Agosta, 11/13/2002, GIGA Information Group3 ““ Metadata Treated HaphazardlyMetadata Treated Haphazardly ”” ,, Forrester Research, Forrester Research, 2/28/2003, Lou Agosta, Page 1-24 “ 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



““Sample Sample 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

[email protected](212) 547-3108 Mobile

Or just blank stares…

BusRulesMetadata

Governance

Documents

Business Rules For Metadata Governance & Stewardship