EAI - Shared Database

Identification

Name: EAI - Shared Database

Category: Application/Technology

Version: v1.1

Modelling/Architecture Pattern: Architecture Pattern

Synonyms: No data

Contributor(s): Ed Walters

Attribution: This pattern is based on information in “Enterprise Integration Patterns” (Hohpe, Woolf 2003), supplemented by internet and Wikipedia searches.

Description

Context: In most enterprises there is a mix of different applications and technologies that supply its automated information system needs. These will have been acquired from multiple vendors at different times. Information though needs to flow around the enterprise as smoothly and seamlessly as possible, ‘boundaryless information flow’, hence there is a need to integrate data managed by a set of heterogeneous applications. There is also an expectation for modern enterprises to be able to exchange information with many sorts of external entities, including Customers, Partners and Regulators.

Problem: The problem that recurs is the need to ‘integrate’ the data of distinct applications both within the enterprise and to link up with external entities. • Information Portal • Data Replication • Distributed Business Processes • B2B Integration • Master and Reference data

EAI - Shared Database may be a solution to some of these integration needs.

Trade-offs, Design Constraints (Forces): There are a number of forces to balance in an integration solution. The integrator must consider: • Performance issues • Latency issues • Security issues • Robustness and the implications of failure to integrate • Scalability of the solution

Solution Structure:

Shared Database is one of a number of possible data integration solutions. In Shared Database a number of applications share a common database, ensuring they all have access to the same ‘version of the truth’. For this to be successful, it's essential the applications' understanding of the data is based on a common data model. The access to the data is enabled through database drivers installed locally, provided by a Database Management System (DBMS). The DBMS handles contention for resources and offers facilities like record locking and ACID transactions.

Solution Dynamics: In Shared Database no movement of data is necessary to achieve integration and data consistency is assured.

Layers/Aspects of the ArchiMate modelling language used: Applications/Technology.

Variants, Refinements and Combinations: The idea of accessing common data values is at the core of Master Data Management (MDM) strategies. This pattern of integration could be usefully combined with the RPC Pattern to form a more robust system.

Known Uses: Shared Database is one of the publicised benefits of adopting ERP solutions rather than Best-of-Breed.

Other comments and references: The principal problem with this arrangement is that applications are tightly coupled through the database structures, if given unencapsulated access. The database designer has the difficult task of designing schemas that suit all applications, and/or the applications may need tortuous code to accommodate the data available to suit their needs. Changes in the database structures or the applications could imply a lot of knock-on work, making for some reluctance to take on necessary changes.

Shielding the database by using a system of data services would alleviate some of these issues, which otherwise might be classified as something of an ‘anti-pattern’ in a modern setting. Applications don’t really need to share a common physical database, but they do often need to access ‘common data’. This form of integration spills over into the realm of enterprise Data Governance/Data Management where there are lots of issues to consider, well beyond the scope for discussion here. For example, which application manages the ‘golden record’ of any given entity type is one such issue, and the answer to this may be more political than technical.

Pattern Metamodel

![Shared_Database_Pattern]Shared_Database_Pattern_v1.1

Example(s)

![Shared_Database_Example]Shared_Database_Example_v1.1

In this example the Sales system reads Customer data and writes Sales transactions to a relational database. The Invoicing system reads Sales and Customer data from the same database and has a shared understanding of the meaning of the data.

Downloadable Model

[EAI_Shared_Database.xml]EAI_Shared_Database.xml

Edited by Edward Walters