Keine Frage der Schönheit

Architekturalternativen für mobile Anwendungen
Kommentare

Informationsarchitekten in großen Unternehmen sehen sich einem Basar von Plattformen für die Integration von mobilen Anwendungen gegenübergestellt. Schnelle Wechselzyklen, hohe Benutzererwartung und wenig etablierte Standards machen die Auswahl einer Plattform schwierig. Wie stellt man die eigene Architektur darauf ein? Welche Entwicklungsmöglichkeiten gibt es?

Manager mögen iPhones. Selten war eine Entwicklung in den IT-Abteilungen von Unternehmen so von den Bedürfnissen der Nutzer getrieben wie die nach Mobilität. Doch nicht nur Mobilität wird erwartet, sondern auch leichte Benutzbarkeit und der ständige Zugriff auf Echtzeitdaten – unabhängig von der Plattform. Wo früher nur Außendienstmitarbeitern mit formularbasierten Anwendungen ein Teilprozess erleichtert wurde, sind es heute die „Information Worker“, die ständig mobil auf den gesamten Prozess Einfluss haben wollen. Die Technologiearchitekturen stellt das vor große Herausforderungen.

Anwendungsarchitektur

Das vielzitierte Bild von der Kathedrale und dem Basar trifft auch auf viele IT-Architekturen in Unternehmen zu. In den meisten großen Unternehmen sind die Architekturen in streng geplante Schichten unterteilt: relationale Datenbank mit Skripten und Sichten, Geschäftslogik/Anwendungen, Integrationsschicht darauf aufsetzend, darüber Business Intelligence und mobile Anwendungen. Netzwerke und Schnittstellen werden an spezifischen Stellen eingesetzt, sind jedoch nicht generell von außen zu erreichen. Die Architektur funktioniert, erschließt sich in ihrer Ganzheit aber nur wenigen – wie bei einer Kathedrale. Mobile Anwendungen benötigen eine andere, leichter zu organisierende Form der Architektur – dynamisch kombiniert wie auf einem Basar. Benutzer von mobilen Anwendungen sind auf ihren Kontext abgestimmte Anwendungen gewohnt, die nicht in starren Fenstern denken, sondern die richtigen Daten zur richtigen Zeit in einem dynamischen Prozess bereitstellen. Die Implikation daraus ist: Schnittstellen müssen nach außen bekannt sein und direkt auf die Daten zugreifen, Geschäftsprozesse müssen von den Daten getrennt sein. Das macht den Netzwerkzugriff an anderen Stellen notwendig und stellt die Integrationsarchitektur gleichberechtigt neben Daten und Prozesse. In diesem Artikel werden verschiedene Möglichkeiten aufgezeigt, diesen Architekturanforderungen zu begegnen. Schließlich sind die wachstumsstärksten Regionen dieser Welt gleichzeitig diejenigen, die fast alle Prozesse über Mobiltelefone abwickeln – und deshalb Basare geblieben sind.

[header = Herausforderungen]

Die Erwartungshaltung von Smartphone-Anwendern, auch „Information Worker“ genannt, ist die Benutzbarkeit von mobilen Anwendungen, wie sie es von erfolgreichen iPhone und Android-Anwendungen gewohnt sind. Bei genauer Betrachtung unterscheidet sich diese Art von Anwendungen vom klassischen, beliebig interaktiven Fenstermodell – sie heben den Fluss hervor (Abb. 1).

Elemente einer typischen Smartphone-Anwendung

Abb. 1: Elemente einer typischen Smartphone-Anwendung

Mobile Anwendungen müssen vor allem Daten zeigen, da der Benutzer den Prozess auf diese Daten selbst bestimmt. Drilldown und Analyse müssen ebenso wie die Bearbeitung unterstützt werden. Deshalb existieren mehrere Menüs oder Themen. Zusätzlich muss eine schnelle und exakte Suche vorhanden sein. Die Anwendung darf nicht abhängig vom Netzwerk sein (Occasionally connected) und muss ständig Updateinformationen bereithalten. Am wichtigsten aber ist, dass die Aktivität eines Benutzers jederzeit unterbrochen werden kann und er danach direkt weiterarbeiten möchte. Alle Daten müssen schnell bereitgestellt werden und einfach wahrnehmbar und erreichbar sein. Daraus folgen viele Links und Scrolling in alle Richtungen. Die Daten selbst müssen abgewandelt, etwa für geringe Auflösungen optimiert und Textlängen sinnvoll gekürzt und durchsuchbar gemacht werden.

Das alles ist nicht einfach mit Standardarchitekturen umzusetzen, denn extrem verknüpfte Daten, die dennoch durchsuchbar und direkt erreichbar sein sollen, stellen immense Anforderungen an die Datenbank, die Geschäftslogik und vor allem Transaktionssicherheit und Replikation.

[header = Übliche Ansätze]

Mobile Anwendungen werden traditionell häufig im CRM-Bereich angesiedelt, dieser wiederum nah an der Business Intelligence. Ein Grund, warum gerade CRM-Hersteller mit mobilen on-Demand-Plattformen (MEAD) in diesen Markt drängen. SAP mit Sybase oder Salesforce bauen sich zu mobilen Plattformen aus. Heute ist aber mehr als CRM notwendig. Für Echtzeitzugriff auf eine breite Anzahl von integrierten Anwendungen benötigt man Lösungen, die direkt auf Daten und Services zugreifen. Doch leider müssen Offlinefähigkeit und Durchsatzoptimierung bei schwachem Netz immer noch berücksichtigt werden. Zusätzlich benötigen mobile Anwendungen eine völlig andere Deployment- und Sicherheitsarchitektur. Diese Anforderungen sind schwer zu vereinbaren, ein Aspekt wird sich immer in den Vordergrund drängen.

Stellt man den Zugriff in den Vordergrund, findet man oft webbasierte Anwendungen, die per VPN verbunden und mit Zertifikaten abgesichert sind. Im Extremfall handelt es sich um rein serverbasierte HTML-4-Anwendungen, die heute mit AJAX-Funktionen angereichert sind.  Üblicherweise werden diese Thin Client genannt. Stellt man die Unabhängigkeit in den Vordergrund, so findet man oft native Anwendungen, speziell für die Plattform entwickelt, mit kontrollierter Sicherheit und speziellem Übertragungskanal (z. B. gesicherte Web Services), beispielsweise Windows Mobile oder Symbian-Anwendungen. Diese werden Thick Client genannt.

Strategische Lösungen

Beide Ansätze haben ihre Vor- und Nachteile. Der Thick Client erfordert einen hohen Management-, Entwicklungs-und Testaufwand, während der Thin Client schlechter zu bedienen und abhängig von Netz und Batterie ist. Interessanter sind die Grautöne. Die Wahl der Plattform hängt von der Unternehmensstrategie, der Art der Anwender, der akzeptierten Technologieabhängigkeit und dem realen Einsatzkontext ab. Daraus entwickeln sich verschiedenste Stile mobiler Anwendungen, die nicht notwendigerweise innerhalb eines Unternehmens immer gleich sein müssen.

Beispielhafte Segmentierung mobiler Anwendungsstile

Abb. 2: Beispielhafte Segmentierung mobiler Anwendungsstile

In Abbildung 2 ist eine beispielhafte Segmentierung dieser Anwendungsstile vorgenommen. Das Wort Thick Client wurde in den letzten Jahren immer mehr durch Rich Client ersetzt. Wir möchten es jedoch im ursprünglichen Sinn einer spezialisierten Entwicklungs- und Laufzeitumgebung benutzen, wie sie Flash, Silverlight und Oracle Fusion bereitstellen. Davon ausgehend könnte man sich dem Thin und Thick Client in kleinen Schritten nähern. Etwas schwergewichtiger als der Rich Client ist die klassische Java VM, aber auch Sybase‘ Unwired-Plattform, Rhomobile’s Ruby-Interpreter oder CouchApps. Wenn man die Laufzeitumgebung wegfallen lässt, kommen Codegeneratoren wie Titanium, Mosync und Dragon ins Spiel – aber auch Android, dessen Sprache irgendwo zwischen VM und Generator angesiedelt ist (abgesehen vom NDK). Und schließlich die klassischen nativen Entwicklungen wie Qt für Symbian und MeeGo oder iPhone. Allen diesen Lösungen sind eine gute Leistung auch Offline, intuitive Oberflächen und reichhaltige Schnittstellen gemein.

Bewegt man sich nach rechts auf der Achse, kommt man zu den eher webbasierten Anwendungen. Hybride Apps prämierten auf dem iPhone, um einen Starter für eine Webseite zu haben. Frameworks wie PhoneGap kann man hierzu zählen, da es HTML 5 um Gerätefähigkeiten erweitert. Geht man noch einen Schritt weiter und verlässt sich auch beim Starter auf Webstandards, kommt man zu Widgets, „Cloud“-Anwendungen und AJAX-Frameworks wie Sencha Touch, jQuery Touch, SproutCore und AppMakr. Das Besondere an diesen Frameworks ist, dass sie mit HTML-basierten Lösungen wie Rhomobile oder PhoneGap zusammenarbeiten können. Schließlich kommen die Thin Clients, die in ihrer reinen Form als HTML-Anwendungen heute kaum noch existieren.

Interessanterweise finden sich zur linken Seite, den nativen Anwendungen, eher kommerzielle Frameworks, während zur rechten Seite hin eher freie Software zu finden ist. Support gibt es für alle Systeme, doch besonders Rich Clients sind fest in der Hand der großen Softwarehäuser. Hier spielt oft der Vendor Lock-in eine Rolle. Bei den kurzen Lebenszeiten mobiler Geräte muss besonders auf eine breite Basis geachtet werden, um Investitionen zu sichern.

Unternehmen müssen sich entscheiden, auf welchen dieser Lösungen sie ihre Architektur aufbauen. Mobile Anwendungen müssen oft aktualisiert werden, und jede der Lösungen bedingt unterschiedlichen Deployment-, Test- und Infrastrukturaufwand. In der Enterprise-Architekturstrategie sollte genau festgelegt sein, welche Option gewählt wird. Dabei sind natürlich Kombinationen möglich: z. B. hybride Apps mit einem HTML5-Framework und einem selbstentwickelten Backend-Framework unter der Kontrolle einer MEAP.

[header = Backend Integration]

Die Art der Serviceintegration ist bei all diesen Ansätzen überraschend ähnlich. Da das Netzwerk und die Replikation heute gut abstrahiert sind, spielt es fast keine Rolle, ob ein extra gesicherter Webserver einen Service aufrufen muss oder ein nativ laufendes Programm eine SSL-Schnittstelle anspricht. Die vielleicht wichtigste Implikation mobiler Anwendungen auf die Enterprise-Architektur ist der direkte Zugriff auf Daten. Da jede Anwendung den Prozess anders gestaltet, müssen die Daten in ihrer ursprünglichsten Form zugreifbar sein. Nur so können sie variiert, analysiert, repliziert und atomar gesichert werden. Dieses Paradigma, ob nun SOA, ROA oder WOA genannt, wird durch RESTful Services umgesetzt. Diese haben in ihrer Ausprägung des JSON über RESTful HTTPS zudem den Vorteil, nur eine geringe Bandbreite zu benötigen und vollständig auf Standardsystemen sowohl server- als auch clientseitig lauffähig zu sein. Mit dem Konzept der Aktivitäten hat sich die Android-Plattform hier an der Idee der Repräsentationen von Daten bei REST orientiert: Jede Anwendung setzt sich aus Aufgaben zusammen, die nur über Nachrichten (oder Links) lose gekoppelt sind. So können Prozesse beliebig neu zusammengesetzt und perfekt auf den Nutzer optimiert werden, die Anwendung wird zu einer reinen Perspektive auf Daten. Die größere Herausforderung ist hier eher die Integration in bestehende Systeme – denn diese benötigen oft noch im Hintergrund laufende Batch-Prozesse oder Skripte und sind nicht über Nachrichten oder Dienste erreichbar.

Konsequente Anwendung von REST- und SOA-Prinzipien machen Architektur mobil

Abb. 3: Konsequente Anwendung von REST- und SOA-Prinzipien macht Architekturen „mobil“

Neben dem Service-Backend spielt vor allem die Datensicherheit eine Rolle. Auf dem Gerät muss sie durch spezielle Software, Zertifikate, sicheren Speicher, ständige Prüfung und Optimierung des Servicezugriffs sichergestellt werden. Mobile Endgeräte sind immer auch privat genutzte Geräte und damit per se einer höheren Gefährdung ausgesetzt. Auf Serviceseite muss dem durch exakte Authentifizierung über User/Passwort hinaus, unter Einbeziehung des Kontexts, entsprochen werden. Verschlüsselung ist hierbei besonders wichtig, denn durch mehrere Netzwerkschichten kann nicht mehr eindeutig sichergestellt werden, wer die Daten mitschneiden könnte. Gerade bei webbasierten Anwendungen kommen hier noch Gefahren durch Cross-site Scripting (XSS) und potenziell unkontrollierbares Caching hinzu.

[header = Fazit]

Eine Strategie zur Implementierung mobiler Anwendungen muss heute mit der Geschäftsprozessstrategie und der Identifizierung der Zielgruppen beginnen. Zusammen mit der Auswahl der Hardwareplattformen müssen Anwendungsstile identifiziert werden, die diesen resultierenden Ansprüchen gerecht werden. Entscheidend ist dabei jedoch immer die Integration in die Backend-Systeme, denn nur durch vollständigen Zugriff auf alle Daten und deren perfekte Aufbereitung kann der Nutzer gleichbleibend produktiv arbeiten. Für Unternehmen heißt das, die gesamte Architektur muss bei großflächigen mobilen Anwendungen geprüft werden – eine Chance, mehr besser zu machen als nur das schicke Design.

Marktsituation

So gut wie alle Statistiken sehen bei Smartphones übergreifend Android vorne, danach das iPhone und BlackBerry. In Unternehmen mag diese Reihenfolge noch exakt umgekehrt sein. Doch das kann sich bei eins bis zwei Jahreszyklen von Gerätegenerationen schnell ändern. Windows Phone 7 könnte das System zurück in die Spitzengruppe bringen, Nokia forciert MeeGo und schiebt Symbian weiter nach unten. Vor allem aber Android, dessen Version 2.2 mit starken Unternehmensfeatures ausgerüstet ist und mittlerweile die größte Untergruppe darstellt, wächst extrem stark.

Mobile Enterprise Application Platforms (MEAP

Mobile Integration hat eine lange Geschichte im Unternehmenseinsatz. Diese hat sich in den letzten Jahren aber vom Endkundenmarkt weg entwickelt. Heute müssen viel heterogenere Ökosysteme eingebunden werden. Neben der Backend-Integration, die üblicherweise von Frameworks gut gelöst wird, sind Deployment und Change Management sowie Sicherheit Unsicherheitsfaktoren im Unternehmenseinsatz. Online Application Stores werden häufig nicht vertraut, gleichzeitig kann man nicht alle Geräte kontrollieren. Eine Lösung dafür ist Mobile Device Management (MDM)-Software, die Möglichkeiten wie Installation, Update(OTA), Rollenverwaltung, Zertifikatsverwaltung, Remote Kill/Wipe und GPS Tracking. Viele dieser Lösungen werden mittlerweile von Plattformen angeboten, Microsoft und BlackBerry sind hier traditionell stark. Aber auch das iPhone und Android kommen mit guten Lösungen. Einen Schritt weiter gehen Mobile Enterprise Applicaiton Platofrms (MEAP), die zusätzlich noch eine zentrale Middleware und Schnittstelle sowie Programmierumgebung für Cross-Plattform-Entwicklung bereitstellen.

Möglichkeiten von HTML5

Einige der Nachteile von webbasierten Anwendungen, z. B. die lokale Speicherung, Widget-Starter und Datenvisualisierung werden mit HTML 5 verbessert. Der größte Nachteil bleibt allerdings erhalten: uneinheitliche Oberflächen, die Nutzerparadigmen des Geräts nicht weiterverfolgen, Offline nicht vollständig lauffähig sind und mit hoher Ressourcenbelastung einhergehen. Bei mobilen Geräten hat sich WebKit mittlerweile als Standard durchgesetzt. JavaScript ist dank Engines wie V8, CrankShaft und TraceMonkey extrem effizient. Doch diese Varianten und Zugriffsmodelle sowie verschiedene Oberflächen-CSS zwingen auch unter HTML 5 zur Cross-Browser-Entwicklung. Dazu stehen Frameworks wie Sencha Touch oder jQTouch bereit. Aus der Sicherheitsperspektive muss hier noch mehr Wert auf Analyse der Plattform gelegt werden, vor allem wie die Offlinedaten gespeichert und gegen Fremdzugriff durch Nutzer und andere Anwendungen, auch zur Laufzeit (z. B. XSS) gesichert werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -