Innovation durch Mashups

Klassische Business-Anwendungen oder neuartige Mashups? Beide haben ihre Vorteile, also warum nicht einfach das IT-Budget splitten und beides nutzen? Wichtig ist es für Unternehmen aber in jedem Fall, die neuen Möglichkeiten ernst zu nehmen und nicht als technische Spielerei abzutun. Bei Web 2.0-Communities sind viele der neuen Anwendungen bereits etabliert, erlauben sie doch eine neue, individuellere Nutzung der IT im Unternehmen. Für eine flexible Reaktion auf Marktbedürfnisse sollten Unternehmen sich die Innovationen also nicht entgehen lassen.

1. Executive Summary

Unter „Mashup“ versteht man die Verknüpfung von mehreren modularen Diensten (Datendiensten oder funktionalen Diensten) zu einem neuen Dienst, der völlig neue Anwendungsbereiche erschließt und gegenüber den einzelnen Dienstemodulen einen Mehrwert bietet.

Durch die Nutzung von Mashups können schnell und einfach externe Dienste und Informationen in unternehmenseigene Web-Angebote und Applikationen integriert werden. Zahlreiche Web-2.0 Anbieter nutzen bereits Mashup-Technologien für die Erweitung des Funktionsumfangs ihrer Seiten, z.B. mit Google Maps.

Es liegt nahe, die Vorteile von Mashup-Applikationen auch in Unternehmen zu nutzen. Obwohl es bei der Verwendung von Mashups für die klassische Massendatenverarbeitung Probleme hinsichtlich Sicherheit, Governance und Performance gibt, können Mashups klassische IT-Anwendungen durch die flexible Verbindung mit unternehmensinternen und – externen Datenquellen bereichern.

Darüber hinaus ermöglichen Mashups der Unternehmens-IT, ihren Nutzern größere individuelle Freiheit bei der Gestaltung und Nutzung von Applikationen einzuräumen. Mashups helfen hierbei, die gegenläufigen Ziele von IT-Betrieb (z.B. Zentralisierung und Standardisierung) und IT-Nutzern (z.B. Individualisierung basierend auf Eigenentwicklungen) in Einklang zu bringen. Durch den Aufbau einer zentralen Mashup-Plattform und eines geeigneten Anreizsystems für gemeinsame Mashup Entwicklungen innerhalb der Mashup-Community können Unternehmen den Entwicklungs- und Betriebsaufwand von Mashups zusätzlich reduzieren.

Mashups in Unternehmen sind nicht nur ein technisches Thema für den Umbau bestehender oder die Schaffung neuer Applikationen. Der CIO eines Unternehmens kann mit Mashups gezielt die Individualisierung der IT fördern und sie insgesamt effizienter gestalten. Dazu bedarf es einer Unternehmenskultur, in der Anreize zur Entwicklung von Mashups geschaffen werden, so dass alle Unternehmensbereiche davon profitieren können.

2. Ein Anwendungsfall

Die Verknüpfung von Telefonie-, Informations- und Workflow-Diensten im Unternehmen

Ein Lieferant ruft bei einem Unternehmen an. Das angerufene Unternehmen betreibt keine eigene Telefonanlage, sondern bezieht seine Telekommunikations- und seine CRM-Dienste (Customer Relationship Management) in Form von Software-as-a-Service (SaaS).

Das CRM-System und die Telefonanlage verfügen über offene Programmierschnittstellen und sind über Mashup-Technologien miteinander verknüpft. So steuert bei dem Anruf des Lieferanten die Telefonanlage das CRM-System an, um den Anrufer zu identifizieren und relevante Informationen auszulesen. Die Mashup-Anwendung stellt fest, dass es sich um einen bekannten Lieferanten handelt, daher wird der Anruf zum Einkauf weitergeleitet. Durch die Verwendung von Web- und Mashup-Technologien muss das Unternehmen für diese Verknüpfung keinerlei eigene Applikations- und Middleware-Infrastruktur betreiben, sondern kann CRM-System, Telekommunikation und Integrationsplattform in die kostengünstige „Cloud“ verlagern.

Sobald der Anruf durchgeleitet wird, verknüpft und präsentiert ein Mashup auf dem Rechner
des Mitarbeiters Informationen zu dem Anrufer aus verschiedensten Daten-Quellen, wie CRM-, Warenwirtschafts- und Finanzsystemen. Durch die Verwendung von Standard-Web und Mashup-Technologien zeigen die Browser bei Anrufeingang auch den Firmenstandort des Anrufers auf Google-Maps an und liefern basierend auf Google News die neuesten Nachrichten zum anrufenden Unternehmen.

Zusätzlich hat der Angestellte, zu dem der Anruf durchgestellt wird, individuell das Mashup mit Informationen aus anderen externen Quellen (wie z.B. aktuelle Wechselkursdaten aus Internet-Finanzdiensten) ergänzt. Das Unternehmen unterstützt aktiv diese Form der individuellen Datenverarbeitung, indem es ein Mashup-Design-Tool und ein Repository der schon verfügbaren individuellen Erweiterungen zur Verfügung stellt.

Um eine schnelle Rücksprache mit Kollegen zu ermöglichen, wird ein Instant-Messaging- Client eingebunden, inklusive der Präsenzinformationen aller Kollegen, die ebenfalls schon mit dem Lieferanten Kontakt hatten.

Darf der Angestellte die Entscheidung nicht alleine treffen, werden die wichtigsten Daten über den Lieferanten und sein Angebot als RSS-Feed zusammengestellt und an einen Collaboration-Dienst weitergereicht.

Möglicherweise kann der Angestellte den Kauf aber auch gleich abschließen. Dafür sind in seinem Browserfenster alle notwendigen Funktionen der B2B-(Ver-)kaufsplattform eingebunden.

3. Was sind Mashups?

Definition von Mashups

Wie unser Anwendungsfall zeigt, versteht man unter „Mashup“ die Verknüpfung von mehreren modularen Diensten (Datendiensten oder funktionalen Diensten) mit Hilfe von offenen Schnittstellen zu einem neuen Dienst, der völlig neue Anwendungsbereiche erschließt und gegenüber den einzelnen Dienstemodulen einen Mehrwert bietet.

Die Dienstemodule können serverbasiert integriert werden, d.h., der Client bekommt die Ergebnisse der Dienste-Verknüpfung von einer Mashup-Plattform zugesandt. Oder die Integration erfolgt clientbasiert, d.h. der Client zapft mehrere Dienstequellen an und integriert die Daten selbst (beispielsweise per Javascript im Browser).

Anwendungsbereiche von Mashups

Mashup-Applikationen werden meist mit Websites in Verbindung gebracht, auf denen Dienste verschiedener anderer Anbieter nahtlos integriert sind. Bekannte Beispiele sind:

– Google Maps: Integration von Kartenmaterial in eigene Web-Angebote

– Facebook: Export von Fotos und personenbezogenen Daten

– Amazon: Extraktion von Preisen oder ähnlichen Produkten zur Nutzung in anderen Webservice-Diensten

Webseiten, die Inhalte und Services über solche Mashup-Dienste anbieten, richten sich meist an den Endverbraucher (B2C – Business to Consumer). Sowohl die Anbieter solcher Seiten (Business) als auch die Nutzer (Consumer) haben durch eine Integration von Mashups viele Vorteile, die u.a. in „Die Mischung macht’s“ von J. Ewers, Detecon Management Report 2/2009 beschrieben sind.

Mashups für Consumer

Dies sind Mashups, die sich vornehmlich direkt an Internet-Nutzer richten. Die B2CEndkunden eines Unternehmens oder Nutzer einer Webseite profitieren so von den Vorteilen, die Mashup-Applikationen bieten. Es handelt sich um Mashups, die einen Service auf Basis von öffentlichen zugänglichen Schnittstellen und evtl. eigenen Business-internen APIs (Application Programming Interface, deutsch: „Schnittstelle zur Anwendungsprogrammierung“) generieren und diesen dem Endkunden bzw. Privatkunden anbieten. Ein Beispiel ist der Dienst Google Maps, mit dem eine mit eigenen Daten angereicherte Karte auf der eigenen Plattform/Webseite angezeigt werden kann.

Es liegt nahe, die Vorteile von Mashups auch für B2B-(Business-to-Business)-Anwendungen zu nutzen. Können Mashups auch im Rahmen von klassischen Business-Applikationen in Großunternehmen eingesetzt werden? Falls ja, was sind die Vorteile und unter welchen Rahmenbedingungen ist ihr Einsatz möglich?

Mashups in Unternehmen (Business-Mashups)

Nur ein kleiner Teil der IT-Services eines Unternehmens wird direkt von Endkunden genutzt. Fast alle IT-Services dienen zur Unterstützung der primären oder sekundären Geschäftsprozesse. Aber auch hier ergeben sich Möglichkeiten zum Einsatz von Mashups, die sich nur indirekt an Enduser richten.

1. Durch die Verknüpfung verschiedener Webservices unterschiedlicher Anbieter können ganz neue Angebote für den Endkunden zusammengestellt werden. Voraussetzung hierfür ist eine Partnerschaft zwischen mindestens zwei Unternehmen bei der Nutzung von Schnittstellen zur Anwendungsprogrammierung (API) und die Bereitstellung einer Plattform für Mashup-Building und -Selling. Im eingangs skizzierten Anwendungsfall waren dies der Telekommunikations- und der CRM-Dienstleister.

2. Auch sind Mashups als Ergänzung oder sogar als Ersatz von klassischen Business-Applikationen denkbar. Mit einer Service Oriented Architecture (SOA) gehen Unternehmen schon einen Schritt in diese Richtung. In diesen Fällen befinden sich die Nutzer im Unternehmen und die zum Mashup gehörenden Web Services und APIs sind nur unternehmensintern zugänglich (oder werden von Partner-unternehmen eingebunden). Solche Mashups müssen allerdings die Organisations-, Sicherheits- und Governance-Richtlinien des Unternehmens erfüllen.

3. Eine dritte Möglichkeit, Mashups in Unternehmen zu nutzen, ist die Unterstützung der individuellen IT für Nutzer. Mit entsprechenden Webservices und APIs können schnell und einfach Informationen aus Business-Applikationen verknüpft und verarbeitet werden. Beispielsweise können Marktdaten aus externen Quellen in ein unternehmensinternes Data Warehouse importiert werden.

Für die Erzeugung von Mashups existieren Tools, mit denen verschiedene Webservices einfach zu Mashups verknüpft werden können. Während Microsoft sein Angebot „Popfly“ nach zwei Jahren im August 2009 eingestellt hat, gibt es mit „Yahoo Pipes“ weiterhin die Möglichkeit, auch ohne tiefer gehende Programmierkenntnisse Mashup-Applikationen zu erstellen.

4. Auswirkungen von Business-Mashups

4.1. Schnelligkeit, Innovation, Vielfalt, Spezialisierung

Mit Hilfe von Mashups können Applikationen vergleichsweise schnell erweitert werden. Es können Anforderungen abgedeckt werden, für die es sich bisher nicht gelohnt hat, eine Client-Server-basierte oder lokal laufende Applikation zu entwickeln oder für die dies aus Zeitgründen nicht möglich war.

Für die Bereitstellung von (Nischen-)Anwendungen, die nur von wenigen Nutzern benötigt werden, können Mashup-Applikationen im Rahmen der individuellen IT genutzt werden (s. Kapitel Individualisierung der IT).

Einfache Applikationen mit einer nur kurzen Lebensdauer werden mit Hilfe von Mashups schnell und einfach erstellt. In dem einleitenden Anwendungsfall wäre das beispielsweise eine einmalige Feedback-Aktion, bei der die Lieferanten einen externen Fragebogen-Service nutzen, der per Mashup in die Unternehmens-IT integriert wird.

Mit Mashups können schnell integrierte Dienste entwickelt werden. Existierende Anwendungen werden über entsprechende, definierte API in eigene Angebote eingefügt. Auch bei der Zusammenführung unternehmensinterner und -externer Informationen und Dienste können Mashups wertvoll sein. So kann das Unternehmen im eingangs beschriebenen Anwendungsfall mit Web-Services unternehmensexterne Informationen, wie Zahlen zu Markt- und Branchenentwicklungen, in sein Data Warehouse integrieren.

Wesentliche Vorteile von Mashup-Applikationen sind:

– Kurze Einführungszeit durch einfache und flexible Anwendungsentwicklung, Design-Tools für die einfache Erzeugung von Mashups (z.B. Yahoo Pipes)

– Standard-API für die Integration neuer Dienste in eigene Web-Angebote. Web 2.0-Technologie verschmilzt Inhalte zu einem neuen Ganzen

– Web-Technologien und verbesserte Nutzbarkeit durch moderne, webgestützte Oberflächen

– Nutzung einer Entwickler-Community, die neue Dienste hinzufügt und existierende Dienste weiterentwickelt

4.2. IT-Betriebsorganisation, Sicherheit, Authentifizierung, Datenschutz und Governance

Für den Kunden zählen – egal ob klassische Applikationen oder Mashups genutzt werden – Leistung, Kosten und Sicherheit. Das sichere Funktionieren einer Applikation ist für Unternehmen umso wichtiger, je stärker sie in die Geschäftsprozesse integriert ist.

Waren bisher meist spezielle Organisationseinheiten eines Unternehmens für die Entwicklung und den Betrieb von Business-Applikationen verantwortlich (oder tragen die Verantwortung für entsprechend outgesourcte Leistungen), ist die Lage bei Mashup- Applikationen komplexer.

Einzelne Web Services können von Unternehmensteilen oder auch verschiedenen Unternehmen genutzt werden. Es stellt sich die Frage, wer Mashups zusammenstellt (orchestriert) oder steuert. Müssen sie überhaupt zentral gesteuert werden? Wer genehmigt Veränderungen von Mashups, wer verwaltet sie?

Für den sicheren Betrieb von Business-Applikationen gibt es verschiedene Rahmensysteme wie beispielsweise ITIL. Wichtig für den zuverlässigen Betrieb sind u.a Verfügbarkeit, Vertraulichkeit, Integrität und Zurechenbarkeit. Darüberhinaus müssen die typischen Bedrohungen für Informationssysteme abgewehrt werden (siehe Abbildung 1).

Abbildung 1: Typische Bedrohungen für Informationssysteme (Quelle: Detecon)

In der klassischen IT werden die oben genannten Risiken schon bei der Entwicklung durch etablierte Vorgaben und Prozesse minimiert. Für den Betrieb der Applikation ist genau geregelt, wer für welche Module der Applikation betriebsverantwortlich ist. Für Schnittstellen werden zur Regelung der Zuständigkeiten häufig Kontrakte geschlossen, die von den beteiligten Applikations-Verantwortlichen unterzeichnet werden. Im Rahmen der ITGovernance wird die Wirksamkeit der entsprechenden Prozesse sowohl während der Entwicklung als auch im Betrieb der Software regelmäßig von einer zentralen Stelle kontrolliert, ggf. werden Verbesserungsmaßnahmen ergriffen.

Bei sich schnell ändernden und dynamisch entwickelten Mashup-Netzen ist es aber schwierig, diese Rahmenbedingungen sicherzustellen. Für Mashup-Applikationen in Unternehmen müssen dieselben Grundsätze wie für klassische Business-Applikationen gelten. Andernfalls sind die Grundanforderungen an die IT-Sicherheit nicht erfüllt.

Hauptproblem bei Mashups ist, dass die Partner nicht wissen, was mit zur Verfügung gestellten Daten passiert und in welchen anderen Mashups sie ggf. auch benutzt werden. Die entstehende Landschaft aus Webservices, API und Mashup Design-Tools wird von unterschiedlichen Organisationen entwickelt und betrieben. Die Sicherheitanforderungen müssen von allen beteiligten Systemen, Schnittstellen und Betriebsorganisationen eingehalten werden. Jedoch wird die Sicherheit nicht durch eine zentrale Einrichtung kontrolliert, so dass auf Dritte vertraut werden muss.

Für jede einzelne Komponente des Mashups müssen Kontrakte und Vereinbarungen getroffen werden, um dieselben Anforderungen wie an klassische Business-Applikationen erfüllen zu können. Die einmaligen Kosten für die Implementierung der entsprechenden Prozesse und die laufenden Kosten für Überwachung und Kontrolle sind aufgrund der Vielzahl der beteiligten Partner nicht zu vernachlässigen.

Vor der Verwendung von Mashups im Unternehmen sind daher folgende Fragen zu klären:

Datenschutz/IT-Sicherheit

– Wer überprüft das Gesamt-Mashup auf Einhaltung der datenschutzrechtlichen Anforderungen? Wer stimmt das mit dem Betriebsrat der beteiligten Unternehmen ab?

– Werden personenbezogene Daten verarbeitet? Wenn ja, wo werden sie gespeichert? Wer ist für sie verantwortlich?

– Wie findet die Authentifizierung statt? Gibt es eine zentrale oder dezentrale Benutzerverwaltung, findet Verschlüsselung statt? Sind Passwörter sicher gespeichert?

IT-Governance

– Wer ist für den Betrieb der einzelnen Teile des Mashups verantwortlich?

– Wer führt den Betrieb durch? Wer kontrolliert den Betrieb?

Service Levels

– Wer verhandelt Service Levels? Gibt es umfassende Service Level Agreements (SLAs)?

– Wer überprüft die SLAs?

– Wer trägt welche Konsequenen, wenn SLAs nicht eingehalten werden?

Die Sicherheits-, Betriebs- und Governance-Anforderungen an Business-Applikationen für
Mashups müssen beurteilt werden und der Aufwand für die erstmalige Erfüllung der
Anforderungen und ihre nachhaltige Einhaltung ist zu beziffern.

Performance

Die Performance von Applikationen nimmt ab, je mehr Schnittstellen und Verarbeitungsbzw. Präsentationsschichten in einem Applikationsverbund vorhanden sind. Alte Mainframe- Anwendungen, die monolithisch angelegt sind, haben in der Regel eine sehr gute
Performance, schon allein weil sie entstanden, als die Verarbeitungsgeschwindigkeit von Rechnern stark beschränkt war und sie daher sehr effizient realisiert wurden. Bereits ERP-Systeme mit ihren zahlreichen Plausibilitätschecks und ihrer Client-Serverbasierten Datenverarbeitung sind trotz wesentlich leistungsfähigerer Hardware erheblich langsamer bei der Verarbeitung von Massendaten als Mainframe-Systeme.

Bei einer Verwendung von Mashups zur Massendatenverarbeitung sinkt die Performance weiter. Durch die starke Abstraktion und die große Distanz von den zu Grunde liegenden Services entsteht ein großer Overhead. So müssen bspw. Verschlüsselung und Authentifizierung implementiert werden, was bei einer klassischen Anwendungsarchitektur einfacher zu realisieren bzw. nicht notwendig ist. Zahlreiche Verarbeitungs- und Präsentationsschichten werden z.T. auf unterschiedlichen Rechnern genutzt und müssen koordiniert werden. Für die klassische Massendatenverarbeitung ist bei der Verwendung von Mashups daher mit erheblichen Performance-Einbußen zu rechnen und es sollte besser auf Architekturen zurückgegriffen werden, in denen die Komponenten direkter gekoppelt sind (z.B. ERP-Systeme).

4.3. Individualisierung der IT

In jedem großen Unternehmen gibt es eine Vielzahl von kleinen, mit (Microsoft) Office- Makros und anderen „einfachen“ Mitteln vom End-Nutzer erstellten Mini-Applikationen, die einzelnen Mitarbeitern das Leben erleichtern („Individuelle Datenverarbeitung“). Diese „Applikationen“ sind meist schlecht oder gar nicht dokumentiert; keine Betriebsorganisation verantwortet diese Lösungen. Sie sind vielmehr abseits der etablierten Entwicklungs- und Genehmigungsprozesse für Applikationen „nebenbei“ durch Mitarbeiter entstanden, und haben trotzdem oft eine tragende Rolle in den Geschäftsprozessen: Sei es durch wichtige Auswertungen aus Business-Applikationen, durch die Erstellung von Reports oder durch spezielle Daten-Aggregationen und Filterungen.

Bei einer Umstellung von Office-Releases, der Versetzung oder dem Ausscheiden des Mitarbeiters, der sich um die Lösung kümmert, oder bei einem Problem im Betrieb ist es anderen Kollegen meist nicht möglich, die Applikation zu verstehen, zu verbessern oder Fehler zu beheben: Die Lösungen sind nicht dokumentiert, die Dateien auf der Festplatte des Mitarbeiters oder unbekannten Netzlaufwerken abgelegt.

Dadurch ist es den IT-Verantwortlichen auch nicht möglich, solche „Schwarzbauten“ zu inventarisieren. Sie verbergen sich in Office-Dokumenten, die im ganzen Unternehmen verstreut sind. Die Konsequenzen eines Office-Releasewechsels sind daher schwer abzuschätzen. Niemand weiß, wie viele individuelle Anwendungen existieren, wie oft sie genutzt werden, wie wichtig sie für Geschäftsprozesse sind und wer sie betreibt.

Durch den Einsatz von Mashup-Applikationen und auf Grund der Tatsache, dass immer mehr Office ähnliche Funktionalitäten ins Web wandern, können Unternehmen die Situation allerdings verbessern: Mitarbeiter programmieren ihre individuelle Software nicht mehr Client-seitig mit Hilfe von Office, sondern können z.B. mit „Yahoo Pipes“ ähnlich einfach wie mit Office-Makros eigene benutzerdefinierte Mashups erstellen.

Mashups bieten vor allem für die einfache Erstellung und Verarbeitung von Daten aus zentralen Business-Applikationen interessante Ansätze: Zum Beispiel sind für ein optimiertes Risikomanagement die relevanten internen und externen Informationen schnell und flexibel bereitzustellen. Dazu müssen häufig Datenexporte aus ERP-Systemen nach bestimmten Kriterien gefiltert, aggregiert oder gruppiert werden, um neue Berichte zu erzeugen. Wenn Daten dann auch noch aus verschiedenen Applikationen kommen oder mit unternehmensexternen Daten angereichert werden sollen, ist das für die Mitarbeiter mit der Standardsoftware nur schwer durchzuführen. Gelöst wird eine solche Aufgabe dann häufig über aus dem ERP-System exportierte Text-Dateien, die anschließend mit Excel, Access und Co. weiterverarbeitet werden.

Durch die Nutzung von Mashups optimieren Unternehmen solche Vorgänge: Anstatt Listen im Text Format aus ERP-Systemen zu exportieren, werden berechtigten Nutzern Daten als Web-Services angeboten. Diese Nutzer können dann mit Hilfe von Mashups die Daten verarbeiten und auch mit unternehmensinternen oder -externen Informationen aus anderen Applikationen ergänzen. Informationen aus Data Warehouses werden mittels Webservices schnell und flexibel mit Daten aus weiteren Quellen angereichert.

Wenn das Unternehmen eine Mashup-Plattform als offizielle Anwendung anbietet, auf der die Mitarbeiter ihre individuellen Webservices und Mashups entwickeln können, entstehen eine Reihe von Vorteilen:

– Automatische Inventarisierung aller individuellen Entwicklungen, da sie auf der Plattform hinterlegt sind.

– Releasewechsel sind einfacher möglich, da nicht in einem „Big Bang“ die gesamte Office-Plattform umgestellt wird, sondern die einzelnen Web- Applikationen mit ihren definierten Schnittstellen sich entkoppelt umstellen lassen.

– Unternehmensexterne Daten z.B. von Branchendiensten, Marktforschungsinstituten, Börsen oder Banken lassen sich einfach einbinden.

– Im Gegensatz zur institutionalisierten Anwendungsentwicklung bleiben die Vorteile der individuellen Softwareentwicklung erhalten, den Überblick verliert das Unternehmen jedoch nicht.

So kann die „U-Boot-Flotte“ von nicht inventarisierten und trotzdem oft unternehmenswichtigen individuellen IT-Applikationen in eine definierte Mashup-Umgebung überführt werden. Bei mittelfristig immer wieder anstehenden Releasewechseln von Office- Produkten und Konsolidierungen ist eine individuelle IT in Form von Mashups vorteilhaft.

5. Mashups im Kontext von Enterprise 2.0

5.1. Aufbau einer Mashup-Community

Mashups haben ihren Ursprung in der Welt des Web 2.0. Dort ermöglichen und fördern Mashup-Technologien offene Communities bei der Entwicklung neuer Dienste. Analog dazu sollte ein Unternehmen die Effektivität und Akzeptanz der Mashup-Anwendungen durch den Aufbau einer Mashup-Community steigern. Eine Anwendung der Web 2.0-Paradigmen innerhalb von Unternehmen wird allgemein auch als Enterprise 2.0 bezeichnet. Viele Unternehmen haben sich dazu entschlossen, ein Enterprise 2.0-Konzept zu entwickeln und durchzusetzen. Der Aufbau einer Mashup-Community sollte in diesem Fall Bestandteil der Strategie sein.

Anders als im Web 2.0, wo die Communities meist öffentlich sind und neben den eigentlichen Dienste- bzw. Mashup-Providern ausdrücklich sämtliche Internet-User ansprechen, werden die Communities der Business-Mashups nicht öffentlich sein und aus den Mashup-Usern des Unternehmens sowie aus den internen bzw. externen ITDienstleistern bestehen. Mashup-User können dabei Unternehmensmitarbeiter sein, aber auch Unternehmenspartner, wie beispielsweise Subunternehmen, selbständige Partner oder Kunden. Die Aufgabe des Business-Mashup-, Dienste- bzw. Plattform-Providers (also z.B. einer unternehmensinternen IT-Abteilung) wird es sein, die grundlegende Community- Infrastruktur (Wikis, Blogs, Foren, Collaboration-Tools, etc.), wie auch die Entwickler- und Laufzeitumgebung für Mashups zu stellen.

Sowohl die Unternehmensmitarbeiter (als Mashup-User) als auch die Unternehmens-IT haben ein großes Interesse daran, die Mashup-Infrastruktur zu nutzen und werden sich daher aufgrund ihrer Eigeninteressen aktiv an der Community beteiligen.

Das Unternehmen sollte durch einfach zu bedienende Entwickler-Tools, fertige Templates (Mashup-Grundgerüste) und ein Mashup-Repository (ähnlich dem „App-Store“ von Apples IPhone) die Aktivität der Nutzer und das Sharen von Mashup-Ideen bzw. –Anwendungen bestmöglich unterstützen. Durch das Bereitstellen von Mashup-Entwicklertools und Laufzeitumgebungen als SaaS stellt das Unternehmen zudem sicher, dass die entwickelten Mashups in einem zentralen, für jeden verfügbarem Repository abgelegt werden und somit die Community-Mitglieder Mashups nicht nur nutzen sondern auch Neuentwicklungen unternehmensweit bereitstellen.

Anders als unternehmensinterne Mashup-User werden externe Unternehmenspartner zwar die Flexibilität und Einfachheit der Mashup-Technologien schätzen, aber der Community eigene neue Mashup-Kreationen nicht automatisch zur Verfügung stellen. Auch wird bei den Partnern Bedarf für eine Client-seitige Mashup-Ausführung bestehen. Hier wird es also eher von den vorherrschenden Firmenkulturen (z.B. wie verankert ist der OpenSource-Gedanke im Unternehmen) in den Partnerunternehmen abhängen, ob diese sich mit neuen Inhalten in die Community einbringen werden. Viele Community-User werden auch nur dann Mashups anderen zur Verfügung stellen, wenn sich Geben und Nehmen die Waage halten, z.B. indem hochgeladene Mashups von der Community verbessert werden. Allerdings besteht hier ein Henne-Ei-Problem: Eine Möglichkeit zur Lösung wäre zum Beispiel, dass der Community-Provider (also z.B. eine interne IT-Abteilung) die Rolle des Power-Users übernimmt und eine Anzahl von „Start-Mashups“ bereitstellt bzw. aktiv bei der Verbesserung von neuen Mashups mitwirkt. Einen anderen Weg zur Förderung des Mitmachens (über monetäre Anreize) beschreibt das folgende Kapitel.

5.2. Leistungs-Verrechnung als Anreiz zur Beteiligung in der Community

Business-Mashups und zugehörige Dienste werden wie jede andere IT-Leistung innerhalb des Unternehmens verrechnet, schon allein, um ihre Kosten verursachungsgrecht zu verteilen. Sind gar externe Dienstleister involviert, ist eine Abrechnung der Mashup- Leistungen ohnehin unerlässlich. Um ein Verrechnungsmodell zu definieren, das Mashup- Benutzer motiviert, sich aktiv in die Mashup Community einzubringen, müssen zunächst die Akteure des Eco-Systems „Business-Mashup“ identifiziert werden. Diese sind:

– Der Betreiber eines Dienstes (API-Provider): Seine Leistung ist der Betrieb der Systeme, die Funktionen und/oder Daten bereitstellen. Über APIs werden die Dienste in Mashups integriert.

– Der Mashup-Provider: Er stellt die Mashup-Laufzeitumgebung und Support- Tools bereit, wie z.B. API-Datenbank, Mashup-Repository, Community- Plattform und Entwicklungs-Tools.

– Der Mashup-Entwickler: Seine Leistung ist die Integration verschiedener Dienstemodule zu einer Mashup-Anwendung, mit einem Mehrwert für den Benutzer gegenüber Einzeldiensten.

– Die Mashup-User: Sie nutzen den Mashup-Dienst.

Eine Verrechnung kann sich demgemäß auf folgenden Modelle stützen:

Modell 1: Kostenmodell

Der Mashup-Nutzer beauftragt den Entwickler, eine Mashup-Anwendung nach seinen Anforderungen zu bestimmten Konditionen und Kosten zu erstellen. Werden Dienste des Mashup-Providers genutzt (z.B. Mashup-Laufzeitumgebung bei Server-seitigen Mashups), wird der Mashup-Provider dem Nutzer diese Kosten in Rechnung stellen. Zusätzliche Kosten fallen für die Benutzung der Schnittstellen der API-Provider an. Abhängig von der IT-Organisation des Unternehmens können API- und Mashup- Provider identisch sein. Darüber hinaus sind auch Mashups denkbar, die APIs externer Anbieter integrieren. Hier ist es gut vorstellbar, dass der Mashup-Provider die zentrale Verrechnungsstelle für den Mashup-Nutzer (beispielsweise eine Fachabteilung) ist und die weitere Abrechung mit den API-Providern (interne und externe) übernimmt.

Abbildung 2: Kostenmodell (inks) und Anreizmodell (Quelle: Detecon)

Modell 2: Anreizmodell

In diesem Modell werden die Entwickler stärker in das Verrechnungsmodell einbezogen. Der Entwickler stellt seine Mashup-Lösung den potenziellen Nutzern zur Verfügung (z.B. indem er sie in das Repository des Mashup-Providers stellt). Bei Nutzung des Mashups rechnet der Provider mit dem Nutzer ab, und er beteiligt neben dem API-Provider auch den Entwickler.

Dieses Modell ist insbesondere interessant, um z.B. Entwicklern eines Partnerunternehmens Anreize zu geben, Mashups, die sie für den „Eigenbedarf“ erstellen, die aber auch andere Partner nutzen könnten, der gesamten Community zur Verfügung zu stellen.

Beispielsweise könnte das Anreizmodell in einem Unternehmensverbund von Franchisegebern und -nehmern Anwendung finden (Abb. 2). Ein Franchisenehmer- Unternehmen könnte so seine ursprünglich für sich entwickelten Mashups bei dem Franchisegebern-Unternehmen (der als Mashup-Provider fungiert) zur Verbreitung einstellen. Andere Franchisenehmer-Unternehmen könnten dann diese Mashups gegen Entrichtung einer Gebühr vom Mashup-Provider beziehen. Da der Mashup-Provider an den ursprünglichen Entwickler eine Provision ausschüttet, besteht für diesen der Anreiz, Mashup-Neuentwicklungen dem Provider und damit anderen zur Verfügung zu stellen.

Abbildung 3: Anreizmodell (Quelle: Detecon)

Das Kostenmodell wird bei kleineren Unternehmen oder bei Unternehmen, die ein sehr heterogenes Partnergeflecht aufweisen, zum Tragen kommen, da es in diesen Fällen unwahrscheinlich ist, dass mehrere Unternehmenspartner oder -abteilungen gleichartige Mashup-Anwendungen benötigen.

Dagegen ist das Anreizmodell vorteilhaft für Unternehmen, die eine Vielzahl von ähnlichen B2B Beziehungen pflegen. Allerdings wird das Anreizmodell immer nur eine Ergänzung des Kostenmodells sein. So können beispielsweise Mashups, die sehr spezifische Unternehmensprozesse unterstützen sollen, ausschließlich nach dem Kostenmodell in Auftrag gegeben werden.

6. Schlussfolgerung und Empfehlungen

CIOs sollten die Möglichkeiten, die sich durch Mashups ergeben, ernst nehmen. Mashups sind nicht nur eine weitere technische Spielart zur Gestaltung von Anwendungssystemen, sondern erlauben eine neue, individuellere Nutzung der IT im Unternehmen.

Mashup-Applikationen spielen ihre Vorteile vor allem dann aus, wenn Daten oder Dienste von unterschiedlichen Anbietern einfach und flexibel in Webseiten integriert werden sollen. Bei Web 2.0-Communities sind Mashups bereits etabliert, zum Beispiel bei der Integration von Kartenmaterial in eigene Web-Angebote. Generell können Applikationen, die sich direkt in Richtung Consumer richten (B2C), stark von Mashups profitieren. Durch eine schnelle Integration vorhandener Funktionalitäten kann flexibel auf Marktbedürfnisse reagiert werden. Durch Tools zur Erstellung von Mashup-Applikationen (z.B. Yahoo Pipes) wird die Schwelle zur Integration von Webservices in eigene Mashups noch weiter gesenkt.

Als neue technische Plattform für Business-Applikationen eignen sich Mashups jedoch nur bedingt: Zu groß sind die erforderlichen organisatorischen und Governance-Anstrengungen, um eine mit klassischen Business-Applikationen (z.B. ERP-Systeme, SAP, Mainframes) vergleichbare Leistung und Qualität zu erzielen.

Für die Massendatenverarbeitung, wie sie in Großunternehmen und zunehmend auch bei Mittelständlern an der Tagesordnung ist, dürfte die Performance von Mashup-Applikationen nicht ausreichen. Die Einhaltung von Service Level Agreements und die Anforderungen an Compliance und Governance können von Mashup-Applikationen nur mit großen Anstrengungen dauerhaft erfüllt werden.

Klassische Business-Applikationen werden also auch weiterhin ihre Daseinsberechtigung haben. Mashups können Business-Applikationen jedoch vor allem im Reporting und bei der Integration von Daten aus unternehmensexternen Quellen oder anderen Applikationen ergänzen. So können neue Datenquellen via Webservices einfach integriert werden.

Folgende Empfehlungen ergeben sich aus den Einsatzmöglichkeiten von Mashup- Applikationen:

– Individuelle IT (z.B. in Form von Office-Makros), die meist schlecht zu warten ist, keiner Governance unterliegt und deren Sicherheit bedenklich ist, aber die trotzdem oft in Business-Prozessen eingesetzt wird, sollte mittelfristig ersetzt werden. Mashups bieten hier die Möglichkeit, die nutzergetriebene Individualisierung der IT beizubehalten und dabei die entstehenden Web- Services systematisch zu verwalten und wiederverwendbar einzusetzen.

– Die Möglichkeiten bei der Inventarisierung und Governance individueller ITLösungen durch die Nutzung von Mashups sollten genutzt werden. Die bislang ungeregelten bzw. nicht vorhandenen Entwicklungs- und Betriebsprozesse für individuelle IT-Lösungen sollten durch eine geordnete und in die ITGovernance des Unternehmens eingebundene Vorgehensweise abgelöst werden, ohne die individuellen Wünsche der Nutzer zu vernachlässigen.

– In zunehmenden Maße gibt es Tools, mit denen sich Mashup-Applikationen einfach erstellen lassen. Diese sollten in Pilotprojekten getestet und zur Einführung von Mashups genutzt werden.

– Um die Entwicklungen und Aktionen der individuellen IT zu bündeln, sollten Unternehmen – z.B. im Rahmen ihrer Enterprise 2.0-Strategie – den Aufbau von Mashup-Communities forcieren. Anreize für Geschäftspartner, ebenfalls ihren Beitrag in der Community zu leisten, können durch adäquate Verrechnungsmodelle geschaffen werden. Darüberhinaus kann durch die Einführung von Verrechungsprozessen eine höhere Transparenz entlang der Wertschöpfungskette von Mashup-Diensten erzielt werden.

– Business-Applikationen können sehr gut von Mashups profitieren, da mit ihrer Hilfe schnell und einfach unternehmensexterne Daten oder auch Daten aus anderen Applikationen eingebunden werden können. Zu prüfen ist hier, inwiefern Mashups existierende Schnittstellen verbessern und ob sich kostengünstig neue Mashup-Schnittstellen erstellen lassen.

– Zur Ablösung von Anwendungssystemen der Massendatenverarbeitung sollte die Mashup-Technologie aber nur in Ausnahmefällen genutzt werden; zu groß sind die Risiken bei Performance, Governance und Sicherheit.

Dieser Artikel erschien am und wurde am aktualisiert.
Nach oben scrollen