About David C. Hay

David Hay was born in Grand Junction, Colorado, mid-way through the last century, when it was significant that his home town was some 250 miles from any city of any size. Back in those days, it mattered. His knowledge of the outside world was limited to magazines, movies, and the public library. (OK, he'd had some friends who'd been there, but he didn't believe a word of what they said.) It was all fiction. This valley was the whole world to him.

Then one beautiful September day, he took his first plane ride. Three hours later, he was by himself in the middle of Los Angeles International Airport at 5:00 on a Friday afternoon--trying to find his way to college.

Pretty much the rest of his life has been spent recovering from that afternoon.

The college was Claremont Men's College (now Claremont McKenna College) in the heart of the smoggy San Gabriel Valley. He remembers it as being pretty traumatic for him, but then this was Southern California in the late 1960s and life was traumatic--and exciting--for everyone. And this "outside world" business was pretty intriguing, too. So much so that when he graduated, he decided that the only logical thing to do was to move to New York City. Why not?

So, with no money, no job, no experience, and a degree in Philosophy, he set out to find his fortune in the big apple.

From there he discovered the rest of the world. Among other things, in 1973, he had a life-changing trip through Eastern Europe during the height of the Cold War. OK, that one wasn't quite so traumatic. He went back to Warsaw the following year to marry the single most wonderful woman he'd ever met.

He got his MBA from New York University the year after that.

In the late 1980s, he discovered data modeling. He took to it in a big way. But not the way most people did. Rather than viewing it as a vehicle for database design, he viewed it as a way to crack open the secrets of a company's semantics, and with that, its very nature. He discovered, among other things that if you model the underlying nature of a business, you have just modeled the underlying nature of pretty much any business.

From this experience came "Data Model Patterns: Conventions of Thought", a groundbreaking book describing a set of standard data models for standard business situations.

At about the same time, he created a consulting practice, Essential Strategies, Inc. (http://essentialstrategies.com), that offers data modeling services to a wide range of industries all over the world. He uses data modeling to support strategic planning, requirements analysis, analysis of semantics and business rules, and data warehouse design. His clients have included representatives of oil (both production and refining), pharmaceutical research, television and movies, banking, among others. In each case, he goes into the company knowing only what he's learned as a customer, and within a very short time (thanks to the model patterns) understands more about its underlying structure than many who work there.

In 2003, he wrote "Requirements Analysis: From Business Views to Architecture", his unique approach to that subject. This is a compendium of some thirty years' worth of analytical techniques, organized according to his version of John Zachman's "Framework for Enterprise Architecture".

Then, in 2006, he published "Data Model Patterns: A Metadata Map", the only book available that describes a complete schema of metadata--encompassing all aspects of both business and technical views. Moreover, it not only describes data from these various points of view, but also covers functions and processes, people and organizations, locations, timing, and motivation.

In 2011, as an update to the "...Conventions of Thought" book, he published "Enterprise Model Patterns: Describing the World". This does not invalidate anything in the first book, but it is more comprehensive, and it addresses the problem from multiple levels of abstraction. It also is the first business patterns book to use the UML notation.

Because that is a controversial thing to do, he also that year published "UML and Data Modeling: A Reconciliation", which is a discussion of the two approaches to modeling, and a handbook about how to use UML to create a business-oriented entity/relationship model.

He has been an active participant in DAMA International, various Oracle user groups, the Object Management Group, and the Business Rules Group. He has given presentations on various data and methodological subjects all over the world.

A library of his articles may be found at articles.essentialstrategies.com. Thanks to the World-wide Web, his writings are read by practitioners from all over the world.

Not bad for a kid from Grand Junction, Colorado, eh?

Learning the basics of a modeling technique is not the same as learning how to use and apply it. To develop a data model of an organization is to gain insights into its nature that do not come easily. Indeed, analysts are often expected to understand subtleties of an organization's structure that may have evaded people who have worked there for years.

Here's help for those analysts who have learned the basics of data modeling (or "entity/relationship modeling") but who need to obtain the insights required to prepare a good model of a real business.

Structures common to many types of business are analyzed in areas such as accounting, material requirements planning, process manufacturing, contracts, laboratories, and documents.

In each chapter, high-level data models are drawn from the following business areas:

The Enterprise and Its World

The Things of the Enterprise

Procedures and Activities

Contracts

Accounting

The Laboratory

Material Requirements Planning

Process Manufacturing

Documents

Lower-Level Conventions