Creating a Database While Integrating IT Systems
Many applications within an organization tend to fail and cause all sorts of problems. How can we address this plight?
This article will answer the following questions:
- How can we ensure data consistency in systems during planned integrations?
- What are the benefits of building centralized databases?
Complications With Separate Databases
One of the problems organizations face is that each system has its own database. Systems create more and more records that may exist – often in a more complete form – in other systems. A similar situation occurs when updating data. In one system, they will be up-to-date, while in others they will still be waiting for an update. If there is no synchronization between systems, this will cause additional workload for system users.
Obviously, you can create integration solutions just for data synchronization between systems. You can also look for Master Data Management solutions that are dedicated to ensuring quality, currency, and availability of the most important data for the organization. Such approaches often entail additional costs which, in the absence of other projects, will not always generate satisfactory business value for the organization.
How to build your own “Central Database”?
By using a data bus and the queuing system, you can easily start building your own databases, which can ultimately become a source for other systems. By creating a canonical data model and a method that will transfer data to the queuing system (e.g. Rabbit MQ), you can add data that is important for the organization without affecting the current process. It’s often by pure chance that data is taken from different systems to the FK or CRM architecture. These systems generally have an interface for passing information. Based on the data from that interface, you can queue specific data for each flow call. When creating a database, you can use appropriate algorithms to recognize data, make proper upgrades and add new records.
The data from all customers can be put in a table that collates information about all records from all sources. However, you can create a separate table for unique records that the algorithm considers to be the same. It will keep the most recent and most complete record for a given customer or product. Obviously, that database will not be complete immediately. It may also happen that it will not contain all records from individual systems. It all depends on whether the particular object will be transferred between systems. This also has its advantages. The central database will contain only those records that are currently processed and do not need to be duplicated between systems.
Korzyści z posiadania „Centralnej bazy danych”
With selected records in place, you can create an appropriate REST API that will be able to return complete information for specific data. API shared on a bus can be called by any system. In this way, each system can retrieve up-to-date data.
In addition to updating clients, the database can be used to add new ones. After entering basic information about a client in a system, and after saving it, a request may be sent to the central database via ESB in order to complete the new client’s data.
Oprócz aktualizowania klientów, baza może służyć do dodawania nowych. Po wprowadzeniu podstawowych informacji o kliencie w danym systemie, po jego zapisie może zostać wysłane żądanie do centralnej bazy za pośrednictwem ESB, w celu uzupełnienia danych nowego klienta.
If you want to learn more about services related to the integration of IT systems, check our integration offering and case studies.
