July 23, 2001

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.

• Privacy
• Your California Privacy Rights
• Copyright © 2008 United Business Media LLC