So you have decided that you need custom integration and have selected an appropriate vendor or vendors to perform the development – or maybe some or all of the work will be done in house – the difference doesn’t matter here. Below are some common, critical mistakes we have seen over the years.
1 Don’t rush requirements gathering and design
Integration between systems can be tricky. Furthermore, since you have already been unable to find an off-the-shelf solution, there may be a good reason the integration you want hasn’t been done. You need to take time to know what you want and why, so it can be evaluated against the systems to be tied to together. Also, when integrating systems, these systems may now become more difficult to integrate with other systems in the future.
You implementor needs to understand the requirements and evaluate them based on the known information of the systems. It will be important to explain what business value the integration will provide. That will help discover alternatives when discrepancies arise between the systems. Be prepared to iterate this process.
2 Don’t over customize the integrated systems
Many systems, especially cloud-based, tout their flexibility and customization. Most of the time that is great – you can quickly customize it to fit your needs. However there is something that any organization must keep in mind: what did we lose by doing this customization on this system? This is a common mistake in platforms, like Salesforce. The ease of creating custom objects can result in many App Exchange applications being unusable. Don’t customize to the point where you can’t use off-the-shelf!
3 Don’t skimp on having multiple environments with good data
Make sure you plan into your development process access to many environments with real data. The cloud is a great place to provision multiple environments quickly. If you have not started working with the cloud, this could be a great place to get initial experience.
4 Don’t ignore testing integrations at scale
Know the stress on each system and understand that each system has its own design for scalability. Plan early on how to test these integrated systems at a scale higher than the expected peak usage.
5 Don’t forget to evaluate integration tools
Just because nothing solves it all, it doesn’t mean you can’t tie separate existing components together to accomplish what you want. Use your requirements and design phases to evaluate tools that could be a good fit. You might even get lucky and find a solution with almost no custom development.
6 Don’t throw out something just because it’s not on your platform of choice
We have heard it many times where a customer would tell us: “We are a .NET organization” or “We are a Java shop.” The explanation usually goes something along these lines: “It’s too difficult to keep resources that can manage applications from multiple platforms.” It’s a legitimate objection in many cases, but is your organization regularly evaluating the opportunity costs?
7 Don’t underestimate the complexity of data migration
When designing the integration, we recommend you plan to minimize the eventual data migration. When you know what you need to migrate, then try to test it as soon as possible. Bad data migration can ruin a software lunch. It needs to be treated as a priority during the entire life-cycle.
8 Don’t expect all systems to be around forever and be in the same phase of their life-cycle
This is very important. Your systems will change again in the future. Decisions you make in this design phase can greatly reduce the burden of future integrations. Try to have an idea as to how long your systems will be around or when the next major release may happen.