Data Modelling - BCS modelling 1970-1990 Enterprise data management coordination Enterprise data integration Enterprise data stewardship Enterprise data use 1990-2000

1

Data Modelling

Where did it all go wrong?DAMA London, 15th June 2007Ch i t h B dl

2

Contents

1. Background2. Seven deadly sins3. Our part in fixing this

3 Complete keyboard char set so that all ordinary characters of IPL Title Fontget embedded in file \zxcvbnm,./asdfghjkl;’#qwertyuiop[]1234567890-=`|ZXCVBNM<>?ASDFGHJKL:@~QWERTYUIOP{}¬!”£$%^&*()_+

Audience PollWhat’s your role within your organization?

Data Architect

DBA

Manager or Executive Sponsor

Business Analyst

Consultant

Marketing

Other


1. Background


Background:Data Management growth:

Database developmentDatabase operation

1950-1970

Data requirements analysisData modelling

1970-1990

Enterprise data management coordinationEnterprise data integrationEnterprise data stewardshipEnterprise data use

1990-2000

Explicit focus on data qualitySecurityComplianceOther responsibilities

1990-2000


Background:Data Modelling’s promise …."a single consistent definition of data" "master data records of reference" “reduced development time”“improved data quality”“impact analysis”…….

So why is it that in many organisations the benefits of data modelling still need to be “sold” and in others the big benefits simplyfail to be delivered?

No brainers?


2. Seven deadly sins


i: Not focusing on benefits

Project requirements vs Big pictureReward drives behaviourWIIFMMetricsEvidenceSustained improvement


What’s the value of Data Modelling to BP?

x body of knowledge - models repository.

Consistency of cross domain data concepts.

Eases Master Data Take-on, Legacy Migration, MI/BI, Application interoperability

Reuse of common models & definitions (including standard industry models)

Interoperability, & efficiency through common approaches

Reduction in maintenance.

Company X benefits


Ston

gly

Agre

e

Dis

agre

e

79% 77%70%

55% 60%

4%0%

10%20%30%40%50%60%70%80%

What benefits are you gaining from the Data modelling service?

We are not obtaining any benefits

We are obtaining benefit through use of a common modelling tool

Company X: User Survey; Benefits

We are obtaining benefit through utilisation of a common repository

We are obtaining benefit through use of common standards, guidelines & processes

We are obtaining benefit through re-use of models & artefacts

We are obtaining benefit through provision of central support & help


What’s the $ value of Data Modelling to BP?

A) Complete representation of requirementsMeasures• Number of definitions the client takes ownership of. If the client is willing to assume responsibility for the maintenance of the definitions, then it is safe to assume the definitions are accurate.• Number of modifications to the model after each review. This is more of a rolling "how well is the modelling process going" measure than an end-state measure of how complete the model is. A lower number of post-review modifications is an indicator of a higher degree of completeness.

B) Retention of collected information (including re-use)Measures• Number of times portions of a model are referenced (on a web page for example). If the model has been published (which all should be) and the repository information is easily accessible, the "number of hits" on each entity (for example) can be a gauge of theusefulness of the originally collected information.• Number of entities re-used in subsequent projects. This is as much a measure of the quality of the original analysis (and potentially design) as it is a measure of the amount of re-use. Costs savings for this measure can be calculated based on a "days per entity" number. Total time savings (and related cost savings) would be equal to the "days per entity" multiplied by the number of entities re-used• Time to market for projects. Assuming we were able to re-use an existing database for a second application, the time savings could simply be "days per entity" multiplied by the number of tables in the existing database.

C) Consistent interfaceMeasures• Review time by entity. The time required to review each entity (or definition) should decrease as the reviewers become familiar with the consistent style of the model. A side benefit to following a consistent style is that subsequent projects will be able to accurately reflect the amount of time required to review a data model in project plans based on the results of past reviews.• Amount of time spent during subsequent referral to the model. Just as the number of times the model is subsequently referenced is a measure of the retention theme, the amount of time spent when referencing a specific portion of the model is a measure of the consistency. If the model has followed a consistent interface, subsequent users of the model should be able to find the requiredinformation quickly.

Company Y metrics


Value of Data Modelling - Company Z

• Increased reuse & development efficiency >>> Reduced development time (*based upon £10k per new Entity & 46% re-use)

$300m

• Increased consistency >>> Decreased maintenance (*based upon 22% reduction in # bespoke tables & messages)

$75m


ii: Forgetting the purpose

Top down only?Bottom up & middle outIt’s not simply for RDBMS development


Why Produce a Data Model?Company Z Top Ten Reasons

1. Capturing Business Requirements 2. Promotes Reuse, Consistency, Quality3. Bridge Between Business and Technology

Personnel4. Assessing Fit of Package Solutions5. Identify and Manage Redundant Data6. Sets Context for Project within the Enterprise 7. Interaction Analysis: Compliments Process Model8. Pictures Communicate Better than Words9. Avoid Late Discovery of Missed Requirements 10. Critical in Managing Integration Between Systems


Not only for “new” Data Base Systems?SOA:Important in an SoA World. Definition of data & consequently calls to / results from services is vital.Straight through processing can exacerbate the issue

• what does the data mean?• which definition of X (e.g. “cost of goods”)?• need to utilise the logical model and ERP models definitions

Data Lineage:Repository based Data migration design - ConsistencySource to target mappingReverse engineer & generate ETLImpact analysis

ERP:Model Data requirements – aid configuration / fit for purpose evaluationData IntegrationLegacy Data take onMaster Data integration

BI / DW:Model Data requirements in Dimensional ModelReverse engineer BW Info Cubes, BO Universes, …….Generate Star / Snowflake / Starflake schemas


iii: Language & intellectual snobbery

The term “Modelling” often has baggage associated with it

Use appropriate language & terms for different audiences

Banish methodology bigots & dogmaBarker / ERD /UML / OR / etc etc

Banish methodology bigots & dogmaNEVER air methodology issues in front of users


iv: Discipline

NASA Mars Climate Orbiter

Dumbing down - It’s not just about picture drawing!Don’t forget the metadataTraining & appropriate personnelIdentify relevant standards & guidelinesCommunicateHonesty – it’s not easy!


v: Inappropriate positioning

Don’t do it just for modelling's sake!


Data modelling performed in isolation – silos DM, PM, DBA ...Left until too late in the lifecycleSpeed – too much focus on final 20% to be “theoretically perfect”DM considered an overheadCharging for Modelling infrastructureHidden / unpublished models – what’s the point!Limited re-useProjects left to own devices – “the train has departed”DM function not resourced appropriately thus models not subject to peer / cross-domain review

v: Inappropriate positioning


vi: Failing to adaptPlethora of tools – good usage is more important

than choosing the “best”Forgetting the overall information architecture

Master Data, Transaction data, MI/BI, Unstructured, BDD …

Disservice by ERP package vendorsCOTS Logical Data Model with package?

Lack of soft skillsHero seeking

cowboys


vii: Square pegs & round holes

TLA factory – DM, MDM, EDM, EII, CDI, SOA …….The right people in the role?

Is being a good modeller enough?Certification coming at last ☺

Engaging with the businessNobody owes us a living

Communicating our successesDo people know why this is undertaken?

Creating communities of interestLack of “Selling” skills

22

3. Our part in fixing this


3NF

DBA• Cautious• Analytical• Structured• Doesn’t like to

talk• “Just let me

code!”

Data Architect• Analytical• Structured• Passionate• “Big Picture” focused• Likes to Talk• “Let me tell you about

my data model!”

Business Executive• Results-Oriented• “Big Picture” focused• Little Time• “How is this going to help

me?”• “I don’t care about your

data model.”• “I don’t have time.”

Industry CultureDBAs, Data Architects and Executives are different creatures


Role of the Data ArchitectHow to gain Traction, Budget and Executive buy-in

• Be Visible about the program:• Identify key decision-makers in your organization and update them on your project and its value to the organization• Focus on the most important data that is crucial to the business first! Publish that and get buy in before moving on. (e.g. start small with a core set of data)

•Monitor the progress of your project and show its value:• Define deliverables, goals and key performance indicators (KPIs) • Start small—focus on core data that is highly visible in the organization. Don’t try to “boil the ocean” initially.• Track and Promote progress that is made• Measure Metrics where possible

“Hard data” is easy (# data elements, #end users, money saved, etc.)“Softer data” is important as well (data quality, improved decision-making, etc.) Anecdotal examples help with business/executive users

“Did you realize we were using the wrong calculation for Total Revenue?”(based on data definitions)


Communicate EffectivelyProvide Information to uses in their “Language”

• Repurpose information into various tools: BI, ETL, DDL, etc.• Publish to the Web• Exploit collaboration tools / SharePoint / Wiki …….• Business users like Excel, Word, Web tools

Document Metadata• Data in Context (by Organization, Project, etc.)• Data with Definitions

Provide the Right Amount of Information• Don’t overwhelm with too much information. For business users, terms and

definitions, might be enough.• Cater to your audience. Don’t show DDL to a business user or Business

definitions to a DBA.Market, Market, Market!

• Provide Visibility to your project.• Talk to teams in the organization that are looking for assistance• Provide short-term results with a subset of information, then move on.


Model publishing



Case Study: Web-based information sharing


Maturity @ your company

Visibility

TechnologyTrigger

Peak of inflatedexpectations

Trough of disillusionment Slope of enlightenment Plateau of productivity

Typical Gartner “hype cycle”

Avoid the abyss via investment in “sustain”activities

Current position

Make it sustainable:


Thank you

Contact details:Email: [email protected]: +44 (0)7973 184475MSN: [email protected]: www.ipl.com

Documents

Data Modelling - BCS modelling 1970-1990 Enterprise data management coordination Enterprise data integration Enterprise data stewardship Enterprise data use 1990-2000