Normalerweise benötigen Unternehmen Middleware, wenn sie den Außendienst mit einer ins SAP ERP (oder auch CRM) integrierten mobilen Lösung ausstatten wollen. Diese sogenannten Zwischenanwendungen vermitteln als neutrale Programme zwischen einzelnen Applikationen und erleichtern Mitarbeitern deren Nutzung. Aber: einige Anbieter behaupten, ihre Lösungen funktionierten auch ohne diese Mittler. Ist Middleware also Schnee von gestern?

Der Begriff "Middleware" ist für viele ein "verbranntes" Wort, das negative Assoziationen auslöst. Oft bedeutet es zusätzliche Kosten für Lizenzen und Infrastruktur, ferner zieht es Betreuungsaufwand nach sich - vor allem im laufenden Betrieb einer mobilen Lösung. Zudem werden aus dem privaten Umfeld Erfahrungen auf den geschäftlichen Alltag übertragen. Hier arbeiten Anwender auf iOS- oder Android-Smartphones und -Tablets - eben ohne Middleware.

Verborgener Problemlöser zwischen Front- und Backend

Nähern wir uns der Situation aus der Vogelperspektive: Der grundsätzliche Aufbau einer mobilen Lösung besteht in der Regel aus der Anwendung selbst, den Quellsystemen, aus denen die Daten kommen und Prozesse gesteuert werden sowie einer Komponente dazwischen. Diese ist dafür verantwortlich, relevante Daten in definierter Menge an die richtigen Anwender zu verteilen, neue Software-Versionen im Falle eines Updates zur Verfügung zu stellen, Daten zu verschlüsseln sowie Datenkonflikte zu offenbaren, wenn im Backend Verbuchungskonflikte aufgrund von Restriktionen entstehen. Gegebenenfalls verarbeitet sie auch Daten vor, um Lastspitzen vom Backend fernzuhalten, damit dieses weiter performant für den Innendienst ist.

Diese Dienste benötigen nicht zwangsläufig eine zusätzliche Hardware-Komponente, die gewissermaßen als Datendrehscheibe zwischen dem mobilen Endgerät und dem Backend steht. Diese Services können im Backend selbst laufen. Aber es sind in jedem Fall eine oder mehrere solcher Komponenten nötig, um diese Dienste zu managen. Eine Lösung gänzlich ohne Middleware ist daher in aller Regel kaum möglich, auch wenn dem Anwender diese häufig verborgen bleibt oder der Name "Middleware" hierfür schlicht nicht in Augenschein tritt.

Die wichtigsten Aufgaben einer Middleware

1. Intelligente Datenverteilung

Die meisten Unternehmen wollen mobile Lösungen auch 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. Der Mitarbeiter bekommt allerdings nur die Datensätze, die er wirklich braucht. Das funktioniert über Datenverteilungsregeln - ein komplexes Regelwerk, dem ein Datenmodell zugrunde liegt. Dieses beschreibt, aus welchen Objekten und aus welchen Datenfeldern die mobile Anwendung besteht und wer nach welchen Regeln welche Daten erhält oder darauf Zugriff hat. Im Ergebnis kommt der Außendienstmitarbeiter dadurch schneller an relevante Daten - etwa den Ansprechpartner oder die Geräte, die der Kunde im Einsatz hat.

2. Datenkonsolidierung

Oft reichen dem Außendienstmitarbeiter die Daten aus dem SAP-Systemumfeld nicht aus. Muss er beispielsweise ein ihm unbekanntes Gerät reparieren, benötigt er 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 zwingend Teil des SAP-Systems sein müssen. Somit lassen sich Daten aus mehreren Quellen zusammenfassen und in nur einem Synchronisationsprozess dem Mitarbeiter zur Verfügung stellen.

3. Performance

Eine hohe Geschwindigkeit ist das A und O einer mobilen Anwendung, hängt doch die Anwenderakzeptanz maßgeblich an der Performance - niemand akzeptiert nachhaltig eine Anwendung wenn sie zu langsam ist. Dies gilt für den Datenzugriff (Suche von Geschäftspartnern, Aufträgen oder in angefügten Dokumenten), aber zum Beispiel 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 erhält das SAP-Backend signifikant mehr Last, wenn - etwa morgens bei Arbeitsbeginn - eine große Anzahl von mobilen Mitarbeitern darauf zugreift und Daten nach komplexen Regeln abruft. Ein komplexes Thema also, welches intelligente Lösungen erfordert, für die mobile Anwendung selbst sowie für das Backend. Eine Middleware kann hierfür Daten im Vorfeld verarbeiten und so zu einer Entzerrung führen, auf dem Client wie auch im Backend. Lastspitzen treten somit erst gar nicht auf und Innen- sowie Außendienst können produktiv(er) arbeiten.

4. Sicherheit

Durch Verlust des Endgeräts oder auch durch einen Wechsel des Mitarbeiters zum Wettbewerb können Sicherheitslücken entstehen, wenn der Zugriff auf Daten weiterhin möglich ist. Deswegen sollten dem Außendienstmitarbeiter nur genau die Daten "mitgegeben" werden, die er wirklich benötigt. Sicherheitsanforderungen im Kontext mobiler Anwendungen lassen sich mit Lösungen für Mobile Device Management erfüllen. Middleware unterstützt aber auch hier: auf der Prozessseite durch Authentisierungs- sowie Verschlüsselungsverfahren, so dass durch Zugriffsbeschränkungen bereits präventiv vorgebeugt wird.

5. Konflikthandling (Rule Engine)

Wenn offline auf mobilen Datenbeständen gearbeitet wird, können (im Nachhinein) Konflikte bei der Verbuchung auftreten, wenn zwischenzeitlich der Innendienst auf denselben Datensätzen gearbeitet hat. Ein kontextsensitives Konflikthandling (d.h. die Fachlichkeit des Geschäftskontextes muss berücksichtigt werden), welches verschiedene Middleware-Lösungen unterstützen, ist erforderlich. Der nüchterne Mechanismus, dass derjenige Anwender, der den Datensatz zuletzt geändert hat, "gewinnt", und die älteren Daten somit überschrieben werden, reicht allein meist nicht aus, da wertvolle Daten verloren gehen könnten.

6. Lastentzerrung

Über je mehr Anwender ein Unternehmen verfügt, desto größer muss das SAP-System infrastrukturell ausgeprägt sein, was natürlich mit Kosten verbunden ist. Eine Middleware kann eine Lastentzerrung herbeiführen, indem die Daten bereits auf einer Meta-Ebene in einer Art Daten-Queue beispielsweise vor Arbeitsbeginn vorgehalten werden. Deswegen unterscheidet man die Datensynchronisation zwischen mobilem Endgerät und Middleware von der Datenreplikation (Vorverarbeitung) zwischen Middleware und Backend. Im Effekt können dadurch Infrastrukturkosten reduziert und zudem die Performance gesteigert werden.

7. Softwareverteilung

Fehler in Anwendungen sind ein wichtiges Thema. Daher müssen Unternehmen Updates schnellstmöglich an alle Mitarbeiter verteilen können - beispielsweise über eine Middleware. Die Aktualisierung kann "Over-The-Air" erfolgen oder durch manuelle Freischaltung des Anwenders. Bei einer zentralen Verteilung durch einen Administrator könnten aber wichtige Daten überschrieben werden, die noch nicht synchronisiert waren, daher ist auch hierfür eine Middleware sinnvoll, die den Geschäftskontext differenziert.

Argumente pro und contra Middleware

Für Regionen mit mangelnder Netzabdeckung oder nur sehr langsamer Internetverbindung ist eine Middleware eigentlich unumgänglich. Denn Mitarbeiter in Service und Instandhaltung benötigen Aspekte wie Offlinefähigkeit oder ältere Daten. Rein theoretisch könnten sie online im Webbrowser arbeiten - das dauert jedoch länger und sobald offline gearbeitet werden muss, treten Probleme auf.

Dem gegenüber steht etwa die mobile Lagerlogistik - einer der häufigsten mobilen Anwendungsbereiche neben Service, Instandhaltung und Vertrieb. Hier müssen Barcodes über eine lange Distanz in einem Lager gescannt werden, um beispielsweise Lagerplätze von Produkten zu verändern. Dank geeigneter WLAN-Ausleuchtung sowie einfacher Datenstrukturen funktioniert dies online meist problemlos. Eine Middleware ist hierfür meist nicht nötig. Hier 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 von mobilen 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. Auch die Wahl der Endgeräte spielt eine Rolle: manche Unternehmen legen sich langfristig fest, andere wollen lieber flexibel bleiben.

Diese Fragen sollten sich Unternehmen stellen, wenn sie über Middleware im Kontext mobiler SAP-Anwendungen nachdenken:

• Läuft die Lösung auch offline oder nur online? Wie sieht das SAP-Integrationskonzept aus? Wird eine Middleware benötigt oder nicht?

• Wie schlank lässt sich diese ausprägen - vor allem hinsichtlich Kosten und Betriebsaufwand?

• Wo wird die Middleware betrieben? Im eigenen Rechenzentrum oder extern, etwa in der Cloud?

• Inwieweit ist die Middleware abhängig von den SAP Backend Releases (Folgekosten für Release-Wechsel)?

• Wie wird die Middleware lizenziert - was kostet diese initial im Erwerb und während der Betriebsdauer (TCO)?

• Welche Kompetenzen werden für den Betrieb benötigt - welche Freiheitsgrade bietet die Middleware in technischer und fachlicher Hinsicht?

• Wie lange wird die Middleware vom Hersteller als Softwareprodukt gewartet?

• Welche Standardschnittstellen liefert diese bereits auf fachlicher Ebene?