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.