West M. Developing High Quality Data Models

Подождите немного. Документ загружается.

17.45 Sign and Pattern............................................................................. 337

17.46 Requirement and Requirement Specification ..............................343

Appendix: A Mapping between the HQDM Schema and

ISO 15926-2. ........................................................................... 347

Index .......................................................................................................... 379

x CONTENTS

PREFACE

I would like to start by explaining how I came to write this

book, and to ackn owledge its influence s and the help I have

received along the way.

I have been extremely fortunate. I have a wonderful wife and

two wonderful grown-up children, and I have had all but thirty

years working for Shell, which provided an environment that

had stimulating challenges and opportunities to look more

deeply at problems than is often the case.

I first came across computers in 1971. My undergraduate

course was in Chemical Engineering at Leeds University, and

we all had to lea rn how to write basic Fortran programs in our

first year. I went on to do a PhD, which involved mathematical

modeling of chemical processes and led to my developing an

automatic integrator for stiff ordinary differential equations. As

a result I am probably among a relatively small group of people

who have started a computer by loading the bootstrap program

into memory from the switches to boot up the computer.

I joined Shell in 1978 at Shell Haven Refinery on the north

bank of the Thames estuary, east of London. I was immediately

thrown into the implementation of a computer super vision sys-

tem for the Crude Distillation Unit, which monitored the hun-

dreds of measurements taken around the unit and warned of

deviations from target pe rformance. I spent eight years at Shell

Haven, and while I had a wide range of roles, computers and

computing were a recurring theme. I was, for example, respon-

sible for the purchase of the first IBM PC on the refinery, and

one of the first in Shell for engineering calculations using a

spreadsheet, and at the time I left the refinery I was responsible

for all the mini-computer based systems on the refinery.

My next move was to London in 1986, where I was a busi-

ness analyst on one of the first relational database (DB2) imple-

mentations in Shell, the Oil Management Project. This was an

information system designed to produce an overview of the

planned and actual production and sales of oil products by

Shell in the UK. It was here where I first came across data mod-

els in the Shell UK Oil data architecture and Bruce Ottmann,

who ran the data architecture team and who became a major

enabler and encourager of much of the work I have done in

data management. I immediately found data models fascinat-

ing. As a chemical engineer, I was very used to a process view

PREFACE xi

of the world, and data models gave a completely different per-

spective. I was hooked.

I spent 1989 in The Hague working for Jan Sijbrand. He had

a vision for a system’s and data architecture for refineries such

that a common suite of systems could develop and evolve to

support refinery operations. My part was to develop the data

models, which was done through a series of workshops, led by

Bruce Ottmann, by now leading the corporate data manage-

ment group. Ken Self, later to be one of my bosses, was one of

the attendees.

I returned to London in 1990 to work for Bruce in a project

called the Data Management Key Thrust. Shell’s Committee of

Managing Directors had noticed that IT costs were rising expo-

nentially, but it was not clear why so much money was being

spent, or whether it was delivering value. They issued an edict

that IT costs were to be capped and instituted a number of Key

Thrusts to improve matters. The Data Management Key Thrust

was one of these.

The next few years were particularly fruitful. What we

noticed was that many Shell companies were developing differ-

ent computer systems to do the same thing, but that these sys-

tems were not suitable for other Shell companies. When we

investigated why this was the case, we discovered that the data

models contained constraints that did not always apply, or

meant that historical data could not be held. We looked for and

discovered data model patterns that were examples of the traps

that data modelers fell into, and wh at you needed to do to

improve those data models. From this we were able to work out

principles for data modeling to avoid falling into those traps.

We also include d a Generic Entity Framework as a high-level

data model to help create data models that were consistent

with each other. These documents were “Reviewing and

Improving Data Models” and “Developing High Quality Data

Models,” and yes, that is where the title of this book comes

from. This book aims to address some of the same issue s as the

original article, and while there is little if anything of the origi-

nal documents that has not been updated, some of the same

issues and principles are recognizable. Shell made a version of

this publicly and freely available and I am plea sed to have use

of this and to significant ly update and extend it.

There was much other work done by that group in informa-

tion management around information quality and information

management maturity that was significant in general, but I will

limit myself to the data modeling story.

xii PREFACE

In 1993 I was asked to get involved in the development of a

standard for the integration and exchange of engineering design

data for process plants, including refineries and offshore oil

platforms, joining a consortium called PISTEP, the Process

Industries STEP

consortium, consisting of UK oil companies,

contractors, and Computer Aided Design software companies.

The aim was to develop a standard as part of the STEP (ISO

10303, developed by ISO TC184/SC4  Industrial Data) family

of standards to meet our needs, so that engineering design data

could be handed over electronically, rather than on paper,

which was the practice at that time. Some of the key people

involved in making PISTE P a success were Terry Lazenby of BP

who chaired PISTEP, Stuart Lord from ICI who managed the

consortium, Donald Bell who provided administration, and Bill

Mesley who looked after publicity and conferences. Other key

contributors were David Adam, Ian Glendinning, Ian Bishop,

Alan Thomson, and David Leal. We found there were a number

of other industrial consortia in Europe, and I was asked to call a

meeting of these to see if we could find a way to work together

on a standard. From this meeting EPISTLE

was established as

a consortium of consortia. This included PISTEP; ProcessBase, a

European Commission funded project; a Dutch consortium that

was to become USPI-NL; and a Norwegian consortium that was

to become POSC Caesar. I became its founding Chair.

When looking for a starting point, the Generic Entity

Framework I had developed for the Data Management Key

Thrust and the data modeling methodology that went with it

was considered to be a better place to start than the alternatives

that were available at the time. Shell agreed to contribute the

work to the standards process. These were developed into what

became the EPISTLE Core Model, edited by Chris Angus, and

another edition of “Developing High Quality Data Models”

published by EPISTLE, written by mysel f and Julian Fowler.

However, there were some niggling problems that kept recur-

ring and to which it was not possible to find an enduring solu-

tion. So I was very interested when I met Chris Partridge at a

conference and he started talking to me about an approach to

ontology

called 4-dimensionalism that could help to explain

the things that were causing problems in the EPISTLE Core

Model. It was eventually agreed that we would adopt this

STEP: Standard for the Exchange of Product model data

EPISTLE: European Process Industries STEP Technical Liaison Executive

http://www.matthew-west.org.uk/documents/princ03.pdf

The study of what exists.

PREFACE xiii

approach for the EPISTLE Core Model, and Chris Partridge’s

book about the 4D paradigm, which he had recently published,

Business Objects: Re-engineering for Re-use, was a key input.

On the standardization front, there were problems emerging

with making our work part of ISO 10303. The Integrated

Resources, the data modeling framework for STEP, were con-

strained in ways that meant we could not meet our require-

ments in a way that was compatible with others who were

developing standards as part of ISO 10303, and those who had

already developed standards were unwilling to see changes

made to the standard that would acco mmodate us, but require

them to rework what they had already done. This resulted in a

new standard being developed: ISO 15926 - Li fecycle integration

of process plant data including oil and gas production facilities.

The first parts of ISO 10303 were also being published at this

time, and it was noticeable that different parts were not actually

compatible with each othe r, unless considerable care had been

taken to make sure they were. This was a surprise to some who

thought that because they were all based on the same

Integrated Resources, this would be sufficient to ensure they

would be compatible. Others of us knew that it wa s quite

enough to use a data model in different wa ys for the two data

sets likely to be incompatible. A new working group, WG10, was

set up with the best brains in ISO TC184/SC4 to work out what

to do about it, and what it would take to develop a suite of stan-

dards that were compatible. I was elected Deputy Convener,

with Bernd Wenzel as Convener. There were two main outputs:

a modular approach to developing ISO 10303 and an integration

architecture.

The modular approach to developing ISO 10303 was

intended to enable the construction of exchange standards out

of modules, so that exchange standards for different require-

ments would be constructed by combining different modules.

This would reduce the chance of the same model being redeve-

loped in different ways in different standards. David Price was a

key contributor to this work.

The integration architecture was developed principally by

Julian Fowler and me with input from Ber nd Wenzel and David

Price. It looked at what was necessary in order to be successful

at integrating data from different sources. The result was ISO TS

18876  Integration of industrial data for exchange access and

sharing. ISO 15926 is a standard that conforms to this

architecture.

The EPISTLE Core Model started its development by com-

mittee, with sometimes twenty or more people in the room,

xiv PREFACE

and not necessarily the same people at different meetings. This

was probably necessary in the early stages to get a broad con-

sensus, but it was unwieldy and unmanageable for the detail

and for issue resolution. It was decided to set up a data model-

ing team with two technical representatives from each consor-

tium: David Lea l and I from PISTEP, Andries van Renssen and

Hans Teijgeler from USPI-NL, and Jan Sullivan and Magne

Valen Sendstad from POSC Caesar, plus someone to manage

the process. This produced more stabil ity and progress, but it

was eventually agreed to reduce the team to just three technical

members, one from each consortium, and these were myself,

Jan Sullivan, and Hans Teijgeler, again with som eone to manage

the process.

In ISO TC184/SC4 American colleagues, including Mark

Palmer, expressed concern that the data model being developed

was too generic, and did not tie down enough terms for unam-

biguous exchange. As a result, it was decided to establish a

Reference Data Library of classes and other objects to create a

more specific common language. Andries van Renssen, Magne

Valen Sendstad, and David Leal went on to make major contri-

butions to the development of the Reference Data Library that

accompanies and extends the data model.

My standards work brought me back into contact with Leeds

University, which was also active in standards development in

ISO TC184/SC4, and in 2000 I was invited to be their Shell

Visiting Professor.

Finally, the data model was published as ISO 15926-2 in

2003, accidentally at almost the same time as ISO TS 18876

parts 1&2. I have used some of the slides developed by Jan

Sullivan as training material for ISO 15926 in this book, and

thank him for permission to do so.

It was at my first ISO TC184/SC4 meeting in 1993 that I was

told that I had not developed a data model, but instead an

ontology—the first time I had heard the word. I did look it up,

but did not think too much more about it until I came across

Chris Partridge and the 4-Dimensionalism he introduced me to,

which is a particular approach to ontology. Since then I have

educated myself to a reasonable extent in both the tools of

ontology, namely logic, and some of the ideas from philosophi-

cal ontology, in particular a more thorough grounding in 4-

Dimensionalism, objections to it, possible worlds, and other

related topics. I have been particularly fortunate that Leeds

University had Professor Peter Simons in its Department of

Philosophy, famous for his book Parts: An Ontology, and an

active computer science ontology group under Professor Tony

PREFACE xv

Cohn, in particular Dr. John Stell. Together with active partici-

pation in the Onto log Forum these have provided lively stimula-

tion and challenges from an ontological perspective.

It was not all theory. There were practical implementations

as well. I was involved in a European Commission supported

project PIPPIN

between 1996 and 19 98, which was about

developing software solutions for the problem. A consortium

that included Shell developing the Shearwater oil field in the

North Sea applied the results delivering significant practical

benefits, in a project lead by Peter Mayhew of AMEC with the

help among others of Robert Adams, Richard Marsh, Ian Bailey,

and Chris Partridge.

Meanwhile, Bruce Ottmann was applying the principles we

had developed to management information. With Chris Angus,

Andy Hayler, Andrew Davis, and Cliff Longman in various roles

and at various times they developed software to integrate data

and manage its summarization for business reporting. This was

initially developed by Shell, but eventually sold off as an inde-

pendent software company cal led Kalido, at first under Andy

Hayler’s leadership.

Around 2003/2004 Shell started a maj or initiative to develop

global processes and implement global systems for its down-

stream (oil tanker to petrol pump) business. This was a truly

massive program split into separate projects for particular busi-

ness areas. Initially, I was a busi ness information architect,

reviewing some of these projects’ progress and in practice help-

ing them to deliver the data specifications for their projects. A

critical area to ensure success in such a project is Master and

Reference Data. This would need to be managed at a global

level across Shell in order to ensure consistency of data across

the business. Frans Liefhebber was put in charge of this, and I

was asked to work for Ken Self in the strategy group responsible

for standards and architecture.

One of the things that was missing was an overall conceptual

data model of the Downstream Business, a weakness that arose

from having had to divide the overall project into smaller

pieces. I was tasked with developing one. By mid 2005 I was

able to put together a strong team for this task consisting of Jan

Sullivan, Chris Partridge, Da vid Price, David Leal, Carol Rene,

Jenny Meader, Ian Bailey, and Tim King. Together we were able

to apply the principles we had learnt to create within a year a

consistent and integrated data model developed as separate but

integrated schemas within an overall entity framework. The

PIPPIN: Pilot Implementation of a Process Plant Information Exchange

xvi PREFACE

whole model was some 1700 entity types. We were fortunate to

persuade David Hay to review what we had done, and he made

many useful suggestions about how we could make the data

model easier to digest.

This book is a distillation and development of what I have

learnt about data modeling through these many experiences.

I am aware that I have only mentioned a small number of

the literally hundreds of people who have contribut ed to what I

have learnt over the years. I apologize if you are one and I have

missed you. However, I have so far mostly mentioned those

who contributed technically. Also as important are the man-

agers who had the vision to support the work the technical peo-

ple were doing. Some of those who were particular ly important

to me are Bruce Ottmann, Dalip Sud, Ian Skinner, Frans

Liefhebber, Ken Self, and Tony Rowe, all managers at Shell;

Stuart Lord, manager of PISTEP and PIPPIN; Nils Sandsmark,

Manager of POSC Caesar; Thore Langeland, Chair of POSC

Caesar; and Howard Mason, Chair of ISO TC184/SC4. It takes a

clear vision of how technology can support business to make

the case, and patience and persistence to pursue a difficult

course in the face of adversity.

Finally, I would like to thank my editors, Rick Adams, David

Bevans, and Heather Shearer, for their support and encourage-

ment. I would also like to thank the book’s project manager,

Sarah Binns, and my reviewers Chris Partridge, David Hay, and

Jan Sullivan for the many helpful suggestions they have made in

helping me write this book.

PREFACE xvii

This page intentionally left blank

PART

MOTIVATIONS AND

NOTATIONS

This part provides the backg round and motivation for the

type of data model this book is about. Not all data models are

the same, and things that are important for one type of data

model may not be important for another. I also introduce a

number of the notations I shall be using.

• Chapter 1 gives an introduction to set the scene.

• Chapter 2 presents a number of different notations that can

be used for data models and instances.

• Chapter 3 looks at some of the different uses of data models,

and in particular how they fit into an integration

architecture.

• Chapter 4 shows how data models fit in the context of enter-

prise architecture.

• Chapter 5 looks at some limitations and challenges of data

models and data modeling.