Data and the enterprise architecture framework

Using a detailed data model, Hay discusses data and the enterprise architecture framework with a focus on the business owner, architect, designer and the functioning system. He also examines business terms, concepts and fact types in relation to his data model.

This Content Component encountered an error

The following excerpt from Data model patterns: A metadata map, by David Hay, is printed with permission from Morgan Kaufmann, a division of Elsevier: Copyright 2006. Click here to read the complete Chapter 2: Data and the enterprise architecture framework, or read Chapter 1: About data models.

Data and the architecture framework

The Data column of the architecture framework is concerned with what is significant to an organization from the six points of view.

 

  • The planner looks at aggregate groups of major things of significance that are the domain of the business.
  • The business owner is concerned with the nature of the business itself, in terms of the tangible things that constitute the organizational environment. Both the planner and the business owner are also responsible for defining the language used by the business. The metamodel for Row Two, then, is concerned with the concepts behind the business and facts that link them, along with the means of describing those concepts.
  • The architect is concerned with the structural elements of the enterprise that will be the basis for automating it. The third row is the conceptual entity-relationship model that codifies the enterprise's language and gives it a rigorous structure suitable for use in information processing.
  • The designer uses the architect's rigorous structure as the basis for defining how data management technology can be used to solve specific problems. Row Four is concerned with relational tables and columns, object-oriented classes, or other approaches for using a particular data manipulation technology.
  • The builder defines places for data on a particular data storage medium.
  • The functioning system consists of an inventory of physical databases.

Figure 2–1 shows the architecture framework, with the cells to be discussed in this chapter (for the Business Owner, the Architect, the Designer, and the Functioning System) highlighted.

The business owner and business rules

The Business Rules Group (formerly the GUIDE Project on Business Rules) published a paper in 1995 describing categories of business rules [Business Rules Group 1995]. The paper essentially addressed the Architect's View of business rules, concentrating on how to capture and organize them for eventual implementation in an information system.

More enterprise architecture resources
Q&A with John Zachman: Enterprise architecture framework 101

Expanding BI with enterprise information integration

Among other observations, that paper included recognition that a business rule at Row Three is best understood as a statement that defines or constrains data about an enterprise. To be sure, some rules are more appropriately described in terms of events and activities, but a preponderance of them are best expressed in terms of permissible states of data. The categories identified by the Business Rules Group paper are:

 

  • Terms (and the business concepts these terms describe): The definition of a business term is itself a rule that describes how people think and talk about things. Thus, according to this view the definition of terms (that is, their underlying business concepts) establishes a category of business rule. For example, this can be a term used in a data model (such as product type) or one simply used in the business, such as prestige client.
  • Facts: These link terms. Both the nature and operational structure of an organization can be described in terms of the facts that relate the enterprise's terms to one another. To say that a customer can place an order, for example, is a fact; and is therefore a business rule. Facts can be documented as natural language sentences or as relationships, attributes, or generalization structures in a graphical model. For example, a fact may be expressed in a sentence, such as "Each product instance may be located in one or more sites."
  • Derivations: These are business rules (including laws of nature) that define how knowledge in one form may be transformed into other knowledge, possibly in a different form. Calculations for product cost and profitability are examples of this category.
  • Constraints: Every enterprise constrains behavior in some way, and this is closely related to constraints on what data may or may not be updated. These include business constraints such as those controlling to whom you will issue credit, and data constraints such as those on the values data elements can take [Business Rules Group 1995, p. 6].

In the Business Rules Group paper, terms and facts are called structural assertions, whereas constraints are called action assertions. Derivations are a separate category, although the results of derivations are derived facts (structural assertions). For the most part, structural assertions (terms and facts) are data-column artifacts—which can be represented in entity-relationship (or object) models— whereas action assertions (constraints) are motivation-column artifacts which for the most part cannot be represented in an entity-relationship model. Derived terms (attributes) are structural assertions that can be presented in a data model, although the logic of their derivations cannot.

Since publication of that original paper, the Business Rules Group has teamed with other organizations and the Object Management Group to form what they call the "Business Rules Team". Their charge is to attempt to deal in more detail with the Data and Motivation columns not from the Architect's View (Row Three) but from the Business Owner's View (Row Two). They set out specifically with the practical objective of describing the characteristics of a language that could be used both to describe a business in business owners' terms and (using formal logic) to convey that meaning in a rigorous way to be useful to technology designers. From this work, they have come up with some significant insights into the role language plays in the manipulation of both business concepts and technology [BRT 2006].

One of the conclusions the group came to was that terms and facts are not, strictly speaking, business rules. First, it is the business concepts behind the terms that are important. Second, the definition of a set of facts (fact types, actually, but more on that later) is more useful for understanding the nature of an enterprise than the facts themselves. Neither of these, strictly speaking, are business rules. Instead, the Business Rules Team asserts that business rules (the former action assertions) are built on fact types, which in turn are built on the business concepts behind terms.

Another term for this first major category—structural assertion—is universe of discourse. This consists of the business concepts that are the meaning behind the terms and fact types, each of which is the definition of a category of facts.

Terms, concepts, and fact types are the domain of the Data column of the Business Owner's View at Row Two of the architecture framework. These will be described more rigorously in the following section. Row Two business rules (and the data and database management system constraints that follow from them) fall under the Motivation column, and are more fully explored in Chapter Seven.

More information


This was first published in December 2006

Dig deeper on Enterprise data architecture best practices

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchBusinessAnalytics

SearchAWS

SearchContentManagement

SearchOracle

SearchSAP

SearchSOA

SearchSQLServer

Close