Scheer PAS Model Driven Integration

The innovative Low-Code integration platform

Do your IT systems work perfectly together?

If not, significant potential for optimization is available to your company. This is because intelligently linked IT systems are more transparent and they can be adapted much more quickly and with greater flexibility. At the same time vulnerability to failure and down time is reduced.

The smart networking of all systems, processes and also people within a company is one of the key factors for success in this age of digitization.

We are the team of experts you need when dealing with model driven IT integration. For over 20 years we have been working on complex integration projects and, thanks to the low-code approach we adopt, provide agility, speed and transparency to our customers in over 50 countries.

transparency

Transparency – the model driven approach from Scheer PAS delivers unique transparency over your processes, systems and data. The foundation for this lies in our use of the graphic modelling languages UML and BPMN. The models function as a common language, understood quickly and without problem by all those involved in your company.

fast-forward

Speed – the adapters we use run natively and therefore with high levels of performance. Every web-service communication and associated processing is compatible with practically every other protocol supported. As the micro-services are executed in our own process room down times are reduced significantly. In this way we achieve high levels of stability for the entire solution and avoid a “single point of failure”.

secure-shield

Stability – the system is mature and proven in many implementations in practice. Model-driven system integration offers many security features. For example, the transaction sequencing logic is mapped in UML state machines. Furthermore, a “history state” can preserve the entire history of condition changes and, in case of failure, this can be accessed again via a retry signal. Processing can start again at exactly the same point at which the error had previously occurred. Furthermore, each micro-process runs as an independent operating system process. The increase in requirement for resources as complexity increases is therefore linear. In comparison with a traditional information infrastructure only a fraction of the server resources are required. This way you not only achieve improved system stability but also greater cost predictability.

move

Agility – comes from the low-code approach we adopt and the use of a micro-service application architecture. You will no longer have any down time when new or changed services are launched. The requirement for regression tests is minimal and furthermore you can execute most changes yourself at any time.

What is system integration?

Integration is the connection of an individual element into the larger whole. In cases of system integration (also known as IT integration) a subsystem, or module, is integrated into the larger system. A decisive factor in integration is that the systems are connection with each other and into each other.

The challenges in system integration are to be found in the planning, conception, integration and launching of complex IT system solutions. The implementation follows mostly be means of an integration platform, or middleware.

Why is the integration of IT systems important?

Many companies can hardly maintain an overview of the ever increasing numbers of software and applications. Upwards of a certain size, IT landscapes in which individual systems are connected via multiple and different interfaces begin to show problems in relation to transparency and the connection of new systems becomes mostly difficult and slow. In addition, with the addition of every new system, the instability of the entire IT landscape increases.

If a centralized integration layer is implemented which functions as a connecting arm between the system, such problems can be solved.

What is middleware?

The term middleware describes the integration layer which enables the differing distributed IT systems and applications to work together. The middleware assumes the role of a translator which regulates the exchange of data between differing systems and applications. Like any good translator the integration platform disregards the differences between the various languages, or in this case the formats and protocols. The complexity is encapsulated and therefore hidden.

The following example from the retail sector illustrates the procedure described: The middleware enables the transfer of customer orders from a Magento online shop to an SAP system. The benefit: Magento does not have to map the data formats and transfer protocols of the SAP system. The middleware takes the new order via a SOAP interface from the online shop, transforms it and executes the secure transfer of the information as an iDoc to SAP. It doesn’t matter at all if the SAP system is temporarily offline. If the customer returns the goods to one of the branches the middleware ensures that the returned goods can be registered by the till software and the stockholding is very quickly updated to include the item for sale again online.

Typically, middleware is based on an integration infrastructure such as an Enterprise Service Bus (ESB). Based on this infrastructure iterative integration solutions can be built. The middleware is comprised of these solutions in their entirety.

When does middleware make sense?

Putting in middleware is similar to kitting out a conference room. For small groups as a rule it will be sufficient to have one multi-plug extension lead and a LAN hub. Meetings with two or three people can be productive with this level of equipment. Should additional participants be included then it quickly becomes more probable that further equipment will need to be organized (hub, adapter, cables etc.) and installed. This takes up time actually intended for the conducting of the meeting agenda. With 20 participants our room is no longer suitable for our requirements, cabling the participants takes a disproportionate amount of time and the work for which the participants have come together begins only after a long delay. If this happens regularly then one would be well advised to invest in appropriate infrastructure.

It is the same with middleware. It makes sense in particular if the amount of different distributed software and applications reaches a critical mass. If you only ever connect the same two or three systems with the same technology, such as SOAP or SQL, then you can probably function productively without middleware. If, however, you are using ever more systems and need to connect these with different interfaces such as SOAP, SQL, REST or iDoc then investing in middleware makes sense. As long as it has been successfully integrated it masks the complexity of your IT landscape and makes the quick integration of new systems and business processes possible.

Which scenarios justify the procurement of middleware?

There are three general dimensions which can be used to define your scenarios.

 

Endpoints – Which protocols do I have?


The systems you need to integrate run on-premise, in the cloud, on mobile end-devices or on smart devices. Typically in each case differing communication protocols will apply. SQL, iDOc, EDI and FTP run on-premise. In the cloud you will find SOAP, REST or ODATA and AMPQ for your smart devices. If middleware is now used, the complexity of your protocols is hidden. The systems to be integrated can simply be connected with your protocol in the middleware.

Deployment – Which network topology do I have?


If the systems you need integrating are distributed across a complex network – on-premise, cloud or mobile devices – the middleware creates transparency. It provides connectors that allow a “local” connection for your systems. The result is that aspects such as firewalls and DMZ are no concern for these systems.

The middleware must naturally be operated somewhere. Ideally, your integration platform should be located close to your systems. Appropriate solutions therefore are on-premise installations, operation in the cloud as IPaaS, embedded solutions or a mix of these models.

 

Integration patterns – what do I want to integrate?


Here we differentiate roughly between four variants: data integration, process integration, application integration and B2B scenarios.

Data integration is about the synchronization of data across multiple distributed systems. For example product master data between ERP and online shop or ETL scenarios with corresponding monitoring.

Process integration is about the integration of a customer order across the distributed systems: online shop, ERP. Logistics, payment, CRM and the monitoring of the overarching process.

Application integration is about the seamless integration of distributed applications. For example the provision of on-premise ERP functionality or data on demand for a tablet app used by technical field staff.

B2B scenarios such as the integration of systems of record with those from B2B partners by means of electronic data transfer (EDI).

Each of these scenarios carries within it differing challenges and each challenge justifies the use of middleware. Should you even have a crossover at multiple points with your scenarios then middleware is a worthwhile investment for your company.