Die Grundidee wirkt simpel: Sogenannte Zwischenanwendungen vermitteln als neutrale Programme zwischen einzelnen Applikationen und erleichtern Mitarbeitern deren Nutzung. Aber einige Anbieter behaupten, ihre mobilen Lösungen funktionierten auch ohne diese Mittler – und rennen damit nicht selten offene Türen ein. Viele IT-Verantwortliche fürchten zusätzliche Kosten, etwa für Lizenzen und Infrastruktur, und weiteren Administrationsaufwand. Middleware steht also gemeinhin für Probleme, auf die man lieber verzichtet. Aber wie sieht es in der Realität aus?

Eine mobile Lösung besteht in der Regel aus der Anwendung selbst, den Quellsystemen, die die Daten liefern und die Prozesse steuern, sowie einer Komponente dazwischen – der Middleware. Diese verteilt relevante Daten in definierter Menge an die richtigen Anwender und stellt neue Software-Versionen im Falle eines Updates zur Verfügung. Darüber hinaus verschlüsselt sie Daten und offenbart Datenkonflikte, wenn im Backend Verbuchungsprobleme aufgrund von Restriktionen entstehen.

Diese Services können im Backend selbst laufen. Sie benötigen nicht zwangsläufig eine zusätzliche Hardware-Komponente, die als Datendrehscheibe zwischen dem mobilen Endgerät und dem Backend – also hier SAP ERP oder CRM – steht. Aber es sind in jedem Fall eine oder mehrere solcher Komponenten nötig, um diese Dienste zu organisieren. Eine Lösung völlig ohne Middleware ist daher in aller Regel kaum möglich, auch wenn dem Anwender diese häufig verborgen bleibt oder der Name “Middleware” dafür nicht in Erscheinung tritt.

Hauptsache die Performance stimmt

Was sind also die zentralen Aufgaben einer Middleware? Die Anwenderakzeptanz hängt maßgeblich von der Performance einer mobilen Anwendung ab. Deshalb ist Geschwindigkeit hier das A und O. Dies gilt für den Datenzugriff, aber auch für die Verarbeitung von Plausibilitätsprüfungen, die sich meist aus dem SAP-Backend dynamisch ableiten und bereits innerhalb der mobilen Anwendung verfügbar sein sollen.

Zudem wird das SAP-Backend signifikant mehr belastet, wenn – etwa morgens bei Arbeitsbeginn – eine große Anzahl von mobilen Mitarbeitern darauf zugreift und Daten nach komplexen Regeln abruft. Eine Middleware kann hierfür Daten im Vorfeld verarbeiten und so den Client wie auch das Backend entlasten. Lastspitzen treten nicht auf und Mitarbeiter können produktiver arbeiten.

Die meisten Unternehmen wollen die mobilen Lösungen ebenso offline nutzen, um die Verfügbarkeit der Daten sowie Logik und Persistenz für den Anwender stets zu garantieren. Dafür müssen die Daten vorher verteilt und synchronisiert werden. Jeder Mitarbeiter bekommt allerdings nur die Daten, die er wirklich benötigt. Das funktioniert über komplexe Datenverteilungsregeln, die auf einem Datenmodell beruhen. Dieses beschreibt, aus welchen Objekten und Datenfeldern die mobile Anwendung besteht und wer nach welchen Regeln bestimmte Daten erhält oder darauf Zugriff hat.

Passende Synchronisierung schützt Daten

Manchmal reichen dem Außendienstmitarbeiter die Daten aus dem SAP-Systemumfeld selbst nicht aus. Wenn er beispielsweise ein ihm unbekanntes Gerät reparieren muss, braucht er dafür weitere Datenquellen – in diesem Fall eine Lösungsdatenbank, die häufig nicht im SAP vorzufinden ist. Die SAP Mobile Plattform – die strategische Middleware der SAP für mobiles Arbeiten – kann unterschiedliche Datenquellen integrieren, die nicht unbedingt Teil des SAP-Systems sein müssen. So lassen sich Daten aus mehreren Quellen zusammenfassen und stehen dem Mitarbeiter nach nur einem Synchronisationsprozess zur Verfügung.

Wenn der Innendienst auf Datenbeständen gearbeitet hat, auf denen gleichzeitig offline mobil gearbeitet wurde, können im Nachhinein Konflikte bei der Verbuchung auftreten. Ein kontextsensitives Konflikthandling, das verschiedene Middleware-Lösungen unterstützen, ist erforderlich. Der Mechanismus, dass derjenige Anwender, der den Datensatz zuletzt geändert hat, “gewinnt”, und die älteren Daten somit überschrieben werden, reicht allein meist nicht aus. Wertvolle Daten könnten so verloren gehen.

Durch Verlust eines Endgeräts oder durch den Wechsel eines Mitarbeiters zu einem Wettbewerber entstehen Sicherheitslücken, wenn der Zugriff auf sensible Daten weiterhin möglich ist. Deshalb sollte der Außendienstmitarbeiter nur genau die Informationen erhalten, die er wirklich braucht. Durch Authentisierungs- sowie Verschlüsselungsverfahren auf der Prozessseite schafft Middleware Zugriffsbeschränkungen und beugt unerlaubter Nutzung vor.

Vom Einsatzgebiet hängen die Anforderungen ab

In Regionen mit mangelnder Netzabdeckung oder sehr langsamer Internetverbindung ist eine Middleware eigentlich unumgänglich. Denn Mitarbeiter in Service und Instandhaltung sind auf gute Offlinefähigkeit oder den Zugriff auf ältere Daten angewiesen. Theoretisch könnten sie online im Webbrowser arbeiten – das dauert jedoch länger und sobald sie offline arbeiten müssen, treten Probleme auf.

Anders sieht es beispielsweise bei der mobilen Lagerlogistik aus – einem der häufigsten mobilen Anwendungsbereiche neben Service, Instandhaltung und Vertrieb. Hier müssen Barcodes über eine große Distanz in einem Lager gescannt werden, um beispielsweise Lagerplätze von Produkten zu verändern. Dank geeignetem WLAN und einfacher Datenstrukturen funktioniert dies online meist problemlos. Eine Middleware ist hier nicht nötig. Es bieten sich hybride Lösungen an, bei denen die eigentliche Anwendung offline auf dem Endgerät läuft und die Daten erst später aktualisiert werden.

Man sieht: Vor der Einführung mobiler Anwendungen sollten diese Punkte mit dem Lösungsanbieter oder einem Dienstleister diskutiert werden. Je nach Einsatzgebiet variieren die Anforderungen. Anhand von Best Practices lassen sich viele Regeln automatisieren, etwa die manuelle Nachverbuchung von Datenkonflikten.