NIST

PUBLICATIONS

nt

A11102 Tbbbbfi

NAFL INST OF STANDARDS & TECH R.I.C.

National lnstitute c aii 102966668

Standards and Te( DAMA symposium (Ist/Oata administration

I M i.- I QC100 .U57 NO.SOO-159 1988 V19 01 NIST- (Tormeriv Naiionai ouieciu ui

nputer Science

I Technology

NIST Special Publication 500-159

Data Administration:

l\/lanagement and Practice

Proceedings of the

First DAMA Synnposiunn

Judith J. Newton and Frankie E. Spielnnan, Editors

loo . us'y I

Computer Science

and Technology

NIST Special Publication 500-159

Data Administration:

IVIanagement and Practice

Proceedings of the

First DAMA Symposiunn

Judith J. Newton and Frankie E. Spielman, Editors

Information Systems Engineering Division

National Computer and Telecommunications Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899

Sponsored by:

National Capital Region of the Data Administration

Management Association (NCR DAMA)

Federal Data Management Users Group (FEDMUG)

Association for Federal Information Resources

Management (AFFIRM)

October 1988

NOTE: As of 23 August 1988, the National Bureau of standards (NBS) became the National Institute of Standards and Technology (NIST) when President

Reagan signed into law the OmnitHJS Trade and

Competitiveness Act.

U.S. DEPARTMENT OF COMMERCE

C. William Verity, Secretary

National Institute of Standards and Technology

(formerly National Bureau of Standards)

Ernest Annbler, Director
Library of Congress Catalog Card Number: 88-600586

National Institute of Standards and Technology

Special Publication 500-159, 122 pages (Oct. 1988)

CODEN: XNBSAV

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1988

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402
FOREWORD

This document represents the proceedings of a one-day symposium

at the National Bureau of Standards on May 17, 1988. It was the

first in what we hope will become an annual series of symposia on

the subject of data administration. As more and more

organizations recognize the need to treat data as a corporate

resource, data administration is gaining acceptance as an

important area of specialization for information processing

professionals

.

The symposium was jointly sponsored by the National Capital

Region of the Data Administration Management Association (NCR

DAMA) , the Federal Data Management Users Group (FEDMUG) , and the

Association for Federal Information Resources Management

(AFFIRM) . We wish to thank the following individuals for their

commitment to and assistance with the symposium:

Jim Clancy, AFFIRM

Alice Cohen, DAMA

John Coyle, AFFIRM

Rene Fecteau, DAMA

Tina Knoeller, DAMA

Mary Lou Mel ley, DAMA

Tammar Paynter, DAMA

Ronald Shelby, DAMA

Rae Thompson, DAMA

We also wish to express our gratitude to the speakers, session

moderators, and participants who made this symposium possible,

and to James H. Burrows, the Director of ICST, for his fine

welcoming talk.

With a few exceptions, the papers in this proceedings represent

manuscripts submitted to the editors for publication. Those

talks for which no manuscript was submitted have been summarized

by the editors from audio recordings and are marked "Summary of

Remarks .

Because the speakers in the symposium drew on their personal

experience and knowledge, they may have expressed views which do

not necessarily reflect those of the National Bureau of

Standards, DAMA, or AFFIRM. Additionally, they sometimes cited

specific vendors and commercial products. The inclusion or

omission of a particular company or product does not imply either

endorsement or criticism by NBS , DAMA, or AFFIRM.

Judith J. Newton

Frankie E. Spielman

Co-Chairs

iii

CONTENTS

FOREWORD iii

INFORMATION ASSET MANAGEMENT 1

Dan Appleton 3

DATA ADMINISTRATION AND THE

SYSTEMS DEVELOPMENT LIFE CYCLE 15

Rene Fecteau 15

Rick Barron 17

Thomas J. Bergin 25

Ellen J. Levin 35

Mary Ann Wallace 41

MANAGING ORGANIZATIONAL CHANGE

AS DATA ADMINISTRATION IS IMPLEMENTED 4 5

Rae Thompson 4 5

Michael P. Menard 47

Joan Shapiro 53

Richard Lytle 55

Margaret Skovira 59

TWO COMPLEMENTARY METHODS OF DEVELOPING DATA ARCHITECTURE . 65

Judith Newton 65

Cathy Hirsh 67

Tom Turk 81

BUILDING THE DATA ADMINISTRATION FUNCTION 91

Frankie E. Spielman 91

Ronald Shelby 93

Elaine C. Hill 103

GAINING AND KEEPING MANAGEMENT COMMITMENT

FOR DATA ADMINISTRATION 117

Herb Jacobsohn 119

V

KEYNOTE ADDRESS

INFORMATION ASSET MANAGEMENT

Dan Appleton

The D. Appleton Company

1
i
INFORMATION ASSET MANAGEMENT

SUMMARY OF REMARKS

Dan Appleton

The D. Appleton Company

Information asset management is data-driven information resource

management. An asset is reusable. One may invest in an asset,

then use it to increase productivity. The quintessential

information asset is data.

The information management function is a 'business within a business.' It must deliver products to customers. This

represents a value shift in the system as it relates to data

processing

.

Processes are what people do; they drive technology. Processes

must change before technology can have its promised effect.

Change must occur on three levels: values, processes , and

technology sets (fig. 2)

.

In 1968, it was possible to produce a system single-handed.

Programmed in COBOL, a typical system took six months and cost

about $100,000. That year, the data processing department

developed seven new applications on the same order. Today,

however, systems average $5 million, take over three years to

develop and may involve 100 people. Though more code is

produced, the concept of productivity has changed.

The concept of the chief information officer (CIO) has also

changed ideas about productivity by introducing the integrated

environment. This is perceived as a desirable improvement over

the old system of segregated systems, even when it takes much

longer to produce a product.

Another major value shift has occurred in regard to changes in

systems as requested by users. Previously, a user would submit a change request to the data processing department and then wait

until a change was produced. Now the users want to make the

changes themselves.

New technologies such as relational database management systems

have affected data management (fig. 3) . Data modeling has

brought a new concept to data processing: it has taken data out

of the process context. Normalization even without relational

databases is now seen as fundamental. Business rules have been

the missing link in data management. Data dictionaries, renamed

repositories or encyclopedias, are still seen as a hope for the

near future.

3
All these new technologies are

separation of data and process,

from process to process.

leading to data independence; the

Data is "leveragable" - reusable

As more new technologies become available, they will lead to even

more data independence. Object-oriented systems and artificial

intelligence products which employ knowledge bases will

strengthen the trend.

How can data administrators deal with new requirements? The

traditional systems life cycle takes too long for big systems.

There are three alternatives: use off-the-shelf, reusable

modules; modify existing code; build new from scratch. The first

alternative holds the most promise for the future, but it

requires adoption of a new set of values. A new approach to

defining requirements, such as designing the 'shelf' and how to

put the data there, is needed. In the process, data

administrators should recast themselves as data asset engineers.

The concept of 'an information" is important to the understanding

of data administration. An information is the result of

combining one or more data. Four hundred basic data can be

combined to produce 10^^^ informations. A datum may be defined

as fact plus stimulus (meaning) . This notion of the ontological

structure of data (that is, its meaning) allows the data

administrator to leverage those meanings through the application

of business rules. These rules are changing constantly, but

managing at the data element level without the application of

business rules is like trying to manage a beach one grain of sand

at a time.

In figure 6, business rules may be applied to the conceptual view

of the data. External schemas may be seen as requirements

arriving from the user, and the internal schemas as the 'shelf

from which the reusable modules are pulled.

Figures 9 and 10 show how data engineering is a continuous

process in the new system life cycle which will allow us to

march, flags flying, into the bright new future of data asset

engineering

.

Mr. Appleton is President of D. Appleton Co. Inc. (DACOM) , a

firm that specializes in industrial modernization and data

resource management methods and tools. He has many years of

experience in Strategic Business Planning, Management

Information Systems, and Systems Development. Mr. Appleton has

published numerous technical papers and articles on manufacturing

automation and database management.

4
coc o Q)

MB U)

05E

(Q

(0 o

(0 < o C0"O5

iS >*

CO c/) c5 E

E-c5£

"O c •= <.2<3

CO Z O

00

CO

(0
6
0)

'5)

o

o

c

o

0)

h75

c

o

0)

C£

o

"5)

CO

CO

CDQ

DC

D

O

0)

"D

O

^

cr

03 LU

CO . Q

0) DO

D

0)N

E

CO

OC

CO

CO

c

"co

CD

CO

*^

CT5 C

b

CO •—

»

Q

7

9
10

Q

a ii

2-2 it

OO@

(7

12
13
mo

Q.oo

03N

03C<o

0) x:o «

(DO

"O

0)NE

t3

C3

tocwcoo

3^ ^

033

cc

toc

\nm

CDcQ

0}O

CC

LU

'5m

0) >

03w

CD c

c5EoQ

T3o< Qo

00

T3o

-JQQ

CO

03

CO

03

CO

03 o o o

(A

03

CC

CO

CO

03 c C

CO3 03

w CD 03

N

03 "to Q 03 pul

rm 03 o o

(/) z • • • ^ 5

03

CO > c

03E8c

CO cc

UJoc

(0oE

Q.O

03>

03 Oi i cc

CO

(0Q.E

it

OQ©

s14
DATA ADMINISTRATION

AND THE

SYSTEMS DEVELOPMENT LIFE CYCLE

MODERATOR

Rene Fecteau

Veterans Administration

PANELISTS

Rick Barron

Thomas J. Bergin

Ellen J. Levin

Mary Ann Wallace

15

DATA ADMINISTRATION

AND THE

SYSTEMS DEVELOPMENT LIFE CYCLE

Rick Barron

McDonnell Douglas

Good Morning. I am Rick Barron with McDonnell Douglas and I am

delighted to be here this morning to discuss Data Administration

and the Systems Development Life Cycle at McDonnell Douglas.

McDonnell Douglas is a large international, multi-divisional

company. Within McDonnell Douglas, I am in a portion of the

company called MDAIS or McDonnell Douglas Aerospace Information

Services Company. This part of the company provides internal

information services support to the aerospace components of

McDonnell Douglas. It is a separate division and company from the

information services that are offered to commercial customers.

Within McDonnell Douglas Aerospace Information Services Company I head an organization called Application Support which is part of

the Professional Services Division of the Company. Heading this

organization puts me in an excellent position to comment on

today's topic since I have functional responsibility in both St.

Louis and the West Coast for Application Data Management Services

and an organization called Application Productivity Services.

The Application Data Management Services is responsible for

database management and data administration support across the

corporation and the Application Productivity Services is

responsible for programmer productivity, productivity tools,

productivity measurement, and software quality assurance. Thus, I

own the tools to support data administration and the tools to

support application productivity in the Systems Development Life

Cycle.

What do the following words have in common?

Oxymoron

Data Administration

Data Driven Methodology

Computer Aided Software Engineering (CASE)

Relational Database or Distributed Relational Database

Artificial Intelligence (AI)

Three Schema Architecture

No, I am not trying to imply that each of those are oxymorons.

Rather, each of these words seem to be in vogue today. I don't

think I have heard a speech in the last six months or a year that

didn't work these phrases somewhere into the speech. See, I have

fulfilled my commitment by already mentioning them now.

17
Actually, these are all topics except for oxymoron, of course,

that everybody seems to salute, have a lot of focus on and feel

are the key to the future. Obviously, that is why we are all here

today. I can't tell you the number of times I go out to a user

organization and I am told that the user needs a relational

database. I don't understand why the user cares how the data is

physically stored internally. The same thing is true with data

administration. I haven't decided whether there are a few data

administrators or 106,000 data administrators within McDonnell

Douglas. It depends how narrow or how broad you want to make the

term. I think every new project we are starting is using data

driven methodology, preparing to implement three schema

architecture, using new integrated CASE tools, and working on

Artificial Intelligence in their implementation of their

distributed relational database. All of this is true if you

listen to the project managers. If only the practice and

commitment were as advanced as the vocabulary, we would be in

great shape.

More specifically, what do the products PM/SS from Adpac

Corporation and Arthur Anderson's Foundation have in common?

Those are both products that have been requested by parts of my

organization to evaluate. With two of these products, I have

received requests from both St. Louis and the West Coast to

evaluate them. That wouldn't be bad at all, in fact I had felt

great about the fact that the two parts of the organization are

becoming more common, if it weren't for the fact that in one

center it is the data administration folks asking for the product

evaluation while at the other center it was the systems

development life cycle folks asking for the evaluation. It

reminds me of the commercials "is it a candy mint or a breath

mint, tastes great or less filling," etc.. It just highlights

the fact that there is tremendous overlap between the systems

development life cycle and data administration discipline.

More specifically, what do the following projects going on

internally within McDonnell Douglas have in common: Corporate

Data Administration Project as well as our component data

administration projects. Product Definition Data, Integrated

Composite Center, CALS (Computer Aided Logistic Support) , AIM

(Artificial Intelligence for Machining), Advance Business

Management Systems (ABMS) , etc., etc., in fact, the list goes on.

Each one of those projects, as part of its activity, is looking

at repositories, data administration, further integration in

sharing data across disciplines, and the methodology to make it

all happen. The methodology will dictate the CASE tools to be

used to integrate with the repository selected for each project

and, therefore, with the systems development life cycle

automation processes. Each one of those projects thinks that the

other projects will integrate with it. They all agree on the

common goal. They all have data administration, they all think

they are data driven instead of process driven, yet each one

18
considers a critical success factor its ability to define the

methodology and the processes and believes it can't wait on

global solutions if it is going to make its dates.

I was going to leave the labels off the picture I am showing here

(fig. 3) and could probably talk to it for four days, constantly

putting different things in the center circle, the outer circle

and the sections in between. However, whether you call it the

dictionary, of which we have 4,000 it seems, whether a repository

or whatever name you wish to give it, it is in the center hub.

The life cycle surrounds it, while encompassed in turn by the

methodology. There, you see, I have solved all your problems. A

nice simple solution.

Actually, it's a lot more complex than this picture shows. The

data administrator is included as part of maintenance or a global

support function. It could be shown as a ring on the inside. In

fact, that is where I suspect it would be.

The bottom line is that the goals are the same. We need to be

able to provide users with quicker, easier access to data. Both

the systems development life cycle and data administration are

enabling functions to make that happen. We all agree that we

need to treat data as a corporate asset with more than just lip

service. We need to have a breakthrough reduction in the systems

development life cycle development by an order of magnitude. We

need to get to reusable everything, code modules, analyst design

elements, data and data definitions, etc. We need to support the

concepts of the three schema architecture and separate data from

the applications so that changing data stores and locations of

where data is stored and database managers require no maintenance

from the application perspective. We have to have high

portability. We are getting a lot more complex, especially in

our industry where you have secure projects that have to put up

their own processors. You may have to port large Information

Management System (IMS) applications onto hardware platforms that

cannot afford to run on large IMS systems. The bottom line is to

increase the availability and reliability of information for our

users while reducing their cost of that information. Easily

said, not so easily accomplished.

What I leave you with for consideration is that the political

issues may be as great as the technological issues. When I look

at both the data administration and the systems development life

cycle discussions within McDonnell Douglas and around industry,

we are arguing the "hows" of the implementation and getting

frustrated when the tools that we want aren't there to meet our

requirements. But, I am not sure we really understand all the

"whats." Secondly, I see that middle management is a major

inhibitor whether putting in programming tools or using data

administration. They resist giving up their control or

custodianship of data to a common source. They are deeply

19
entrenched and don't want to let go. We need to focus more time

on solving that problem and not worrying about the fact that the

technology is not there yet. The fact that we have many

different data dictionaries popping up doesn't bother me if it

facilitates resolving the political issues and changing mind set.

What does bother me is if we keep evaluating the next one and

next one because the 2 3 in house don't meet requirements. That

is not productive. Facilitate the political solutions but don't

proliferate the software.

That gets to our next point, we need implementation functions in

step. Look at the Personal Computer (PC) and Video Cassette

Recorder (VCR) market. Every week something is better, more

functional and cheaper. You can't wait to make a decision

because you get more functionality and lower cost the next day.

You can't wait because every time you think that the function

that was on your "must have" list was there you realize that

three more "must have's" are just around the corner. You can't

put in 412 different platforms because each week when a specific

user wants to make an acquisition, they can succeed in buying

something different because what is available then is better,

faster, more functional and cheaper than what you have already

got on board. Maintenance and support costs will become a

nightmare. You won't get to common data in that process.

As more and more integrated tools and vendors enter the market

the problem is going to get worse in the short term. I think

about every six nanoseconds another new integrated dictionary and

life cycle tool is announced. The key to success though is to

keep the ball moving forward. Keep progress going. I would

rather have the projects I listed earlier within McDonnell

Douglas each talking data administration, common data methodology

and changing that mind set solving some of the political

problems, better helping us understand what works and doesn't

work and what our needs are for repositories over time than the

alternative of doing nothing. It is not ideal, but it is moving

the ball forward. This is a very exciting and challenging area.

It is a lot of fun. The next evolution of change in all these

areas is getting our dreams to become reality, and not just talk.

The glossies 15-20 years ago used the exact same words and had

the same promises. Let's plan it carefully, not leave bad

impressions in our minds or others that may inhibit reaching our

common destiny, and we will have breakthroughs in productivity

through both Data Administration and automating the System

Development Life Cycle.
Mr. Barron is Director of Application Support at McDonnell

Douglas Aerospace Services Company. He has given seminars,

lectures and taught classes in the United States, Canada and

Europe. He is currently an officer of GUIDE International (IBM

user group)

.

21
e w o £>

ill •E S o

iifa <D CO

JC O CM

5 cS2

22
•

o

<

o

zoo

OLU

a.

<CO

<CO

zoo

OLU

l-HO

uo>

Ul

U. LU

Q_

<

03

23
j

!.

j

i

I

24
DATA ADMINISTRATION

AND THE

SYSTEMS DEVELOPMENT LIFE CYCLE

, '0 ^. J, : Thomas J. Bergin

The American University

The Promise of Data Administration

The first time I heard the term "data administration" was at the

Veterans Administration (VA) in the Fall of 1974. I was made

project leader of the Data Administration Project! Our first job

was to inventory the data elements (fields?) maintained in manual

and automated systems. The Reports and Statistics Service of the

Comptroller's Office had estimated that there were about 8,000

such elements. Another office, Management Engineering and

Evaluation (which had responsibility for forms management) had

estimated 12 to 14,000 data elements. We decided that we would

look at automated systems of records first, and then worry about

manual systems. Three months later, we had counted over 56,000

data elements in automated systems of records. We stopped!

There was no need to increase the accuracy of bad news.

Like every other large user of computers, the Veterans

Administration had created numerous automated systems. Each

project team was separate, and worked with different users. The

members of each project had different backgrounds: some had been

functional users, others had a few years of systems work (14 01,

7080 and assembly languages) , and some were new to the business

of computers and computing. The result was that each data

processing system (either manual or automated) was created

independently. Yes, we tried to coordinate efforts between

projects in the same functional area, but. . .

.

The net result was that by 1974, the VA had a great number of

manual and automated systems to capture, manipulate, and retrieve

information. As I recall, we had 38 places where we stored the

veteran's name and address. Depending on which system you were

in, there were three different meanings for "SSN": Service

Serial Number (Army identification number. Navy...), Station

Serial Number (for hospitals) , and Social Security Number. We

weren't alone! The rush to use computers resulted in similar

situations in all organizations.

I also remember the first time I set foot on the National Bureau

of Standards campus. In the Summer of 1974, Harry White, the

Director of the Federal Information Processing Standards (FTPS)

Program, asked me to Chair TG-17, the NBS Task Group on Data

Element Dictionaries. It was an exciting task, thinking about

data as an entity. I recall sitting around a large table with 12

25
or 13 people from other Federal agencies talking about "data

dictionaries" and "data directories", and what the differences

were between them. I remember hearing a colleague from NSA using

the term "metadata" for the first time. In March 1975, I

nervously gave a lecture on "Data Administration in the Federal

Sector" in this very auditorium.

The Promise of Life Cycle Management

The term Life Cycle Management (LCM) came into vogue a few years

ago in an attempt to amalgamate the existing Systems Development

Life Cycle (SDLC) with the planning and budgeting processes. In

a sense, we can think of LCM as an attempt on the part of

management to pull control of the SDLC back toward the functional

user. At the same time, Yourdon, DeMarco, and Constantine

provided technical management with new methodologies and

techniques, in an attempt to make the Systems Development Life

Cycle more rigorous.

The reasons for these efforts were obvious years ago. The

problems which triggered them still exist today: application

development projects typically cost more than estimated, take

longer than anticipated, and do less than expected. When we

couple these criticisms with the systems development backlog, we

can understand the rationale behind efforts to improve the

planning, analysis, design, and development of automated systems.

Reality in Large Complex Organizations (Has Anything Changed?)

Life Cycle Management today is little better than it was 10 or 15

years ago. It is focused on the creation and maintenance of

individual (stand-alone) systems. Analysts are still using outof-date methodologies and tools. The application plans are still

tightly coupled to hardware and software. Management still

focuses on the short-term costs and benefits of individual

applications or application areas. The systems development

process is still slow, ponderous, and resistant to change.

Indeed, a recent article in Infosystems stated:

Despite what adherents of structured methodologies consider

obvious benefits, less than 10 percent of the 750,000

programmers in this country are estimated to use these

techniques

.

The bottom line is that most organizations have out-of-date Life

Cycle Management policies and procedures. I have seen life cycle

manuals that still contain flowcharts. Worse still, some of the

flowcharts show punched cards. Systems Development organizations

are not using structured methods such as data dictionaries, data

flow diagrams, and entity relationship diagrams. They are doing

things much the way they did them twenty years ago. Data

26
Administration is even harder to characterize- Today, we have

few data standards, poor data quality, and high data redundancy.

Most large organizations do not know how much data they collect,

what they do to it, and why they need it. Few organizations are

serious about managing data, or have well-staffed data

administration programs. Indeed, some organizations are still

wrestling with the meaning of data administration. To paraphrase

Justice Potter Stewart:

data administration is a little like pornography; it is

difficult to define, but everyone is sure that they will know

it when they see it.

This past summer, I worked with Software Solutions, Inc., to rewrite and update the Life Cycle Management policies and

procedures for the Manpower, Personnel and Training arena of the

Department of the Navy. In so doing, I called a number of

Information Resources Management (IRM) organizations around the

city. In each case, there was a small staff working at the

policy level. There seemed to be limited understanding of the

need for data resource management, data standards, or data

dictionaries, as a tool for implementing a data administration

program. This finding is consistent with the Caudle Report on

Federal IRM.

On a Positive Note

At the Department of the Navy, on the other hand, there is a concerted effort to make data administration a reality. There is

a sophisticated, and well staffed, organization in place. A data

standards program exists as do data standards. A data naming

standard was recently promulgated and is in use. An information

resource encyclopedia (data dictionary/directory) has been

populated and is being used in many phases of the systems

development life cycle.

As I mentioned above, the Life Cycle Management policies and

procedures have been re-written. When these policies and

procedures are officially implemented, the use of these data

administration tools will be part of the applications development

process.

Although much of this is new, there are already some success

stories. The Department of Defense Documentation Center needed

permanent change of station information. Through a "data issue

resolution process" the data needs were evaluated and it was

determined that available data could be used to meet the new

need. Had this problem been examined in a purely technical

context, there is no doubt that the Navy would have an additional

data processing application under development.

27
Observations and Conclusions

To help map the reality of the present to the promises of data

administration and life cycle management, the following

observations and conclusions are offered:

1. Neither data administration or life cycle management

have changed much since the 1970 's. Evolutionary

changes take forever. A revolution is needed in the

way we develop applications, and in the way we think

about data. The focus of life cycle management must

shift from the management of technology to the

management of data.

2. Data must be recognized as an organizational

resource. This has to become more than just a

platitude. Data Administration must start to manage

data from an organizational perspective, and not from

the limited perspective of specific functional units

or applications.

3. System Development organizations must recognize that

quality data is crucial to any efforts to improve the

systems development and life cycle management

processes. Recent approaches to improving the

systems development process, such as prototyping,

fourth generation languages, and subject area

databases all require quality data.

4. Data Administration must take the lead in modifying

the Life Cycle Management policies and procedures, to

incorporate data administration methods and

techniques

.

5. Systems analysts, systems designers, programmers and

others in the systems development process must become

familiar with, use, and appreciate data element

dictionaries and other data administration processes,

techniques, and tools.

6. Data Administration must recognize that Life Cycle

Management is the vehicle for institutionalizing data

administration and data resource management.

These are difficult prescriptions. They will require risk

taking, time, and considerable resources. It is only though

these processes, however, that data administration theory and

promise will become reality.

28
Dr. Bergin served at NBS in 1974-76 as first chairman of Task

Group 17, Data Element Dictionaries. In 1982, he became the

Director of the Quantitative Teaching and Research Lab at

American University. In 1983, he was Senior Technical Specialist

to a joint American University-Institute of Public Administration

advisory group to the Government of Bangladesh. He is co-author

of Microcomputer Based Primer on Structural Behavior (1966)

.

29
LIFE CYCLE MANAGEMENT TODAY:

F>ROCESS DRIVEN: AI»I»L I CAT I ONS

USERS

TECHNOLOGIES

SLOW AND PONDEROUS

TIGHTLY COUFLED TO OUT — OE — DATE

HARDWARE

SOFTWARE

METHODOLOGIES

TOOLS

PROCEDURES & STANDARDS

PRESENT ENVIRONMENT:

RELIANCE ON EXISTING APPLICATIONS

COST/HENEEIT SENSITIVE

LACK OF ORGANIZATIONAL PERSPECTIVE

Figure 1

30
DATA ADMINISTRATION TODAY:

r>OOR DATA QUALITY

HIGH DATA REDUNDANCY

ACCOUNTING I»AF£AD I GM

TECHNOLOGY DEPENDENT

F»OORLY RESOURCED

SLOW RATE OF ADOPTION

EMERGING METHODOLOGIES

DATA STANDARDIZATION

DATA ELEMENT NAMING

DATA QUALITY ASSURANCE

DATA ENGINEERING

DATA MANAGEMENT TOOLS

GROWING AWARENESS ACROSS DISCIF'LINE

Figure 2

31
WHY LCM NEEDS DA

QUALITY DATA

IS THE KEY

TO QUALITY SYSTEMS

MOVE AWAY FROM TECHNOLOGY AS FOCUS

FTiOMOTE IMPROVED FUNCTIONAL CONTROL

MAKE NEW TECHNOLOGrI CAL TOOLS WORK:

PROTOTYPING

C.A.S.E.

4 GL s

DBMS & DDBMS

ENTERPRISE NETWORKING

OFFICE AUTOMATION

,, . Figure 3

32
WHY DA NEEDS LCM

TRANSFORM THEORY INTO PRACTICE

INTEGRATION VEHICLE EOR

DATA MANAGEMENT

DATA STANDARDIZATION

DATA ELEMENT NAMING

DATA QUALITY ASSURANCE

DATA ENGINEERING

DATA MANAGEMENT

GAIN ADDITIONAL RESOURCES:

I»EOI»LE

EUND I NG

TECHNICAL ASSISTANCE (TOOLS)

LEGITIMIZE & INSTITUTIONALIZE DA

Figure 4

33
RECOMMENDATIONS

DATA ADMINISTRATION &. DATA MANAGEMENT

MUST BECOME CHANGE AGENTS

!

RE— WRITE LIFE CYCLE MANAGEMENT:

I»OL I C I ES

STANDARDS St. GUIDELINES

OPERATING I»ROCEDURES

SEPARATE DATA ADMINISTRATION

AND SYSTEMS DEVE LOI=»ME NT

BE F»REF»ARED TO TAKE SOME RISKS,

INCREMENTAL CHANGE TAKES FOREVER!

Figure 5

34
DATA ADMINISTRATION

AND THE

SYSTEMS DEVELOPMENT LIFE CYCLE

Ellen J. Levin

Federal Home Loan Mortgage Corporation

This paper describes some of the efforts to introduce a system

development life cycle management approach at the Federal Home

Loan Mortgage Corporation, more commonly known as Freddie Mac.

This approach involves a development methodology that

incorporates the data driven and process-driven approaches to

application system development. This paper offers an analysis of

the factors which have contributed to its successful

implementation and offers directions for future development

toward an approach more heavily weighted toward a data-driven

methodology

.

The life cycle development manual was developed by a small team

of individuals representing different sets of experiences toward

system development — entity and data modeling, functional

decomposition/structured analysis, and testing/quality assurance.

Established by high-level technical development management, the

team's purpose was announced to all information systems

personnel. An advisory committee, representing key systems

development, database, and maintenance areas, provided regular

feedback on the team's efforts, and helped to publicize the life

cycle activity.

The team had two major objectives which it followed to assemble

the methodology. The first was that the methodology had to be a balance between "data and process," and second, that the life

cycle should be an "organizing principle" which would provide the

framework for a common basis of understanding. Both of these

goals were achieved. The necessity for addressing both data and

process recognized that there were two vocal, equally determined

schools of thought within the organization, each convinced that

one approach or the other was the preferred method. In fact, the

"process people" far outweighed the "data defenders" in numbers.

This is a reflection of the prevalence of process-driven

structured analysis techniques currently practiced by information

systems professionals today. The balanced approach required that

each side would have to understand the other and that the result

would be a workable method that would address all concerns. The

organizing principle involved the definition and description of

products to be produced at each phase of the life cycle,

categorized as pertaining either to the process model or the data

model. Additionally, products were specified. The life cycle

manual was summarized on one page as a matrix of products to be

produced at each phase within each model (see fig. 1)

.

35
Definition of products irrespective of the functional area that

might be responsible for producing them helped to focus attention

on information content. This avoided potential conflicts between

organizational groups and also a premature concern about

resources. A further benefit of this approach was that the

skills needed to produce each product could be identified. This

has formed the basis for hiring and training decisions, which

will ultimately change the organizational makeup and the approach

to system development.

Successful implementation of the life cycle methodology is

dependent on a number of factors. Clearly, management commitment

is essential and can be seen in several key areas. One is the

official endorsement which management can provide. Second, and

perhaps more significant, is the encouragement and support that

management can provide by rewarding quality products. This could

be a departure from a cultural norm where the primary focus is

getting things done on time. When implementing a new

methodology, inevitably there will be impacts on schedules, since

there are new techniques to understand and use effectively.

While management should endorse and reward use of the new life

cycle, it should not, initially, mandate its use. Preferably,

pilot projects involving team members with a willingness to try

new things should volunteer to exercise the life cycle out of an

interest in providing more structure to their projects. This

voluntary nature produces willing participants who are then able

to identify the benefits, as well as some of the difficulties, to

management and to other developers. A critical component is

providing ongoing training in the use of the new life cycle

methods

.

One area of difficulty which must be addressed involves some

apparent duplication of effort and products inherent in producing

discrete products for both the data and process models, some of

which do overlap. For example, structured analysis techniques

identify data items such as data flows, data stores and data

elements. The developers must reconcile these with the entities,

entity-relationships, and entity attributes that form the data

model. A second difficulty is the large volume of information

that must be documented and managed for the project. Both the

structured analysis techniques and entity-relationship approaches

require the production of graphic materials, data flow diagrams

and entity-relationship diagrams, as well as narrative and

descriptive text. These difficulties can be effectively

addressed through the use of software engineering tools that

fully integrate and cross-validate the data and process model

products of the life cycle in an automated way.

The use of automated CASE tools also helps to assure that life

cycle products meet quality standards. The life cycle specifies

that certain products will be produced at certain phases. A

level of rigor is imposed on developers to produce the

36
deliverables at the specified time. This encourages complete

analysis before beginning design, and completed design before

implementation. There may be a tendency to postpone clear

specification until the design and development phases, reflecting

a tendency of developers to devise physical solutions to problems

before completely understanding the logical system requirements.

A quality assurance function can play a valuable role in this

area by educating project teams, conducting product reviews at

identified milestones and by informing management of risks when

life cycle method standards are not met.

The life cycle methodology, with its emphasis on a balance

between process and data, provides a certain familiar frame of

reference for a majority of the developers, because it includes

the functional decomposition, structured analysis approach.

Because of that, it tends to represent an application view of the

data. The structured analysis methodologies define scope based

on the functionality of the systems, not on the data being used.

This is a fundamental weakness of the balanced approach. This

may result in continued redefinition of data, since each

application project has a limited, partial view of the data.

One solution to this dilemma is to use the life cycle within the

perspective of a global conceptual entity-relationship model,

which documents organization-wide business rules. The global

model becomes the starting point for all development projects. In

this way, project scope boundaries can be established in a

rational manner. The starting point of the life cycle process is

the validation of the global entity relationship model and the

definition of all entity attributes. The process portion of the

life cycle then consists primarily in determining what business

functions and processes need to be performed on the data. All

possible questions and activities required by the functional

areas must be satisfied by the logical database structure as

depicted in the entity-relationship diagram.

Defining the data model prior to the process model requires an

understanding of the importance of focusing on the data. This

data-driven understanding, in many organizations, cannot be

achieved quickly. Rather, a gradual progression of increasing

understanding is more achievable. Using a life cycle methodology

that combines the data and process approaches, while initially

resulting in some inefficiencies, serves to highlight the

importance of defining the data model while acquainting

developers with the purpose and methods used in data analysis.

It sets the stage for moving beyond process driven requirements

analysis to an organizational environment that is prepared to

adopt a data-driven approach.

37
Ms. Levin is Senior Information Systems Analyst at the Federal

Home Loan Mortgage Corporation (Freddie Mac) , designing the Life

Cycle Methodology and Corporate Enterprise Model. Previously,

she has worked at Intelsat and Comsat.

38
I

CD

O

U

«4H

oE

o.o

>oo

CO c 5-?

0> li

i2 £

0)

0) —

QC

a> .t:

o "> * £

CL CO 3 O

.5 <g E ? S

« S « « Ek' w S a a: S -c

re re tf Q D<

°oo aw 5^o- E

0) B 3 o

~

to * oB aico S U

' •5 D re ~«<^ re re e

o S E

- a. u) G 5? CO o 8 re

> re re V) "q. E re IllSlE^ig re o o (1) c IW w I- £

(/J eg

re c: Q) c- c

c <1> > n ^ —

o p c g P c |§-El^.^ u. 5 a; 0) p 5 =j 5 o >, a> Z W CC

re;^ 5^

p p r; p _ 5 2 g

if £5?: S

^„ §C0 res 2 re ^ re i w re ^ O

CD O LL

re Q

po g g cfl re 5

-o^5®E«a>Q-=a> y2:iSo)^Cwi--,re«

1^

.9 c

o

:3S ^2 Svi Sv) -Q.>

.- S*^ ns re 2 a. £ Q. Q Q (- <

E CO

5 E

> 0) o 5 • S DC re a:

re 2> o w o « _ 0) t S o) E

*" re c c 2 O O O) w re iS

0) J? bo ^ M oc DC a: c 'a —

c c c

aiLuuj

2 o'.e

.5, re o re re 2Q

c o

x3 re

^ 5 -2c

0) 0) re 2 2

t/33 5 DCOl^DC

2 0,0: i £ S 5|

Sen

^ ,= re goc ?

re s <n m o- <J E

Q.2 5>c<-Dcn

I

I

CC -Io E §w

E 01 O ^ m Q- ^ 1 1 E a; Q. to _J o( Q. J ^ LU (JJ c ^ oi dj 3

E re o> E i3 o a

0) jt re 3 if o) 0; •5.5; c (/) < 0) CC ^ re —

E 2 2

0) _ re 5 5 a.^ E p U, $ r=o g.Et2 aE

tSS ojCCSi

1-2 2 CO

Q. -o I E^i^^m g m E p o) 5 c

o m oi E (3 0 p. o -c re 3 c 05 «^ >Q. CtO< (BCC

<D re — Q 2 5

CO o

to 5 8

2^

4 « O) E (3 o !1 = ^ re 13 c o) 1) <S a: S CO .5 0) CC <S 5 i

p^ 1 I

0) ^ E C ? ^ ^f8g)Etoa 0) ^ re 3 cf 05 ^ c Q. c CO < 0) q: 020) TO ^2

E TO 3 -£ ^ re

05

0, E ^

05 ^ c: ^ s o> E "s 2 a = ^ TO 13 C 05 ^ So. c CO < a CC

S re 5

? Q-05T,

c c

CL E re „ 05 0.

d5 5 P ?P

— . CC ^

o o< *

a. al

(0 O O

39

DATA ADMINISTRATION

AND THE

SYSTEMS DEVELOPMENT LIFE CYCLE

SUMMARY OF REMARKS

Mary Ann Wallace

National Archives and Records Administration

Records managers act as a 'drain' for information systems,

assuring that archived information is stored safely and

systematically. In addition, they identify information already

available, ensure its existence for a certain length of time,

then dispose of it. Two percent of all government records reside

permanently in the National Archives.

A 'record' has been defined by Congress as any information

related to the government's business, regardless of physical

form. This is not too far from the data management definition of

a set of related data treated as a unit.

Figures two through five illustrate the interaction between

records management and the life cycle management of information

systems

.

Ms. Wallace is Director of the Agency Services Division of the

National Archives and Records Administration. She is responsible

for assisting agencies in the management of recorded information.

41
RECORDS MANAGEMENT

AND THE LIFE CYCLE MANAGEMENT OF INFORMATION SYSTEMS

WHAT IS RECORDS MANAGEMENT?

PURPOSE

TOOLS

ORGANIZATIONAL RELATIONSHIPS

AUTHORITIES

Figure 1

RECORDS MANAGEMENT

AND THE

LIFE CYCLE MANAGEMENT OF INFORMATION SYSTEMS

WHAT DOES THIS HAVE TO DO WITH THE LIFE CYCLE MANAGEMENT OF INFORMATION SYSTEMS?

MANAGING INFORMATION AND THE TOOLS NEEDED TO SUPPORT IT RECORDS ARE RECORDED INFORMATION

THEY MUST BE PROPERLY MANAGED JUST AS THE TOOLS THAT CREATE, COLLECT,

PROCESS, TRANSMIT, USE, AND STORE THE INFORMATION

RECORDS MANAGFMENT CONSIDERATIONS APPLIED TO LIFE CYCLE MANAGEMENT CAN;

REDUCE INFORMATION SYSTEM COSTS

ENSURE AVAII.ABLITY OF INFORMATION TO USERS FUR LENGTH OF TIME REQUIRED

PROVIDE FOR THE PROTECTION AND INTEGRITY OF THE INFORMATION

--- SEE THAT AGENCY OPERATIONAL NEEDS, INCLUDING LEGAL REQUIREMENTS, ARE

MET OBTAIN THE NECESSARY AUTHORIZATION TO DISPOSE OF THE INFORMTION WHEN NO LONGER NEEDED

Figure 2

42
RECORrS MANAGEMENT

AND THE LIFE CYCLE MANAGEMENT OF INFORMATION SYSTEMS

WHERE AND HOW DO THEY GET TOGETHER

INITIATION PHASE

IDENTIFY INFORMATION SUPPORTING MISSION AND ITS CURRENT LOCATION,

ORGANIZATION, AND DISPOSITION

AGENCY /EXTERNAL SOURCES OF INFORMTTON

OTHER INFORMATION USERS INFORMATION DOCUMENTATION REQUIREMENTS, INCLUDING LEGAL REQUIREMENTS

ESTABLISH SYSTEM DOCUMENTATION AND RECORDKEEPING REQUIREMENTS

DOCUMENT ACCESS REQUIREMENTS, INCLUDING PUBLIC ACCESS AND RESTRICTED

INFORMATION

Figure 3

RECORDS MANAGEMENT

AND THE LIFE CYCLE MANAGEMENT OF INFORMATION SYSTEMS

DEVELOPMENT PHASE

IDENTIFY RECORDS SUPPORTING INFORMATION IN CURRENT SYSTEM IDENTIFY INFORMATION REQUIREMENTS FROM THE SYSTEM AND THEIR RECORDKEEPING PRACTICES (ROUTINE, SITUATIONAL AND EXPECTIONAL REPORTS) DETERMINE IF THE SYSTEM WILL RESULT IN NEW RECORDKEEPING REQUIREMENTS

- WHAT ARE THEY, HOW WILL THEY BE COMPLIED WITH ANALYZE THE LENGTH OF TIME INFORMATION IS NEEDED TO SUPPORT THE INFORMATION REQUIREMENTS OF ALL USERS DETERMINE FORMAT THAT BEST MEETS LENGTH OF TIME REQUIREMENTS

ADVISE ON VITAL RECORDS PROCEDURES

OBTAIN A PRELIMINARY DETERMINATION FROM THE NATIONAL ARCHIVES ON PERMANENT VALUE OF INFORMATION CONTAINED IN THE SYSTEM DETERMINE HOW SYSTEM WILL MEET NATIONAL ARCHIVES REQUIREMENTS FOR THE MAINTENANCE AND DISPOSITION OF ARCHIVAL INFORMATION

ASSIST WITH DOCUMENTATION OF SYSTEM DESIGN TO ENSURE INTEGRITY OF THE RECORDS

Figure 4

43
RECORDS MANAGEMENT

AND THE LIFE CYCLE MANAGEMENT OF INFORMATION SYSTEMS

DEVELOPMENT PHASE ( CONT )

DETERMINE AND EFFECT DISPOSITION OF RECORDS ASSOCIATED WITH INFORMATION SYSTEMS BEING REPF.ACED OBTAIN DISPOSITION AUTHORITY FOR INTERIM DOCUMENTATION

PROVIDE GUIDANCE ON RECORDS MAINTENANCE, ACCESS, AND DISPOSITION FOR INCLUSION IN USER AND OPERATIONS MANUALS

ENSURE RECORDKEEPING AND RECORDS DISPOSITION REQUIREMENTS ARE PART OF

POST IMPLEMENTATION REVIEW PLAN

OPERATION PHASE

ENSURE ALL RECORDS MAINTENANCE, ACCESS, AND DISPOSITION PROCEDURES ARE INCLUDED AND WORKABLE

PERIODICALLY REVIEW SYSTEM OPERATION

OBTAIN DISPOSITION AUTHORITY FROM THE NATIONAL ARCHIVES AS NECESSARY

PARTICPATE IN THE POST IMPLEMENTATION REVIEW AND REFINE RECORDKEEPING

AND DISPOSITION REQUIREMENTS AS NECESSARY

Figure 5

44
/

MANAGING ORGANIZATIONAL CHANGE

AS DATA ADMINISTRATION IS IMPLEMENTED

MODERATOR

Rae Thompson

Smithsonian Institution

PANELISTS

Michael Menard

Joan Shapiro

Richard Lytle

Margaret Skovira

45

MANAGING ORGANIZATIONAL CHANGE

AS DATA ADMINISTRATION IS IMPLEMENTED

Michael P. Menard

President, Bush Menard, Inc.

Objectives of the Presentation

The team responsible for bringing new technology into an

organization faces a formidable series of challenges. Technical

success does not guarantee project success; equally important is

that you gain the commitment of employees and managers at all

levels to integrate the new technology into the fabric of the

organization. The purpose of this presentation is for both

myself and the other panel members to discuss with you some of

the techniques which we have found to be successful in this task.

The Dynamics of Technical Change

I find it helpful to look at the introduction of new technology

in relation to three other organizational factors: the overall

goals of the organization, the operations or tasks and activities

performed in the course of doing business, and, most important,

the employees themselves. Figure 1 shows the state of these four

factors before new technology is introduced. Ideally, the

existing technology has been designed to facilitate the current

operations and both factors are strongly tied to the goals. The

people know how to do their jobs, how to use the technology and

are committed to the goals.

Figure 2 shows the disruption caused by the introduction of new

technology and suggests a possible agenda for its successful

integration into the organization. In Phase 1 not only does new

technology replace the old, but it breaks down technology's

existing relationships with goals, people and operations. In

Phase 2 new operations are put into place to take advantage of

and support the new technology. At the same time, however,

operation's previous relationships with goals and people are

seriously altered. Phases 3 and 4 complete the restructuring

process through training of users and demonstration of benefits.

The job of the team, then, is not just to install new technology,

but also to construct appropriate new operations and then re-knit

the fabric of the organization.

47
Critical Success Factors

The specific issues you choose to address and the actual

techniques for implementation are highly dependent upon the

culture of your own organization. No single approach will work

in all cases. Here are a number of ideas to consider. The

chance to alter existing operations presents a significant

opportunity. Instead of merely using new technology to "automate

the problem," use this time to reexamine the effectiveness of

current procedures. Often employees will view new technology as

an increased burden on their work load. If better operations are

part of your overall package, then you will be able to sell the

technology to employees on the basis of making their job easier.

Use one of the existing business modeling technologies to be sure

that you fully understand the existing operations and the impact

that your technology will have.

Do everything possible to transfer ownership of the new

technology to the employees and managers who are going to be

affected. People are your most valuable resource and the most

important actions you can take are those which will inspire the

rest of the organization to work actively for the success of the

project. Early involvement in project planning is critical.

People who feel that they have some control over their job

environment will work hard to make improvements. There is a

dangerous tendency to try to maintain tight control over a project and not get too many people or organizations involved.

But early on in a project you should identify all the people

whose help is critical to your success and involve them in the

decision making process. This includes not only your own

employees, but managers and key employees from other work groups.

Have an honest but active marketing plan. Contrary to popular

belief, good ideas do not sell themselves. You must anticipate

potential adverse reactions and develop plans to channel these

energies in useful directions. You must, however, resist over

selling. Every beneficial change has costs of some sort or

another. Be forthright in your explanations of these costs.

People will appreciate the respect they are being given by having

all aspects of the situation explained to them. Even more

importantly, they will not feel resentful later when the hidden

costs must be paid.

Make your training program activity-based. It is rarely enough

merely to teach people how to use the new technology. You must

teach them how to do their jobs with the new technology. During

the course of the training, take key work activities and

explicitly demonstrate how they will be carried out with the new

tools. Ignoring this critical step in the transfer of technology

will only result in delayed productivity for the new system.

48
Finally, it should be an ongoing daily task of every manager to

improve the bonding between employees and the goals of the

organization. If employees are committed to the overall mission

of an organization AND THEY UNDERSTAND THAT AN IMPORTANT

COMPONENT OF THAT MISSION IS TO PROVIDE A REWARDING AND

PRODUCTIVE WORK ENVIRONMENT, then managing change is really quite

simple. Building such trust cannot be done just for one project.

It must exist long before the project is even conceived. But in

those organizations where these activities occur, change is

always an opportunity to be savored rather than a crisis to be

solved.

Dr. Menard is Assistant Professor of Information and

Communications Systems at Fordham University's Graduate Business

School. He has spent eight years at Exxon Corporation in a variety of information systems positions. He holds a Doctorate

in Adult Education. His book. The End User's Guide to Computer

Systems Development... will be published soon.

49
50
51

MANAGING ORGANIZATIONAL CHANGE

AS DATA ADMINISTRATION IS IMPLEMENTED

SUMMARY OF REMARKS

Joan Shapiro

Chemical Bank, New York

A real problem in data administration has been business entities

within the corporation which consider themselves, and their data,

independent of all other organizational units. They consider

their data model their own. There is confusion between sharing

record structure and data values, especially at the top of the

company.

The data administration function has been renamed Corporate

Information Architecture. The stress is on interfacing and

standard definitions of such common data elements as 'customer'

and product definitions, and the relationships between data

elements. Information of cross-corporate use is stored in the

corporate dictionary. This data is defined by a very high-level

business information model.

Ms. Shapiro has spent twenty years in IRM and data processing.

She is currently Associate Vice-President and internal data

consultant for Chemical Bank of New York City. She has spoken at

many conventions and conferences.

53

MANAGING ORGANIZATIONAL CHANGE

AS DATA ADMINISTRATION IS IMPLEMENTED

SUMMARY OF REMARKS

Richard Lytle

Drexel University

Our culture holds hard science and technology superior to such

'soft areas' as information content.

An organization has both a formal and an informal structure. It

is important to know both when introducing change. One should

also know the attitude toward top management in the rest of the

organization. In converting the data processing staff to data

administration, selling planning is the hardest part. Try to

find allies in line areas.

The 'soft areas' must be managed rationally. Staff attitudes

towards change are seldom taken into account in business

presentations. Commitment at the top, ideally at the very top,

is essential.

The 'change agent' for the soft areas should be personally

consistent with the corporate culture. Once the users catch on,

they will be way ahead of the change agent, because they know

their business.

FACTORS SELECTED FOR DISCUSSION

O CULTURE OF THE ORGANIZATION

0 PERSONALITIES OF KEY MEMBERS OF TOP

MANAGEMENT

0 POSITIONS AND PERSONALITIES OF THE

CATALYSTS OF CHANGE

O FACTORS SPECIFIC TO DATA ADMINISTRATION

CULTURE OF THE ORGANIZATION

O FORMAL AND INFORMAL STRUCTURE

O ATTITUDE TOWARD MANAGEMENT PER SE

55
O PLACE ON ACADEMIC VS BUSINESS SPECTRUM

O ROLE OF DATA PROCESSING IN THE

ORGANIZATION

O INTERNAL CULTURE OF DATA PROCESSING

O ATTITUDE TOWARD PLANNING

O OPENNESS TO CHANGE OF ANY KIND

O AWARENESS OF DATA ISSUES SPECIFICALLY

O WILLINGNESS TO MANAGE "SOFT" FACTORS

RATIONALLY

PERSONALITIES OF KEY MEMBERS OF TOP MANAGEMENT

O AS INDIVIDUALS

O INTERACTION AT TOP MANAGEMENT LEVEL

POSITION AND PERSONALITY OF THE KEY CHANGE CATALYSTS

O ADMINISTRATION POSITION

O PERSONAL RELATIONSHIPS WITH KEY

PARTICIPANTS

O FIT WITH CORPORATE CULTURE

FACTORS SPECIFIC TO DATA ADMINISTRATION

O INHERENT DIFFICULTY OF EXPLAINING DATA

ADMINISTRATION IN MOST ORGANIZATIONS:

DATA ADMINISTRATION EQUAL MIND CONTROL?

O PERCEIVED IMPORTANCE OF THE TASK THAT IS

THE OCCASION OF DATA ADMINISTRATION

IMPLEMENTATION

O CONFUSION OF TECHNICAL AND DATA ISSUES

O CONFUSION BETWEEN DATA ADMINISTRATION AND

DATA PROCESSING

56
o DATA PROCESSING

ADMINISTRATION??

VERSUS DATA

EXAMINE A FEW PRESCRIPTIONS FOR SUCCESS

O DATA ADMINISTRATION CAN SUCCEED ONLY WITH

TOP MANAGEMENT SUPPORT

O DATA ADMINISTRATION MUST REPORT AT LEAST

TO LEVEL THAT DATA PROCESSING REPORTS

O CONSTRUCTING DATA ARCHITECTURES MUST

PROCEED TOP DOWN

O AUDIENCE-SUPPLIED PRECEPTS

Dr. Lytle is Dean of the College of Information Studies at Drexel

University. Until 1987, he was Director of IRM at the

Smithsonian Institution. He previously held positions at the

Smithsonian, Rice University, and Washington University. He has

a PhD in Information Science from the University of Maryland.

57

MANAGING ORGANIZATIONAL CHANGE

AS DATA ADMINISTRATION IS IMPLEMENTED

Margaret Skovira

Bureau of the Public Debt

In the children's song, "The Farmer in the Dell," the farmer

acquires a wife and child, a nurse, a dog and cat and in effect

builds an organization. The farmer's last selection is the

cheese, who is immediately abandoned to "stand alone" by the

group into which he was so recently welcomed.

Is this scenario familiar to the data administrators in the

audience? Was data administration introduced in your

organization with a great deal of fanfare, which soon amounted to

a crowd of people waiting to see what you would do? and how? and

how soon?

Hiring a data administrator in an organization which has not had

one introduces a change that goes beyond an organizational

realignment. It does, of course, add a box to the organization

chart, and cause some responsibilities to be shifted, but it does

much more than that: the introduction of data administration

implies a change in management emphasis. An organization without

data administration is managing the processing of its data; an

organization with data administration aspires to manage the data

itself.

Why is the shift from managing processes to managing resources so

significant? Consider, for a moment, an organization with no

personnel office. Each manager could hire a staff, reward it as

he or she saw fit, and retain employees only as long as the need

was evident. In such a hypothetical situation the manager would

have control over the personnel it took to do the job at hand. A

personnel director with classification standards, hiring

practices, pay scales, performance appraisals, productivity

standards and so on would benefit the organization as a whole,

but the individual manager would lose control over one essential

resource to getting the job done. He would lose control to a function that would not consider only his office's needs as he

would have considered them. A personnel manager might require

activities for the benefit of the organization, or for the

benefit of its employees, activities that might interfere with

"getting the job done."

"Getting the job done" is the focus of operations managers and

process managers. Ensuring that the resources are there to do

the job is the focus of personnel directors, vice presidents of

finance, and data administrators. "Managing data as a resource"

is not my topic. But it is important in that context to

recognize that data administration is more than a new office or a

59
further specialization of technical functions. Data

administration has the potential to change the way an entire

organization does business.

The problem for the data administrator becomes one of how to

introduce this far-ranging type of change without adversely

affecting productivity. Notice, I did not say "without

disrupting the organization." As Dr. Menard has suggested, change

will be disruptive when human organizations are affected by it.

The challenge is to direct organizational energy into new avenues

of endeavor as the traditional ways of doing things change.

The goal is to manage the way data is maintained, used, and

discarded and not bring to a grinding halt those processes that

depend on the availability of data.

The introduction of data administration has both a tactical and a strategic aspect. Tactically, the data administrator must

establish an organizational base. The organizational base will

be derived from the components of the old organization, and

integrated with them. Strategically, the data administrator will

use this organizational base as the springboard for the move to

data management.

My experience with data administration is exclusively from within

the data processing shop, and my thoughts on change management

derive from that viewpoint. Inside the data processing

organization, data administration is usually introduced

deliberately. It will not appear to be technology driven, as

end-user computing is, for example. It will appear to be the

result of management commitment to an emphasis on the importance

of data. It will not come about because someone is already

performing the function, legitimizing what already exists in

fact. Rather, the organization chart, the function statements,

and the position descriptions will be carefully developed and the

reorganization announced with much fanfare. Having established

the requisite management commitment to data administration, the

organization will stand back to observe how the first incumbent

will perform. The cheese stands alone.

If the data administrator wishes to bring about the change she

has been chartered to introduce, she will not allow herself to

stand alone for long. A strategic data planning project will

keep the data administration staff busy, and will have a longterm payoff, but it will not integrate data administration into

the organization in the short term. And organizational

integration means contributing to the accomplishment of today's

work today. The benefits are twofold: first, a product in a user's hand is worth two in the long range plan. When it comes

to establishing credibility there is nothing like a concrete

accomplishment. Second, by devoting energy to meeting current

work demands, the data administrator will uncover areas of

60
opportunity for the future, opportunities for improved data

management; not theoretical opportunities, but real ones.

For example, in my organization the only interaction between

users and data has traditionally been a custom built application.

As a result, a certain amount of manual data manipulation was

occurring when it was not cost effective to design and write

programs. Data was being keyed into PC's from computer listings.

The automated data access developed for users by the data

administration staff was not elegant, but it made the user's job

easier and removed an item from the system development backlog.

And the data administration branch had a visible accomplishment.

The danger of this approach is the old problem freguently

summarized as, "when you're up to your neck in alligators it is

difficult to remember that your original objective was to drain

the swamp." Achieving a balance requires not losing sight of the

objective, in our case a data oriented approach to systems

planning and management, and always evaluating the daily

opportunities for how they will advance that objective. In

providing a single user a means to access data, the data

administrator could be laying the foundation for the development

of an information center, for example. Another example of a double-edged opportunity is data base administration (DBA) . In

my experience, the data administration shop, if it has DBA

responsibilities, can be overwhelmed in maintaining physical,

single application, databases, to the detriment of the

achievement of long-term objectives. On the other hand, in the

course of time many opportunities will surface through the DBA

function, opportunities for data sharing and for information

driven systems.

Another aspect of organizational change to be managed by data

administration is the introduction of new ways of doing work. The

design and definition of data structures, once a by-product of

system design, becomes a primary objective in a data

administration environment. Entity analysis, data analysis, even

a little business systems planning enter the methodology. Though

some of these processes may have been occurring intuitively, with

data administration comes the opportunity to formalize them into

the system development methodology. A data dictionary becomes

critical, and automated tools for data analysis, database design,

and for information extraction are likely to be called for. The

data administrator's task is to see that the tools and

methodologies for the new ways of working are in place. But

these tools and methodologies apply to the whole organization and

cannot be established by fiat. The data administrator may be

developer, facilitator and implementor - but not the "owner" of

the new methodologies. And never merely a spectator on the

sidelines. The introduction of these changes, so critical to

long-term accomplishments, will require all the diplomatic and

technical skill that the data administrator can muster.

61
The introduction of new tools and methodologies will not be

universally welcomed. A dictionary full of metadata restricts

the "creativity" of application developers, and requires

additional steps in the system design process. Initially, at

least, the systems analyst will not find his job made easier by

the fact that data definitions are centralized and independent of

applications. Instead, he will bemoan the need to coordinate his

activities with other organizational components, and the

inevitable errors, omissions and inconsistencies that require

time and effort to resolve. As a data oriented system

development methodology is introduced, the first attempts to do

new tasks may be tentative, trial and error efforts in which no

one is sure of the objective because "we've never done this

before.

The challenge for the data administrator is to facilitate the

implementation of these changes in the ways of doing work without

retaining sole proprietorship of the processes. There is a certain amount of "selling" involved, as Dr. Menard has

suggested. The selling may occur in the guise of training, or,

better, during consensus building as new procedures are

incorporated into existing methodologies. Eventually, the

benefits have to be apparent to all involved, or the new

approaches will be short cut.

What does the data administrator hope to achieve in the short

term? The management commitment that was behind the original

establishment of data administration must be bolstered with an

organizational commitment: an organizational commitment to a data

management approach to data processing, an organizational

commitmient to planning and developing systems from an information

requirements perspective.

To be successful in the long term, data administration must

change the way an organization views data. Data will be treated

as the primary resource of systems, as the term "data processing"

has always implied. Data will not be taken for granted but

analyzed, understood, and its forms perfected before processing

systems and user interfaces are designed. To be effective, this

new view of data must be shared throughout the organization.. It

cannot be a vision held only by the data administration staff.

Data administration cannot be introduced in isolation, the cheese

cannot stand alone. The first step is the realignment and

integration of functions. The second is the modification of the

infrastructure of standards and procedures, methodologies and

tools, to facilitate a data management approach. As these

changes are introduced, some immediate accomplishments are

desirable to establish the utility and credibility of data

administration, now, and its potential for the future.

62
When all this is done, data administration will have a base from

which to address the entire organization's data and information

requirements. Ultimately data management can become as normal as

personnel management.

Ms. Skovira is Data Administrator for the Treasury Department's

Bureau of Public Debt. She has spent twenty years in the

Automatic Data Processing (ADP) field. She is currently

Chairperson of AFFIRM.

63

TWO COMPLEMENTARY METHODS OF DEVELOPING DATA ARCHITECTURE

MODERATOR

Judith Newton

National Bureau of Standards

PANELISTS

Cathy Hirsh

Tom Turk

65

TOP-DOWN METHOD OF DEVELOPING DATA ARCHITECTURE

Cathy Hirsh

American Management Systems, Inc.

Peter Drucker has defined information as "data endowed with

relevance and purpose" in his article, "The New Organization,"

published in the January-February, 1988 issue of the Harvard

Business Review . Today, organizations have much automated data,

in fact, too often, more data than can be used effectively. In

addition, and unfortunately, much of that data cannot be applied

with "relevance and purpose" because the data available are not

the correct set of data needed or because they are of inadequate

quality.

How can this problem be corrected and how can organizations

position their information systems to be capable of delivering

needed information, or data that can be endowed with "relevance

and purpose", to support the goals of the enterprise? One of the

answers lies with the development and implementation of an

appropriate data architecture. This presentation addresses one

way of developing a data architecture—the Top-Down Design

Approach.

There are two key objectives of a data architecture:

0 To be able to provide a capability that can deliver the

information required by the organization over both the

short and longer terms; and

0 To provide a basis and aid for coordinating and

implementing appropriate information systems facilities.

To fully satisfy these objectives, any approach that is to be

used in designing a data architecture must have the following

characteristics

:

0 The activities performed in designing the data

architecture must be integrated and addressed together

with other requirements, such as functional requirements,

technology requirements, organizational requirements, etc.

While it is desirable to utilize an approach that is

"data-driven," identification of data requirements, absent

of consideration for other needs, cannot be the sole

focus

.

0 The approach must be capable of providing results that are

timely, developed at a reasonable level of effort, and

that address the appropriate level of detail.

67
0 The approach must be capable of addressing requirements

for data other than those arising from traditional,

"institutional" systems. In the past, most of the

automated support, and consequent requirements for data,

have resulted from the attention focused on the needs for

basic support of organizational operations. Today,

capabilities to support the "professional" or knowledge

worker must also be considered—capabilities such as

requirements for decision support systems, executive

information systems, and user support systems. In

addition, capabilities to support "external" systems

interfaces or potentially, even users of the

organization's systems who are themselves not part of the

organization (external to the organization) , must also be

addressed. As figure 4 shows, institutional systems

represent only one aspect of the total information systems

portfolio which most organizations require.

o The approach must also result in recommendations which are

practical and feasible within the context of the

organization's situation. Recommendations that are

"ideal," but not practical for the organization, are not

the "right" recommendations.

o The approach should be capable of being applied either at

the top-level of the enterprise or to portions of the

organization. Often, the scope of a study at the toplevel of the organization would be too broad, or else, the

organization is not yet ready to address the issues at

that level. Hence, an effort for some important or

"strategic" portion of the organization might be more

appropriate.

0 The approach must provide assurance that the

recommendations are integrated with the organization's

business or mission-support strategies.

The Top-Down Design Approach, if implemented properly, has all of

these attributes.

The key steps and products of the Top-Down Design Approach are

shown in figure 5. There is not time to discuss this process in

detail. Instead, some examples will be used to highlight a couple

of steps in the process.

The first example (fig. 6) shows an "information flow" model that

is one of the products of the enterprise analysis phase. This

diagram shows candidate groupings of information systems and data

flows among them based upon a high-level analysis of

organizational functions and their supporting information

requirements. This diagram provides a high-level overview and

context that can be used for further refinement to determine

68
additional detail about specific systems and data requirements

and, in the case of potentially distributed processing

environments, to determine possible levels and types of

distribution

.

The next example (fig. 7) presents a summary level information

architecture. It identifies the major systems, the subject data

stores and data classes, flows among the systems, and the

location of the systems (i.e., mainframe, local workstation,

external, etc.). While not obvious to one unfamiliar with the

specific situation, it also incorporates the information

technology approaches selected to satisfy identified

organizational strategies. This diagram demonstrates the type of

information necessary to the next stages of effort, the more

detailed development of data, application, and distribution

architectures and the development of an implementation plan.

Up to this point, the presentation has addressed the context

within which a data architecture is developed utilizing a topdown design approach. The remainder of the discussion will focus

specifically on the development of the data architecture and on

the benefits of developing it in this fashion.

The process for developing a data architecture following a topdown design approach is the following. It begins, as one might

expect in utilizing a top-down approach, at a high level with

content progressively refined as more detailed requirements are

determined. Entity-Relationship (E-R) Analysis techniques are

used initially and, as further detail is developed, throughout

all phases of development and implementation. As the design

progresses, primary and secondary identifiers and groups of

attributes, or domains, for each of the entities are identified.

As identifiers and attributes are determined for each of the

entities, the rules for first and second normal forms can be

applied. At the logical database design level, the full set of

attributes should be identified and the database design can be

represented following relational data model conventions. The

next graphic depicts the process just described. Note that

further detail on the "data side" progresses only as further

detail is determined on the "process side," and vice versa.

Figure 10 is a sample Entity-Relationship diagram. The scope

covered by this diagram is intended to be that for a full

personnel system, and it identifies all the entities for which

support will be provided by the particular system. The

diagramming technique used in this example is one of the

techniques used in E-R diagrams. Other techniques, some of which

show more detailed information, are also possible.

The E-R diagram, even though at a high level, displays much

information for review and analysis - "business rules" that might

otherwise not be visible but imbedded in program design

69
specifications, code, or omitted entirely from the system. For

example, the diagram shows that for this particular organization,

an employee can have multiple positions and that a given position

can be held by multiple employees. For other organizations, this

rule might be entirely different. A 1-to-l relationship, for

instance, is one some organizations have which means that an

employee can only have one position and that a position can be

held by only one employee. Similarly, the entire content of an

E-R diagram can be reviewed to ensure full coverage of the

necessary entities and that the relationships defined among them

are proper for the organization. Such "rules," shown in diagrams

of this nature, can be easily reviewed, analyzed, and verified by

end users and top management to ensure that the system will be

designed to meet the organization's requirements.

Optimally, it is nice to be able to begin data analysis and the

preparation of E-R diagrams at the enterprise level with

refinement occurring as further design work progresses to the

system and project levels. At each successively lower level, the

E-R diagrams are reconciled to the next-higher level to ensure

that consistency of the design is maintained across all systems

for the enterprise.

In some cases, as in the example, it is not possible to begin at

the enterprise level, and work begins at the system, or even at

the project level. Even in these instances, the use of entity

analysis techniques is very beneficial, providing a full picture

of the data at the particular design level and providing a basis

for review and analysis as other systems are developed that will

interface to or be integrated with the system.

Benefits of the top-down design and entity analysis approach are:

0 It provides a very understandable, simple technique for

exposing, determining, and verifying business rules and

integrity rules related to the data.

0 It provides an easy technique for building consensus as to

what data requirements a system needs to support.

0 It can be applied in a phased manner as the process and

data designs are refined progressively.

0 It can be applied to both new and existing systems and

data stores.

0 Numerous tools are now available to support the techniques

with more refined tool support expected for the future.

0 It provides a big picture look to avoid the "missing the

forest for the trees" syndrome.

70
In conclusion, a data architecture, as well as all the other

information system products must relate to and support an

organization's strategies and management objectives. The topdown design approach, coupled with entity analysis techniques, by

providing an overview process, provides an opportunity for

development of products that do so. This approach works and,

like any approach, can be adapted to meet the needs of a particular organization and situation.

Ms. Hirsh is Senior Principal at American Management Systems,

Inc. She is currently manager of the information resources

management practice area. She has supervised projects addressing

a wide range of IRM issues. She has been a manager of many

corporation-wide planning and implementation projects, and team

leader for numerous system development projects and ADP studies.

Previously, she was director of data administration for

Government Employees Insurance Company (GEICO) . She is past

member of the board of directors for GUIDE International and

currently manages GUIDE'S Executive Forum for senior level

executives. She is also the Vice-Chairperson for Programs for

AFFIRM.

71
TWO COMPLEMENTARY METHODS

OF DEVELOPING

DATA ARCHITECTURETOP DOWN DESIGN APPROACH

Cathy Hirsh, Senior Principal

American Management Systems, Inc.

Prepared for

DAMA Symposium

Data Administration: Management and Practice

May 17, 1988

Figure 1 —ams—

OBJECTIVES FOR A DATA ARCHITECTURE

• "INFORMATION IS DATA ENDOWED WITH RELEVANCE AND PURPOSE"

- Peter Drucker, "The New Organization." Harvard Business Review . January-February, 1988

• OBJECTIVES IN BUILDING A DATA ARCHITECTURE

-- To be able to provide a capability that can deliver the information

required by the organization over both the short and longer terms;

-- To provide basis and aid for coordinating and implementing

appropriate information systems facilities.

ams

Figure 2

72
ANY APPROACH USED TO DESIGN A DATA ARCHITECTURE

MUST HAVE THESE ATTRIBUTES

• Activities in building a data architecture must be integrated and addressed

together with other requirements.

• Approach must result in timely recommendations with level of detail appropriate to objectives.

• Must address systems and requirements other than "institutional" systems. - Decision support systems

-- Executive information systems

-- User support systems - "External" systems/data

• Must result in practical, doable recommendations.

• Can be applied to portions of the organization as well as to the entire "enterprise."

• Must support the organization's strategies.

Figure 3 ams

Information Systems Portfolio

ams

Figure 4
TOP DOWN APPROACH

KEY STEPS AND PRODUCTS

Project Plan

Organizational

Strategies

I

Enterprise Analysis Business Products & Services/Strategies

Functions/Processes Data Entities/Classes Organizational Responsibilities Information Flow

Existing Data Systems/Technology Support

Matrices

Information Strategies

and Architecture

Application Architecture Data

Architecture

Distribution Architecture

r

Implementation Plan

Specific Implementation Tasks

Figure 5

74

ams
"no 1 1« 2 I N««w6 ~ JIM ~oc»

-III"! *i6iMa^i ii»*oT»~

III iiiifAi.^oiiwiioiMi'ooi'

Jiiiai.iaiaiaji, liiai i i lai l

^21 IIIII„IIIIIIIh*9??^?Io*5I" " IIIIIIIIIIIII?oIi'*9i~'*J" IIIIIIIIb????'!?^^?!???!?^^!???"

~'TTeM*»<r"ii6fIi«riiVm"o»t""

" *ni*?*i§sii!

" IIIIII'*Ii!?lD!°"?l^-.

~ " IIIl!''il9¥?*'!l?HI!

3 "TiliniTiii'Ajiiiiiiliir'oii"' " IIIIIIII^li?!7?9?I??*I! IIII"IIIII"9?^I?tIZ

" I.!99?JcI;Ii?^?^I?55l

II?9liCiIi¥?lI;Ii?l^**IH?I!

~ II"?5iI?*Ii*¥?^9lH?I ~ ~ I..Ii^l^l^^??I§l?I

II"IIIIIi??¥i?7?*l9liI ~ '

^ 11"^?j»iijg;j<»Ij°II

'" II"""••?!'?iiI*?Qi!l?*iI

IIII"i5iIili»ii!S»i«oii"oiI" ~ '"•"tI?*!!

'OQI

oTi

H"III".Il!?liOili!?II?tI Tiiouin iiillioiiMi'"Iiii»i'T»3iIi"o*"

3< 3< bib!'

I 3< 31 3i so

ai laiai laia 3'3i3<3'3< >3

I3i3 Ibis

J< 3i3

'

I 3 1 3

>3>U<3i3i3< _i 'ui3l30'>3i3l3<3l3 o! si si 31 3^

. 3i 3- isisi

i iiaiaiiiaia 3>U> 3 3

3i 3>« U0i3

ui 3i".

i

I 3t3

i3'3

• 3>3

oi's

3' 30

3. SiB

si 30

3. 3-

S

3' si 3

si bis

3iSi3i30t

J_|__;3i3|3'3iSO-3i3i3iS'

I'slslbl-ao'i"! i'"l"'lsls!"l

;|i : i

5:5:8;'

;s: :

:3:::t':

75
U to

to

at

I

1^

z < o o

- £

ll

II m

E

ID

lu O

a:

CoQ

i

1 I

sic

I II la if!

1 i r

J i

III 1 ^

z

i if 5

1 1

I. 5 IJII

J ? j

so

toQ

1

(oI

toQ

5

ae

to

. e

76
DATA ARCHITECTURE DEVELOPMENT PROCESS

• Begins at a high level, becoming more detailed as the "process" side is refined.

• Utilizes Entity-Relationship Analysis Techniques and diagrams throughout ail phases of development and operation.

• As design progresses,

-- Identifiers and groups of attributes or domains are identified for each entity;

-- Rules of first and second normal forms are applied.

• At completion of logical data base design, all attributes are identified and design can be represented using relational data model conventions.

Figure 8

DATA ARCHITECTURE DEVELOPMENT PROCESS

Conceptual

Logical

Physical

Process

Lx>gical Process I>esign

Functional Decomposition

Event Analysis Data Row Diagrams

Procedure 3E

Design

Detailed Design

logical Data Access Maps

Logical Database Design

Nonmalizaiion

Cluster Analysis Data Usage Analysis

Physical Database Design

DBMS-Specific Design Performance Analysis

Figure 9

77
A SAMPLE ENTITY-RELATIONSHIP DIAGRAM

1

^^BliO^A^ED CaUEVANCC/

LEGEND

One-io-onc relaiionship

One-io many relaiionship

Many io-many relaiionship

SUGGESTION

Figure 10

DATA ANALYSIS SCOPE

II ill

SCOPE

Enterprise Level System Level

Project Project

Level Level

DBMS

Figure 11

78

ams
BENEFITS OF THE APPROACH

• An understandable, easy technique for exposing, determining, and verifying business rules and integrity rules.

• An easy consensus-building technique.

• Can be applied in a phased manner.

• Can be used for both new and existing systems and data stores.

• Automated tools are available and becoming better.

• Avoids the "Missing the Forest for the Trees" syndrome.

Figure 12

CONCLUDING REMARKS

• Data architecture must relate to and support organizational strategies and

management objectives.

• Top-Down approach and entity analysis techniques, applied and adapted

appropriately, provide opportunity to develop needed products.

Figure 13

79

ams

DATA PLANNING METHOD OF DEVELOPING DATA ARCHITECTURE

Tom Turk

American Data Technologies, Inc.

Why Data Planning?

To support a multi-divisional company you must ensure that each

division's data is compatible and meshes. When their data views

are brought together, the inconsistencies show up very clearly.

The problem in today's database environment is not the lack of

data, but the over-abundance of redundantly stored data in

different files and databases, and data stored on different

hardware devices. Making reliable data available for decision

makers in this environment is nearly impossible or very expensive

and time consuming.

What is Data Planning?

Data Planning provides a synergistic approach using normalization

techniques to define and create a database environment which

satisfies end-user needs, reduces system development expense, and

enables more effective utilization of "user friendly" software.

A synergistic approach defines the whole data environment first,

then breaks it into its component parts for implementation. Data

Planning does this by establishing the direction for database

development throughout the company by creating an inventory of

the company's data and by establishing a model of the data from

which all databases and files are built.

Data Planning emphasizes front-end, top down analysis to

establish the way the company structures its data (called a logical data model) . The planning process integrates analysis of

business functions and the data required to perform the business

functions. Analysis of a system's functions occurs later, during

system development. During system development the designers use

the company's logical data structures to design the processing

logic and the database.

The planning process is composed of six steps with their

completion identifying or producing: an inventory of the

company's data; a model of the company's data; dependencies of

data within the data model; logical data structures used to

design the physical database; and identified source systems for

the data.

81
The seven steps of Data Planning are:

1. Determine the business model which depicts the

business' functions, events (flows of data), and

categories of data required to support the business.

2 . Map current and proposed computer systems to the

business functions which are supported by them.

3. Identify data items required by each business

function and develop a normalized data model for

it.

4. Determine the logical data structures used to design

the physical databases.

5. Identify basic volume information for the normalized

data.

6. Determine the dependencies that exist among the

normalized entities and chart the dependency flow

required for creating and updating entities.

7. Determine the business function which is the source

for each normalized entity and which system should be

the source system.

Database design can be done more quickly, accurately and

effectively using data planning techniques. These techniques

translate a theoretical model to a physical database which can be

implemented in any of the current database management systems. A

total of three data models (normalized, usage and structural) are

developed during data planning. From these data models, a physical database can be designed and implemented prior to the

development of the system's programs. The resulting physical

database design can be for micro, mini, or mainframe computers.

Unlike most system, business, or data planning approaches (e.g.,

IBM's Business System Planning) this data planning approach

collects detailed data items and stresses data, not systems,

problem analysis, or the development of a high-level view of the

entire company. The Data Planning approach results in a general

business model of the major functional areas of the business v/ith

enough detail to ensure that a detailed data model can be

developed. The data model is a logical design of the data that

can be implemented in any database management system currently

available

.

82
Benefits

Some of the more traditional benefits of data planning are:

o More data sharing because the data structures are based

upon the company's definition of data, not a specific

system ' s

.

o More consistent information because of standard

terminology and definitions.

o Increased knowledge of data availability because of a centralized, mechanized inventory of information about

data

.

o Better systems planning as the approach fosters the

integration of systems' functions based upon the

commonality of data.

o Reduces costs by minimizing data analysis efforts, by

providing initial physical structures earlier in the

development cycle, and by reducing maintenance efforts

with more common input/update processing.

Data Planning aids the company in achieving its goals and

objectives by improving management's ability to more easily

obtain timely data required to increase management's ability to

make knowledgeable decisions.

When data planning is integrated with the company's tactical

plans, data can be made available on a predefined schedule as

part of Management Information Systems' (MIS) tactical plans.

This enables system developers and end-users to be able to plan

on the availability of data.

System development and maintenance costs can be reduced by

sharing data and designing databases for multiple systems.

Systems are designed to use the Data Planning developed databases

rather than the databases design to satisfy only that system's

needs

.

During system analysis, the data plan identifies whether the data

required to support the system is available or will be available

based on current or planned systems. If the data is not

available, the system's scope will have to be expanded to collect

the data.

83
Mr. Turk is well-known in data administration circles. In his 18

years in data processing, he has held positions ranging from

programmer to manager of data and database administration. As a

consultant and head of his own company, American Data

Technologies, Inc. , he has assisted various companies in the

implementation of data administration; developed and taught

courses to both end users and MIS personnel ; and conducted data

planning projects and developed data models. His book, Planning

and Designing the Data Base Environment , was published in 1985.

84
UJ iiZ I- < o

Q.

>- < 7i h-< Z O UJ

cc

co cc — HI O c/5 cc D

1X1 z

CO

ii< 9 B< Uu ~ < < o < 2 1:

V> I < X

h- «fl

I- UJ < I') UJ

CO~ o< < o

V) < z p 5 " Q < !=

(0 3

cn(0 LU

i</)

— I CO — < ®

CM

O)3

CD

C «

'7, o

,2 o £ = Z

LU

Q.O-J

LU>

LUO

-I

LUQO

COw

LUzD

QQ

0)cO

00C

T5

(0ao

(0O 2 E

reO)

re

_o

u.

re

re Q

rec2oc3a>O

CMn c € « 0 R c 1 E I > £ f 1 5 e a u

.2

O ct 5 " lis-: O (rt o O £

LU-Io

>-oozzz<owa

cclUz

>-CO = a o c

0) c

cc c

Ol

SC/3 LUXo<o

ccQ.

a.<Ozzz i < ! I0)Eao>o

a.o 3 5o 11 o2

cn

CA«c

'553

CD

0)Eao

0)>oO«

•DO2 coEao>o 1 S 2 OT 8 S o

7\

>•

CO

85
LLI

Q.o-JUJ>

1X1 Q

LLI Go<<G o

V) 6 m S O

N < ^ 9 S ^ P S Q • 5 = = * ° 2 O _ >. >. _ o * o " a c c I

(0 o S S u m V V V

(0 O

0)u3Ow

0) a. u o O J£

CO 5N I I o o u z

">o i ! f E E ° ^ "

.1 I g = 1 1 s

=° sill 0) O- s 1 ^ .52 Ul E

e\j

n * >

0) QC

IT)

s_en

Q.oX

crO

LUIH

OC

LU coES 1 < £aEoO

COae o

ir to D S e 5 ^ 1 I

Q)

00

i.

Q.oX

V)Ozm

Q.o-I

LU>

LUGHZ

00« 5 1 I ? d Til u jc ^ . . o s 1 « I * •= 2

0) S E e a S o

IIo c e Q o w 2 Q

Q. % Z § m s

'5V

QCcVE

0>U)

CQc

CO 2

Q.oX

V3o

CO5o<G ci il

Q.

U 5 (0

O

O = B

j=

Q o £ «« ° § o •« 5 ^ I i ^ cisoQ> S = aO

om . . 0 o . . * eo O 1 ' ' • 1 1

CVJ 0)

V) (A CO > >. >> >>

CO CO CO CO Q a o O

ao

COo

0>u3oCoo

0)

S86
UJ

wODQO

oc

a.

0) Ocouc3

IL

C

0)coo

V) «

a>

Ou

C CO ^

LUO £ E a 1 E I 2 CO W S

"35 - co m

ra c Q> O LU cr ^ ^ c

0)

0)

COC 5 & n -

_^ CD .s « u3ww

CO to CD— 2

CO Q. o

O) >> o o> -J ^

CD

<u

LUQO<

I-<G

IJJ O<

COD c

_o

Q.o

Q.

CO =9

"DO2

CO

(0 o

0)

CO 133

COo

'5c

0)

CO

(0oc3roaaOcVEao>a

V

T5O

CO

COVcw3

CD

tn

g I o I <^ w _ I I O =

CO3

LL= Ia

CM

87
GZ

t-<H

C/5

QCo

u.wZ

LU

CCDO

LLI cr z

LUioo

H-z

UJ

111 o<z<2 r a. = I 0

>-OooQoX

LU 0 2<

LUHoz

Q. o

Q.oo<

LU<

LUQ 2 I 5 I S O 6 S <

l3g 5 5 E C O S S ^ ^ to (0 > ^ Q Q cn

Q> -J o <

sQ

LUQC5o

LUQCW<I c

0)EEEoo

0)(A 3 cEEEooi inco

*5Oc3

U.MM«

"«3mMCO E2E

(0

0)

aauo oou

0) Q ooo(0 3 O«<O

(0cSooOw

0)

0) 3

cn <

LUozzz zg

COOa2O I O -2

CO

crO(- - < ? z I 5 ? o £ O - o 2<

HIH

LUCOo 1 E e *

B) E 1 S 5 » A

(0

a >. 3 O O M M « 2 o« ~ cI I £ o . GC e LU S S U§ < > e a «

11I

88
C/5 UJD

(/) Zgd>Zoo wco

o.ucO

a. c

Q.wo>c

93aEoo

CO Q.coo = 0) >oocuz 2o S-CD

89

BUILDING THE DATA ADMINISTRATION FUNCTION

MODERATOR

Frankie E. Spielman

National Bureau of Standards

PANELISTS

Ronald ShelbyElaine Hill

BUILDING THE DATA ADMINISTRATION FUNCTION

Ronald Shelby

American Management Systems, Inc.

Building an effective data administration function has proven to

be a difficult, although not impossible, task during the 1980 's.

Corporations and government agencies have established data

administration functions for a variety of reasons. Some

organizations cite the need to reduce data redundancy, and others

target the need to increase data sharing. While motivations for

establishing data administration vary, a common problem

transcends the initial efforts of most organizations; they

underestimate the difficulty of establishing an effective data

administration function. This presentation addresses the keys to

building the data administration function, and reviews three

organizations' approaches to building data administration.

If you look at the purpose of data administration carefully, it

should be clear that its ultimate aim is to ensure that the data

asset of an organization is managed appropriately. Every

organization wants the right people to receive accurate data at

the right moment in time to support their business, programmatic,

or administrative duties. Few organizations anticipate the

changes required to make this vision reality.

Usually, the demand for better data management results from

changes in the role of information systems in an organization.

As an organization's information systems are used to provide

operational and management decision-making support, data quality

and coordination problems become visible. Coordination and

synchronization of data between two systems is an example of the

problems organizations experience.

While these problems result from a significant change in the role

of the information systems function, management's first impulse

is to treat only the symptom (data problems) . Organizations

often create a data administration function after they experience

clear data management problems, but before they understand the

root causes of these problems. Most heads of data administration

step into this situation on their first day on the job. Data

administration is charged with responsibility for fixing the

"data problem" before others recognize the breadth of change

required to effect the solution.

If you face this, or a similar, situation in your organization,

there are three keys to success that you should address to build

a successful data administration function. These keys are

organizational fit, credibility, and building a data management

infrastructure

.

93
Organizational Fit

First, stop for a minute to examine the relationship between the

data administration (DA) function and its place in the

organization. Does the DA function report to the individual who

is its chief management proponent, or sponsor? If the head of DA

does report to its sponsor, then it will be easier to gain

support for the innovations required to implement an effective

data administration function. If the head of DA doesn't report

to the sponsor, DA could be deprived of the direct support it

needs. Data administrators without a direct report to their

sponsor should cultivate a "dotted-line" relationship by

promoting a project that the sponsor favors.

Second, ensure that the functions assigned to DA match its

charter, or mission. If DA is chartered to "manage the

organization's data, ensure its accuracy, security, and

availability to those who need it," but plays no role in

information systems development, operation, and management, then

the DA function can't expect to fulfill its charter. A charter

that outlines a specific responsibility for managing an

organization's data calls for a robust DA function with a significant role in information systems development and

management.

Third, review the degree to which a DA function's authority and

accountability correspond. The fit between authority and

accountability should be viewed as an extension of the

function/charter issue that has an even greater impact upon the

chances for a successful DA implementation. If DA is accountable

for establishing a policy and standards-driven DA program, as is

often the case in government agencies, then the function must

have the authority to issue policy and standards directives.

Correspondingly, accountability for ensuring that future data

requirements are met requires authority to establish and support

a strategic data planning effort, and monitor the implementation

of the plan during information systems development.

Credibility

Establishing and keeping credibility is the second key to

success. Planning the data administration function's

implementation, managing expectations, and managing innovation as

you establish data administration will boost DA's credibility and

chances for success.

Good planning is an excellent way to provide focus while building

the DA function. A plan should be specific about the DA

function's activities and deliverables, and it should be

realistic. For instance, building a strategic data plan and

delivering a data and systems architecture might be realistic

94
during the first year of DA at one organization, while being

improbable at a second organization. Because the DA function

will impact many parts of an organization, an initial plan should

look at least three to five years ahead. Update the plan each

year to keep it current.

Use planning to shape the expectations others have of the DA

function. Planning, describing, and meeting clearly stated

objectives is the best way to manage expectations. Another way

to manage expectations is making clear, realistic promises during

meetings, and delivering on these promises.

Saying you will "ensure we manage data as a resource" sounds

vague and can create very different expectations in the minds of

different listeners. Don't use this phrase too often. Instead,

try to manage expectations by using clearer expressions such as

"we will ensure management's reporting needs can be met by the

new database." Break down management's expectations for your

function into smaller, feasible tasks, then complete these tasks

so that da's credibility will grow.

Facilitating and managing innovation is also an important facet

of building credibility. Desirable innovations include an

increased emphasis upon data when information systems are

developed, and changing the role of the information systems

function in the organization. You should encourage increased

end-user involvement in the system development process, and

change the system development approach of your organization from

a process-driven to a data-driven approach. Above all else,

encourage broad participation in planning and implementing the

innovations your organization will need. While innovation can be

planned from the top-down, it must be implemented from the

bottom-up. Build partnerships with management and floor-level

staff to support the innovations DA will need to succeed.

Data Management Infrastructure

Building and operating a data management infrastructure is the

third key to success for the data administration function.

Whether data administration is implemented by building a strong

data administration organization, by distributing functions

between existing organizational units, or by taking a policy and

standards-driven approach, you must establish a solid data

management infrastructure: a substructure or underlying

foundation for managing data appropriately. This infrastructure

should include policy, staff skills, methodologies, and automated

tools

.

Data is clearly an important asset in the information age, and

organizations should have clear policies based upon this premise.

Data administration policies should address data planning and

95
acquisition, requirements definition, data stewardship,

documentation, and quality assurance. Policies should specify

improved organizational effectiveness as a key objective for the

innovations data administration will propose.

Building new skills for information system, end-user, and data

administration staff, and applying these skills in the workplace

is another key to successful innovation. Data modeling,

documentation, and database design skills are needed to develop

information systems. Increasingly, the data administration

function participates in building data-sharing systems that touch

all levels within organizations. Building, maintaining, and

using these systems requires significant staff skills.

New methodologies for designing and building information systems

are an important aspect of building a data management

infrastructure. Process-oriented development methodologies that

view data as something that is a by-product of processes were

effective ways of automating the back room functions addressed by

information systems in the past. However, these methodologies

have become ineffective in the electronic, information-rich

organizations of today. Information engineering methodologies

that rely upon data-driven techniques such as data modeling and

event analysis, should be taught and used to improve the quality

of the data your organization has available in the future.

After other elements of your infrastructure are in place, use

automated software tools such as data dictionaries, database

management systems, and CASE (Computer Assisted Software

Engineering) software to manage data effectively. Like other

significant resources (money, facilities and people are other

resources that are usually the subject of special, organizationwide management attention) , data is too pervasive and too

important to manage without automated tools. Using these

automated tools, the data administration function can participate

in planning and building the systems and databases that will take

your organization into the 21st century.

Automated CASE software, dictionaries, and database management

systems are being used to do more than manage data. They are

being used to build information systems that use data to

strategic advantage. I'or example, many corporations analyze data

describing existing customers to design new products tailored

specifically to these customers. Other corporations can provide

customer service worldwide by having data profiling their

customers available to their offices around the world.

Government agencies are eliminating fraud and abuse from many

programs by matching and analyzing data. As the price of

technology falls and organizations' data management skills

increase, data's value as an asset will increase in most

organizations. An effective DA function will help organizations

to leverage the asset further.

96
Ensuring good organizational fit, maintaining credibility, and

building a data management infrastructure are the keys to success

in building an effective data administration function.

Technology, especially data dictionaries and CASE software, has

improved the short-term benefits for organizations that build an

effective DA function. However, the keys to building the data

administration function involve more than effective use of these

technologies

.

Mr. Shelby is Senior Principal at American Management Systems,

Inc. , working in data administration and systems life cycle

management, strategic planning, database design, and information

engineering for both government and private corporations.

Previously, he worked in data administration for Travelers

Insurance (Canada) and the Department of Interior's Office of the

Secretary, and was a consultant with Applied Data Research (ADR)

.

He has 10 years experience as a practitioner and consultant in

the data management field. He is currently Vice-President of the

International Data Administration Management Association.

97
DATA ADMINISTRATION MANAGEMENT

THE KEYS TO

BUILDING THE

DATA ADMINISTRATION

FUNCTION

Ron Shelby

Gaithersburg, Maryland

May 17, 1988 amE

Figure 1

DATA ADMINISTRATION'S PURPOSE

Ensuring the data asset

is appropriately managed.

Figure 2

98
BUILDING THE DATA ADMINISTRATION FUNCTION

KEYS TO SUCCESS

1. Organizational Fit

2. Credibility

3. Data Management Infrastructure

ams

Figure 3

KEYS TO SUCCESS

ORGANIZATIONAL FIT

1. Placement vs. Sponsor

2. Functions vs. Charter

3. Authority vs. Accountability

Figure 4

99

amE
KEYS TO SUCCESS

CREDBHITY

1. Planning

2. Managing Expectations

3. Managing Innovation

ams

Figure 5

KEYS TO SUCCESS

DATA MANAGEMENT INFRASTRUCTURE

1. Policy

2. Staff Skills

3. Standards and Methodology

4. Automated Tools

Figure 6

100

ams
BUILDING THE DATA ADMI>aSTRATION FUNCTION

KEYS TO SUCCESS

ams

Figure 7

DATA MANAGEMENT INFRASTRUCTURE

Figure 8

101
EXAMPLES

ORGANIZATONAL FIT CREDIBILITY INPRASTRUrrURE

XXX Financial Services

• Rcponed lo Sponsor

• Narrow Funciions/Broad Chanrr

• Auihonty y Accouniability

• 5 Year Plan/AnnuaJ Revision

• IncrcmeniaJ Approach

• Shaped Expecianons

• DirecUy Managed Innovanon

• Policy Ligged ImpkiiKrnuiion - Linked to Business

• Staff Trained/Managed

• Revised Standards/System r>vclopmentyChange

ManagcmcniyOrganizetionaJ Structure

• Extensive Tool Use

ABC Food Stores

• Unclear Sponsor

• Broad Funciions/Chancr

• Auttioniy Unclear/ Accounubiliiy Clear

• AnnuaJ Plan High Impact Approach

• Rajsed Expecunons

• Documentation = Only

innovation

• No Policy

• Training Deferred

- Only DA Suff Involved

• Standards Dcferred/Daia Modelling Methods

Addressed

• DBMS/Dicnonary

Agency A

• Rcponed lo Sponsor

• Broad Functions/Chaner

• Lmle Auihonry/

Accounubiliiy

• Annual Plan

- Low ProHle Approach

• Constrained Expeaanons

• Facilitated Innovation

• Policy-Dnven Approach

• No DA Siaff/OthcrSuff

Training Not Addressed

• System Developtneni

Standards/Data Planning

Policy

• No Automated Tools

Figure 9

EXAMPLES - EPILOGUE

XXX Financial Services —

ABC Food Stores

Agency A

Stable data administration practices

from business planning through

operational systems management.

Eliminated data administration after two years. CEO re-started effort two

years later to support strategic planning.

Slow progress, but widespread interest

in data management across the agency.

Figure 10

102
BUILDING THE DATA ADMINISTRATION FUNCTION

Elaine C. Hill

Chief of Naval Personnel

The Navy Manpower, Personnel, and Training (MPT) business

includes policy, planning, and implementation for the

acquisition, training, distribution, and career management for

over one million Navy members. Other areas supported by MPT

functions include military pay, financial management and civilian

personnel management.

The MPT business is an information-dependent business. Our

information management goals are to get the right data to the

right people at the right time. The information processing

environment includes over 150 automated systems running on

diverse and geographically separated computers that support

world-wide users. A number of information deficiencies have been

highlighted over the last several years that have a direct impact

on critical Navy management decisions and operations. These

deficiencies have been caused by the development of stovepipe

systems that supported individual user needs, and technology that

was relatively inflexible and could not provide a shared data

environment. As the Navy moved toward total force management and

the information needs broadened, a spider web of systems

interfaces grew. These interfaces were generally unmanaged as a whole and were poorly documented. The results were data

redundancy and inconsistency, extremely high maintenance costs,

and management decisions made on poor quality data.

The MPT community began addressing the data problem with the

establishment of the Data Resource Management (DRM) Program in

1980. This program was to establish the policies and plans

necessary to manage MPT data as a corporate resource. In

December 1984, the Chief of Naval Personnel (CNP) Data

Administration Office was established as a prototype organization

to implement the DRM policies and procedures.

As the organizations have matured, we have come from an

environment where technology and information systems drove the

data to an environment today where data is driving the technology

and the systems. Information Resources Management (IRM) is the

framework we are using to manage the data and information, as

well as the information technologies. Our goal is to reach a Chief Information Officer environment where data is truly managed

as a resource, as are money and people.

The MPT IRM Program addresses three major areas: program

management (plans, standards, and dollars) , information

management (includes DRM and Data Administration) , and

information systems and technology. A hierarchy of guiding

103
policies and instructions provide the impetus and the direction

for this Navy-wide program. The key concepts of the IRM program

are: that information has value and cost, that we must manage

information and data first . and that we must manage systems and

technology to meet requirements for information and data and to

improve efficiency of functional processes.

The MPT policies and guidance are incorporated in the MPT IRM

instruction issued in October 1986. The instruction establishes

policies and responsibilities for managing MPT data throughout

the data life cycle, focuses on Data Administrators as the

execution arm of the DRM policies, and delineates the roles of

the many players in the DRM world.

The DRM Program has realized many accomplishments over the last

five years. For the most part, benefits have been seen in the

functional world through standardization of data elements,

integration of data, systems, and functions, and data and

management issue resolution.

There are three major concepts being used to manage the MPT data

resource: Data Administration, Database Administration, and Data

Dictionary/Directory Systems. In trying to develop a workable

data administration program, definite roles have been defined and

refined. While the need for data administration has been slowly

recognized, its value and benefits are now accepted. Data

administration supports users, system developers, and management.

The key elements that are making data administration work are the

corporate data dictionary/directory system (the MPT Information

Resource Encyclopedia) , data standards and guidelines, and data

planning. All these things are essential in a shared data

environment

.

Needless to say, implementing data administration has been a

tremendous learning experience. Our thoughts on what standards

were necessary three years ago are somewhat different from where

we are today. It is important to be flexible enough to change

and to take advantage of opportunities as they arise.

The MPT Information Resource Encyclopedia (IRE) is really the

cornerstone of the DRM program. We use MSP's DataManager and

DesignManager products to support the IRE and our data modeling

efforts. The development of the IRE has been a major undertaking

and a constantly moving target. Our main goals have been to

support documentation of the MPT data, to support data modeling,

and to support documentation of information systems and life

cycle management.

Initially, the corporate dictionary was called the Data and

Information Resource Directory. Data elements from about ten

major master files and about 4 0 systems were documented in the

dictionary and resulted in about 4000 data elements. The amount

104
of redundancy and inconsistency in the data caused us to

reevaluate our approach, standardizing element by element. We

decided to redesign our dictionary and to develop standards based

on two new corporate databases being built, the personnel and

jobs databases. These databases represent about 60 percent of

the MPT corporate data.

Congress has directed that the Navy integrate its pay and

personnel systems. We realized the importance of a common IRE to

that effort and so we have designed and developed the IRE

together with the Navy Finance Center in Cleveland, Ohio. We are

also developing an interface between DataManager and Supra, our

database management system, as well as a Dbase III interface that

will allow for upload and download and manipulation of IRE data

by a PC.

The DRM program has also been instrumental in outlining the

corporate database strategy for KPT. Data architectures have

been developed over the last five years leading to the design of

corporate subject area databases. These corporate databases are

the cornerstone of the data/technology strategy phase of our IRM

program. Key areas offering challenges and opportunities include

data integration, standards, introduction of new technology, and

transition from the existing environment.

An area that both DRM and Data Administration staff members spend

a lot of time and effort doing is analyzing and resolving data

issues. These issues arise because of such things as new data

requirements being levied on the Navy or by the Navy, erroneous

processing by existing systems, or implementation of new systems

or modifications to existing systems that must be coordinated

across a wide range of systems and users.

I have highlighted throughout the briefing the need to manage

data as a resource. One result of managing data should be

improved data quality. In order to measure quality one must have

standards and metrics. We have begun to develop guidance for

data quality assurance. While there is a good bit of literature

and guidance for quality assurance of systems, there is very

little that addresses the data itself. Our focus is on the

accuracy, timeliness, and completeness of the data. We expect to

learn a great deal over the next year as we attempt to apply the

concepts and criteria.

I have tried to cover where we have been over the last four to

five years as we have developed the DRM Program. Our growth has

been tremendous. In 1984, we had six people and today we have

over 40 people in the DRM and Data Administration offices. We

are about to embark on a reorganization that will put the error

research and correction function under the data administration

function. We are designating Associate Data Administrators in

customer support centers and geographically separate commands

105
where corporate data knowledge exists. We have consistently

spent more dollars than we budgeted because of the burgeoning

interest in the program and the visibility of the issues we deal

with.

In summary, a few lessons have been learned. To be successful,

you have to get organizational commitment, from top management to

the working level. You must continually build support. You must

show successes. You must educate people and show them how you

can make their life easier or better.

Ms. Hill is Deputy Director of Data Administration for the Chief

of Naval Personnel. She was responsible for creating the Data

Administration Office at the Navy Military Personnel Command

which has served as a prototype organization for the Navy. She

has spent 14 years in the Federal Government holding positions in

systems operations, systems analysis and programming, functional

analysis and database design, distributed processing, and

database planning and evaluation.

106
z

o

z

=1

< 2

Q. o

z < o z

K <

O Z) ^ (- Z OQ CC Z

I- Q u a u.

z z E

LU UJ

LU < o z

< <

I I I I I I I

o

z

Q.UJQ

Z . . O UJ

O X

< <

ID a

SI

u in 3 kI- Q

CL Z

E <

r(—o

I—Q

UJO

>o

a

a

::: < ^

u- 9 E

XXX

o o o

a a a

zO

CDa

UJ >- > -J LU >—< a a

z 9 z

3 O

o o LU LU

LU cn

LU <

CO o

<

r:

cr o o

<

Q

Z

o

LU

< =:UJ ^ CL z 0^

3= ^ LU O I- < 01

cr >

u. to

o

<

LU^ LU < t- 2-

til

_i > m >

C <

I- z

a ^ IZ LU o

o >- < LU

o

a

z

<r

LUo

<z

<E

o

z

z

<

CO 5

< ^

i- LU O u

_J LU

u- a

z

o

aLUa

I

< t- O CO

CO 00

-J z LU O

>

V)V)

til

107
<>o

ii

ii <oz

a.Oz

ex ^ < IP, Z E < <

t- z

-J z < LU

Ir S Z UJ - c ^

u. Z < LU 3 Q I I 2o

1-<a

LUz

LUo

1- < cn

1—

DA u.

u. E O Oa > Lk. zo <z

1- o coz E < o a u \- 1 1 zo

1-<

LUZ

LU

<3X yD a

cu

s_ 3 :3 O cn o > z O

1- 1-

;f "Sis Pi III

in >z<ozo

LU<

t-< <

(/I

CD

u. «> O u Z <o

in a.

Q. 4<

tn

LU<

Lk. <O Q. I I ZoUU

A.E I i => 3 I E a N (E

108
CLUlU

z

ou

>

ui

*£E

<

Q

5

.2 5

.2 5

I

CO

"55 .-^ 1 1

1

?<5

2 o >

o s

.2 ^

• 2^ 2

CO

C3 Q

C/2 O

c

=3C

a

Q

J! ^ 2

2 G i

1 ^

t; O to § 5 I

5 11 ^

E a

oa ^ 03 u • • HI

I

3 -S —

o :5 g Q. > o o 2 5 Q

C

Q

<

= 2 = -=

01

s-Z3

Eo

' CX) csc

C C 5 C =

g *u r3 V a

>N £0 >, JO

IT) u

- e

S u 0 _

0^ S ; ?

« S u

aE _ ^ _

uj a ^ ^ 9 » : =

> < s

z ; E

Z 31-

i if -'or <-cauxuiuu

Ea

' o

o J c -SO.

• « -

0. i

u 2

Z ^ u u

5 £

i i

i -

Z C G c - 03 c g 5 - w £ 1 a ; - — ° 6 e z < < o o — " 3 :

» "

•

'

5 ? * " ' i_i o L » e Q o S r ; » ^ O li u b II Q O K < O Z

« —

z

w

zo

>zu

zo

<

<

<

<Q

H

CL

HI

o -S ^ C

5 2 .5<

aC

^ ^

i o E V

'

-= ^ c •§

2 c

= o

"S 5 5

^ -i

-3<

109
COo

oc<Qz< I coQ oc c

0)c3

(0

(0oz3mO

CCUui

aZoc

U.UJ.W Zuj

•-'

a o > ^ c c -o ^ ^ - ^ 5 i I

0.h = E ^ z E o o a o ; - a ie o u £ < o - c - w - f.

O -5

in" £ E o o ^ O O O E Q a a - a a a.

—

Q C/> </> 3 3 3 O

O 3

(/> t/> ly^

Q

C i/> £o

*>cc

C3

*£EaQ Q.

Q. < <

:23

^3 o

f2

to

a?

JO to »_ too I c

!2

CO

a> •ac3

Ui

0)u

0)3

ffl 3O

110
u- a

Q. <N C

C ^

° < IS

—

a o o a ^5 ?£

O ^ 5&

oCM

u u u

111
UN

— LU

l/lLl.

7; -e

a-

• • •

5

'^^ 5i

O T>

2

^ UJ

(

j

5

"3

112

UJ

- ^-ocu

Icq.

3 = 2; ho"

UJ
0 ^ * - - S o - 1/1 1 - n - Z * o c u e 4 e _ < u C C » • c • c e c e a fPS??* M» • - » m

?!— C ? I • a. • « = - • • > a VI o ; , u - w : « O £ B

t) (/) Q. o ^ » m -) > ; 31- - ~ e - • o - c ^ E E " o C o o c Xo<ocr

CL<

»-oILI o

GC ceo

u.o<CO

(/I •ac

<uQ.VOaCQ

00

>-

19

UJ<KK

U)

111 <<<O

UlHO

0.etOu

Ln

Lli Oz<

GCCO

CO< B

.3e <o

COo

cc<oz

;^CO

crOu.

LLI

UJQ

Z)o <Q

k—

H « 5 5 5 o o o 3

CD

113
114
C/3 OaaO

C/3 oCO

5" ^ O Ph

C/3 CooOOa o

C3oo>

(y2

00 CL,

cdoo

00

c/3 O

(/3 WD

cdCO ^ Q

cd>

cd X

O)

CD o

GENERAL SESSION

GAINING AND KEEPING MANAGEMENT COMMITMENT

FOR DATA ADMINISTRATION

Herb Jacobsohn

Technology Information Products Corporation

117

GAINING AND KEEPING MANAGEMENT COMMITMENT

FOR DATA ADMINISTRATION

SUMMARY OF REMARKS

Herb Jacobsohn

Technology Information Products Corporation

One of the big problems for Data Administration is getting the

management commitment to manage the data resources. There are

three primary interrelated areas addressed in this session:

planning, business orientation, and implementation.

Planning is the key factor essential for managing information or

data resources. The reason for current problems in justifying

information planning is that we focus on solving them through

technical solutions. Instead, the focus needs to be on the

business issues and the crucial areas for investing the MIS

dollars that will provide the best payback. It's difficult to

develop a good information plan but it is important and can

provide many benefits.

An example of one organization justifying the use of common data

was illustrated by showing the cost benefits in developing

generic code for their data elements. Initially, they selected

four data elements and developed generic code, using it on 15

projects with a net savings of $62,000 for the first year. With

this success, they then repeated the process on another four data

elements resulting in a net savings of $108,000. This savings of

$170,000 for the first year was the result of having one data

element representing one thing or one definition. The savings

for large databases over several years can be significantly

large.

Another approach for driving the point across is to emphasize the

dollars spent over a five-year period on MIS/DP. The cost can be

staggering. Are managers happy with what they are getting? If

not, then what can be done? If the way things are done is not

changed, then it is likely that twice that amount will be spent

over the next five years with similarly poor results. It is

going to cost resources to develop systems anyway, why not add a little extra cost that can provide significant long-term

benefits?

An MIS plan and Information Architecture supporting the business

functions must be developed. The plan and architecture must

address the sharable databases, integrated information systems,

and distributed data processing. The cost may seem high but in

relation to the total MIS budget it can be a miniscule amount.

The payoff generally seems too far away and most benefits are

long term. However, this can be offset by placing emphasis on

119
the short-term payoffs, for example, eliminating forms,

identifying problems to be solved, and new ways of doing

business

.

The ideal approach to the development of information systems is

top-down, completing the information architecture, data models,

and normalized relations. The problem is that it takes too much

time and costs too much money. On the other hand, bottom-up

doesn't work because we end up with incompatible, incomplete,

application oriented databases. The solution is to do some of

both, completing 60-7 0% of the top-down approach on a business

basis, then implementing bottom-up using the products developed

during the top-down effort. While implementing on a bottom-up

basis, the additional details can be completed, such as

determining information usages, normalizing the relations, and

developing accurate data models. Using this approach,

significant results can be obtained in a short period of time as

well as laying the framework for long-term benefits.

In summary, the business perspective must be the focus of attack

for determining problems to be solved. Once these are determined

then the technical problems can be resolved. Of course, from a

central information resource or data resource management

perspective, the data dictionary, encyclopedia, or repository is

the key tool that aids in this effort.

Mr. Herb Jacobsohn is President of Technology Information

Products (TIP) Corporation. He has been a leader in the data

processing industry for 3 3 years. He has laid the groundwork for

and influenced the establishment of software technology that has

made data processing systems, information management and data

management a reality. In 1981, he founded TIP, a company

specializing in software technology for managing data throughout

the systems life cycle.

120
I-Z)o<

Z)OX

LU

CO

cr<—I

_joQ

00O

CO

LU>

CCou.CO<

UJ

CC<<o

CCo

LU

I—

CO

LU>

cnOLL

LUO

-z. LU3O

LUCO

LU

CCO

CC

LLUJ

CC

LU

LUo

LUoo

CO

LU3O

LUCC

LU

CC<Q

CC<X

UJ

CC<o

CO

CCo

LU

COb

CLCD

-z. < ooXo

LU

uuo

LUo<<>Q<

(3<

I-<

CEO

Q.

GCLU>

cnoz<

-JQ.>

_l<

lU

CO>o<Qoo

CD<

LU

iiO< LU If

cn<

LU o<

u. o > LU

z:

ILDI, CTO OA <

cn<

1— <

h- ED

_j _l > 3 O

CD CQ >

LJL (-

ii^ z 5 <

HI

O > LJ. OQ>X

LU>

1-o

LUCL

COCC

LU

CL. COO

QCo

CC

LU

CD

LU

co"

CC<gXo

LU

hLUCO3

LU

CO

LUCO<

CCl <

h-<Q<

LUX<

h-o

LU

—0

CQ3

CO

_i

ULI Qo

CO

TY CO Q.

LU J2

rEGRI

CO

MS

YNT noN

S_cn

X z CO ;

<

u_

O _j

Ll_ _J TIC ICA RE < z z > < O 1— CO c )— 1j O LU < CD

z.

O UJ

Icn

Z)

-3

Oz

LU-J

CDo

cr

Q.

LU><X

LUOo>X <

-J

CLzo

CCo Q z X O o o _j Z

OO TY' O

1—

X z

rr CO

Q < < < CO

00 < CO

INING ON

z: Z z < z < <

_l

c_ CL 3

121
Q

LU<

LLI DZOo3m

LUx

I-

(£O

LL. LUm

CO

w o

CO

CO =io W III =: od< O< m^ o D LU

_J _l

G. LU

00

ccLU>o

UJcr

Z)

I—o

LUXo

cc<<_J

CLoo<o

I—

is; ccO

cc

CD ai

C7> <<QOo

cco

LLo

I-<u

LJ- IC/) Z)

-:>

LU

_l

LU<

I—<a

CO

cc ooo

COQOOO

CC

LU(3

Li. o

I—00OO oo

o_

Ln

UJQoog

LLO

LU

Q.00O

_

C/^ O oo

o_

feeCO

COO

_jCOO><

CO

LUXQQ

00

I—00

_J<o

LU

CLoo

LU

CC

00

cc

LU

o- oo

CO LU H Q

xcc < ±:

CDD

_iDO

00

LUO

Ll_ LLO

LU>

I—O

LUX

LULUX

I—

LU

crLUo

I—

LLo<

LU<

CO

LUOX

CL

UJ

I—

I-3o< Q<X

UJXO

Ll_ UJ

CDCO

LUo

ZDDOX

Q.

I—Xo<

LUCQQ

_J3O

00^OOX

co

UJX

LUX

hLUX

LUXoX

CO<Xo<

CLX

LU>

LUXo

ILU

LUO<

LUILU X X

Oli

,no < >1 ! 1 X IA3 ci o X

LL _i

X

X LU

X

X

CQ <

_i o t- CL X CAN LL o o

_J

Q _J X COX X < UJ

fee- LU Q > < X X CO

LU h- LU

CL00 EX i— TO X

LU DO

ING Hi TO O X O O CO X

LU

O

X UJ

O

b

lOA., SYST LON

cco

(/) LUOQ<X

hLl.

X

h-CQO—3

I-X

LUXXxo>

122
<

i-<QOO

CEoO<O

I-cn

00 <

I—X<

COcO

u_COO>< o

fee00O

CLo_lLU>

LU

—

Q \[1 t O

LUQ

LU

CLLUQ ooo

LUQoOO

cr

LU

LUO

LLO

I—00O oo

co" o

CO>< 2o<O

LL

!-

(/) -3

CELUI

ICEZ) <Q

z:OOOO><o

a:

u.COO><

CO

UJ

CO

oo ozI

I—

LU2O oZ

u.LUQ

LUZO

Q

LUQ

00O><

00

LU

f—LUo<

C/5 UU<

CO<<QO

LU-n

CQ00<

LUzO

DCQ<

cc

t-co

LU<zO <azooo

oco

u.o

I-<

-3

00<

00

cr

c:<

cr

c:O

U-00

CD><

00 o o o o o o o o o_

h-" co"

cr> (M CD

fee- fee- fee00OOaO_i

LU>

LUQ

h-Z

LUQZ

LU

Q.LUQ

00

LU

IDo

irzooooz

ID

LLO

I—cnO oo

o_

fee1-z

LU

D_o_l

LU>

LUQ

LUQOOo

crLU

LUo

CO z: o O z 00 > 00 < o CO 1 oo

o_

CM

CDee

COO><

CO

I—

LU <<QZooo

oco

LL. g<

cn

z>

-3

ooz><

oo

cc<

LU>

I—w

cr o o o o o o o o_ o

C\J co" o'

CD o

fee^ fee- feeh-z

LU

LU<

t-<

CO

cr

CO

LU<<Q

CO

I—

LU

LU

_lLU<

t—<Q

00

CCo

U-

_j<

I—O o

CM

fee

LU ^

LU 3 <<Q

CCLU

Q.COO

-z. ><

CO

123
Q.<I

LU

LU

CE<

I-Oo

LU>

LU<I

LUm

LU

CE<

LU

CELUI

LUOc

CLO

_J<gooo § I

-I CO < > Q H

I- en < W LU . —iIjCLO LUOXlcr ixiLU

CO

LL CO LU 3 LU (H

CO ^ < 3 p ^ CO c ^ LU ^ ^ g CO

f= <

LU

O

Q- Z ^ ^ - O ? uj o u- cn

LUo

DCo

CO

CC

LU>o

LU

(Ji

LU>

LU oooooo

><XX

cn

CE<

LU>

in

C/) <

LUX

»-

CLQ

05

LUX^ cn

LUO

O<

cn

X - oo

LU

LL

X z

LU<

LU cn

CL LU cn ^

LU

CM ooooooXXX

cn

CE<

LU>

inI-X

LU

LUX

ILU><X

CD<

CDO

CE

CLLU

CELU

II-LU

CDXo3oX

h-><

124
ooooo

COooo

in

CM

(/) OO

LU>O

LLJ LL

U.lU< Z<

Q. -i O CL

-J

LLI C/) SiQ

C/5

LU

COX

Ico

I- ooooXX

cco>O

CO

CO

COoo

LU

00

oo

00occD

CO

CO

CO<

I— ^

C/0 LU LU CC > D Z 1- — o

cc LU o t

CO o < cc LU < o < ^ cc

COPi±o m ^ <<Qpo

LUm

Z)CO

LU

_l

CO<

cc<X

00

00

00>

COo

00

00

LUoo

cc

D.<

I—<

LU H-i

cco<Xo

LU

mX1—Q

00Vco

LUo

I—<ooo ^

*^ CO CT) uj 00 [2 X LU < 21

I- Z)

Li_ CQ

uJ

O

Is o>

LL

ii

cc

uj

O oQ>Xo><

Q. <<X<

U-OO

I-00<<

COO><

0-

X

LU

h-oO

_j

LUX<

CO

LU

LU

CD

I—COO

CO

I—00OO

LU coco^

LU 2 < i_ ^ <H

X^Z)

X^LU CO^X

Q

LUX<

CO

Ll_

Ll_ O><cX

LUXOX

CO oCM

125
CO

liJ =>

cnCO

LJJ a.O

LJJ Q.

LU Oo

LUo<oo

I—UJo<

i—

HOLU

cr

OQo

I—Q<

CO

LU

CL <

ROI CM

Z)

LU

LU

ure cr< YN > >- GO cn

OG TM <1—

Ll_

1—

O <

>-

Q

EAS

IT'S "MY

COo<o

UJ

CLX

LU

UJ<

CO

L_LUZU

CDLUO<

00

CO 00 CO Zccr

tr << Zluu o>> 2 OJ 2

cr ^

UJ cr ^^LU ^ Ll. L_ t: UJ .

OO^Zj

00

-J<

LU

cr

UJm

OJ

CO

UJ3

CO

CO<ooooXo>

CO

Q. ><o

lu : zo o

I—<o

LU<o

cnI <

I—00

it: z

LUo

cr<

LU

LU

hU_O

cr<

UJ

LL

UJO

crQ UJ z cr > o CO U-LU

LU CD

cr CO

FO "TH Q z LU

QC

u~> UJ < > -L. ill 5

CT)

u3

UJ

UJO

Oi

CO

CM

<u

CD

126
C/) U-LLO<

CL

IT

LUII-CEoI

CO

LU<X

UJ

00

enO

cc

CL. Q

LU I i (- UJ = i

00o>

LUc

CLO

CO

ooO§ cr

LU £ O >o o o

-z. o

I—< <

LUQ

oo

00

LU

oo

zo

inOOQ

LU

LU

_Jm

oo

00O

CL

LUO o o

LU t:! <o

CO

COm

CO

CDOoD

Li. o

CO<

LUQ

LU

UJQ ow b < r)g s

CL =3 o

00>

00O

CCo

LU

OOo

I—o

Li- en

CO

LU

C/D =)

CD

LU

I—<o

_J

CLZ)Q

I-z

LUQ

LU

CCO>

CDO

LUo<Q

LU

oo>

CCLUa.3

CO

00

3ZLi-< >CD

LL CC PO

Lu^:

cco

>oo < LU

CC CO <3

Icq

c/) = £|

c/oQ

oo oo o

I—<

CCo<

00

u.Oo

I—<

cc

LU

z:LUO

LU

I—<o

U_ UJ t5 tQ>

95

LUQ <

LU

CCo

LJ.

00

_j

LUQO

LUo<

C/5 3O3o

CC

00

cco<

LUo<

cc <

LUcco1—COzo o o o >o<

003zoz

ccg

LUO<

cn3>

LLcrLU>

00

_l

UJQo>>

I—o<

UJQ<>Q

LU3o

LU

CCo<

003zO

LU

h-<<>

oo

cc

CM o 11 LL s_ Q 00 cn LU00 cc

Ll_ 3 o Z LL. o cc Z <

LU< 00 z <

LU

Q

LU no o 00 z z < C a o

127
(f)

U.

LU -z

ill mm

LU

K < > <

00O <3O

c:Oo

I—< <QZ

ZDD

LU

cc

LLO

h- 1— o oQ

LU

CCzo

jZLU

<^z <

lo

LU LU CO

C

00

00

LU

crQQ<o

00^

LU

I00>

Z_i om

h^O <cc

Zc/5

Slu

LUZ

CO Is

Q

LU<

CO

cr

CM oQO

Qo<QoQ

CLO

h-LU

ILU < o m O

c/3 Zo

LU

CCQ

LUN

CCo

CDO

CC

co i i

CM LL

CNJ

O

LLI O

ZDoo

I—

c/? LU<

cn<ozooo

h-coi—Oo

C/5 UJZD

KCEo

Q.

Q.o

LU

CO

>-O<o

li.

LU <Q<

L!_ o

oo<

LU

CCO<QZ

ZDQ

LU

CC>

LUQ <Q<

OO

L.. o

CO

LUCCo

I-00<QQ

LU

CC>

LLI-z

UJQ

Q

COLLI

I- CC <o

^LU

<^

coo

UJ CC

z^LULL ccO

LUCO

LL LU toQ LU >CL

tuj

h- CC ZUJ

UJX

9^ <1—<Q

U_O h-Z O < z Q

_1 Z QZ Q < < LU H- CC<

LU> >i±;

CO y50

CO CO CO

LU LU Z o oo

EX

FY

ENTI ENTI Q of

C/)

Ll. LUZ

LUm

oc

LUI ozo

CO

LUCO<<QQ

LU

CC<X

CO

00zo

I-<o

CLCL<a

LU

CC<X

CO o<aD

LU

CC oo

LU

1-

LUz

_l

_J<

I-COz

CO<

UJo1—>

CO< oCO

128
liJ 2

Z)

_Jo

CO

02<

cn00

LU

00m< r O OOO

00OQ

OQo >oo_Jo

LU

h-co

C/0 LU

CO

CDLU

CO

Z3

UJ>

)-o

LUC

co

c:

LUc

COCO

LU

CO<

cr

LU>o Q

LU

I-o

UJa

cc

LUCO3

LU

I—

LUooooCD

LU

LU

CD

OQo

g:

LUc

I-cOw<

00

i—

_J3

CO

LUC

H-<O

Ll

COLU>

LUXo<

CO^

LU

_J

CDO

CC

CL

LU

CO3

CDQ

OO

LLI

CCo

CL

CLO>

LL

LUQ

LU

CC3

t—Oo

CC<6

CCoo3Qo

CCCL <I Q.LU00<

CO<

I—<Q

I—O

LL

~:i CD3

00

2:<

LLI

CLO_J

LU>

LUQ

CO>

CO

mCO

Q.

Z)O

CD CCO

CO

LUoQ o

LU—D o

CC

CL>

CD

t-o

UJo

CC

0.

00

LU00<

CD<<Q<O

_i

CL

CL<

CO

LU

CO3

CD

LU

_Jo

LLo

LU < >

LUO<3 Q oooo O

UJ

CLCO

d:LUQ_o ^

CO<oO

CO

CO<

COo

CCo

CL

LUXoQ

CCLU>

UJ o

CO o

CD

LLO

LUo

COOQ

CO

CO<

C2

I-<

LU

LU

_J

CL<Xo3Oo

CD

CO<

CD<

t-<

CD3

CO

oo>

COXo

LU

_

CL

CL<

LUcO<O

0.O_iLU>

LUQ

CO

LUO<

CO3 < o

LU

CC<o

CDO

CCo

CC

UJX^-<

(3

CCQ

LUNXO

LUo3QOX

CL

LUXo

LUOX

CO < § 6 5 5XOLL.

00<<

LU<9<>

00

_j

LUQoO

LUXXoo

LU

LU

129
CO

LL

U.O<

a.

CE

LU

I-o

0) o

00

CE

LUQZ

ZD

LUO

00 en

HO

O<

cr

UJCLO

CO

00

LU

LU ^

_J CO

CD

LU

cn LUcr

ZDo

LU

cco <Q

z:

IDQ

LU

CC

LLo C o<O

LL

CO 00

LU LU

(3 CC < O w (- 3 W

00zo

f—oz

Ll_

O

O

CCO

cco

CO

00

COLU>

CO3

tn

I— t— 2O

Q <

CC

LLI CLO ^

00

O

00 zm

CO

cc< <

LU

CC

y-00

O

LUNO <O

I-

(/) -3

LU

-Jmo o

I—<

ccoOzO<

NJQ

CC<Q

CO

OOzOH

Q.

CCo

CO

LUa

COCO

LUz

CO

CD

D

Q

LU LU H Z Z Z o LL

LU ED

LU ^ Q

LU _j

O CC _i o CD LU Q < 5

LUo

cc3O

CO

LU

CCzO

I—<

CCOLL<

CC

LUo

LU00

ZD>

LU>

I—o

LU

LLLL

LUz<o >

cc<zooQ<< <Q

LUQ-o_lO>oz

LU >

CCo

COO

CL

LUCC

Ll- LUZ

LUm

XO

CO

00

CO

ZD

XI<

CC

LU>OO

LUo

CC

CL

LUOO

LU

00

cz

LU

Q.o

CCc

LU

00 00o

UJo

cc

CL <

CCo

LU

COzO

I—<o

_lc

CL<

CO

00<

CQ

I—O

LU—)

CQZDCOzo

CQiO

LU

00<

CQ<

I—<Q zo<o

IC/)

LU

-Jmoz<

I00

LU

00<

CQ<

h-<Q

LU_J

CD<

LU

CC<

-L. 00

Q

LUUzo

COOOO

cco3

CD

COQ >

_J

00<

LU >

_l

CC

UJ

Q.C

CC

CL

>•-J

LU>

I-o

LU

LL

LLLU

CCoo

cco

CO

cc

LU

LUOzO

cc^ i^

I—X

LU

QCO

LUZo

Q.

00

CD a. Z ^

CO CT) oO

CC

a.LU

h-ZDm

CCt—

COQ

130
NBS-lUA iREv. 2-ec) U.S. DEPT. OF COMM. BIBLIOGRAPHIC DATA

SHEET (See instructions)

1. PUBLICATION OR

D p po RT NO

NIST/SP-500/159

2. Performing Organ. Report No. 3. Publication Date October 1988

4. TITLE AND SUBTITLE

Data Administration: Management and Practice

Proceedings of the First DAMA Symposium

5. AUTHOR(S)

Judith J. Newton and Frankie E. Spielman

6. PERFORMING ORGANIZATION (If joint or other than NBS, see in struct/on s)

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

(formerly NATIONAL BUREAU OF STANDARDS)

U.S. DEPARTMENT OF COMMERCE

GAITHERSBURG, MD 20899

7. Contract/Gram No.

8. Type of Report & Period Covered

Fina 1

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (Street. City. State, ZIP)

National Capital Region of the Data Administration Federal Data Management Users Group (FEDMUG)

Management Association (NCR DAMA) Association for Federal Information Resources Management (AFFIRf^;

10. SUPPLEMENTARY NOTES

Library of Congress Catalog Card Number: 88-600586

Document describes a computer program; SF-185, FIPS Software Summary, is attached.

11. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a si gnificant

bi bl iography or I i leratu re survey, mention it here) This publication constitutes the proceedings of a one-day symposium at the

National Bureau of Standards on May 17, 1988. It was jointly sponsored by the

National Capital Region of the Data Administration Management Association

(NCR DAMA), the Federal Data Management Users Group (FEDMUG), and the Association

for Federal Information Resources Management (AFFIRM).

The symposium provided attendees with an opportunity to share the insights

of leaders in the Data Administration field. Special emphasis was given to the

factors which contribute to successful implementation of Data Administration

management policies and practical methodologies.

12. KEY WORDS (Six to twelve entries; olphabetical order; capitalize only proper names; and separate key words by semicolons,!

administration; data; data administration; data architecture; information; information

asset management; life cycle; management

13. AVAILABILITY 14. NO. OF

PRINTED PAGES

[j^ Unl imited Q For Official Distribution. Do Not Release to NTIS

Order From Superintendent of Documents, U.S. Government Printing Office, Washington, D.C.

20402.

15. Price

Order From National Technical Information Service (NTIS). Springfield, VA. 22161

uSCOMM-OC 6043-PeC

ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SCIENCE & TECHNOLOGY

Superintendent of Docunments,

Government Printing Office,

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued in the

series: National Institute of Standards and Technology Special Publication 500-.

Name

Company

Address

City State Zip Code

{Notification key N-503)


U.S. Department of Commerce

National Institute of Standards and Technology

(formerly National Bureau of Standards)

Gaithersburg, MD 20899

Official Business

Penalty for Private Use $300

Stimulaling America s Progress 1913-1988