Structure for your integration projects

E2E BRIDGE defines a framework for an agile approach, especially in integration projects. The aim is always to start as quickly as possible with the implementation of the highest priority requirements. The E2E approach model can be summarised in one sentence as follows:

Integrations are separated into pathways and these are then successively implemented or adapted in iterations (sprints) relative to their priority using proven patterns.


Integrations and Pathways

In each integration project systems are linked to each other for the exchange of data or to trigger an action. For example, for the processing of online-shop orders a connection to the ERP system is often necessary, which in turn generates an invoice. Instead of speaking of “shop/ERP integration” and anticipating this in the project plan we differentiate at a more granular level. This is because there is further data in other application scenarios which is exchanged by both systems (customer data, item master data, prices, stock levels, reservations, cancellations & returns etc.). E2E BRIDGE differentiates therefore between integration paths within a single integration project.

Shop/ERP SE1 Shop ERP Oder on-demand / REST call synchronous-asynchronous n 2
Shop/ERP SE2 ERP Shop Item täglich / batch asynchronous-asynchronous n 1
Shop/ERP SE3 ERP Shop Stock on-demand / REST call synchronous-synchronous y aktive / refresh every 5 Min. 1

This method of distribution enables users to prioritize their integration projects in a finely granular way and in the same way to implement, test, deploy and control them in a detail based way. Each path can be implemented and rolled out as an individual service (see Agile Architecture).

Path mapping with patterns

Each integration path has differing requirements for its implementation. A nightly master data synchronisation run will be implemented differently to an on-demand stock level request via cached values. A detail based interface has different requirements from a synchronous REST interface. For example, criteria could be based on the following questions:

  • Should the processing be synchronous or can it be, or must it be, asynchronous?
  • Should, or must, data be cached?
  • Should data mapping be maintainable externally via a UI?

At E2E we know the special characteristics of (nearly) all integration pathways and have developed patterns for them which cover the complexities of these pathways completely. Especially for asynchronous interfaces, E2E BRIDGE has a very powerful mechanism in “PersistentState” models. For many integration pathways we also have alternative patterns ready for use. The most important thing is:

The most important thing:

We can estimate time and costs per integration pathway extremely well and never start from scratch but with a significant head start.

More information on this topic 


Automation support

Automation for continuous delivery: we offer automation support for installation and operation, for full compatibility with continuous delivery platforms (e.g. Jenkins).

> Further information

Agile solution architecture

All our integration solutions follow a micros-services architecture which allows an iterative approach. The deployment of new or adapted services is executed in seconds.

> Further Information

Learn more about the strengths of E2E BRIDGE


Stephan Prinzkosky

Stephan Prinzkosky

Scheer E2E AG
Lautengartenstrasse 12
CH-4052 Basel

T +41 61 27097-10