Integration Nightmare: The Case Of Super-flexible e-commerce platforms

Freedom comes at a cost, which is not devoting ourselves to what we know well and accustomed to. This is especially true when we are building an e-commerce solution, with its various components being plug-and-play and when we aspire to replace the components at our will. 'Well, it sounds terrific to have plug-and-play components so that I have the freedom to replace any of them when I want!' I hear you saying. But things are not as easy as they seem, even though they appear simple.

Extreme freedom in plug-and-play comes with some nightmarish headaches. Let's look at some of them from a quality and testing standpoint in this article.

Technical Competency

Technologies come and go, so do frameworks and platforms. If you are an application front-end person, I need not tell you. It is highly risky to move to a framework that sounds cool because you will not get continuous and consistent technical support in this flimsy market. To find the right people is a very tough task. Imagine writing a very specific job description asking for a technology whose shelf-life is around two years! What are the chances that you will get specialists in that technology while you are facing deadline pressures to get your product out of the door? How about getting testers for the technology?

Code, Data, and Platform Integration

When you have many-to-many relationships between various components of the stack (even though it is a stack!), it is tough to integrate between the code bases, data, and the platforms. You start with 1-1 integration between two components, you integrate and test it, and suddenly you discover that it breaks some other component! Code, data, and platform integration and testing takes a lot of effort, and every time you move to a new component, you got to do this process again. If you don't do the necessary, you end up with technical debt!

Quality and Testing aspects

We all get excited by the functionality we get with various component plugins, but we don't pause to think about the other pillars of usability, accessibility, performance, and security. How many times we have moved to a new component and then realized that the component does not handle the load required by the application, or a specific security patch not being available for that particular component, or usability of the component being miserable?

What can we do?

One thing is not get too excited about the functionality, and do our due-diligence through thorough testing of the new incoming component on the various pillars, not just the functionality. This testing needs be done right upfront by testers so that we know the suitability of the new component for a specific scenario. It is not sufficient for the developers to do some spot checks and integrate the component to the existing stack because they might miss key aspects as mentioned above. We can call this testing as Component Integration Testing and get it done by dedicated testing team.

The other thing that we can do is to not be exhibit too much freedom in terms of adopting plug-and-play components. This helps a lot in having a competent team for development and testing, avoiding frequent integration nightmares, and prevents retesting components integration with each other frequently. Probably we could have plug-and-play only for a few components of the stack. Which components would be plug-and-play would be left to us and we need to decide that on a case-by-case basis depending on the business needs, team composition, and various other practical factors.

Conclusion

Freedom to pick any component of the application stack is great, but it comes with its own challenges. A balanced and selective approach of picking the components to be plug-and-play, with having a solid test strategy and test team for the replaceable components will solve our integration nightmares.

For more inputs on quality and testing aspects for your organisation, feel free to get in touch with me.