Enterprise Architecture

An enterprise architecture is comprised of a set of pictorial representations (models) of the organization in terms of business functions, business processes, and business data. Each enterprise architecture model is supplemented with supporting meta data, such as standard definitions, business rules, and policies. The purpose of these models is to document the set of business actions performed on any real-world object in the course of conducting business. In other words, enterprise architecture models describe the actual business in which the organization engages.

Every active organization has an enterprise architecture by default, even if it is not documented. With undocumented architecture, the organization's business actions and business objects are most likely not consistently understood by everyone in the organization. The goal of documenting the architecture is to avoid abusing , misusing, or redundantly recreating unique processes or data about business objects, which can lead to losing sight of the cross-organizational picture.

A fully documented enterprise architecture includes at least five architectural components (Figure 2.9). The following subsections describe these components .

Figure 2.9. Enterprise Architecture Components

The Business Function Model

This model depicts the hierarchical decomposition of an organization's nature of business; it shows what the organization does. This model is instrumental for organizing or reorganizing the structure of an organization into its lines of business. Usually one vertical line of business supports a major business function on this model. Two examples of such an alignment are the loan-origination division and the loan- servicing division of a mortgage- lending institution.

The Business Process Model

This model depicts the processes implemented for the business functions; it shows how the organization performs its business functions. This model is essential for business process reengineering as well as business process improvement initiatives, which often result from BI projects. For example, a business process model could be analyzed to determine whether it is possible to streamline a current business process called loan payment processing because customers have complained about the long delays in posting their loan payments while their loans continue to accrue interest.

The Business Data Model

This model, which is commonly called the enterprise logical data model or enterprise information architecture, shows what data is part of the organization's business activities. This model depicts the following:

• Data objects participating in a business activity

• Relationships among these objects as they exist in the actual business activities

• Data elements stored about these objects

• Business rules governing these objects

Since data objects and data elements are all unique, they appear in the real world only once. Therefore, they are documented in the business data model only once, regardless of the numbers of physical files and databases used for their storage. There is only one business data model for an organization. This model and the meta data repository are the two most important nontechnical infrastructure components for an evolving BI decision-support environment.

The Application Inventory

The application inventory is an accounting of the physical implementation components of business functions, business processes, and business data (objects as well as data elements). It shows where the architectural pieces reside in the technical architecture. Application inventory entries include the relationships among the physical implementation components, such as programs, job streams, databases, or files.

Organizations should always identify, catalog, and document their applications as well as the business rules about their business data as part of the development work on every project ”but they seldom do. Such inventories are paramount for performing impact analysis. Remember the colossal efforts of Y2K impact analysis without such an inventory!

The Meta Data Repository

Although "a picture is worth a thousand words," business models without words are not worth much. The descriptive details about the models are called meta data. Business meta data is collected during business analysis, and technical meta data is collected during design and construction. The two types of meta data are linked to each other and made available to the business community of the BI decision-support environment. Meta data is an essential navigation tool. Some examples of meta data components include the following:

• Column name

• Column domain ( allowable values)

• Table name

• Program name

• Report name

• Report description

• Data owner

• Data definition

• Data quality metrics