Design patterns for data integration

Abstract

Purpose The application landscapes of major companies all have their own complex structure. Data have to be exchanged between or distributed to the various applications. Systemizing different data integration patterns on a conceptual level can help to avoid uncontrolled redundancy and support the design process of data integration solutions. Each pattern provides a solution for certain data integration requirements and makes the design process more effective by reusing approved solutions. Proposes identifying these patterns. Design/methodology/approach After a broad literature review data were obtained from interviews and documentary sources. Ten semi‐structured interviews were conducted within four different companies operating in the financial service industry. EAI‐ and IT‐architects as well as project managers and CTOs were involved in these interviews. Findings Five different data integration patterns were identified. Solutions for upcoming data integration requirements can be designed using these patterns. Advantages and disadvantages as well as typical usage scenarios are discussed for each identified data integration pattern. Research limitations/implications In order to identify data dependencies, to detect redundancies and to conduct further investigations, a consistent methodology for the description of application landscapes has to be developed. The presented design patterns are one part of this methodology only. The approach in this paper only considers data integration while in reality there are also other integration requirements like functional or process‐oriented integration. Practical implications The identified design patterns help practitioners (e.g. IT‐architects) to design solutions for data integration requirements. They can map the conceptual patterns to company specific technologies or products to realize the solution physically. Originality/value The design patterns are indifferent from any technology or products which ensure a broad application. Business requirements (e.g. requirement for autonomous processing) are considered first when designing a data integration solution.

Cite this work

No public copy is stored for this record, so only the metadata is cited.

Stored only when both papers are in the corpus — 24 citations exist upstream.

Papers that cite the same references — the relational fallback while embeddings are still backfilling.