Suchen

Schlank und mobil im Frontend – fett und superschnell im Backend Neuer Schwung mit SAP HANA und SAP Mobile

Autor / Redakteur: Hinrich Mielke / Ulrike Ostler

SAP propagiert „SAP Mobile“ und „SAP HANA“ als eine der entschiedensten Innovationen der vergangenen Jahrzehnte. SAP-Co-CEO Hagemann Snabe geht sogar so weit, den damit einhergehenden Paradigmenwechsel mit dem Start der legendären Software R3 zu vergleichen. Wie ist diese Aussage zu verstehen? Und was kann HANA?

Firmen zum Thema

Wer mobile Business will, landet im Backend fasst zwangsläufig bei In-Memory-Techniken - SAP Mobile findet SAP HANA.
Wer mobile Business will, landet im Backend fasst zwangsläufig bei In-Memory-Techniken - SAP Mobile findet SAP HANA.
(Bild: Frank Peters/Fotolia.com)

Was ist so revolutionär an HANA und SAP Mobile, dass sich diese auch auf den Arbeitsalltag auswirken wird? Wie hängen SAP HANA und Mobile zusammen? Und wie profitieren SAP-Kunden vom Zusammenspiel der neuen Technologien?

Mit der Integration von Smart-Phones und Tablets in den Berufsalltag wurde ein massiver Trend zur Mobilisierung von Business Prozessen angestoßen. Produktivitätszuwächse und die Reduktion von Prozesslaufzeiten rechtfertigen häufig Investitionen in dafür notwendige Technologien.

Ein Bestellvorgang, der auf herkömmlichen Weg mehrere Tage dauerte, wäre heutzutage undenkbar. Ebenso eine Laufzeit von einigen Tagen für das Anlegen eines neuen Users. Es gibt also keinen Grund mehr dafür, dass prozessinvolvierte Mitarbeiter zur Erteilung einer Freigabe am Schreibtisch sitzen müssen. Oder doch?

Geänderte Rahmenbedingungen

Das Frontend wandert vom Schreibtisch, mit fester und breitbandiger Anbindung, in das Auto, den Zug oder einen Konferenzraum an einem beliebigen Ort. Hier ist es oftmals schmalbanding mit geringem Durchsatz und hoher Latenz angebunden, hat einen kleinen Bildschirm und keine vollwertige Tastatur.

Aus dieser Situation resultieren hauptsächlich zwei Anforderungen. Zum einen gilt es die durch den Übertragungsweg bedingt hohen Antwortzeiten mit Rechenleistung wieder auszugleichen und zum anderen die Userinterfaces Anwendergerecht anzupassen.

Die 1:1 Umsetzung einer Desktopanwendung auf ein mobiles Endgerät ist dabei nicht zielführend. Ebenso wenig wie eine für den Desktop designte „Webanwendung“, die dann einfach im Browser auf dem mobilen Endgerät aufgerufen werden soll.

Das Backend muss Leistung bringen

SAP selbst bietet hier von Haus aus verschiedene Lösungen zur On- und Offline Nutzung an. Eine wesentliche Voraussetzung für den zielführenden Einsatz ist jedoch, dass ein sehr leistungsfähiges Backend vorhanden ist. Dies aus drei Gründen:

  • 1. Die Informationen müssen auf den Punkt genau für einen kleinen Bildschirm ausgewertet und aufbereitet sein. Eine lange Liste, in der erst geblättert werden muss, wird von einem mobilen Anwender nicht akzeptiert werden. Darüber hinaus verfügen mobile Endgerät oft nicht über ausreichend Rechenleistung um aufwändige Darstellungsvarianten in vertretbarer Zeit verarbeiten zu können. Diese Aufbereitung ist jedoch nicht trivial. Je weniger Daten angezeigt werden sollen, desto präziser muss vorher extrahiert werden.
  • 2. Mit der zunehmenden Datenmenge durch das „Internet of Things“, der Digitalisierung des Alltags und der automatisierten Betriebsdatenerfassung nimmt das Datenwachstum massiv zu. Dies sind zunehmend Daten die sich nicht durch herkömmliche Reports auswerten lassen, z.B. Blogeinträge, GPS-Positionen oder auch Bilder mit Kommentaren – mit Folgen für den Aufwand der Auswertung.
  • 3. Die technischen Einschränkungen der Anbindung über die Mobilfunkschnittstelle des mobilen Endgerätes müssen kompensiert werden. Die Zeit, die bei der Übergabe zum mobilen Telekommunikationsdienstleister und bei der Funkübertragung verloren wird, muss das Backend wieder aufholen. Weitere Zeitverluste resultieren aus der notwendigen Verschlüsselung der Daten – denn anstelle eines sicheren Firmen-Intranet fließen Unternehmensdaten jetzt in einem nicht exklusivem 3’rd Party Netzwerk und einer per se unsicheren Mobilfunkschnittstelle.

Zusammenfassend ist eine Initiative zur mobilen Nutzung von Business-Prozessen ohne SAP HANA im Backend vergleichbar mit der Entwicklung von neuartigen Flugzeugen ohne entsprechende Anpassung der Flughäfen - also wenig zielführend.

Warum ist SAP HANA so schnell?

Leistung im Backend muss nicht gleichbedeutend sein mit einer Steigerung der Server-Last.
Leistung im Backend muss nicht gleichbedeutend sein mit einer Steigerung der Server-Last.
(Bild: Realtech)
In-Memory-Datenbanken versprechen eine exorbitante Geschwindigkeitssteigerung beim Zugriff auf Daten. Rein rechnerisch lässt sich der Datenzugriff durch die Ablage von Daten im Hauptspeicher um den Faktor 50.000 beschleunigen.

Um jedoch große Datenbanken mit mehreren Dutzend Terabyte im Hauptspeicher halten zu können, ist eine Reduktion des benötigten Speicherplatzes durch Kompression erforderlich. SAP HANA ist dazu in der Lage. Zur Reduktion des benötigten Hauptspeichers komprimiert SAP HANA redundante Daten, was bei einer spaltenorientierten Datenhaltung deutlich besser gelingt als bei einer zeilenorientierten.

Großer Cache ist keine Alternative

Aber warum stattet man eine herkömmliche Datenbank nicht mit großem Cache aus, um die Leistung zu steigern? Dies würde lediglich den Symptomen entgegenwirken, jedoch nicht den Ursachen. So werden zwar Schreibvorgänge auf das Plattensubsystem reduziert, jedoch nicht eliminiert, wie es bei einer In-Memory-Datenbank der Fall ist.

Das Design-Ziel einer herkömmlichen Datenbank besteht darin, zeitraubende Zugriffe auf das Plattensubsystem zu minimieren. Das Design-Ziel einer In-Memory-Datenbank unterscheidet sich davon jedoch maßgeblich.

Da ein Zugriff auf das Plattensubsystem nicht mehr vorhanden ist, kann eine Optimierung auf effektive Speichernutzung und effiziente Nutzung der CPU abzielen. Eine bereits durch das Design der Datenbank erfolgte konsequente und durchgängige Nutzung von aktuellen Multi-Core CPUs trägt ebenfalls zu einer massiven Beschleunigung bei.

Die Analyse rückt in die Nähe von Echtzeit

Zeitnahes Handeln und Datenexplosion stehen durchaus in einem Zusammenhang.
Zeitnahes Handeln und Datenexplosion stehen durchaus in einem Zusammenhang.
(Bild: piumadaquila.com/Fotolia.com)
Der potenzielle Nutzen einer In-Memory-Datenbank geht jedoch weit über den technischen Aspekt einer Beschleunigung des Datenzugriffes hinaus:

Bei einer In-Memory Datenbank findet die Bearbeitung der Daten bereits auf dem Datenbank-Server statt. Daten müssen nicht mehr vom Datenbank-System zum Applikations-Server transportiert werden. Hierdurch wird der Transfer von Daten über die Netzwerkschnittstelle massiv reduziert und die Geschwindigkeit der Datenauswertung steigt, da die Fachanwendung nun direkt gegen die Daten der SAP HANA arbeitet.

Auswirkungen auf die zielgerichtete Auswertung von Daten

Die unterschiedlichen Anforderungen an OLTP- (Online Transaction Processing, entspricht ERP-Anwendungen) und OLAP-Systeme (Online Analytical Processing, entspricht Business Warehouse Anwendungen) ließen sich bisher nur durch eine technische Trennung adäquat erfüllen. OLAP-Systeme unterliegen noch stärker als OLTP-Systeme den Einschränkungen und Leistungsgrenzen der existierenden Hardware, insbesondere der Plattensubsysteme. Damit OLAP-Systeme den Anforderungen der Anwender entsprechend funktionieren, sind Kompromisse und Einschränkungen nötig.

Im Vorfeld definieren OLAP-Spezialisten zusammen mit der Fachabteilung die gewünschten Abfragen und konfigurieren das OLAP-System entsprechend. Um die Performance des Systems zu verbessern, werden die Daten häufig aggregiert und sind damit unpräzise.

Hier bietet sich SAP HANA als Datenbank für ein OLAP-System an. Durch die massive Beschleunigung einer In-Memory-Datenbank fallen viele der bisher vorhandenen Restriktionen und Einschränkungen ersatzlos weg. Dies wird von SAP durch die aktuelle Freigabe von SAP HANA für SAP BW 7.3 unterstützt. Somit lassen sich auch die Ergebnisse komplexerer Reports direkt auf mobilen Endgeräten nutzen.

OLAP versus OLTP? OLAP und OLTP!

OLAP versus OLTP? Olap und OLTP? Wo ist In-Memory sinnvoll?
OLAP versus OLTP? Olap und OLTP? Wo ist In-Memory sinnvoll?
(Bild: sellingpix/Fotolia.com)
Die bis dato noch erforderliche technische Trennung von OLTP- und OLAP-Systemen bedingt eine komplexe, teure und wartungsintensive Anbindung des OLAP-Systems an das OLTP-System. OLAP-Systeme werden durch ETL-Prozesse (Extraction, Transformation und Load) aus OLTP-Systemen mit den entsprechenden Daten befüllt. Dies erzeugt einen hohen Aufwand und verringert die Flexibilität. Das Extrahieren der Daten aus einem OLTP-System kann eine beachtliche Last auf dem OLTP-System erzeugen.

Die Transformation der Daten muss sorgfältig erfolgen, um insbesondere beim Zusammenführen von Daten aus unterschiedlichen Quellen stimmige Ergebnisse zu erzielen. Nach dem Load-Prozess liegen die Daten dann im OLAP-System vor, sind jedoch je nach Ausprägung des ETL-Prozesses bereits nicht mehr aktuell.

Eine elegante Auflösung dieser vielfältigen Beschränkungen besteht im Einsatz von SAP HANA: Aufgrund der Leistungsfähigkeit bietet es sich mittelfristig an, die traditionelle Trennung von OLTP und OLAP einfach aufzuheben. Dadurch reduziert sich der Aufwand beim Erstellen der ETL-Prozesse massiv, und Berichte sowie Auswertungen basieren auf Echtzeitdaten, denn es liegt keine Latenz der Daten mehr vor. Zudem sind die zugrundeliegenden Daten nicht mehr aggregiert, was beispielsweise ein detailliertes und nahtloses Drill-Down ermöglicht.

Die Migration ist zu schaffen

Ebenfalls entfällt ein weiteres SAP System, das gewartet, betrieben gesichert und mit Transporten versehen werden muss. Dies ist vor dem Hintergrund der Freigabe von SAP ERP auf HANA in näherer Zukunft möglich. Insbesondere wenn Kunden überwiegend Standard -Reports der SAP nutzen, ist diese Integration wenig aufwändig.

Somit ergibt sich eine weitere Qualitätssteigerung sowie eine Flexibilisierung von Auswertungen für die ortsungebundene Nutzung.

Integration neuer Anwendungen

Bald werden Anwender andere Anwendungen nachziehen wollen oder müssen.
Bald werden Anwender andere Anwendungen nachziehen wollen oder müssen.
(Bild: Frank Peters/Fotolia.com)
Sobald die Vorteile des Berichtswesens in „real-realtime“ sichtbar und spürbar geworden sind und diese Verbesserungen auch zu ergebniswirksamen Beiträgen führen, wird der Druck steigen, betriebswirtschaftlichen Anwendungen von anderen Herstellern zu konsolidieren.

Denn ein Punkt bleibt weiterhin bestehen: Selbst wenn zum Beispiel SAP ECC und SAP BW auf einem technischen System vereint sind, gibt es nach wie vor Fremdanwendungen. Es existiert zum Beispiel ein Siebel-System, um die Kundendaten zu verwalten.

Die darin enthaltenen Daten sind für ein zielführendes Berichtswesen wichtig und müssen daher in SAP BW integriert werden. Für jedes Fremdsystem ist nach wie vor ein ETL-Prozess zu erstellen und kontinuierlich zu pflegen, was die Flexibilität bei Auswertungen einschränkt. Die Daten liegen somit möglicherweise nicht in Echtzeit vor.

Andere Anwendungen sollten nachziehen

Der Wechsel einer Business-Applikation, zum Beispiel von Siebel zu SAP CRM, ist jedoch mit Vorbehalten und Herausforderungen verbunden. Hier muss der daraus resultierende Kundennutzen bedeutend sein: Neue Anwendungen und die bereits genannten Vorteile von SAP HANA können und sollen Kunden dazu bewegen, Fremdsysteme aufzulösen und deren Funktionalität mit integrierten SAP-Anwendungen abzubilden.

Dies ist der Kern der SAP-Strategie: Um in einem weitestgehend gesättigten Marktumfeld den eigenen Marktanteil zu vergrößern, muss der Kundennutzen deutlich steigen, um das Beharrungsvermögen zu überwinden. SAP erhöht den Wert und den Nutzen der eigenen Applikationen entscheidend durch die In-Memory-Technologie von SAP HANA.

Der Einsatz von SAP HANA bietet einen vielschichtigen Mehrwert für sämtliche SAP Kunden: Kurzfristig durch das Entfesseln von OLAP und Mobile, mittelfristig durch bisher ungeahnte Anwendungsfälle, wie beispielsweise das Zusammenwachsen von ERP und BW und langfristig durch die Konvergenz verschiedenster Business Applikationen auf SAP HANA. Dieser Mehrwert wird durch eine faszinierende und vielschichtige Technologie ermöglicht, die zur Zeit leider noch an die Grenzen des technisch Möglichen stößt.

Der Autor:

Hinrich Mielke ist Bereichsleiter der Realtech Consulting GmbH.

(ID:39189260)