What Is Information Architecture? 

Linking an enterprises strategic plan with its enterprise data architecture, enterprise application architecture and enterprise technical architecture results in enterprise information architecture.

A well-documented architecture is a logical organization of information pertaining to the following corporate-level, enterprise-wide elements:

Enterprise information architecture also establishes guidelines, standards, and operational services that define the enterprise’s systems development environment. When an enterprise’s architecture is so documented, it can be used to accomplish the following:

Before an enterprise information architecture can be implemented, it must be "engineered." This requires a method and approach that is rigorous and repeatable.

The Metro InfoDesign approach developed by Marcus Tremble , Director of Projects, to engineering an enterprise information architecture is described here:

Defining New Architecture:  Identify Enterprise needs

Identifying enterprise needs is the first task in the engineering life cycle for any information system, and it is crucial when engineering an enterprise architecture. When developing operational systems, there is often one single sponsor or one group of users with a clear view of what they need, what the system should look like, and how it should function. Conversely, when developing enterprise architecture, there are normally multiple potential sponsors, each with a different idea of what the enterprise architecture is and what it should provide, and all requesting or demanding action. Because of this lack of a single focused direction, identifying precise enterprise needs is critical to the success of an enterprise architecture project.

Enterprise architecture needs should be expressed in terms of business functions, rules, measures, and critical success factors. An enterprise’s business plans typically provide the basis for defining preliminary enterprise needs. In addition, it may be necessary to interview key enterprise managers and analyze other pertinent documentation in order to ascertain the enterprise’s strategic information needs.

The best technique for defining and refining preliminary enterprise information needs is to conduct a series of facilitated focus group sessions. (If no business or performance plans exist, similar sessions first should be used to create the plans.) The participants in any of these sessions should be decision-makers for whom the information is important.

After identifying and defining enterprise needs, it is advantageous to communicate them throughout the enterprise. One of the best justifications for undertaking an architecture project is the synergy achieved through the process of defining and then communicating its critical success factors and measures. Everyone becomes aware of precisely what defines success and how it is measured. In addition, the measures undergo a "reality check" by people who were not involved in their development, but who may be measured by them and who will be involved in creating the raw data from which the measures will be derived. Their feedback is used for refining the measures.

Completely validating enterprise measures includes describing the cycles or time periods used. Are quarters, months, or hours appropriate for capturing useful measurement data? How much historical data will be needed? These vary greatly by organization. The United States Federal Reserve Bank views enterprise measures in monthly, quarterly and annual increments and uses years of historical data to determine trends in the economy. An insurance company requires decades of actuarial data for meaningful measures. A telephone sales operation, on the other hand, uses hourly enterprise measures and may keep only a few weeks of information.

A well-defined enterprise architecture model cannot contain homonyms, synonyms, or other data definition conflicts. These data conflicts may exist because most enterprises have one or more major terms that are used by everyone in the organization, but mean different things in different organizational units. One of the most commonly misused terms is "customer.

To the Accounting Department, "customer" could mean the organization (or individual) that receives a bill. "Customer" could also mean an individual receiving service or buying a product. To the Sales Department, "customer" could mean the organizations on which the salesperson calls. Additionally, each department may use different names to describe the same data element (Customer vs. Client vs. Prospect vs…). Providing any one of these interpretations as the single enterprise definition of "customer" would not meet the needs of the enterprise and would predispose its information resource management efforts to failure.

Great pains should be taken to resolve all data conflicts in the enterprise architecture before attempting to implement applications that support the new architecture.

Build the Enterprise Architecture

Creating an enterprise architecture is a lot like creating a building architecture. Both involve a disciplined development cycle, use rigorous techniques, and require the right tools.

A building is constructed using architectural diagrams (blueprints) that clearly depict the building's infrastructure (structural elements, walls, electrical wiring, plumbing, etc.). Enterprise architectures include architectural models of enterprise infrastructure (policies, goals, measures, critical success factors, data elements, etc.).

Blueprints are also used to enlarge a building or make any significant modifications. Without a diagram of the infrastructure, such changes are quite difficult and very costly -- and can even be dangerous. It is the same with enterprise architectures. Managing change means first updating the enterprise's architecture model so that it reflects changes (new product lines or services, for example) and then modifying the information systems to support the changed enterprise.

Enterprise architecture engineering is easier and less costly when based upon an accurate architectural model of the enterprise. Further, strategic information based upon the architecture is easier to use and consistently produces desired outcomes when decision-makers have access to an enterprise architecture that accurately reflects enterprise infrastructure.

It is imperative that an enterprise information architecture reflects both strategic information requirements and day-to-day operational data requirements. The architecture must be closely linked to the enterprise strategic plan and corporate performance measures.

Enterprise information needs, corporate performance measures, and critical success factors should be documented in a central repository, along with a corresponding logical data model. The logical model should include operational data entities as well as strategic information data entities that will tell executives and managers how well their enterprise is performing.

Activities critical to capturing a clear understanding of an enterprise’s information architecture include providing a clear and unambiguous definition of every data entity, describing the way each is used, defining derivation formulas and aggregation categories, and documenting data collection and retention time periods. The resulting enterprise architecture model, which links enterprise needs with data entities and enterprise rules, becomes both requirement documentation and a source for communicating the contents of the architecture (and its metadata) to its users.

Contact Us, and learn more about how Metro InfoDesign Information Architecture and Metadata Management services apply to your business requirements...