Over the years as technology has matured, the approach to keeping data in synchronisation has matured. Originating as an export and import approach for moving data between systems, more and more solutions now request data on demand using APIs (Application Programming Interface) where smaller individual records are required. If you do use an API, you need to potentially have two system functions developed, one at the source system and then a matching one on the receiving system. A lot of commercial systems have standard APIs but it is unlikely that the standard APIs of two different supply systems will talk to each other out of the box.
The primary objective of either method is removing the old enemy, the rekeying of data! It is time consuming, prone to error and means your data is usually always out of data.
What is the frequency or trigger event that mean data needs to move?
- Will the source format and field design match that of destination system or will there need to be some sort of data change as part of the interface? For example, date fields could be different in the two systems.
- Are there any supporting lists or databases that need to remain updated as they are referenced in the main data transfer? For example, moving data between a rostering system and payroll system will need employee numbers to be accurate and updated between two system as part of the payroll transfer.
- What are the business rules involved with triggering a data transfer?
- Once the data has been transferred, do you need to change anything in the source system? This could be a change in status, a reference number from the system and/or the time stamp of when it occurred.
This isn’t a comprehensive list but an example of the areas you need to consider. Also if you are moving data between internal systems and either cloud or supply chain systems, infrastructure security and data protection restrictions need to be assessed.
We can work with you to identify and document your needs, then potentially manage and test the work undertaken by the software providers to deliver your solution. As a Microsoft Development Partner, we can potentially build elements of the solution as well depending on the specific source and destination systems.
Click on the diagram above to see how a typical organisation may use different types of methods to transfer data between systems.