information is at the heart of all architecture disciplines

INFORMATION IS AT THE HEART OF ALL ARCHITECTURE DISCIPLINES...AND THERE’S MORE TO DATA MODELLING THAN YOU THOUGHT

CHRISTOPHER BRADLEY CHIEF DATA OFFICER

FROMHEREON WHITE PAPER

2 | FROMHEREON ©2014


3FROMHEREON ©2014 |

CONTENTS INFORMATION IS AT THE HEART OF ALL ARCHITECTURE DISCIPLINES 4

DATA MODELLING INTRODUCTION 6

HORSES FOR COURSES 8

DATA MODELLING INCORRECTLY TAUGHT AT UNIVERSITY 10

BUT THIS IS WRONG! SO WHAT NEEDS TO CHANGE? 12

PUMP UP THE SOFT SKILLS 14

CONCLUSION 16

ABOUT THE AUTHOR 18

ABOUT FROMHEREON 19

Co

ver

Imag

e: F

lickr

, Dim

a B

ush

kov



INFORMATION IS AT THE HEART OF ALL ARCHITECTURE DISCIPLINES

But they were wrong.

People who believe Data Modelling is just for DBMS design are just as misinformed. Data Modelling, particularly Conceptual Data Modelling is an absolutely critical technique and is at the heart of all architecture disciplines. Here’s why:

Since data has to be understood to be managed, it stands to reason that something whose purpose is to gain agreement on the meaning and definition of concepts will be a key component. That is precisely what a Data Model provides.

But just what do I mean when I state that Data Modelling is at the heart of all architecture disciplines?

At its heart, the Data Model provides the unifying language, lingua franca, the common vocabulary upon which everything else is based. Other modelling techniques within the complimentary architecture disciplines will interact with each other, forming a supportive; cross-checked, integrated and validated set of techniques. It’s not just (sometimes it’s never) about technical DBMS design.

So to illustrate the case with a few simple examples, we see in:

The Business Architecture Domain: A Project Charter documents the rationale, the objectives, the business scope, and measures the success of the project. It uses the language of a high level data model to describe the business concepts.

The Process Architecture Domain: A Workflow Model describes the sequence of steps carried out by the actors involved in the process.

The Application and Systems Architecture Domain: A Use Case describes how an actor completes a step in the process, by interacting with a system to obtain a service. A Service Specification describes some form of business service that is initiated to complete a business event.

The Information Architecture Domain: A Data Model depicts the critical data items, and the attributes or facts about them. This is important data that the organisation wishes to know or store information on, and is the stuff that the processes and systems act on.

Many years ago people believed the World was flat and if they sailed over the horizon, then they would fall off the edge. They also believed that the Earth was at the centre of the heavens and that all the other planets orbited around it.

BUSINESSARCHITECTURE

Business Objectives & Goals

Motivations & Metrics

Functions, Roles, Departments

INFORMATIONARCHITECTURE

Enterprise Data Model

Conceptual Data Models

Logical Data Models

Physical Data Models

PROCESSARCHITECTURE

Overall Value Chain

High-Level Business Processes

Workflow Models

APPLICATION / SYSTEMSARCHITECTURE

Systems within Scope

High-Level Mapping

Business Services

Presentation Services (use cases)

The company is undertaking a radical approach to enhance Customer experience, service and satisfaction by providing seamless multi-channel Customer access to all core services

BUSINESS OBJECTIVES INFORMATION SERVICES BUSINESS SERVICES

PRESENTATION SERVICES

BUSINESS PROCESS

all of the architecture disciplines use the language (and rules) of the data model



FIGURE 1: Data Modelling is at the heart of all architecture disciplines

Every type of model references the entities of significance in the Conceptual Data Model, showing why Conceptual Data Modelling is such a vital technique.

Getting agreement on the language and definition of the data concepts must always occur first; once established detail about processes can be added:

To begin we discover the Nouns: i.e. the items of interest to the organisation , e.g. “Product”, “Customer” and “Location”.

Next we discover “Verb – Noun” pairs: These are activities that must be performed, such as process and sub-process, in order for the organisation to operate, e.g. “Design Product” and “Ship Order”.

Lastly we discover “Actor – Verb – Noun” combinations: These form the Use Cases or steps within a business process, , e.g. “Lead Architect Designs New Product”.

At this high level, we are seeking to gain an understanding and agreement on terms and vocabulary for the data concepts. We do not want to get bogged down in the level of excruciating detail that a detailed logical model would take us into.

Thus, high level conceptual models (often called Business Data Models) are the appropriate vehicle to use here. It can be loosely argued that they provide some of the features of an “ontology”, i.e. business concepts and their relationships, although a Conceptual Data Model with its metadata extensions provides much more.



DATA MODELLING INTRODUCTION

Data Modelling has been around since the mid 1970’s (I started in 1979). Unfortunately for many new Data Architects there is a connotation that “Data Modelling” has fallen into disrepute, and for many organisations it simply holds too strong a stigma.

“We’re an agile shop and Data Modelling isn’t relevant”.

“My project is installing a COTS system; we don’t need to do Data Modelling”.

“We don’t do bespoke RDBMS systems, so we don’t need Data Modelling”.

“It’s not relevant to us”.

However, when Data Modelling first became mainstream in the mid 1970’s the benefit to deliver a single consistent definition of data, and undertake impact analysis to see where logical data concepts were physically implemented were eagerly awaited.

Of course everybody wanted these benefits but as the business and systems landscape moved on, the messaging and methods provided by Data Modelling did not keep up. It’s only recently that things are heading back uphill.

Although DBMS’s such as such as DL1, IMS, IDMS and TOTAL were around long before the relational data movement, it was partly on relational theory that Data Modelling was founded.



HORSES FOR COURSES

Therefore, it’s no surprise that the focus of IT Departments and the emerging methods were predominantly concentrated on the development of new, usually custom built systems. DBMS technologies began to replace ISAM & VSAM file based systems, so the early days of Data Modelling were almost exclusively aimed at supporting DBMS development.

The general approach prevalent at that time was the “top-down” method. Broadly speaking this meant:

Creating a Conceptual Data Model (CDM).

The purpose of the CDM is to establish scope and agree on the high level data concepts for the organisation. The CDM documents major attributes and the definitions of business data objects; it also shows the most important relationships between business data objects.

For Data Modelling purists, the CDM will allow non-atomic attributes, recurring attributes and has plenty of many-to-many relationships.

Following the CDM, the next step is to create a Logical Data Model (LDM).

The LDM contains more detail than the CDM. Applying the rules of Data Modelling all of the entities will be normalised, non-atomic attributes split, all keys added, and many-to-many relationships resolved. In my experience, on careful analysis the vast majority of intersection entities actually have real business meaning. Frequently a detailed LDM is not created for the entire CDM but is undertaken within the scope of a defined application project.

Following the LDM, there needs to be a design related to the target “data platform”. This includes taking the Logical Data Models and creating a specific highly tailored Physical Data Model (PDM) to support the specific target platform.

For IMS/DL1 this means creating a hierarchic model, and for IDMS it includes the creation of a network model. These physical models represented the blueprint of actual tables, columns, keys, foreign keys, and other constraints to be implemented in

In the early days, many Business Functions had little or no IT (then called ADP) systems to support their operations, there were also fewer COTS packages available on the market.



the database. From the Physical Data Model, the actual DBMS schema was generated via the Data Definition Language (DDL), these days the most common DDL is SQL.

Occasionally development of an Enterprise Data Model (EDM) is attempted.

Today it’s widely accepted that an EDM is there to set context, and documents the high level business data objects and definitions. In the early days however, many Enterprise models were actually “Enterprise wide Logical Data Models”. These were frequently incomplete, and covered the wall with hundreds, often thousands, of entities and in no small part were responsible for many business feeling that they had been “modelled to death”.

Looking at Figure 2 below, which I’ve adapted from my book (Data Modeling for the Business), we see there are many different levels of “Data Models”. As we go up the pyramid the more “communication” focused the models become, whereas further down the pyramid, the models become more “implementation” focused. These days it’s common that a high level model is created with the exclusive purpose of improving communication and understanding.

FIGURE 2: Levels of Data Models

ENTERPRISE

CONCEPTUAL

LOGICAL

PHYSICAL

SYSTEM

CO

MM

UN

ICA

TIO

N F

OC

US

IMP

LE

ME

NT

AT

ION

FO

CU

S



DATA MODELLING INCORRECTLY TAUGHT AT UNIVERSITY

I am also currently providing advice to a number of Universities on the creation of a Masters of Information Management.

However, over the past 10 years or so I have been taken aback at what I have observed regarding the way in which Data Modelling is portrayed in many Universities across the UK and USA (I suspect in other places too).

Here are a few recent snippets I have from five of these Universities regarding data modelling on the Computer Science Bachelors & Masters courses:

» “The purpose of a Data model is to design a relational database system”

» “An ER Model is used to specify design and document Database design”

» “A Data model is a pictorial representation of the structure of a relational database system”

» “… it is a description of the objects represented by a computer system together with their properties and relationships”

» “ER Modelling is a Database design method”

At one of the Universities I dug deeper and examined several of the course assignments.

One assignment asked students to prepare a model that represented an office environment, and in part of the assignment brief it mentioned the “Rolodex” and “IBM Selectric” which were on the desks in this hypothetical office.

This was not an assignment paper set for a course in 1975; but one I saw in 2013!!

With the uses of Data Models that I’ve described so far, the history of Data Modelling, the way it’s still being taught in some Universities and judging from many of the literature pieces by Data Modelling tool vendors themselves, it is not surprising that many people are left with the impression that Data Modelling is just for DBMS’s.

As part of my DAMA-I education brief, and to be honest as a way of giving something back to the community, I am frequently asked to speak not just at conferences but with academic institutions.



BUT THIS IS WRONG! SO WHAT NEEDS TO CHANGE?

To make Data Modelling relevant for today’s systems landscape we must show that it’s relevant for the “new” technologies such as:

» COTS packages

» SOA and XML

» Big Data Analytics

» Business Intelligence

» Data Lineage

» Data Virtualisation

Not forgetting that an appropriate level Data Model is an awesome tool for communicating with the business.

See also: “Data Modelling for the Business – A Handbook for Aligning the Business with IT Using High-Level Data Models”; Technics Publishing; ISBN 978-0-9771400-7-7.

We don’t require detailed models in every instance and really should make the relevant information available in a format users can readily understand. This means that Data Architects need to recognise the different motivations of their stakeholders and re-purpose the model for the audience: Don’t show a business user a data model!

The information we create in models (the metadata) should be updated quickly, and we need to embrace business stakeholder’s feedback. At the end of the day you’ll achieve better and agreed definitions more swiftly that way.

We need to wake up to the business environment that we’re working in and break away from arcane academic arguments about notations, methodologies and the like. If we want to have Data Modelling play a real part in our business then it is up to us to demonstrate and communicate the genuine benefits that can be realised. Remember, Data Modelling isn’t a belief system, just because you “get it” don’t assume that the next person does.

The use and benefit of Data Modelling is considerably greater than its current “one trick pony” press would suggest.



PUMP UP THE SOFT SKILLS

Nobody owes us a living, and no matter how important WE believe the place of modelling to be, it is our responsibility to demonstrate (and sell) the benefits within our organisations.

Information Professionals need to recognise the different motivations of their users and re-purpose the information they present to be suitable for the audience. Here are a few ideas on what you can try:

4. Provide Business Data Glossaries (it’s Metadata really).

» Data with Definitions

5. Take the Goldilocks approach

» Not too much, not too little

» Know your audience & adapt the message accordingly

6. Market and Provide Updates!

» Make your project visible

» Communicate with other groups seeking information management assistance

» Publish dashboards and interim-results

7. Acknowledge the differences in behaviours and motivations of different stakeholder groups.

We need to demonstrate why Data modelling is essential and regularly illustrate the benefits ensuing from Data Modelling.

1. Obtain independent vendor agnostic professional certification (CDMP / BCS etc.). This demonstrates that we are serious about professionalism in the Information Management discipline.

2. Get soft skills and communication technique training.

3. Provide relevant level Information to users in formats and layouts they can easily consume, for example:

» Publish to the Web

» Repurpose information into other tools

» Company social media and collaboration tools, i.e. Yammer, SharePoint, Wiki, etc.



Image: Flickr, Sebastiaan ter Berg

OBTAIN INDEPENDENT CERTIFICATION

GET SOFT SKILLS AND COMMUNICATION TRAINING

PROVIDE FORMATS AND LAYOUTS USERS CAN UNDERSTAND AND CONSUME

PROVIDE BUSINESS DATA GLOSSARIES

TAKE THE GOLDILOCKS APPROACH

MARKET AND PROVIDE UPDATES

ACKNOWLEDGE DIFFERENCES AND STAKEHOLDER MOTIVATION



CONCLUSION

Agreement and consistency of the language and definition of data is absolutely essential for the success of all other architecture initiatives.

We have seen that data models can be produced at different levels and for different purposes and audiences.

We have examined many aspects of Data Modelling, starting with its history, its use in DBMS development, the way it is taught in some Universities and firmly refuting the criticism that it’s only appropriate for DBMS development.

Throughout this paper we have illustrated that data is at the heart of all architecture disciplines.

However as data professionals, it’s up to us to make the biggest change necessary to make the content appropriate to the technologies, stakeholders and the business environments of today.

We need to grasp the nettle to engage and communicate effectively within our businesses.

SO AS CAPTAIN PICARD SAID:

MR DATA - MAKE IT SO!



FOR MORE DETAILS CONTACT

CHRIS BRADLEY Chief Data [email protected]

ABOUT THE AUTHOR

With 32 years experience in the Information Management field, Chris works with leading organisations including Total, Barclays, RBS, GSK, Disney, BP, Statoil, Riyad Bank & Aramco in Data Governance, Information Management Strategy, Data Quality & Master Data Management, Metadata Management and Business Intelligence.

He is a Director of DAMA-I, holds the CDMP Master certification, a Fellow of the Chartered Institute of Management Consulting (now IC) member of the MPO, and SME Director of the DM Board.

As a columnist and frequent contributor to industry publications, Chris is a recognised thought-leader in Information Management. He leads an experts channel on the influential BeyeNETWORK, is a regular speaker at major international conferences, and is the co-author of “Data Modelling For The Business – A Handbook for aligning the business with IT using high-level data models”. He also blogs frequently on Information Management (and motorsport).

Chris is the Chief Information Architect at FromHereOn (FHO).

CHRIS BRADLEY

mailto:chris.bradley%40fromhereon.com%20?subject=



ABOUT FROMHEREONFromHereOn focuses on enabling service transformation for leaders of service organisations such as IT, HR, Procurement and Finance.

Uniquely FHO combines Service Design, Information Management and Enterprise Architecture capabilities to enable transformation end-to-end, from strategy development, roadmap design, costing & estimation, business case development, through to program management and project level architecture and design services.

ENTERPRISE DESIGN

We call this new capability Enterprise Design, by combining design thinking with the human value of information and the scale of enterprise architecture, we take a people centred approach to transform large organisations and build better consistency, efficiency, simplicity and experiences.

This approach ensures people and their motivation to realise a vision worthy of their passion remain at the heart of major change initiatives, from concept right through to delivery.

Learn more about FromHereOn:

FROMHEREON.COM

http://www.fromhereon.com/

NEW YORK The Seagram Building375 Park Avenue, Suite 2607 New York City, NY 10152, U.S.A

+1 212 634 [email protected]

LONDON19 Eastbourne Terrace London, W2 6LGUnited Kingdom

+44 20 8906 [email protected]

mailto:hello-nyc%40fromhereon.com?subject=

mailto:Hello-London%40FromHereOn.com?subject=

information is at the heart of all architecture disciplines

Technology