September 27, 2016

Eight Critical Mistakes to Avoid During a Custom Integration Project

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.

Communication between all parties working on the solution is paramount! Make sure the strategic value of the solution is made clear all the way down to the implementer. That will greatly help in reducing the risk of not getting what you need.

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.