Enterprise-in-a-Box

An enterprise data model should be the cornerstone for your organization's IT development efforts

By Jim Stewart

Preparing an enterprise model is one of the most valuable tasks that IT managers or CIOs can do for their organizations. Contrary to common belief, a good enterprise model is surprisingly easy to understand and create for large or small organizations. Using an initial framework and intermediate data modeling skills, you can quickly create an enterprise model that gives immediate value to IT planning and system architecture efforts.

In this article I review an approach to developing an enterprise model that:

• Can be quickly built, requiring only days or weeks
• Is easily understood
• Jumpstarts data warehouse and system integration efforts
• Builds a strong foundation for IT planning and budgeting.
• Provides the supporting foundation for data resource management.

The enterprise data model (EDM) is the cornerstone architecture for all IT development. As with other architectures, the EDM promotes quality and communication, which are crucial to the success of your IT project. Architects are typically creative thinkers who leave the details to others. Therefore, the architect's vision must be clearly communicated to the builders and the sponsor who must be convinced to invest potentially large sums of money in it. Obviously, good communication is critical to project success. Quality is also important because IT shops are responsible for creating and delivering some of the most complex engineering efforts within an organization, and their success can directly affect corporate profitability.

WHAT IS AN ARCHITECTURE?

An architecture is the external view of a system that shows its main components and how they fit together. By external, I mean the view of the system as you see it when you step back and look at its overall structure. An architecture document should consist of three items: an objective statement, a component diagram, and a set of component definitions. An objective statement of the architecture of a vehicle, for example, would define the type and structure of its key components (body, drive train, and interior) as a "four-door sedan, front-wheel drive and six-cylinder engine, with luxury seating for five." The statement for a computer application might be "Windows NT operating system, three-tier with a 145-table Oracle database, written using Microsoft Active Server Pages, and supporting 700 concurrent users."

You should not confuse architectures with designs. A design provides sufficient detail to manufacture the object, meeting the objectives and concepts outlined by its architecture. Designs are highly detailed and often voluminous. In contrast to the architecture statement of the car, its design would require gigabytes of carefully conceived and executed information that is incomprehensible without special training.

In complex software projects, success depends on a valid architecture and matching designs. The chances for project success certainly increase when it starts with a good architecture, but how do you tell a good architecture from a bad one? A well-defined architecture should have the following five characteristics:

• Understandable. It communicates the overall concepts of a product to both technical and lay audiences. A good architecture should not require a technical specialist to understand it, yet it should infer key technical concepts that technologists will recognize.
• Concise. It achieves its purpose without superfluous baggage, which is not to say architecture should eschew purely esthetic components. A building architect would be the first to note that carefully considered nonfunctional features add to the aesthetic value of a building and contribute to its longevity. It is the dome on the Duomo in Florence, Italy, for example, that makes the building a classic.
• Whole. It is an architecture that you can quickly scan and comprehend. For a house, a single sheet that shows the street elevation and the main and upper floor plans will do. For a software system, a block diagram of its major components and their interfaces should be sufficient. If it is whole, it fits easily on one page without being too complex.
• Orthogonal. It consists of a minimum set of components, each of which has a well-defined purpose that doesn't overlap other components. The architect should write a definition statement for every component that clearly describes each component's role.
• Visually appealing. When people (especially clients) like what they see, the project is more easily accepted. This characteristic also has practical value: Both aeronautical and software engineers have found that a balanced and graceful design tends to perform better than a cumbersome, unattractive one.

WHAT ARCHITECTURES DO YOU NEED?

John Zachman identified 36 potential models in his classic paper, "A Framework for Information Systems Architecture." (See Resources.) He tells us that you don't need to create all 36 models for every project, and those that you create don't need to have the same degree of detail. The architectures that are the most important - for without them your should not fund the project - include:

• Enterprise data model
• Business process architecture
• Application technology architecture
• Network architecture.

Of these, the EDM is the most critical. You can't correctly define the other architectures unless you understand the basic data resources of the organization. Now let's look at how to create your own EDM.

THE GENERIC ENTERPRISE DATA MODEL

The generic business EDM, shown in Figure 1, is a set of related, decomposed data models that show the critical data of an organization. You can use these models as the starting point for producing an enterprise model for any organization. The model is based on a one-page diagram that shows the nine most important data resources (enterprise data entities) of an organization. One or more of these enterprise data entities appear in almost all data models and databases of the organization.

I present Figure 1 in standard entity-relationship format. Organizations maintain databases to manage the detailed information represented by each entity. The relationships between the entities show associations between them, which when implemented in a database show query paths for questions such as, "Show names of workers who installed the assets at the South Park Station." Experienced data modelers will recognize that this model is too coarse-grained for database development, but that is not its intent. Its purpose is to support planning and integration and provide a framework for classification of the finer-grained models needed for system development.

FINER-GRAINED MODELS

Nine finer-grained models called enterprise subject area models further define the EDM. Each one more fully describes one of the enterprise entities. You can further decompose each of these models as needed into models for individual development projects.

Figure 2 shows the nine enterprise subject diagrams and how they are decomposed into multiple, more detailed application models. Each application subject area is a standard format data model consisting of entities, attributes, and definitions. No hard and fast rules exist to define the depth or breadth of the subject area decomposition. The number of application subject areas appearing under each enterprise subject area varies according to the type of business.

Figure 3 shows the product enterprise subject area as an example. It is centered on the product data entity and shows other entities as needed. Another of the nine enterprise data entities, site, appears in this context. Whereas the EDM is so generic that it looks about the same for any business, the enterprise subject areas are specific to an industry or business. In Figure 3, the products sold are items a business stores and ships out of a physical inventory. This model is a goods business that needs warehousing and distribution systems. If it were a telecom service provider, the model would depict its continuous-delivery type services.

As discussed earlier, the intent of these high-level models is to quickly convey the key components of an architecture. Any additional information detracts from its value. To determine what information is critical to include or what information you should omit from the model depends on its intended audience and the types of decisions for which you will use it.

PUTTING THE EDM TO WORK

The EDM has a variety of applications that generate immediate value from the small effort needed to create it. Here are three of the most common uses:

• Planning and budgeting
• Support of data resource management (DRM)
• Integration management.

EDM for planning and budgeting. In defining its budget, an IT organization can use the enterprise model to demonstrate that it is helping build company data assets. A simple matrix can quickly show where to schedule planned maintenance and development funds for a proposed budget cycle (see Table 1). Displaying system development initiatives at this coarse level lets planners verify that funds are being allocated according to corporate objectives.

You can develop other versions of the chart for other purposes. To show different levels of funding, you could use circles of different sizes. Or you could use pie chart symbols to show that the project life cycle percentage is complete. As executives of the organization become accustomed to classifying IT investments by data resource, they will be stronger supporters of well-architected projects and will be able to make more informed resource-allocation decisions.

EDM for data resource management. DRM is the job of identifying the critical data resources of the organization, cataloging and modeling them, and making sure that they get properly implemented in computer systems. Done well, DRM can save a large company millions of dollars and trim months off development schedules. You can directly apply the EDM to support many DRM activities:

EDM for integration management. System integration efforts will tend to focus on one or more of the entities in the EDM. As part of integration and DRM planning, the organization should closely manage how data representing the nine enterprise entities is exchanged between applications. This effort can realize substantial savings over what it would have cost to integrate them after the fact.

Starting to use an EDM in your business can be relatively easy: First, leverage the generic nature of the generic enterprise model. Recreate the model in Figure 1, in your favorite diagramming or CASE tool, post it on your bulletin board, and start talking about it. The next time someone bemoans the lack of an EDM for your business, pull out your picture and tell them (with only a slight stretch of the truth): "It's done."

You can use this one-page model immediately to support the kind of high-level planning described here. And you can use it to organize other modeling efforts. As time allows, you can go into further detail by gathering existing models built for application development or other purposes and organize them into a decomposition hierarchy similar to Figure 2. You can formally create this hierarchy by using automated repository software, or you can create it informally with Visio or PowerPoint and file folders in your desk drawer. Synchronize the models by defining naming standards and writing common definitions. Finally, organize, combine them, and publish it (in Word, or better yet in portable document format and put it on your intranet site).

PERCEPTION VS. REALITY

My goal in writing this article is to remove the perception of complexity that is a common barrier to starting an enterprise architecture project. Please don't interpret my comments as belittling the task of the data architect. As others have pointed out (see Resources) this job is a complex one that requires experience, training, and talent. The generic enterprise model will help you get started, but you need perseverance to achieve the full potential return on investment.

JIM STEWART [jim.stewart@asix.com] is director of ASIX Consulting in Bellevue, Wash. He specializes in developing data and system architectures for clients of ASIX, a developer of custom Web-enabled database systems. He is the author of many IT newsletter articles and is a system development presenter for many national user groups.

RESOURCES

"A Framework for Information Systems Architecture," by John A. Zachman. IBM Systems Journal, Vol. 26, No. 3, 1987. IBM Publication G321-5298

"Architecting in a Virtual World," by Barbara von Halle. Database Programming & Design, October 1997

Related Articles on IntelligentEnterprise.com:

"Get the Complete Picture," January 30, 2001

"No Enterprise Is an Island," January 30, 2001