AI Glossary / Data engineering and architecture / Intermediate

Enterprise information integration

Definition

Enterprise information integration, or EII, provides a unified way to access information held in different organisational sources. In its established data-federation usage, it lets applications query those sources through a common interface without first loading all their data into one warehouse.

What it means

A business question may require customer details from one database, orders from another and service information from a third. EII presents an integrated view so the application does not need to understand every source's access method and structure separately.

The unity is logical. The source systems can remain separate, with different technologies and responsibilities. Some implementations also use caching or materialized results, so “federated” should not be interpreted as a promise that no data is ever copied.

This differs in emphasis from enterprise application integration, which often coordinates application messages and processes. It also differs from physically consolidating data through a warehouse pipeline. These approaches can coexist; choosing one for a particular workload does not make the others unnecessary.

How it works

A federation layer records metadata about the sources and maps their fields into a usable integrated model. Connectors translate requests into the operations each source supports. The system plans how to retrieve and combine the necessary results.

Where possible, filtering or aggregation can run at a source so fewer records cross the network. Operations that cannot be pushed down may run in the integration layer. The best plan depends on source capabilities, data volumes, network conditions and available statistics.

Meaning requires explicit work. A field called customer may identify a person in one source and an organization in another. Matching schemas does not automatically reconcile those meanings, currencies, date conventions or identifiers.

Operational guarantees also need attention. Independent sources may be read at different moments, and an unavailable source can prevent a complete answer. A unified interface does not inherently provide a single transaction snapshot, consistent permissions or unlimited query performance.

Three practical examples

• A service portal combines an authorized customer's order status and support cases from their respective operational systems.
• An analyst compares a selected product's catalog details with recent stock positions without copying every source table first.
• An AI reporting assistant queries a governed integrated view, while retaining source and freshness information needed to explain the answer's limitations.

Think of it this way

Think of a reference desk that can consult several specialist libraries. A visitor asks one question, and the desk coordinates the necessary lookups instead of asking the visitor to learn each library's catalog.

The analogy has limits. A common desk cannot make conflicting definitions agree or force every library to update at the same moment. Similarly, EII simplifies access while leaving important semantic and timing questions to be resolved.

Worked example

Reducing transfer through source filtering

An invented query needs orders for one customer. The order source holds one million rows, averaging 200 bytes each. Fetching every row would transfer roughly 200 million bytes before considering protocol overhead.

Suppose the source can filter by customer and returns 500 matching rows. The transferred order data becomes about 500 × 200 = 100,000 bytes. The ratio is 200,000,000 ÷ 100,000 = 2,000: the example transfers about two thousand times less order data.

That is a data-volume comparison, not a promise of a two-thousand-fold speedup. Source lookup cost, connection setup and joining to customer details still take time. If the filter cannot run remotely, the saving may disappear.

If customer details are read before a change and orders afterwards, the combined result may also span different source states. Reduced transfer does not establish a common snapshot. The application must decide whether that timing is acceptable for its question.

Illustrative case study

A fictional equipment supplier builds an integrated account view for its support staff. Customer details remain in a relationship system, orders in an order database and repair records in a service application. The view uses a documented account cross-reference rather than assuming the identifiers match.

During testing, the repair source becomes unavailable. An early design displays an empty repair list, which staff interpret as “no repairs.” The team changes the view to distinguish unavailable information from a successful query returning no records.

It also tests a customer whose status changes during the combined lookup and documents the view's freshness limitations. For a monthly reconciled report, the supplier retains a separate controlled reporting pipeline. This fictional case shows how integrated access and reporting guarantees can serve different needs.

Common misconceptions and mistakes

• A unified interface means one physical database. Federation can retain separate sources.
• EII automatically cleans every record. Semantic mapping and source-quality work remain necessary.
• Every combined answer reflects one instant. Independent reads need not share a transaction snapshot.
• A missing source can safely be treated as no matching data. Unavailability and a valid empty result mean different things.

Business use

Consider EII when users need combined access and the data should remain under existing source ownership, or when selective queries make full consolidation unnecessary. Assess the actual workload instead of assuming that federation is always faster or cheaper.

Agree on definitions, access enforcement and acceptable freshness. Measure source load and query performance under representative conditions, including slow or unavailable sources. Keep lineage visible so users can investigate conflicting results.

For AI-generated queries, expose appropriately governed views and validate the resulting joins and filters. A language model can ask a coherent question against an integrated interface while still choosing an incorrect relationship or overlooking incomplete source coverage.

People also ask

Is EII another name for federation?

The terms are closely associated in established product and research usage, though EII can be used more broadly for integrated information access.

Does EII replace a warehouse?

Not necessarily. Warehouses can provide historical, consolidated or controlled reporting views alongside federation.

Can EII include non-relational sources?

Yes, when suitable connectors and mappings make their information accessible through the integrated interface.

Check your understanding

A federated report shows customer information and orders through one query. Does that alone prove both sources were read at exactly the same transactional moment?

Answer: No. The system's cross-source consistency guarantees must be established separately from its unified query interface.

Related terms

• Data virtualization
• Metadata
• ETL
• Data federation
• schema mapping
• query pushdown
• enterprise application integration

Learn next

Read data federation and schema mapping. Trace one cross-system question and identify its source meanings, join keys, permissions, freshness requirements and behavior when one source is unavailable.

More in Data engineering and architecture

• Enterprise bus matrix - An enterprise bus matrix is a data-warehouse planning grid that maps business processes to the dimensions used to describe them.
• Enterprise data modeling - Enterprise data modeling is the practice of describing the important data concepts, relationships and rules across an organization.
• Enterprise data planning - Enterprise data planning is the coordinated process of deciding what an organization needs from its data and how to develop the capabilities to meet those...
• Entity-Relationship Model - The entity-relationship model is a conceptual approach to describing data through entities, their attributes, and relationships among them.
• Entry-sequenced organization - Entry-sequenced organization is a way of arranging stored records according to the order in which they enter a data set.
• Entry SQL - Entry SQL is the entry-level conformance category associated with the historical SQL-92 standard.

Sources

IBM documentation, InfoSphere Federation Server: https://www.ibm.com/docs/en/iis/11.5.0?topic=components-infosphere-federation-server. Primary product description linking EII and federation.

Halevy and colleagues, Enterprise Information Integration: Successes, Challenges and Controversies: https://citeseerx.ist.psu.edu/document?doi=f86f64601e9bc468c43e54c876dae842b3176abe&repid=rep1&type=pdf. Research discussion of uniform access without prior warehousing.

IBM Research, UMRR: Towards an enterprise-wide Web of models: https://research.ibm.com/publications/umrr-towards-an-enterprise-wide-web-of-models. Primary research context for metadata heterogeneity. Numerical examples are illustrative.

Previous: Enterprise data planning Next: Entity-based coherence