How to start an Integration project
An integration project usually aims to improve the networking of an existing system landscape by connecting systems, services, applications and end devices with the aim of synchronizing data, streamlining processes and increasing their efficiency and maintainability.
Before you start with the actual implementation of your integration project, it is worth making some preliminary considerations and adapting the implementation of the project to the actual business requirements. We would like to share our many years of project experience with you here and give you some tips for sensible project planning.
Example: E-Commerce Scenario
Let's look at an e-commerce scenario as an example:
Our example company operates an online and a stationary business with a connected point of sale system and a payment provider. An ERP, a CRM, a logistics system and a supplier system are also part of the system landscape. Some of these systems are interconnected, for example point-to-point - or not yet at all.

The Integration Path Concept
Our integration professionals work with the integration path concept. An integration project consists of one or more integrations, which can comprise one or more integration paths, which in turn can consist of various partial integration paths:

Start by identifying the different levels of your planned integration project.
Integration Project
The project itself is the highest level. It consists of the entire data exchange between the systems within the scope of the project.
The questions you need to answer for this level:
Which systems need to exchange data with which other systems?
Does the data exchange only take place in one direction or in both/multiple directions?

Integration
The next lower level is one integration. It represents one data exchange between two systems.
The question you need to answer for this level:
Which systems exchange data?

Integration Path
Two systems can exchange very different information. In addition to the obvious integrations, e.g. articles and stock are sent to the online store, reservations and orders are sent back to the ERP, there are many more characteristics that describe such integration paths.
The questions you need to answer for this level:
What data do the systems involved exchange with each other?
What types of data are involved?
In which direction does data exchange take place?
At what frequency is data exchanged?
What triggers the data exchange?
Is master data or transaction data exchanged?
Which endpoint technology is used?
e.g. SQL, File/FTP, SOAP, REST, MQTT, S3…
Is the data exchange synchronous or asynchronous?
Is the data pushed or pulled?

All of this characterizes your integration path. And identifying these characteristics also helps you to plan your integration project.
Partial Integration Path
In some cases, it may make sense to break down the integration paths even further into partial integration paths, e.g. if there is a cache in between that caches inventory data, which is regularly refreshed by one side and queried by the other side.
Sometimes such details only become apparent during the sprints.

Project Planning
Why do we recommend to use the integration path approach to plan a project and track project progress? Because the granularity of the integration path level facilitates the planning, implementation and deployment of isolated services.
Once you have identified the integrations and the necessary integration paths, you can easily begin planning your project.
Now is the time to think about the concrete procedures in the project and the time planning:
Start by estimating the effort required to implement each individual integration path.
Next, discuss the importance of the various integration paths. This is best done using the various business drivers: What are the priorities from a business perspective?
Example: A new cash register system is to be introduced.
The most important thing is that the cash register knows the items and prices so that customers can go to the checkout and the cash register recognizes the barcode, knows what product it is, and how much it costs. The store can sell products and collect money. This is therefore the highest priority.
Priority 2 could be to support things such as loyalty cards and discount campaigns.
Priority 3 could then be to automatically scan receipts, make the corresponding inventory entries, and update the data warehouse so that the purchasing department can see what sells best etc.
Once the business priorities have been identified, the necessary integration paths that must be implemented in order to achieve a priority can be selected and bundled. This results in a group-based prioritization of the integration paths.
Now you can display the project workflow on a timeline and plan the project, for example using sprints with a fixed duration or scope.

Example: Our sample project plan shows the identified integrations with their various integration paths on the left. In the middle, these are prioritized according to various business factors. On the right, the sprint planning then goes into detail:
In the first sprint, only integration paths from the first priority group will be implemented. Path 2.1 is not covered here, as all others belong to Integration 1. This way, only two system owners are involved in the first sprint, which simplifies implementation, as fewer people need to come together to specify and implement the requirements in detail.
It has become apparent that path 2.1 is too extensive. It will therefore be divided into two halves and planned in two different sprints.
etc.
This approach has proven itself and allows you to plan the project schedule and test phases with relative reliability. Once the first integration paths are complete and available in the test environment, application owners, power users, or end users can already start testing. It is helpful for them to know approximately when this will be the case.
Project management can be easily implemented in an Excel spreadsheet. Another option is to use a ticket system such as Atlassian Jira.
Implementation in PAS
In PAS, integration solutions are built in a microservices architecture. Typically, an integration path is implemented with a microservice.
BEFORE

AFTER

The implementation of microservices is done in the PAS Designer. For more information on setting up a project in Designer, refer to PAS Modeling Guidelines.
When creating a microservice, we recommend writing a versioned service description in the service properties that contains the service requirements, acceptance criteria, and elements to be implemented. For further details refer to the following documentation pages: