In 1995, David Hay published Data Model Patterns: Conventions of Thought.—the groundbreaking book on how to use standard data models to describe the standard business situations. Enterprise Model Patterns: Describing the World builds on the concepts presented there, adds 15 years of practical experience, and presents a more comprehensive view.

From this book, you will learn how to apply both abstract and concrete aspects of your enterprise’s architectural data model, through four levels of abstraction.

• Level 0: This is an abstract template that underlies the level 1 model that follows, plus two “meta” models: information resources (documents, et al. that describe data from the model), and accounting (itself a modeling language).
• Level 1: This is an enterprise model that is generic enough to apply to any company or government agency, but concrete enough to be readily understood by all. It describes people, geographic areas, physical assets, and activities.
• Level 2: This is a more detailed model describing specific functional areas, such as contracts, facilities management, marketing, manufacturing, and so forth.
• Level 3: Here are some examples of the details a model can have to address what is truly unique in a particular industry. The idea is that most of an enterprise’s architecture can be conveyed by the level 1 and 2 models. Here you just see how to address the unique bits.

Note that the models make use of a revolutionary new approach to the Uniform Modeling Language (UML). For the first time a version is available not just for representing object-oriented design, but also for representing a conceptual, business-oriented model. This requires 5 steps:

• Constrain yourself to classes of things that are significant to the business, and exclude any technological artifacts.
• Limit your use of the notation to the symbols for classes, attributes, and associations (what data modelers call “relationships”).
• Define a stereotype (such as “<ID>”) to represent an attribute’s or a relationship’s participating in a unique identifier.
• Redefine the concept of “RoleName” so that it describes a predicate in the sentence represented by the role.
(For example, “Each Order must be composed of one or more Line Items. Do not use it as a simple label for the second class.
• Follow aesthetic guidelines to make drawings easy to read.

This is not the UML that your object-oriented colleagues know, but it is a reasonable notation for presenting a conceptual entity/relationship diagram. And just as the conceptual e/r model can be converted to a database design, so too can it be converted to a more conventional object-oriented design.

Technics Publications
Bradley Beach, NJ 07458
To buy it on Amazon.com, click here .

ISBN: 978-1-9355040-5-4
$78.95 U.S.