The riskiest problems are those you don’t know to expect, and system integration services are rife with pitfalls that pose risks for the unprepared or inexperienced IT team. To save you from making the kind of mistakes that can derail your systems integration, we’re going to share 5 critical challenges to make sure you are prepared. Whether you’re linking your inventory to your sales platform, your order fulfillment to your transport dispatch, or trying to overcome different digital standards for farm equipment, you’re sure to uncover potential obstacles.
1. Things don’t always go as planned: store everything!
It’s easy to fall into the trap of thinking a system integration service will take care of everything, but to do so is to set yourself up for failure. Instead, incorporate expected failure into your plan so you can recover quickly. 
When integrating two complex software systems, the backlog of problems can climb rapidly and overwhelm your Minimum Viable Product. One worst-case scenario is transferring data from one system to another and not recording the details of where the data came from. In a situation like this, your v2 release has to re-approach the whole integration from the ground up. We’ve seen system integration services to import sales proposals and convert them into orders, neglect to actually track which order came from which proposal. When the management team wanted to figure out who their most effective sales reps were by tracing the proposal through to delivery, they had no way to connect the dots. As a client, you want to ensure that any integration service you purchase or have developed is ready to handle these complexities. A successful integration service must take steps to track sufficient data such that you can apply a fix without starting over. This often means keeping accurate, machine-readable audit logs of all actions that are taken as data flows from one system to another. Storage is cheap, and a well-designed integration service will be able to keep recording in the background without impacting your path forward.
2. Automated systems: Not as simple as you think
Large-scale data integration is difficult, and dates and times can be downright impossible. Automated systems often need very precise timings on events to know the order in which they actually occurred. Imagine a server in New York talking to a server in Seattle. Bob updates a sales record at 1 p.m. in New York, but Jim also edits it at 10am in Seattle. We know that we have to account for time zone differences, but are the servers designed to handle it? 
What if Jim was actually in Tokyo when he made that change? Was that 10 a.m. Tokyo time, Seattle time, or New York time? Now imagine that the edit happened at 1 a.m. on the day we reset the clocks back an hour for daylight savings time. Was that the first 1 a.m. before the clocks moved back, or the second? For systems to be interoperable, they need to recognize the differences between point-in-time events that happen on a global clock, and local user time that describes how it appears to someone when they look at a clock. By separating the concerns, you can record when an action happens in UTC (Universal Time Coordinates) for an accurate order of events.
3. Automated systems can’t think like you
Looking back at the previous example, you may have noticed we set up a bit of a conundrum; 1 p.m. in New York is actually the same moment as 10 a.m. in Seattle, so both Jim and Bob edited the record at the exact same time. How does the system decide what happens if Jim updated the sale to $100 just as Bob changes it to $50? As fast as the internet is, it still isn’t instantaneous, so the events may take a second to travel across the country. This is compounded even further if your system can operate offline. Charlie had a flight to Chicago, so he put his tablet in airplane mode and used it to update all his sales data for the month. When he lands and connects to WiFi, the tablet discovers that his partner has also been modifying the sales data over the last couple of hours, and nothing matches! Someone else looking at the numbers won’t be able to make sense of the discrepancy. They may even wonder if Charlie and his partner are fudging their sales numbers! How do you account for this in integrating systems?
Another example of software system blind spots
What if an agronomist is scouting a field to see how different areas of crops are growing. He has no cell reception as he is in a rural area. He marks the changes on his tablet, gets within cell range, tries to upload the changes to the cloud, but someone at the office just deleted that field. The automatic system doesn’t know what to do in this scenario. The truth is, there may not be one answer to apply across the board. You could say, “last entry wins” and just accept the last modification as gospel. That won’t work too well if the record is just deleted. In the sales scenario, maybe you have business rules that the more senior salesman wins and can’t be overridden without a manager’s approval. For truly critical data, the best bet may be to store both versions of the changes and notify someone higher up that they need to look into the discrepancy to solve it. (For Charlie and his partner, maybe consider letting them one of them go if the final values aren’t what they should be.) For any of these solutions, a dashboard that can provide insight into what the conflicts were and how they were resolved. Don’t forget to update the final result.
4. Disparate systems can mean disparate business rules
It may be obvious that disparate systems have disparate business rules, but the challenge is how you handle them. Salesforce might allow you to use punctuation marks in your account names, but QuickBooks may not. A naive technology integration may end up needlessly ‘correcting’ the account names back and forth between systems, unaware that no matter how much updating you do, the names will never match up. An independent ‘registry’ of items can be used to cross-reference the accounts between different systems, while tracking the appropriate name in each domain independently. Changes are compared to the registry rather than the other integrations, isolating and accommodating the independent rule sets. Accounting for system-specific business rules can prevent you from chasing your own tail.
5. Monitoring for aberrations, not just system failures
Time and time again, I’ve witnessed the same sequence of events — a user reaches out to support because some mission-critical service simply isn’t working. Much consternation ensues because this service has gone down many times in the past, and no matter how much error reporting is put in place, no one ever seems to know that the service isn’t working before the client reports it. This kind of situation comes up when the monitoring service is looking purely for failures. What can happen is that a process stalls out — a hard drive runs out of space, or a network connection drops. There’s no error per se, because the request has been queued –it simply will never be picked up and processed. This is why any good monitoring system will track the number of requests that actually complete successfully. These can be assigned a ‘time-out’ — a length of time that the task needs to complete within, before it is interpreted as an error. For high-volume tasks, you can do statistical analysis to highlight a significant and unexpected drop in the number of completions.
Avoid the risks of system integration services
Regardless of the type of business you do, you need end-to-end visibility of all the data flowing through your IT ecosystem. Off-the-shelf system integration services are not a panacea. There will be implementation challenges even with the best enterprise or supply chain solutions. If you are accountable for its implementation, head off the inevitable problems by planning for them.
Get it right the first time.
Sign up for a free 1-hour consultation to scope out pitfalls you may not know to consider. No obligation. No reason not to.