THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Published in TDAN.com July 2002

The cover of Information Week the week of Jan. 21, 2002 proclaimed:

“THE SORRY STATE OF SOFTWARE QUALITY: The number of bugs, holes and patches more than doubled last year, keeping IT departments busy and putting business data at risk…”

Perhaps twenty years ago, this would have been a less shocking headline. Today, it is pretty disturbing. While many factors contribute to software failure, lack of planning or “dis-integrated” planning is a key factor. As a friend says, “we don’t plan to fail, we fail to plan.” Some examples of planning failures that we continue to see in our practice are:

• A lack of formal, enterprise-wide IT planning (architecture) or unrelated pockets of planning
• Data planning isolated from the “real” architecture (i.e., the technology architecture)
• The terms “data architecture” and “data model” used inter-changeably;
• The data model constructed before or without (reference to) the enterprise architecture
• The data management organization viewed as a group of eccentrics with ersatz skill sets who aren’t nearly as vital to IT as the developers and data base administrators, or worse—viewed as a roadblock.

Like many, I began my IT career as a programmer, and moved “up” to design, then analysis, all at the project level. It took a few un-sought job “opportunities” before I understood the value and the business benefits of integrated IT planning at the enterprise level—not the least of which is protecting business data. Even now, when the criticality of “business data” is almost universally understood, many organizations resist using IT resources to develop an architecture that goes beyond technology. In the past couple of years, I have seen an intensified interest in attendees of our architecture seminars—in more broad-based architecture, especially when mergers and consolidations virtually require it. I believe we can leverage this interest to begin to make some profound changes in the process—or lack thereof—that we use to create plans for IT. Data and the data manager play a vital translation role in this process.

I have recently been reminded of how apt is the comparison of IT to building a house. I learned first-hand that what you plan formally is more likely to happen, that what you include in the plan is most likely to be executed and that what you omit—like an extra closet—will likely not see the light of day. I was reminded also that key to a successful outcome is the ability to translate intent from the client to the architect, through the builder and to the implementers who execute the plan (electrician, plumber). In the instance to which I refer, the builder’s outstanding ability to translate the architect’s plan into directions for the implementers resulted in tremendous success.

In our workplace organizations, the business client, the architect, the data manager and the developers often need to forge stronger relationships and call on their translation skills. One of the approaches we use to create better, integrated IT plans is process modification. Working within the same, better-defined process, our IT professionals can have a profound impact on the quality of IT implementations, and ultimately on the organization’s success.

At my company, we call the broad-based, enterprise-wide integrated IT plan the “Enterprise Information Architecture” (EIA).* We define a complete set of strategies for creating an EIA in the “Enterprise Information Architecture Toolkit”. Presented here is one of the approaches we use to begin to close some of the gaps in the IT planning process. Specifically, we look at how to create the often-missing link between enterprise architecture and data modeling. Here’s how the two views line up:

When the gaps between the two views are not bridged, the result may be technically excellent but useless outputs. For example, in one organization, when we developed the target architecture required to support a new business direction, it was an almost impossible task to persuade the data team to “reverse engineer” the enterprise data model. In another organization, we urged our client not to purchase an external data model before we defined the target architecture. Neither of these situations was likely to produce the sort of high-quality business data on which organizations today rely.

Our experiences—the good, the painful and the almost terminally ugly—have led us to devise and successfully use some very practical approaches for creating the necessary linkages and closing the gaps. In the nine “Dos and Don’ts” that follow, the architect and the data manager play key roles in creating linkages through translation.

1. Do include business functions and key information in your IT architecture. If your “architecture” is simply a technology plan, throw it away and start over. The plan needs to include the function, data and technology components of the business and how they are related. Architecture modeling is one of the best ways to portray the relationships.
2. Do use business language in the architecture models. The architect plays a critical role in the translation of business needs to IT architecture. If the business calls them “clients” don’t refer to them as “customers” in the architecture. There is plenty of time to precisely name objects in the detailed logical data models.
3. Do get business and IT concurrence on the architecture before you proceed any further. This tests the accuracy of your translation. Any lack of time spent here is sure to cost you greatly in later steps.
4. Do use the architecture model as the basis for developing a conceptual data model.* The data analyst plays a critical role in the translation from architecture model to data model. This requires the data analyst to identify large, conceptual data subject areas referenced in the lowest level target state architecture models. These data areas are translated to provide an initial set of conceptual mega-entities. The data analyst edits the mega-entities by adding or dividing where big, obvious gaps exist.
5. Do include business policies in the conceptual data model—those very high-level written statements or guidelines that describe how the business wants to operate on the information. Don’t try to get “atomic” or pin down “rules” yet.
6. Do set a few, key standards—names and definitions for the mega-entities. Since a conceptual data model should fit on one page, there should only be a few, not many, entities that require standards, and these should be the basic information blocks of the organization, e.g., Customer, Product, Employee. These will be the basis for more detailed modeling and development.
7. Do get concurrence from the architect and the business on the conceptual data model before you build anything new. If possible, do use the same participants who reviewed the architecture model. In a couple of cases, I found marketing and operations leaders who were eager to participate in both reviews. If this group doesn’t understand the conceptual data model, then it is not conceptual or it is not an accurate translation.
8. Do consider “just in time” logical modeling as you go forward—developing detailed logical data models only for new, large funded projects that comply with the target architecture.
9. Do publish and update. Even the most excellent plans, if “secret” or static, are useless. Make sure the architecture models and the data models are available to the business and IT—architects, analysts, designers and developers—through the intranet, repositories and open forums.

This is a fairly simple, but not necessarily easy, process to execute. You are likely to meet resistance, which is why the concurrence steps are so important—and often, so time consuming. But having undertaken these steps, you will have put in place key linkages required to accurately translate the business requirements to architecture, to translate the architecture to data models, and to use data models to provide direction and guidance for on-target code and business data implementations. By following this process, you will contribute heavily to the delivery of IT components that actually meet the business goals—and that, hopefully, is why we are getting paid.

* “where “enterprise” means all parts of the company, business unit, agency or organization. “Information” means all the data required to run the enterprise and includes the functions, the technology and the people that create, access, use or transform that data into information and ultimately, knowledge. “Architecture” refers to the set of plans that describes how all parts of the IT infrastructure need to behave to support the enterprise needs and goals.”

** “…the one-page entity-relationship model that describes the relationship of each set of data included in the architecture model to every other set.”