E-commerce integration, part 3. Growing number of dependencies between apps as an integration challenge

Why a large number of dependencies can be a significant difficulty and a serious challenge

Let’s have a look at the Salesforce scheme, which shows the internal dependencies between different systems while development lasts for years. This picture shows exactly what could happen to the system during its development. The number of links and dependencies between systems is increasing, and at some point, programmers seeing the whole complexity of the system, prefer not to touch it at all. Or they consider replatforming, changing or completely abandoning this system.

Because of the presence of several data exchange points, the presence of complex and sometimes uncontrollable dependencies imposes such massive restrictions that the system becomes unchangeable and unattended. And if you do change it, it can lead to disastrous consequences, to incorrect behavior or even a crash of the system.

Therefore, the huge number of dependencies is a big problem and a big challenge. Every programmer works just with some particular piece of the system and does not see its entire structure at operation. Different standards, data formats and solutions were developed earlier, becoming a legacy or even obsolete. On the client-side there can be both legacy solutions that work on RPC, as well as modern solutions that support RestAPI, GraphQL, XML specifications.

Remember when NASA was recently looking for programmers able to work with assembly languages used in early computing for the Voyager space program? All those guys are now retired. Imagine the same for software modules developed for retail business sometime in the 1970s. Today no one understands or knows how to work with this data format and how to integrate it with modern apps.

Another challenge is the different terminology used in projects. Each system has its own designations, which also differ from company to company. The price on the website can differ dramatically from the “price” cell, which is located in the ERP system or the logistics system, or in the marketing campaigns software.

Corporate specifics also add its two pennies when each business has its own specific terminology, glossaries and definitions within the company. At the time the solution was developed, it was most likely doing for other market conditions and other IT systems. Entities such as retail consumers, suppliers or vendors may differ significantly between the systems.

And the next but not the last challenge is to support all this application diversity that exists in the IT ecosystem. Applications that were deployed initially as small software modules have grown into complex systems over the years, including a set of solutions. These solutions work within the company, between companies, the number of modules, fixes and updates is growing, and all these affect the cost of service and support.

Where is the way out? We, at Virto Commerce, believe modern tools and technologies can simplify the process of building integration and organize this process. The modern tools and technologies can make the term “simple integration” pretty realistic.

Share. Spread tech knowledge & news:

About the author of this article

Oleg Zhuk
Technical Product Owner

Oleg is a leading technologist and has grown professionally from being senior C++ and C# developer to solution architect. He joined Virto Commerce as a Solution Architect was promoted to lead Technical Product Owner. Oleg has leadership and communication skills and has had the opportunity to coach solution architects and share best practices of building great architecture. He holds a degree in mathematics from the Emmanuel Kant State University.