Agile approach model

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.

agiles-vorgehen

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/ERPSE1ShopERPOderon-demand / REST callsynchronous-asynchronousn2
Shop/ERPSE2ERPShopItemtäglich / batchasynchronous-asynchronousn1
Shop/ERPSE3ERPShopStockon-demand / REST callsynchronous-synchronousyaktive / 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 

prozess

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

loesungs_architektur

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

 

transparency
agility
Trusted Technology
Stephan Prinzkosky

Stephan Prinzkosky

Scheer E2E AG
Management
Lautengartenstrasse 12
CH-4052 Basel

T +41 61 27097-10
Contact