Companies need middleware if they want to equip their sales force with a mobile solution integrated into SAP ERP or CRM - in principle. However, some providers claim that their solutions also work without these 'intermediate applications'. So is middleware a thing of the past? For many IT managers, the term 'middleware' makes their stomach ache. They fear additional costs for licenses and infrastructure as well as high costs for mobile solutions. But what is the reality?

A mobile solution usually consists of the application itself, the source systems from which the data comes and processes are controlled, and a component in between. This is responsible for distributing relevant data in a defined quantity to the right users and making new software versions available in the event of an update. It also encrypts data and reveals data conflicts if posting problems arise in the backend due to restrictions.
Corresponding services that can be accessed on the move do not necessarily require an additional hardware component that acts as a data hub between the mobile device and the backend. They can run in the backend itself. But in any case, one or more such components are required to manage these services. A solution entirely without middleware is therefore hardly possible as a rule, even if this often remains hidden from the user or the name middleware simply does not come to mind.

Middleware handles a wide range of tasks

So what are the most important tasks of middleware? Most companies also want to use mobile solutions offline in order to guarantee the availability of data, logic and persistence for the user at all times. To achieve this, the data must be distributed and synchronized. However, employees only receive the data records that they really need. This works via data distribution rules - a complex set of rules based on a data model. This describes which objects and data fields make up the mobile application and who receives or has access to certain data. As a result, the sales representative can access relevant information in their own system more quickly, for example about devices that the customer is using or contact details of contact persons.

In some cases, the data from the SAP system environment is not sufficient for the sales representative. For example, if they need to repair an unknown device, they need additional data sources - in this case a solution database that is often not available in SAP. The SAP Mobile Platform - SAP's strategic middleware for mobile working - can integrate different data sources that do not necessarily have to be part of the SAP system. This means that data from multiple sources can be combined and made available to employees after just one synchronization process.

Speed is the be-all and end-all of a mobile application, as user acceptance is largely dependent on performance. This applies to data access, but also to the processing of plausibility checks, which are usually derived dynamically from the SAP backend and should already be available within the mobile application. In addition, the SAP backend is subjected to a significantly higher load if a large number of mobile employees access it and retrieve data according to complex rules, for example when they start work in the morning. Middleware can process data in advance for this and thus lead to an equalization, both on the client and in the backend. As a result, peak loads do not occur in the first place and office and field staff can work more productively.

Greater safety and distributed loads

If the end device is lost or the employee moves to a competitor, security gaps arise if access to sensitive data is still possible. For this reason, field staff should only be 'given' the information they really need. The security requirements in the context of mobile applications can be met with solutions for mobile device management. But middleware also provides support here: it creates access restrictions and prevents unauthorized use through authentication and encryption procedures on the process side.

When working offline on mobile data sets, conflicts can arise in retrospect during posting if office staff have worked on the same data sets in the meantime. Context-sensitive conflict handling, which is supported by various middleware solutions, is required. The simple mechanism that the user who last changed the data record 'wins' and the older data is thus overwritten is usually not sufficient on its own, as valuable data could be lost.

For mobile applications, middleware coordinates data distribution or consolidation.

© Axians IT Solutions

The more users a company has, the larger the SAP system must be in terms of infrastructure, which entails corresponding costs. Middleware can equalize the load by storing the data at a meta level in a type of data queue, for example before work begins. As a result, infrastructure costs can be reduced and performance increased.

Errors in applications are an important issue. Companies must therefore be able to distribute updates quickly to all employees - for example via middleware. The update can be carried out 'over-the-air' or by manual activation by the user. However, central distribution by an administrator could overwrite important data that has not yet been synchronized. Middleware that differentiates the business context is therefore also useful here.

Requirements vary

For regions with poor network coverage or only a very slow internet connection, middleware is basically unavoidable. This is because employees in service and maintenance depend on good offline capability or access to older data. In theory, they could work online in a web browser - but this takes longer and problems arise as soon as they have to work offline.

On the other hand, there is mobile warehouse logistics - one of the most common mobile application areas alongside service, maintenance and sales. Here, barcodes have to be scanned over a long distance in a warehouse in order to change product storage locations, for example. Thanks to suitable WLAN coverage and simple data structures, this usually works online without any problems. Middleware is not required for this. Hybrid solutions are ideal here, where the actual application runs offline on the end device and the data is only updated later.

As you can see: Before introducing mobile applications, these points should be discussed with the solution provider or a service provider. The requirements vary depending on the area of application. Many rules can be automated on the basis of best practice examples - such as the manual updating of data conflicts. The choice of end devices also plays a role: some companies make a long-term commitment, others prefer to remain flexible.

Author:
Jens Beier is Division Manager SAP Solutions & Technology at Axians IT Solutions