Das Software-as-a-Service-Paradigma hat in den letzten Monaten eine breite Akzeptanz am Markt erfahren. Das enorme Wachstum der Vorreiter wie Salesforce.com oder 37 Signals spricht Bände, und nicht zuletzt SAPs Launch ihres SaaS-Produktes Business by Design hat viele Zweifler davon überzeugt, dass diese neue Art und Weise, Computeranwendungen zu nutzen, über ein grosses Zukunftspotential verfügt.
Die Anpassung der SaaS-Anwendungen an die eigenen Bedürfnisse bis hin zur Entwicklung eigener Applikationen sowie die Integration dieser Lösungen in bestehende ICT-Umgebungen bilden die nächsten grossen Herausforderungen für Anbieter wie für Anwender. Google, Twitter und Flickr mit ihren verschiedenen APIs, Facebook mit den Plug-in-Applikationen, Salesforce mit ihrer SaaS-Entwicklungs- und -Betriebsplattform Force.com, aber auch Marc Andreessens Ning.com sind Beispiele für verschiedene Wege, diesen Herausforderungen zu begegnen.
Spielereien wie Flickrvision oder Twittervision sind einfache Beispiele für Anwendungen, die via API auf die Daten eines oder mehrerer SaaS-Anbieter zugreifen und diese in sogenannten Mashups zusammenfügen. Im professionellen Bereich können solche APIs eingesetzt werden, um zum Beispiel den Bestellstatus eines Inhouse-ERP-Systems an ein SaaS-CRM-System weiterzugeben oder um Daten wie Umsatz- und Marktentwicklung auf einer Karte von Google Maps anzeigen zu lassen.
Voraussetzung dafür ist natürlich das Vorhandensein eines solchen API für die zu integrierende SaaS-Anwendung. Zurzeit bieten unter den Anbietern von SaaS-Geschäftsanwendungen allerdings nur die wenigsten eine derartige Schnittstelle an, während bei den an privaten Anwendern orientierten Web-2.0-Diensten wie Flickr oder Facebook eine API längst zum guten Ton gehört. Dieser Umstand erschwert vielen professionellen SaaS-Anbietern den Markteintritt, denn wer will heute noch Insellösungen realisieren?
Die Integrationsmöglichkeiten stehen und fallen mit den Services, die eine API zur Verfügung stellt. Darum gilt es im Vorfeld eines Integrationsvorhabens genau zu prüfen, welche Dienste denn tatsächlich genutzt werden können. Google bietet zum Beispiel für ihre Mail-Anwendung «nur» API-Funktionen für die Migration der E-Mails von einem anderen Server an. Es fehlen dagegen Möglichkeiten, die eigentliche E-Mail-Applikation zu verwenden, während für Google Calendar umfangreiche Dienste für die direkte Manipulation der Kalenderdaten verfügbar sind. Das Salesforce.com-API ist bereits in der Version 11 vorhanden und lässt dem Entwickler fast keine Wünsche mehr offen. Auch die Amazon Web Services (Vorstellung siehe Seite 39) bieten umfangreiche APIs, was vor allem dadurch begründet ist, dass die Amazon-Angebote hauptsächlich für die Nutzung via API konzipiert wurden.
Facebook hat im Mai letzten Jahres mit ihrer Ankündigung, die bekannte Social Network Platform für die Integration eigener Applika-
tionen zu öffnen, ziemlich Furore gemacht. Das Spezielle am Facebook-API ist, dass Anwendungen so entwickelt werden können, dass sie nicht nur auf die Facebook-Funktionen und -Daten zugreifen können, sondern dass diese direkt innerhalb des Facebook GUI angezeigt und bedient werden können. Sie werden als Applikationsmodule innerhalb der Facebook-Plattform angeboten und sind für den User nicht von ori-
ginalen Facebook-Anwendungen zu unterscheiden. Der Code für diese sogenannten Facebook Apps läuft aber nicht innerhalb der Facebook-Infrastruktur, sondern irgendwo im Internet. Das heisst, der Programmierer muss sich selbst um die Betriebsumgebung kümmern. Ein ähnliches Modell verfolgt Google mit den Google Gadgets.
Bei den bis jetzt beschriebenen Möglichkeiten und Beispielen gibt es aus Sicht des Software-as-a-Service-Gedankens noch immer einen grossen Nachteil: Für den eigenen Code muss eine separate, oft in-house betriebene Umgebung gepflegt werden. Marc Andreessen, der ehemalige Netscape-Gründer, hat zu diesem Thema einen lesenswerten Blogartikel (http://blog.pmarca.com/2007/09/the-three-kinds.html) verfasst.
Er beschreibt dort die Konfusion, die zum Begriff Plattformen im Internet herrscht und definiert eine Level-3-Plattform als eine Laufzeitumgebung, in welcher der Code für die Applikation selbst läuft. Eine solche Betriebsplattform als Service bietet natürlich den grossen Vorteil, dass man sich als Entwickler vollständig auf die Anwendung, also auf das zu lösende Problem konzentrieren kann und sich um den sicheren und zuverlässigen Betrieb des Programms nicht kümmern muss. Andressens Social Network Service Ning.com bietet eine solche Plattform an. Amazon bietet mit EC2 zwar die Möglichkeit, eine Art virtuelle Recheneinheit als Service zu beziehen, allerdings ist das eher vergleichbar mit einem klassischen Server-Hosting, auch wenn der Service viel stärker automatisiert und virtualisiert aufgebaut ist als die üblichen Hosting-Angebote.
Als wichtigsten Anbieter in diesem Bereich ist derzeit allerdings auch wieder Salesforce.com zu nennen. Mit ihrer Plattform Force.com bietet Salesforce mittlerweile eine vollständige Applikationsentwicklungs- und Betriebsumgebung an, die es ermöglicht, beliebige Geschäftsanwendungen zu programmieren und als SaaS-Lösung anzubieten, ohne sich selber um die Infrastruktur kümmern zu müssen. Dabei werden die Grundfunktionalitäten wie User-Verwaltung, Datenmanagement, Workflows oder Reporting zusammen mit einer an Java orientierten Programmiersprache und den verschiedensten Entwicklertools – wie zum Beispiel Visualforce für die Entwicklung beliebiger GUI und Outputkanäle – in einer einzigen Umgebung bereitgestellt. Dabei sind die eigenen Applikationen auch wieder via API mit anderen Systemen integrierbar.
SaaS-Anbieter mit API und/oder Plattformen
Obwohl die Entwicklung zu Plattformen als Service noch in den Anfängen steckt, zeichnet sich doch eine allgemeine Tendenz zu vollständigen On-Demand-Lösungen ab. Auch wenn die Angebote
noch dünn gesät sind, ist es bereits heute möglich, komplexe Geschäftsanwendungen zu entwickeln und zu betreiben, ohne sich um die Infrastruktur kümmern zu müssen.
Die wenigsten Anbieter gehen heute soweit wie Salesforce.com, Amazon oder Ning, indem Sie den Entwicklern nicht nur APIs zur Verfügung stellen, sondern gleich die komplette Betriebsumgebung für die Ausführung von Programmcode. Es wird sich aber noch zeigen müssen, ob sich dieses Modell durchsetzen wird. Dies wird weitgehend davon abhängen, ob das Vertrauen der Entwicklergemeinde gewonnen werden kann.
Nicht so bei der Frage ob ein SaaS-Anbieter eine API bereitstellt. Dies ist definitiv eine kritische Anforderung an nahezu jede SaaS-Anwendung, denn ohne API keine zuverlässige Integration.
Mit den neuen Möglichkeiten, die sich durch die Verwendung von APIs ergeben, steigen allerdings auch wieder die Anforderungen an das nötige technische Fachwissen, um von diesen Funktionen Gebrauch zu machen. Wie die Bedeutung für die Abkürzung API, Application Programming Interface, schon ausdrückt, geht es darum, die SaaS-Anwendung per Computerprogramm anzusprechen. Das heisst, wer nicht programmieren kann, kann damit auch nicht viel anfangen.
Es gibt auch erste Ansätze, um das Erstellen von einfachen Mashups oder Schnittstellen ohne Programmierung zu ermöglichen. Microsoft Popfly, Yahoo Pipes, aber auch die einfachen Controls von Salesforce.com deuten in diese Richtung. Ganz ohne Programmierkenntnisse geht es aber auch hier nicht. Nichtsdestotrotz wird Komplexität reduziert. Vor allem dann, wenn der Code direkt auf der Plattform ausgeführt und gewartet werden kann. Eine Anwendung auf einer SaaS-Umgebung wie Force.com von Salesforce zu entwickeln, dauert um den Faktor 5 bis 10 weniger lang als in einer klassischen Applikationsentwicklungsumgebung.
Andreas von Gunten (www.andreasvongunten.com) ist Gründer von Parx, die auf Dienstleistungen rund um SaaS spezialisiert ist.
