Swiss IT Magazine: Herr Ward, unsere erste Frage dürfte klar sein: Sie bezeichnen sich als «RIA Cowboy» – was ist damit gemeint?
Eigentlich nennt man Leute wie mich in der IT-Industrie üblicherweise «Evangelist» – aber dieser Begriff ist stark mit Religion verknüpft. Den Cowboy dagegen kennt man aus Wildwestfilmen. Er reitet frei durch die Prärie, erklimmt Felsen und schiesst in der Gegend herum. Etwas Ähnliches mache ich in bezug auf Software: Ich möchte die Softwareszene aufrütteln und mit dem Konzept RIA einen frischen Ansatz beisteuern. Man könnte sagen, ich lebe punkto Software den «Cowboy Way of Life».
Was bedeutet das konkret?
Software, besonders Business-Software, war lange Zeit ziemlich langweilig. Geschäftliche Softwaresysteme sind oft schwierig zu bedienen, die Oberfläche ist schlicht grässlich, so dass die Nutzer Mühe haben, damit umzugehen. Meine Aufgabe ist es, einen anderen Blickwinkel auf Enterprise-Software aufzuzeigen.
Das klingt interessant, aber wenig konkret – können Sie ein Beispiel nennen?
Vor etwa sechs Jahren habe ich ein Supportportal für ein Unternehmen erstellt. Im Back-End lief ein Oracle-CRM – ich wollte aber nicht, dass die Mitarbeitenden mit dem grauenhaften Original-Interface kämpfen mussten, und habe deshalb eine Flex-basierte Oberfläche darüber gelegt. Das Portal stiess sofort auf höchste Akzeptanz, die User liebten das neue System geradezu. Davon zeugen Kommentare wie «Das ist das faszinierendste Kundensupportsystem, das ich je gesehen habe». Seit dieser Zeit bin ich dem Konzept RIA und besonders der damals ganz frischen Flex-Technologie verfallen. In der Zwischenzeit bin ich zu Adobe gestossen und zum RIA-Cowboy geworden …
Eine schöne Oberfläche ist sicher angenehm, aber bringt sie auch geschäftlichen Nutzen?
Bessere Software führt auch zu besserem Return on Investment. Als Beispiel mag eine Call-Center-Anwendung dienen: Vor dem Redesign konnte ein Agent in einer Stunde vielleicht zehn Anrufe bearbeiten. Mit einer neuen RIA-Oberfläche stieg die Produktivität auf 50 Calls pro Stunde. Das ist ein gutes Beispiel dafür, wie sich Software verändern und wie RIA-Technologie sich auf den Nutzen einer Anwendung auswirken kann. Da kommt auch wieder der Cowboy-Aspekt ins Spiel: Das schwerfällige, langweilige Enterprise-Software-Öko-system aufmischen und zeigen, dass es auch anders und vor allem besser geht.
Wie wird das Konzept RIA heute aufgenommen – müssen Sie die Kunden davon überzeugen oder kommen sie von selbst auf die Idee?
Als ich vor drei Jahren angefangen habe, Flex zu evangelisieren, musste ich meistens zu den Kunden gehen und Überzeugungsarbeit leis-ten. Heute ist das völlig anders: Ich musskaum jemandem mehr zureden, sondern die Kunden kommen zu mir und fragen vielleicht, wie sie konkret vorgehen sollen, um ihr System X in eine RIA-Anwendung umzugestalten. Die Betrachtungsweise hat sich also dramatisch verändert. Die Vorteile von RIA sind heute meist klar, es geht fast nur noch um technische Details und Best Practices.
Es gibt ja mehrere RIA-Technologien. Könnten Sie kurz die Charakteristiken, Vor- und Nachteile schildern?
Die wichtigsten Player sind heute Ajax, Silverlight, JavaFX und natürlich Flex. Die Adobe-Technologie Flex hat den grossen Vorteil, dass sie schon ziemlich lange existiert. Version 1.0 kam vor sechs Jahren auf den Markt. Die grundlegende Technologie, das Komponentenmodell und die Entwicklungstools sind somit sehr gut ausgereift – seit kurzem gibt es ja eine Betaversion der neuesten Generation der Entwicklungsumgebung, die wir von Flex Builder in Flash Builder umbenannt und auf die Basis Eclipse gestellt haben. Dazu kommt als neues Werkzeug Flash Catalyst. Generell gesehen handelt es sich dabei bereits um den vierten Hauptrelease unserer RIA-Software.Diese Reife haben die anderen Technologien noch nicht erreicht. Silverlight zum Beispiel wird sich sicher schnell weiterentwickeln – Microsoft investiert ja auch eine Menge in die Technologie. Aber Silverlight wird vor allem im Enterprise-Umfeld nicht so schnell aufgenommen wie es bei Flex der Fall war und steht heute etwa dort, wo wir schon vor ein paar Jahren waren. Ich sehe Silverlight vor allem in traditionellen «Microsoft-Shops», die auch sonst den ganzen .NET-Stack einsetzen und mit Visual Studio arbeiten. Das heisst natürlich nicht, dass es keine Flex-Anwendungen mit .NET-Back-End gibt!
Flex kommt dagegen besonders in der Java-Welt und bei PHP-, Python- und Coldfusion-Entwicklern gut an. Das sind unsere «Sweet Spots» – unter anderem, weil in diesen Umgebungen sonst keine ausgereiften RIA-Optionen zur Verfügung stehen.
Die Reife unserer Technologie zeigt sich übrigens auf der einen Seite auch in Form einer langen Liste von Kunden und Softwareanbietern, von Oracle und SAP bis zu zahlreichen Global-2000-Unternehmen. Auf der anderen Seite haben wir mit tausenden von Flex-Entwicklern eine grosse Entwicklergemeinde, und es gibt einen Markt mit hunderten von Flex-Komponenten, die von Drittherstellern angeboten werden. IBM hat zum Beispiel gerade den Business-Rules-Anbieter Ilog übernommen, der auch Flex-Komponenten für die Datenvisualisierung im Front-End im Programm hat. Es gibt zudem tonnenweise Open-Source-Komponenten, die man in Flex-Anwendungen einbauen kann.
Eine pikante Frage: Geben Sie JavaFX überhaupt eine Chance?
Das hängt natürlich ganz davon ab, was Oracle nach der Sun-Übernahme damit anstellt. Als Sun JavaFX vorstellte, war man allgemein skeptisch – die gängige Meinung war, das würde niemals abheben. Heute sieht man ein wachsendes Interesse an JavaFX. Wenn Oracle die Technologie vorantreibt, könnte sie zu einer guten Option für Java-Entwickler werden. Interessanterweise nutzt Oracle selbst aber bereits sehr viel Flex, und auch in der Java-Community ist Flex beliebt. Bis heute wird in den Projekten, mit denen ich in Kontakt komme, auch nirgends zwischen JavaFX und Flex evaluiert – im Gespräch sind jeweils nur Flex, Silverlight und Ajax.
Es gibt Stimmen, die auf Webstandards schwören und Flex, Flash & Co. als proprietäre Technologien abtun. Was ist Ihre Position dazu?
Bei Adobe ist es Tradition, dass die Dinge zuerst durch eine Phase gehen, in der Innovation und schnelle Veränderung den Ton angeben. Wenn eine Technologie dann genügend ausgereift ist, folgt die Standardisierung. Im Fall von PDF ist das Format heute ein offener ISO-Standard, der Reader ist kostenlos, aber Tools wie Acrobat Professional und diverse Serverprodukte werden kommerziell angeboten.
So ähnlich läuft es auch mit Flex: Das Runtime, der Flash Player, ist seit langem kostenlos zu haben. Der Kern des Players sowie diverse Protokolle, die der Player nutzt, sind ebenfalls schon Open Source oder offene Standards – letzthin haben wir zum Beispiel das RMTP-Protokoll (Reliable Multicast Transport Protocol) veröffentlicht. Das Flex-Framework per se ist auch Open Source, aber die Entwicklungstools Flash Builder und Flash Catalyst sind kommerzielle Produkte. Weil die Entwickler wissen, wie Adobe in der Vergangenheit mit PDF vorgegangen ist, fühlen sie sich mit der Flash-Plattform heute durchaus wohl.
Genügen die Umsätze mit Tools wie Flash Builder, um mit RIA wirklich Geld zu verdienen?
Ich komme wieder auf Acrobat zurück: Was wir mit Acrobat Professional und den Serverprodukten einnehmen, bringt sicher genug Geld ein. Ähnlich sieht es mit Flex und den Entwicklungstools, Serverprodukten und Services rund um die Flash-Plattform aus. Flex, Flash und RIA sind für Adobe strategische Bereiche, die auch in Zukunft für gute Erträge sorgen sollen. Dazu gehört auch die Weiterentwicklung der Plattform – Flash soll mit voller Funktionalität auf Mobilgeräten zum Zug kommen, und Video auf dem Web ist ein heisses Thema.
Was bringen Flash Builder, Flash Catalyst und Flex 4 an Neuerungen?
Der wichtigste Aspekt der neuesten Generation der Flash-Plattform ist der Workflow zwischen Designern und Entwicklern. Für wirklich bessere Software braucht es nicht nur Entwickler, sondern auch Designer – sonst gewinnen technisch orientierte «Geeks» wie ich wieder die Oberhand, und die Benutzerfreundlichkeit verbessert sich kaum. Mit der nächsten Generation unserer Tools wollen wir erreichen, dass Designer und Entwickler nahtlos zusammenarbeiten können.
Mit Flash Catalyst kann der Designer einen funktionsfähigen Entwurf der Oberfläche erstellen. Der Entwickler übernimmt diesen Entwurf und sorgt für die Back-end-Programmierung. Die Community reagiert seit der Freigabe der ersten Testversion an der Max-Konferenz im Herbst 2008 begeistert: Die Leute probieren den neuen Workflow aus und finden, dass manches in zwei Tagen erledigt werden kann, was bisher Wochen in Anspruch nahm. Im Moment ist Flash Catalyst als Beta erhältlich, die definitive Version folgt im Lauf des Jahres.
Kommen alle drei Tools gleichzeitig auf den Markt?
Üblicherweise liefern wir den SDK, in diesem Fall also Flex 4, und die Entwicklungstools gleichzeitig aus. Das ist ja auch sinnvoll, weil alles voneinander abhängt. Ob es diesmal mit Flash Catalyst auch so sein wird, kann ich nicht sagen. Hier ist der Zusammenhang ja nicht so eng. Ein offizielles Releasedatum gibt es bisher noch nicht.
Was raten Sie einer Firma, die ihre Anwendungen verbessern will – wie bereitet man sich auf RIA vor, und wie geht man vor?
Die meisten Entwickler profitieren von ihren bisherigen Kenntnissen, wenn sie mit Flex anfangen. Sowohl Java- als auch .NET-Entwickler kommen mit Flex sehr schnell zurecht. Bei Entwicklern, die nur HTML und JavaScript kennen, ist es etwas anders, weil Flex ein echt objektorientiertes Entwicklungs- und Komponentenmodell nutzt, das «konventionellen» Entwicklern eher entgegenkommt. Auf der anderen Seite arbeiten HTML/JavaScript-Entwickler bereits mit einer Mischung aus deklarativer und prozeduraler Sprache mit objekt-orientierten Elementen – bei Flex entspricht dies dem Mix aus dem deklarativen MXML und dem prozeduralen ActionScript beziehungsweise Java.
Im grossen Ganzen arbeiten sich Entwickler aller Art also schnell in Flex ein. Der Knackpunkt liegt woanders: Wie soll die Software umgestaltet werden, damit sie wirklich benutzerfreundlicher wird und die Produktivität steigert? Die Schnittstelle zwischen Designer und Developer ist in vielen Unternehmen die grösste Herausforderung – nur schon die Designer zu finden, die eine neue Oberfläche gestalten können, ist oft nicht einfach.
Wenn man nicht aufpasst und kein guter Designer involviert ist, entsteht nämlich auch mit RIA-Technologien meist etwas, das ganz ähnlich funktioniert wie bisher – und das ist ja gerade nicht das, was man mit RIA eigentlich erreichen möchte. Das volle Potential von RIA wird in diesem Fall nicht genutzt.
Mein Rat: Wenn man auf RIA umstellt, kann man meist nicht mit den bisherigen Designern arbeiten – vielleicht ist es besser, wenn man ein externes Designbüro beizieht, das RIA-Erfahrung hat.
Wir haben in diesem Zusammenhang eine «Tour de Flex» ins Netz gestellt, wo man alle unsere Flex-Komponenten und auch Community-Komponenten in Live-Demos betrachten und so beurteilen kann, was mit Flex alles möglich ist. Zu sehen gibt es das unter www.flex.org/tour.
Was sollte man in einer RIA vermeiden, das aus der Desktop- beziehungsweise Web-Welt kommt?
Ein Beispiel: In Flex lassen sich grosse Datenmengen sehr rasch darstellen. Die meisten traditionellen Webanwendungen laden aus Rücksicht auf die Performance aber nur wenige Records auf einmal. Der Nutzer muss ständig weiterklicken und jeweils warten, bis sich die Seite neu aufgebaut hat. Mit Flex lassen sich alle Daten auf einmal laden und mit passenden Navigationselementen adäquat darstellen.
Auf der anderen Seite muss man sich bei einer RIA mit Dingen befassen, die bei Desktop-Software nicht relevant sind, zum Beispiel mit der Suchmaschinenfreundlichkeit – wie werden die Inhalte «spiderable»?
Wir arbeiten hier mit Google zusammen, um SWF-Files indexierbar zu machen und haben Best Practices veröffentlicht, wie man eine Flex-Anwendung indexierbar macht.
Von Vorteil ist das hybride Deployment-Modell bei Rich Internet Applications: Mit Flex kann man Anwendungen bauen, die im Browser, auf dem Desktop und zunehmend auch auf Mobilgeräten laufen und keine oder nur geringe Anpassungen auf die jeweilige Runtime-Umgebung benötigen. Das ist weder mit herkömmlicher Technik noch mit den anderen RIA-Technologien möglich.
Wie bedeutend ist der Anteil der RIA, die ausserhalb des Browsers laufen? Gibt es einen Markt für solche Software?
Die Frage ist interessant, weil ja in den letzten Jahren alles vom Desktop aufs Web migriert wurde, und jetzt soll es wieder auf den Desktop zurück. Es gibt meiner Ansicht nach durchaus Situationen, in denen eine RIA ausserhalb des Browsers Sinn macht – zum Beispiel, wenn man Zugriff auf lokale Daten braucht oder bei Anwendungen, die manchmal online und manchmal offline gebraucht werden. Was jedoch wirklich immer bedeutender wird, sind RIA auf Mobilgeräten: Natürlich kann man auch hier browserbasierte Applikationen nutzen – aber was passiert, wenn man im Tunnel oder im Lift steckenbleibt und wieder einmal «kein Netz» hat? Deshalb arbeiten wir intensiv daran, sowohl den Flash-Player als auch AIR auf Mobilgeräte zu portieren.
Wie weit ist Adobe dabei vorgestossen?
Es gibt eine ganze Reihe von Herausforderungen. AIR und der Flash Player waren ursprünglich für Geräte mit der Leistung eines Desktop-PC gedacht. Mobile Geräte haben im Vergleich nur beschränkte Ressourcen, vom RAM über die Prozessorleistung bis zur Bildschirmgrösse. Wir müssen deshalb einen Grossteil des Codes neu entwickeln und auf diese Beschränkungen hin anpassen. Unsere Ingenieure arbeiten momentan daran, ausserdem gibt es das Open-Screen-Project, bei dem verschiedene Anbieter an der Optimierung für ihre Plattformen arbeiten. Diese Anstrengungen tragen auch schon Früchte: Das Android-Gerät «Hero» von HTC unterstützt die volle Flash-Plattform schon heute.
Wie sieht es mit dem iPhone aus – gibt es eine Chance, dass der volle Flash-Player jemals auf dem Apple-Smartphone laufen wird?
Der Safari-Prozess auf dem iPhone darf höchstens 20 Megabyte in Anspruch nehmen, und jede Safari-Seite kann nicht mehr als 8 MB nutzen. Eine Flex-Anwendung braucht mindes-tens 20 MB – also würde es nicht gut funktionieren, selbst wenn es einen Flash-Player fürs iPhone gäbe. Wir müssen die Runtimes also zuerst noch optimieren und arbeiten auch an einem neuen Framework und Komponenten-Set, das schlankere Flex-Anwendungen auf Mobilgeräten ermöglicht. Wie das genau aussehen soll, wird im Moment noch evaluiert.
