At first, this seems manageable. Until it isn't.
The problem is not necessarily the number of systems. It is the way those systems are connected.
The point-to-point trap
A common approach to integration is to connect systems directly whenever a new connection is needed.
System A talks to System B.
System B talks to System C.
System A also needs information from System C, so another connection is created.
This works perfectly well when there are only a few systems. But as the number of applications increases, the number of possible connections grows rapidly.
And with every new connection comes another piece of logic to maintain.
This creates a familiar problem: integration becomes a collection of individual solutions instead of a coherent architecture.
Changing one system can suddenly affect several other systems. Data is transformed differently in different places. Business rules are duplicated. Monitoring becomes fragmented. And when something goes wrong, it can be difficult to determine where the problem actually started.
The result is an IT landscape that becomes increasingly difficult to change.
Integration should be an architecture, not a collection of connections
The alternative is to treat integration as an architectural layer. Instead of allowing every system to communicate directly with every other system, responsibilities are clearly separated. Systems remain responsible for what they are good at.
Salesforce, for example, can remain the central platform for customer and order management. Suppliers remain responsible for their own product and fulfillment information. A dedicated integration layer takes care of communication, transformation, orchestration, and monitoring.
This creates a much more manageable structure. At Infodation, we used this approach in the procurement automation platform we built for Hallo Nederland.
The architecture combines Salesforce, Azure-based middleware, and OneTrail TPN to connect Hallo with multiple distributors.
The goal was not simply to connect nine suppliers. The goal was to create an integration architecture that could continue to grow.
A canonical data model as the foundation
One of the most important architectural choices is to establish a common data model. Every supplier may represent products, prices, stock levels, orders, shipments, and invoices differently.
If Salesforce has to understand every supplier-specific format, the complexity quickly moves into the core business platform. Instead, the integration layer can translate different external formats into a common, canonical representation.
For example, one distributor might describe available stock in one way while another uses a completely different structure. The integration layer normalizes this information so that the rest of the application does not need to know which supplier originally provided it.
This creates an important separation:
External systems can change without forcing the entire architecture to change with them.
That is a powerful principle when building software that needs to scale.
Standardization reduces complexity
The same principle applies to communication. In the Hallo platform, OneTrail TPN provides a standardized XML-based communication layer for messages such as orders, shipment notifications, invoices, and product information.
This means that the platform does not need a completely different integration mechanism for every distributor. The external complexity is absorbed at the integration boundary.
The internal architecture can remain consistent. This is one of the biggest advantages of standardization: it does not eliminate complexity, but it puts that complexity in the right place.
Middleware as the orchestration layer
A modern integration architecture also needs more than data transformation.
It needs orchestration. In the Hallo solution, Azure middleware provides components such as a canonical product database, a service bus, a fulfillment engine, and monitoring capabilities.
These components allow the platform to coordinate a complete business process rather than simply pass messages from one system to another. Consider what happens when a customer places an order.
The platform needs to determine which supplier can fulfill the order, taking factors such as price, stock availability, and historical delivery performance into account.
Once a supplier has been selected, the purchase order needs to be created and sent.
The system then needs to process acknowledgements, handle updates or cancellations, retrieve shipment information, track deliveries, and eventually validate and match the invoice.
That is no longer just an integration. It is a process. And the architecture needs to support that process from beginning to end.
From integration to process orchestration
This distinction is important. An API integration answers a relatively simple question:
How do I get data from system A into system B?
Process automation asks a much broader question:
What needs to happen across multiple systems to complete the business process?
Those are fundamentally different challenges.
In the Hallo platform, the process runs from:
Quote → Customer Order → Smart Sourcing → Purchase Order → Order Management → Shipment → Delivery → Invoice
Each step depends on information from previous steps and may trigger actions in another system.
A robust integration architecture makes these dependencies explicit and manageable.
Monitoring is part of the architecture
There is another aspect that is often overlooked: visibility. When a process crosses multiple systems, failures are inevitable.
A supplier may not respond. A message may fail validation. An order may be rejected. A shipment notification may contain unexpected data. Without centralized monitoring, troubleshooting becomes a manual investigation across different systems.
With proper monitoring, teams can see what happened, where the process currently stands, and where an error occurred. This is particularly important when automation becomes business-critical.
The more processes a company automates, the less acceptable it becomes to rely on people discovering problems by accident.
Designing for the next supplier, not just the current one
A good integration architecture should make the next integration easier than the previous one. That was one of the important design principles behind the Hallo solution.
The platform was built around reusable components and a standardized integration layer. This makes it possible to add new suppliers without redesigning the entire architecture.
The benefit is not simply technical. It directly affects how quickly the business can expand its ecosystem. Adding a supplier should become a configuration and onboarding exercise rather than a new software development project from scratch.
There is an important nuance here: configuring a supplier in Salesforce can be reduced dramatically, but complete supplier onboarding still involves network enrollment, validation, and going live. The one-minute figure therefore refers specifically to the Salesforce configuration step, not the entire onboarding process.
Architecture creates room for growth
The results of the Hallo implementation illustrate why this matters. The platform connects with 10 distributors and more than 300,000 products. Inventory information is updated hourly, and more than 100 purchase orders were already being tracked end-to-end in the first month.
At the same time, the manual effort per order line was reduced from around 28 minutes to just 2–3 minutes. That is approximately 90% less manual work.
The platform also reduced the number of manual process steps by around 80% and increased operational capacity by a factor of ten.
These numbers are not simply the result of connecting systems. They are the result of designing the integration architecture around the business process.
The real value of integration architecture
Integration architecture is sometimes treated as a technical concern. But its impact is fundamentally a business issue.
A well-designed integration layer allows organizations to:
- add systems without multiplying complexity;
- standardize data across different sources;
- automate processes across organizational boundaries;
- monitor business processes end-to-end;
- reduce manual work;
- make changes without destabilizing the entire landscape;
- and scale operations without scaling manual effort at the same rate.
That is the difference between having integrations and having an integration architecture.
The first connects systems. The second creates a foundation on which the business can continue to build.
Build the architecture before complexity builds itself
Most integration problems do not appear overnight. They emerge gradually.
One API here. One custom script there. One temporary workaround that becomes permanent. Eventually, those individual solutions become the architecture. The better approach is to make the architecture a deliberate choice before that happens.
Define where business logic belongs. Establish a canonical data model. Standardize communication. Separate systems from orchestration. Centralize monitoring. Build reusable integration components.
That creates an IT landscape that is not only connected, but manageable.
And when the business grows, the technology can grow with it.
