In a best-of-breed environment a good integration between the different software solutions is of great importance. Usually, this is taken care of with a separate 'omni-channel integration layer.
Apart from the choice for the correct software-solution, design choices for integration will need to be made. Within most current omni-channel architectures this is one of the most difficult and important aspects. Before going deeper into the omnichannel integration layer, we will first consider the future of integration, and the current integration-design choices for key data types.
In an ideal architecture, data is only defined once and stored in one place. Assuming that not all necessary functionality can be provided within a single application, this means that multiple applications should work on a single database. This requires a high degree of standardization and openness of applications, which in today's software market is not yet sufficiently support among different applications.
As an example, the ERP system from software brand X would be using the same customer database as the CRM system from software brand Y. This type of architecture is already supported by major software parties, where the different modules and applications of the software work on the same database.
In terms of technology, this concept will probably prove to be feasible or already is. To what extent it is however practically feasible to let software parties support each other's systems (or create open standards), depends mainly on other aspects that frequently play a role in standardization, such as organizational aspects, monopolies and commercial interests, and the monitoring of consistency of international agreements.
A 'second-best' architecture is an architecure where web applications (services) call in other applications in order to obtain certain information. A webshop application will ask the logistics application for the current stock position, to obtain a certain product as soon as a consumer places it in his shopping cart. This type of integration is generally well applicable to limited amounts of data (transaction-based, enabling the search of few products' stock positions, though not the stock positions of all products visible in a search page or while navigating through a catalog).
In the case of larger amounts of data, a batch-wise integration is usually the best solution with today's technology. The webshop then periodically receives all current stock levels and uses this data to show availability. Only when a single item is placed in the shopping cart, the web service is invoked that checks current stock levels real time for a final check of availability.
In both situations, the integration is simplified when the different systems use the same data model. Think of the way in which products and product variants are related to each other, to see how a system thhandles companies with multiple locations, or that product data may differ on country level. The more uniformity has been achieved in this, the easier integration and mapping of messaging will happen.
The best method of integration may vary by data type (product, price, stock, customer and transaction data) and by management or information analysis.