Ohne API fehlt dir was

Es gibt inzwischen eine Vielzahl von APIs, die man in eigene Anwendungen einbinden kann. Allerdings muss man sich vorher im Klaren sein, was dies bedeutet. Themen wie die generelle Verfügbarkeit des Dienstes, zukünftige Einblendungen von Werbeinformationen oder Änderungen in den Schnittstellen müssen bei der Auswahl mit berücksichtigt werden. Gerade für Unternehmen, die auf Support angewiesen sind, ist das weitgehende Fehlen von Service Level Agreements (SLAs) noch ein Killer-Kriterium. Für die populären Dienste wie GoogleMaps, GoogleSearch oder Flickr benötigt man einen so genannten „API-Key“. Mit diesem Key werden die Dienstabrufe überwacht. Ein solcher Key ist für nichtkommerzielle Zwecke meistens problemlos zu bekommen. Für kommerzielle Zwecke sind die Regeln unterschiedlich und man sollte sich die Bestimmungen des jeweiligen Anbieters genau durchlesen. So weigerte sich z.B. vor einigen Monaten Flickr, einem Mitbewerbsdienst (Zoomr) einen kommerziellen API-Key zu überlassen. Dieses Vorgehen führte zu einem großen Aufschrei im Netz und inzwischen hat Flickr seine Bestimmungen ein wenig gelockert. Google bietet z.B. für den populären Dienst GoogleMaps auch eine kommerzielle Variante an. Mit diesem kostenpflichtigen Dienst erhält man sowohl Support als auch die Möglichkeit, GoogleMaps in Intranet-Anwendungen zu verwenden. Das Vorgehen, eine kommerzielle Variante des API (mit Support) anzubieten, ähnelt dem populären Dual-License-Geschäftsmodell in der Open-Source-Welt und wird sich sicherlich zunehmend verbreiten.

Durch die Verknüpfung der unterschiedlichen APIs entstehen die so genannten „Mashups“. Durch eine „Vermischung“ verschiedener Dienste lassen sich ganz neue Angebote oder gar eigenständige Applikationen entwickeln (Abb. 2). Auch innerhalb von Unternehmen lassen sich nun durch die Verknüpfung neuer Dienste (z.B. GoogleMaps) mit internen Daten neue Applikationen erstellen oder vorhandene (CRM-Lösungen, Marketing-Applikationen) aufwerten.

Als Auslöser für neue Geschäftsmodelle gilt gar Amazon S3. Amazon bietet über die S3-Plattform die Möglichkeit, die Datenhaltung einer Anwendung oder eines Unternehmens komplett auszulagern. Die bereitgestellten Zugriffsfunktionen sind sehr einfach gehalten (read, write, delete) und werden sowohl in Form von REST als auch als SOAP Web Services angeboten. Zur Nutzung der APIs ist, wie üblich, ein eindeutiger Schlüssel notwendig (API-Key). Über die API-Funktionen können Anwendungsdaten abgelegt oder heruntergeladen werden. Die gespeicherten Objekte können entweder für alle oder nur für einen bestimmten User-Kreis zugänglich gemacht werden. Inzwischen gibt es sowohl S3-Bibliotheken für die Einbindung der S3-Funktionalität in eigene Anwendungen als auch Utility-Programme, womit S3 dann im jeweiligen Betriebssystem als „Laufwerk“ verwendet werden kann. Für die Datenhaltung (Speicherung und den Datentransfer) nimmt Amazon einen geringen Cent-Betrag pro GB und ist mit den Preisen durchaus konkurrenzfähig. So haben bereits Unternehmen wie SmugMug ihre Daten von den eigenen Servern teilweise auf Amazon S3 ausgelagert und nach eigenen Angaben mehrere hunderttausend Dollar gespart. Amazon CEO, Jeff Bezos, erklärte in einem Interview anlässlich der MIT Emerging Technology Conference, dass Amazon mit diesem und den anderen Diensten gerade für neue Unternehmen die Infrastrukturprobleme lösen möchte, damit sich die Entwickler auf ihre Innovationen konzentrieren können. Die Anbieter der Web-2.0-APIs bieten diese meistens über eine REST- und/oder SOAP-Schnittstelle an. Allerdings muss der Anwendungsentwickler selten diese Schnittstellen direkt anprogrammieren, denn es existieren oft auch die entsprechenden Bibliotheken für eine einfache Anbindung in eigene Anwendungen.

Nicht noch ein Silo

Ein oftmals angesprochenes Problem bei der Einführung von Anwendungen innerhalb von Unternehmen ist die Schaffung neuer Datenhalden oder Silos. Auch durch die Installation eines Wikis hat man erstmal nur einen zusätzlichen Datentopf aufgestellt, der dann droht, genauso zu enden, wie die vorhandenen klassischen Datentöpfe. Gefragt ist daher vielmehr eine integrative Lösung, die es schafft, die vorhandenen Datentöpfe mit neuen Informationsquellen zu verknüpfen und die Vorteile aller Systeme zu behalten. Wohin die Reise in diesem Bereich gehen könnte, zeigt die junge österreichische Firma System One. System One bietet eine Plattform, die vorhandenen Search-APIs, wie die von Google oder Yahoo, mit Wiki- und Weblog-Funktionalität vereint. Zusätzlich ist die Plattform in der Lage, auch SAP-Dienste mittels SOAP zu integrieren. Der Benutzer arbeitet in einer einheitlichen Wiki-ähnlichen Oberfläche, und im Hintergrund werden die APIs zur Laufzeit herangezogen, um z.B. bei Eingabe von Text in einem Dokument parallel andere Informationsquellen nach passenden Ergänzungen zu durchforsten und anzubieten.

Alles schon mal da gewesen?

Vor einigen Jahren blickte die Enterprise-Welt gebannt wie die Schlange vor dem Kaninchen auf das neue Paradigma „Software as a Service“ oder „SaaS“. Firmen wie Salesforce.com traten auf, um etablierten Softwarelieferanten die Stirn zu bieten. Damals galt das Angebot als Revolution, da die Software nicht mehr installiert werden musste, sondern von einem Provider gehostet wurde. Auch waren keine Lizenzzahlungen notwendig, sondern es wurde nach einem Abo- oder Subscription-Modell, je nach Nutzer oder Nutzung, abgerechnet. Inzwischen haben auch etablierte „On demand“-Anbieter wie Salesforce.com die Zeichen der Zeit erkannt und werben inzwischen aktiv mit dem Web 2.0 Buzz-Word. Im Kern ist Salesforce.com eine gehostete CRM-Lösung, die übers Web mittels Browser bedient werden kann. Allerdings hat die Firma schon im vergangenen Jahr die Weichen für eine Wandlung der Applikation hin zu einer „Business Application Architecture“ gestellt und bietet über „AppExchange“ die Möglichkeit, zusätzliche Anwendungen in die eigene Salesforce-Umgebung zu integrieren. Lösungsanbieter können ihre Applikationen über AppExchange verfügbar machen und so die Plattform erweitern. Mit „Apex“ kündigt Salesforce.com bereits den nächsten Schritt seiner Offensive an. Durch die Verfügbarkeit einer eigenen Programmiersprache soll es Anwendungsentwicklern ermöglicht werden, neue Applikationen direkt in der Salesforce-Umgebung zu implementieren und ablaufen zu lassen. So können diese neuen Anwendungen dann auch die bereitgestellten Salesforce-APIs direkt vom Server aus nutzen.

Heute schon gibt es Anwendungsbeispiele, wie sich durch die Verknüpfung von GoogleMaps und Salesforce entsprechende unternehmensnahe „Mashups“ erstellen lassen. Die Öffnung traditionell abgeschotteter Anwendungen ist eine Tendenz, die durch Web 2.0 beschleunigt wird; so bietet z.B. auch eine bekannte „Web 1.0“-Anwendung wie der AOL Chat Client die Möglichkeit, auf Funktionalität mittels API zuzugreifen. Auch SAP hat den Enterprise-2.0-Trend erkannt, und so passiert im SAP-Umfeld inzwischen einiges, um z.B. Web 2.0 Frameworks wie Ruby on Rails oder auch AJAX zu integrieren. SAP verfügt inzwischen über ein großes Blog-Netzwerk, und auch Formate wie RSS werden schon lange in Waldorf verwendet, um Informationen zur Verfügung zu stellen.

Warum überhaupt?

Wie andere Unternehmen hat SAP erkannt, dass Kunden oder auch Mitarbeiter zunehmend Web-2.0-Technologien kennen und auch anwenden wollen. Es reicht eben nicht mehr aus, als interaktives Medium ein E-Mail-Kontaktformular anzubieten. Die Aufnahme von Web 2.0 durch Unternehmen wird schneller erfolgen als noch bei Web 1.0, da die darunter liegende Infrastruktur in den Unternehmen bereits vorhanden ist. Allerdings müssen Unternehmen aufpassen und sich die richtigen Web-2.0-Technologien aus der Suppe an Möglichkeiten herauspicken. Sie müssen evaluieren, welche Technologien zu ihrer Unternehmenskultur passen, um nicht kostspielige Fehltritte zu riskieren. Auch zeigen die teilweise sehr pragmatischen Vorgehensweisen in der Web-2.0-Welt durchaus Wege auf, die man in ähnlicher Form in Unternehmen hineintransportieren kann. Zusätzlich besteht für Unternehmen die Herausforderung, auch an ihrer internen Organisation die entsprechenden Veränderungen vorzunehmen. Schließlich sollen die Web-2.0-Technologien gerade das gemeinsame, vom „miteinander“ geprägte Arbeiten erleichtern und nicht noch dazu dienen, vorhandene organisatorische Barrieren zu verstärken.