In the age of smartphones, self-driving cars, SQL-less databases and marketing driven by artificial intelligence, it’s easy to forget how old some of the tried-and-true software we interact with every day really is. You may be able to pay your credit card bill from your phone, but somewhere along the line, there’s a good chance that transaction includes adding to a nightly COBOL batch job or similar mainframe process.
Systems are ever-changing, but many of them have a backbone that is 30 years old or more. So let’s discuss some of the key factors to consider when integrating systems.
1. Data Flow
Will data be unidirectional or bidirectional? One factor to take into consideration is synchronizing. If data will only move from one system to another, and never the other way around, you have some freedom to decide whether updates must happen in real time (I click a button and voila, my data appears) or at scheduled intervals (nightly jobs, for example).
If each system is capable of sending data to the other, this will likely limit synchronization to real-time to avoid discrepancies.
2. Source of Truth
Your systems are integrating, not duplicating. This means the stored data should be located in one system and referenced in the other.
3. Master Data
In conjunction with the “source of truth” factor, existing master data strategies must be taken into account. Are both of your systems capable of creating a Customer data object? Is a third? If central data can be maintained from multiple systems, it’s likely this master data will need to be referenced, rather than having numerous Customer objects on different systems.
4. Urgency
How often must your data be synchronized? If data on one system is being pulled into another system for report generation, perhaps the most efficient method would be to schedule data to be synced in bulk every night, once a week or once a month. If data is used by emergency systems or external applications, data will likely need to be migrated in real time.
5. Integration Needs
Integration can be done manually, automatically, or as part of a one-time kickoff.
Is the integration part of a data migration to change over from a legacy system being shut down? Will migration happen every time a new record is needed? Perhaps data will be retrieved ad hoc, selected and transferred only as the user requires and updated as it is received. Consider these situations to decide how the actual transfer should take place.
In short, there are many factors to consider when implementing system integration. These are only a few. Like everything in development, reshaping an existing system is easier said than done. When designing your next system, keep these factors in mind and you’ll be connecting smartphones to COBOL in no time! And if you need a hand, just let us know.
