Heute möchten wir Ihnen zeigen, wie Sie Apps aus einer anderen Perspektive betrachten können, und stellen Ihnen ein Konzept vor, das stark von „Software-as-a-Service“, kurz SaaS, inspiriert ist. Wir nennen es: „Apps-as-a-Service“.
SOFTWARE ALS SERVICE
Das Kernkonzept hinter Software-as-a-Service – eine umfassende, zentral verwaltete Datenverarbeitungsressource – ist so alt wie die Datenverarbeitung selbst. In den ersten Tagen der Datenverarbeitung wurde Größe hauptsächlich im physischen Sinne verstanden, und bei der Wartung musste man Fehler regelrecht von der Hardware entfernen. Im Laufe der Zeit wurden die Computer kleiner, landeten auf unseren Schreibtischen und schließlich sogar auf dem Schoß. Damit stellten sich ganz neue Fragen, nämlich wie die Verwaltung vieler, nicht miteinander verbundener Computer funktionieren könnte. Es folgte das Zeitalter der „IT-Profis“. Doch mit dem aufkommenden Internet kehrte sich dieser Trend wieder um. Jetzt nutzen wir Cloud-Computing, und die wichtigste Schnittstelle ist der Webbrowser. Außerdem müssen wir heute keine Anwendungen mehr installieren, wir verwenden Softwaredienstleister. Es ist ein wunderbares Modell, und es ist enorm erfolgreich.
Parallel zu der Entstehung von SaaS-Lösungen hat ein erfolgreicher Anbieter von MP3-Playern den Mobilfunkmarkt auf den Kopf gestellt und dabei dem MP3-Player den Garaus gemacht. Im Jahr 2007 führte Apple das erste erfolgreiche moderne Smartphone ein, das iPhone. In den Anfangstagen des iPhones wurde empfohlen, Apps mithilfe von Web-Apps zu entwickeln. Apple erweiterte seinen Browser sogar um Funktionen, mit denen die Entwickler Webseiten App-ähnlicher gestalten konnten. Eine Zeitlang sah es so aus, als würde sich das iPhone zu einem starken Treiber für SaaS-gestützte Lösungen entwickeln. Ein Jahr nach Einführung des iPhones wurde dann der App Store eröffnet, und plötzlich sagten alle: „Dafür gibt es doch eine App“.
Viele unserer Kunden und sogar die gesamte Zeitungsbranche wurden hellhörig, vor allem als das iPad eingeführt wurde. Hier gab es endlich ein Endgerät und einen Formfaktor, der sich zum Lesen und für noch sehr viel mehr eignete. Jeder meinte, unbedingt im App Store von Apple präsent sein zu müssen. Zu dem Zeitpunkt war noch ziemlich unklar, was „sehr viel mehr“ sein würde; im Nachhinein zeigte sich, dass es hauptsächlich bei Katzenvideos und Angry Birds bleiben würde!
Seit langem machen die Befürworter von Browser-Technologien als Grundlage für Apps lautstark von sich reden, und zwar zu Recht, denn das durch Browser-Technologien ermöglichte SaaS-Modell ist für Entwickler hochattraktiv. Die Endnutzer dagegen haben wenig Interesse an Technologie. Sie wollen unterhalten werden oder etwas lernen und, was am wichtigsten ist, sie stöbern in den App Stores.
Inzwischen werden kaum noch Einwände gegen die Verfügbarkeit von Apps in den App Stores vorgebracht. Doch zumindest ein Aspekt ist aus der Diskussion um HTML vs. systemeigen geblieben: Die Wartung einer systemeigenen App ist schon etwas aufwändiger als einfach nur die neuesten Änderungen in die Produktionsumgebung zu laden. Man muss sich um eine Menge kümmern, von Prüfverfahren durch Drittanbieter über Benutzer, die keine Upgrades durchführen wollen, aber erwarten, dass alles einwandfrei funktioniert, bis zu häufigen Plattformwechseln. Vor allem Letztere verursachen viele Probleme bei der Wartung. Jedes Jahr kommen grundlegend überarbeitete Betriebssystemversionen heraus, oft neben kleineren Versionsupdates zwischendurch. Hinzu kommen Einführungen neuer Endgeräte und Formfaktoren für zwei völlig unterschiedliche Plattformen, d. h. iOS und Android. Da darf man sich schon mal etwas überfordert fühlen.
ZÄHNEKNIRSCHEN
Mit unseren knapp 800 Apps in unterschiedlichen App Stores müssen auch wir uns laufend damit auseinandersetzen und nach Lösungen suchen – doch unsere Kunden tragen immer ein bisschen von der Last mit. Manchmal muss eine App zwar nur aktualisiert werden, aber irgendjemand muss es bezahlen. Bei einer sehr alten App, die nicht mehr aktuell genug für die Plattform ist, kann das sehr aufwändig werden, zum Beispiel als iOS zu einem flachen Design überging oder als kürzlich alles auf 64 Bit angepasst werden musste.
Doch es gibt nicht nur Sorgen und Zähneknirschen – ein kleiner Teil unserer Projekte macht uns nie Probleme. Sie basieren ausschließlich auf unserer Standardsoftware, die wir täglich warten. Sie wollen aktualisieren? Entwickler werden kaum gebraucht. Sie wollen eine neue Funktion verwenden? Kein Problem! Eine Einstellung reicht. Die Parallelen zu Software-as-a-Service dürften klar sein.
Dieses Modell würden wir sehr gerne all unseren Kunden zur Verfügung stellen und deshalb hat es auch schon einen Namen: Apps-as-a-Service. Den Begriff haben wir zwar nicht erfunden, aber er ist wesentlich weniger bekannt als seine wichtigste Inspirationsquelle. Wir definieren ihn so:
Apps-as-a-Service hat die gleichen Hauptmerkmale wie Software-as-a-Service: eine zentral verwaltete Software, auf die jeder zugreifen kann, mit laufender Integration von Kunden- und Endnutzer-Feedback, häufigen Aktualisierungen, einfacher Bereitstellung neuer Funktionen und berechenbaren Kosten.
Der wesentliche Unterschied besteht darin, dass das Code Management zentral erfolgt, während die Apps entwickelt und dann bereitgestellt werden. Die App, die der Endnutzer verwendet, ist ein Snapshot, der erst aktualisiert wird, wenn ein neuer Snapshot bzw. eine neue Version herausgegeben wird. Da Aktualisierungen nicht durch alle Endnutzer gleichzeitig erfolgen, müssen die Backend-Systeme viele verschiedene App-Versionen gleichzeitig verwalten. Dies macht die Sache sehr komplex. In einer SaaS-Welt würde das entfallen.
Apps-as-a-Service ist ein sehr attraktives Modell für den App-Käufer, denn es bietet Aufwärtskompatibilität, kontinuierliche Verbesserungen und Wartung zu fixen Kosten. Auch für Entwickler ist es ein sehr attraktives Modell. Es hat eine zentral verwaltete Codebasis, sodass wir unseren Workflow zu geringeren Kosten optimieren und mehr in Qualität und Zuverlässigkeit investieren können. Außerdem profitieren wir bei jeder Verbesserung der App von den Erfahrungen mit hunderten von Apps – zum großen Vorteil aller.
EINHEITSGRÖSSEN PASSEN NICHT JEDEM
Sie denken vielleicht, dass Apps-as-a-Service nach dem Prinzip „Einheitsgröße“ funktioniert. Das ist nicht der Fall. Eine kleine Lokalzeitung mit zwei Ausgaben pro Woche hat ganz andere Anforderungen als ein großes regionales Blatt mit mehr als 20 Versionen pro Tag. Die Frage ist, welche Lösung am besten zu Ihrer digitalen Gesamtstrategie passt.
Wir arbeiten inzwischen mit zwei verschiedenen Projekttypen: „Standard“ und „Customized“ sollen als Apps-as-a-Service-Lösungen angeboten werden. Außerdem haben wir den Projekttyp „Co-Created“ für Zeit- und Materiallösungen entwickelt.
Eine Standard-App basiert nur auf Standard-Komponenten. Dabei bedeutet „Standard“ nicht „einfach“, sondern nur, dass die Bausteine auf Code-Ebene unverändert bleiben. Die Standardkomponenten können auf vielfältige Weise konfiguriert und kombiniert werden. Vielleicht möchten Sie zum Beispiel nur eine sehr gezielte Leser-App mit Basisfunktionen entwickeln. Oder Sie brauchen eine umfassendere App, die mehrere Ausgaben unterstützt und/oder historische Archive mit Suchmöglichkeiten bietet und/oder Live-Content von Ihrer Website integriert, oder Sie möchten noch andere Optionen von unserer Liste mit über 20 Funktionen nutzen, die alle zu einer App hinzugefügt werden können – natürlich komplett in Ihrem Markendesign und passend zu Ihrer Papierausgabe gestaltet. Wir schätzen, dass mehr als die Hälfte der bisher von uns bereitgestellten Apps ohne Beeinträchtigung des Endnutzererlebnisses auf Standard umgestellt werden könnten. Die Umstellung auf Standard ist die einfache Option.
Eine App vom Typ „Customized“ basiert hauptsächlich auf Standardkomponenten. Die Hauptkontaktpunkte des Benutzers neben Papier, Startbildschirm und Anmeldebildschirm lassen sich vollständig anpassen oder sogar komplett neu entwickeln. Customized bietet weitere Möglichkeiten zur Einbindung Ihrer Marke, zur Integration von Live-Content oder maßgeschneiderten Kiosk-Lösungen und vieles andere mehr. Customized wurde als überzeugende Alternative zu Co-Created gestaltet: Sie ermöglicht Änderungen in Bereichen mit besonders großen Auswirkungen für den Endnutzer und beschränkt die Änderungsmöglichkeiten in Bereichen, die sich schnell zu einer Handelsware entwickeln. Die Verwaltung einer Customized-App kann allerdings nicht so stark vereinheitlicht werden, da die benutzerdefinierten Komponenten eine eigene Wartungsschiene brauchen. Durch das Einbetten der maßgeschneiderten Teile sind wir aber in der Lage, die Customized-Apps als Dienst anzubieten.
Co-Created-Apps müssen in keinen vordefinierten Rahmen passen. Alles ist möglich. Doch diese grenzenlose Freiheit hat ihren Preis. Manchmal überrascht dieser Preis auch uns, aber vor allem überrascht er unsere Kunden. Und das möchten wir gerne vermeiden. Co-Created ist eine interessante Kategorie, die viel Raum zum Experimentieren und Lernen bietet. Aber Co-Created-Apps können nicht als Dienst angeboten werden, und nur deshalb werden wir ihren Einsatz bei den meisten Projekten nicht so gerne empfehlen.
APPS-AS-A-SERVICE BEI VISIOLINK
Bei Visiolink passen wir unsere Denkweise gerade an eine Apps-as-a-Service-Welt an. Wir arbeiten schon eine ganze Weile intern an dem Apps-as-a-Service-Konzept und freuen uns jetzt, dass wir es endlich teilen können. Jeder bei Visiolink freut sich darauf, mit künftigen Kunden zu arbeiten und sie dabei zu unterstützen, den Projekttyp zu finden, der am besten zu ihrem Bedarf und ihren Wünschen passt. Wir wollen auch mit unseren bestehenden Kunden über ihre Lösungen sprechen und mit ihnen überlegen, wie sie ihr Angebot auf ein Apps-as-a-Service-Modell umstellen können.
