Integrating systems is a surefire way to unlock value. It’s a way to make 1 + 1 equal three. As soon as you do that though immediately surfaces the questions…. which system is in control, how often will things run, what will be synced? In simpler terms, what will be transferred by who when.
I cannot give you the formula for success, but I can give you the
formula for failure. It is: Try to please everybody.
– Herbert Bayard Swope
Overlooking important considerations here will lead to a cleanup effort. What’s sometimes more important though is where the logic that should be done to prepare the data for integration. The integration itself should act like a cable, or a conduit since in effect it is calling a view of the data. If you start to put logic in your integration platform, then you are opening up yourself up for a maintenance liability where you now have to manage and maintain core business logic in multiple places. As programmers, we loathe doing things twice.
Creating an Integration Plan
A vast majority of integration platforms promote plug and play. We integrate with everything they say. So does Netsuite natively … it’s called an API call and most of the time it is far more efficient than the integration platforms for one simple reason…. you can pull the objects into netsuite in bulk, and place them in memory, and then you can scream as you make the data changes to create the integration. The latency is in the connection, not in the data processing, so when you are doing lots of connecting, then you are slowing the system to a snails pace. And if you do it this way, there’s no recurring licensing fee.
Our advice is to spend the money building the integration specific to your needs. When you need to make changes, they are simple, contained and eloquent doing only what you need. Furthermore this starts to lead you towards Netsuite acting as it’s own microservice within your organization where the presentation of the business objects is consistent across multiple integrations.