Dieser Artikel ist zuerst erschienen in IT Management, Ausgabe 11/2005. Download des PDF mit freundlicher genehmigung des Verlags.
Download PDF

Anstatt alle IT-Services selbst zu erbringen, finden sich IT-Abteilungen oft in der Rolle wieder, Outsourcer zu steuern. Dabei trägt die IT-Abteilung die Verantwortung für das Zusammenspiel aller Teilleistungen – sie ist der Service-Integrator. Ohne eine zugrundeliegende Service-Architektur ist dies ein riskantes Spiel. Mit diesem Beitrag diskutieren wir die Einführung von komponentenbasierten Service-Architekturen.

Bisher waren IT-Abteilungen darum bemüht, die Anzahl der Lieferanten gering zu halten. Es galt als Idealfall, nur einen Lieferanten zu haben, der als General-Outsourcer alle Leistungen erbringt. Das ist bequem, weil die Aufgabe der Service-Integration dem Dienstleister übertragen wird.

Jedoch hat die Erfahrung gezeigt, dass so eine hohe Abhängigkeit von diesem Lieferanten besteht, dass auch die Schwächen dieses Lieferanten mit eingekauft werden, und dass die eingekauften IT-Services nicht optimal auf die Anforderungen des Unternehmens zugeschnitten sind.

Wie viele Lieferanten sollte eine IT-Abteilung haben?

In dieser Situation ist es legitim, zu überdenken, ob die Strategie, möglichst wenige Lieferanten zu haben, die richtige ist. In vielen Bereichen der Wirtschaft ist es üblich, zahlreiche Lieferanten unter einen Hut zu bringen. Die Bandbreite der Beispiele dafür reicht vom Automobilkonzern bis zum Bauherren eines Einfamilienhauses. „Best of breed“ ist das Motto, bei dem die IT-Abteilung Teilleistungen einkauft, die sie nicht selbst erbringen möchte, und zwar bei dem Lieferanten, der diese Teilleistung zu den besten Konditionen erbringen kann.

Dadurch ergeben sich folgende Vorteile:

  • Da die Anzahl der eingekauften Services steigt, reduziert sich entsprechend der Umfang einer jeden Leistung. Die IT-Services sind dadurch besser handhabbar, leichter zu spezifizieren und zu überwachen.
  • Es werden großteils Commodity-Dienstleistungen eingekauft, für die eine Preistransparenz am Markt besteht. Die im Einkauf erzielten Preise sind besser als bei großen Leistungspaketen, deren Umfang nicht vergleichbar mit den Angeboten der Wettbewerber ist.
  • Die Lieferanten sind leichter austauschbar. Dadurch ist der Auftraggeber weniger abhängig von seinen Lieferanten und die Lieferanten sind bemüht, gute Qualität zu liefern.

Der Preis für diese Vorteile ist, dass der Auftraggeber sich um die Integration der eingekauften Services kümmern muss. Das sollte jedoch nicht als lästig Pflicht angesehen werden, sondern vielmehr wird die Service-Integration zur Kernkompetenz von IT-Abteilungen.

Unternehmensinterne IT-Dienstleister kennen und verstehen die Anforderungen der Fachabteilungen, aber auch die Unternehmenskultur und -politik. Diesen Wissensvorsprung gegenüber externen Dienstleistern nutzt die IT-Abteilung, um auf die Anforderungen abgestimmte IT-Services aus am Markt verfügbaren Commodity-Services und eigenen Teilleistungen zusammen zu bauen. Das ist das „Geschäftsmodell IT-Service-Integrator“.

Ob die Erbringer der einzelnen Teilleistungen externe Lieferanten sind, die ihre Leistungen am freien Markt anbieten, oder ob es sich dabei um unternehmensinterne Organisationseinheiten handelt, ist irrelevant. In der Regel werden beide Formen auftreten und für den Service-Integrator sind alles Lieferanten. Der Service-Integrator erfüllt die Anforderungen des Kunden an den IT-Service durch die geschickte Kombination zugekaufter Teilleistungen. Bei diesem Geschäftsmodell wird eine höherwertige Dienstleistung dadurch geschaffen, dass mehrere Teilleistungen integriert werden.

Der Service-Kunde möchte das Beziehungsnetzwerk, durch das die konsumierte Dienstleistung erbracht wird, aber nicht kennen müssen. Der Kunde, also die Fachabteilung, möchte einen einzigen Ansprechpartner haben, der die Verantwortung übernimmt. Der Service-Integrator hat die Aufgabe, die verschiedenen Teilleistungen aufeinander abzustimmen, sprich: deren Zusammenspiel sicherzustellen. Dieses Geschäftsmodell wird in der Literatur auch Hub Model genannt und ist in Bild 1 dargestellt.

Das Management des Lieferantennetzwerks

„Make-or-buy“-Entscheidungen stehen bei IT-Dienstleistern ständig auf der Tagesordnung, um das eigene Dienstleistungsportfolio zu optimieren. Obwohl die Lieferantenbeziehungen einen wichtigen Teil in der Strategie eines jeden IT-Dienstleisters haben, ist das Partner-Management noch eine recht junge und wenig ausgereifte Disziplin bei den IT-Dienstleistern.

IT-Service-Provider hängen in großem Maße von ihren Lieferanten ab. IT-Services, wie Dienstleistungen allgemein, unterscheiden sich wesentlich von Produktionsgütern. IT-Services können nicht auf Vorrat produziert werden, sondern werden in Echtzeit erbracht. Die Erbringer von Teilleistungen arbeiten nicht in einem definierten Prozess mit diskreten Fertigungsschritten nacheinander an dem Produkt, sondern müssen zeitgleich zusammenarbeiten. Die Qualitätssicherung von IT-Services erfolgt nicht als Prozess mit eigenem Zeitfenster, sondern während die Dienstleistung erbracht wird. Die Herausforderung liegt in der Kontinuität, mit der IT-Services betrieben werden müssen.

Während beim Aufbau einer Lieferantenbeziehung viel „Handarbeit“ gefordert ist, bestehen im operativen Bereich gute Ansätze zur Automatisierung:

  1. Beim Fulfilment, also dem Beauftragen und einrichten neuer IT-Services im Rahmen einer bestehenden Geschäftsbeziehung.
  2. Beim Assurance, also der kontinuierlichen Qualitätssicherung. Während das Fulfilment sich nicht wesentlich von Bestellvorgängen anderer Branchen unterscheidet, unterscheidet das Assurance die Dienstleistungen von Produktionsgütern.

Eine besondere Herausforderung ist die Service-Konfiguration. Um die einzelnen Komponenten sinnvoll aufeinender abzustimmen, ist eine detaillierte Kenntnis über deren Funktionalität und Zusammenspiel nötig. Die reine Prozessintegration über mehrere Organisationen hinweg reicht dafür nicht aus. Vielmehr muss ein Wissensmodell dieser Service-Komponenten den beteiligten Partnern Auskunft geben können über das Verhalten, die Voraussetzungen und die Konfigurationsmöglichkeiten der Service-Komponenten.

Bild 1: Der Service-Integrator erfüllt die Anforderungen des Kunden an den IT-Service durch die geschickte Kombination zugekaufter Teilleistungen. (Quelle: Advicio)

 

Eine komponentenbasierte Service-Architektur als Basis der Integrationsaufgabe

Damit hochwertige IT-Services aus Teilleistungen unterschiedlicher Leistungserbringer aggregiert werden können, müssen die Teilleistungen aufeinander abgestimmt sein. Es muss eine Service-Architektur zugrunde liegen, welche die Integration der Service-Komponenten ermöglicht. Ziel ist es, die einzelnen Service-Bausteine in einem Service-Katalog so zu spezifizieren, dass ein Zusammenspiel möglich ist, auch wenn die Teilleistungen von unterschiedlichen Dienstleistern erbracht werden.

Das Erstellen eines solchen Service-Katalogs beginnt häufig mit einer Bestandsaufnahme. Dabei wird eine Dekomposition komplexer Services durchgeführt, um überschaubare Teilleistungen zu erhalten. So entsteht eine umfangreiche Sammlung von Service-Komponenten. Einige hundert, manchmal über tausend Teilleistungen sind im Rahmen des üblichen. Eine solche Sammlung von Service-Komponenten ist noch keine Service-Architektur, weil die Komponenten nicht kompatibel zueinander sind. An dieser Stelle muss ein Entwicklungsprozess einsetzen, durch den die Komponenten aneinander angepasst werden. Nur so können die Komponenten in einem Netzwerk gegenseitiger Abhängigkeiten zusammenarbeiten. Die beiden häufigsten Ursachen von Inkompatibilitäten sind:

  1. Eine unterschiedliche Terminologie. Beispielsweise wenn für eine Komponente „QoS“ definiert ist, obwohl Verfügbarkeit gemeint ist. Und wie ist eigentlich „Verfügbarkeit“ definiert? Eine gemeinsame Sprache muss durch ein Glossar geregelt sein.
  2. Grundsätzliche Design-Aspekte. Dies betrifft einheitliche Regelungen für Verfügbarkeiten, Betriebszeiten et cetera. Sind solche Parameter für jede Service-Komponente individuell festgelegt, so ist es mutig bis riskant, für einen daraus aggregierten Service eine Qualitätsgarantie abzugeben.

 

Bild 2: Die Service-Taxonomie ist ein essentieller Bestandteil der Service-Architektur. Das Bild zeigt das Vorgehen zur Entwicklung einer Service-Taxonomie. Ausgehend von einer Basisklassifikation werden dieser die identifizierten Service-Komponenten zugeordnet und neue Oberklassen gebildet. (Quelle: Advicio)

Anzahl der Service-Komponenten minimieren

Typischerweise sind es auch zu viele Service-Komponenten. Eine reiche Auswahl ist in einem gut sortierten Service-Baukasten erwünscht. Allerdings wirken sich mehrfach erfasste, identische Service-Komponenten kontraproduktiv aus. Erfahrungsgemäß kann die Anzahl durch Konsolidierung um 15% reduziert werden. Je nach Historie des IT-Dienstleisters – insbesondere Fusionen wirken sich aus – kann die Konsolidierung auch weit größere Effekte haben.

Des weiteren hilft die Einführung von Varianten, die Anzahl zu minimieren. Allerdings ist die Entscheidung, ob zwei ähnliche Service-Komponenten Varianten voneinander sind, oder ob es sich doch um verschiedene Service-Komponenten handelt, nicht trivial. Advicio empfiehlt diesbezüglich folgende Regelung: Varianten haben eine identische Funktionalität und unterscheiden sich lediglich in der Qualität (Verfügbarkeit, Bereitstellungsdauer, Betriebszeit, etc.), in der Kapazität und im Preis beziehungsweise in den Kosten.

Übersicht gewinnen durch Strukturierung

Im nächsten Schritt sollte die Übersichtlichkeit erhöht werden, indem die Service-Komponenten in sinnvolle Gruppen eingeteilt werden (Bild 2). Doch nach welchem Kriterium soll gruppiert werden? Drei Ansätze sind augenscheinlich möglich:

  1. Nach der Organsiationsstruktur, also welche Einheit die Leistung erbringt.
  2. Nach der verwendeten Technologie.
  3. Nach der durch den Service bereitgestellten Funktionalität.

Eine Reihe von Gründen spricht für die Funktionalität als Kriterium für die Gruppenbildung. So entsteht aus den Teilleistungen „Betrieb Oracle“, „Betrieb DB2“ und „Betrieb MySQL“ die Gruppe „Betrieb RDBMS“.

Die Gruppe ist eine Oberklasse. Wir bezeichnen diese auch als abstrakte Service-Komponente. Abstrakte Service-Komponenten können nicht instantiiert werden, hingegen können konkrete Service-Komponenten wie „Betrieb MySQL“ tatsächlich umgesetzt werden. Die abstrakten Oberklassen dienen lediglich der Strukturierung des Komponentenkatalogs.

Entsprechend kann nun wiederum für mehrere Gruppen eine gemeinsame Oberklasse gefunden werden, so dass letztlich alle Service-Komponenten in einer übersichtlichen Baumstruktur einsortiert sind. Eine solche Struktur nennen wir eine Service-Taxonomie (Bild 3).

 

Bild 3: Durch das Gruppieren der Service-Komponenten nach ihrer Funktionalität entstehen abstrakte Oberklassen. Der so gebildete semantische Zusammenhang ist der Vorteil gegenüber einer Liste, in der die Teilleistungen zusammenhanglos aufgeführt sind. (Quelle: Advicio)

Semantischen Beziehungen der Service-Komponenten zueinander

Wie in Bild 3 zu sehen ist, entstehen jede Menge dieser abstrakten Oberklassen, deren Namen gemäß UML-Notation kursiv geschrieben werden. Was ist der praktische Nutzen von diesem Overhead?

Eine Service-Architektur unterscheidet sich von einer reinen Ansammlung unterschiedlicher Service-Komponenten durch die Beziehungen der Service-Komponenten zueinander. Durch die Service-Taxonomie werden die semantischen Beziehungen der Service-Komponenten hergestellt. Dadurch wird semantisches Wissen erfasst. Wenn man Beispielsweise nicht wüsste, was „MySQL Operation SC“ sein könnte, so verrät die Taxonomie, dass es sich um den Betrieb einer relationalen Datenbank handelt.

Die semantischen Beziehungen helfen auch im IT-Service-Engineering bei der Spezifikation von Service-Komponenten. Soll etwa definiert werden, dass ein Anwendungsservice die Betriebsdienstleistung einer relationalen Datenbank erfordert, ohne festlegen zu wollen, welche dies ist, so wird auch auf eine abstrakte Oberklasse verwiesen. Man erhält dadurch einen Freiheitsgrad, den man ohne Taxonomie nur durch wartungsintensive Konfigurationsregeln erreichen könnte.

Vererbungsmechanismen, um Standards und Konsistenz zu wahren

Aus der objektorientierten Software-Entwicklung sind die Vererbungsmechanismen bekannt, die sich nun auch beim IT-Service-Engineering bewähren. Damit können Eigenschaften bei den abstrakten Service-Komponenten definiert werden und gelten dann durch die Vererbung für alle davon abgeleiteten Service-Komponenten. Zwei Beispiele dazu:

  • Wir definieren ganz oben in der Taxonomie, dass es zwei Qualitätsvarianten geben soll: Standard und Premium. Durch Vererbung gilt dies für alle Service-Komponenten.
  • Alle Betriebsdienstleistungen in der Standard-Variante haben Betriebszeiten zu Bürozeiten, die Premium-Varianten 24×7. Dies wird in der Operation Service Component definiert und von dort vererbt.

Diese Beispiele verdeutlichen, dass die Vererbung dazu führt, Service-Komponenten gewissen Standards und Vorgaben folgend zu spezifizieren. Wie eingangs festgestellt, ist das die Voraussetzung dafür, aufeinender abgestimmte, integrierbare Service-Komponenten – eben eine Service-Architektur – zu erhalten.

Ein weiterer Nutzen ist, dass die Entwicklung neuer Service-Komponenten wesentlich schneller geht, weil sie auf bereits bestehenden aufsetzen und lediglich in Details angepasst werden müssen.

Lieferantensteuerung durch Service-Spezifikationen

Das Entwickeln solcher Service-Architekturen und die damit verbundene Spezifikation der Dienstleistungen sind ein Aufwand, den IT-Abteilungen teils zunächst scheuen. Die Investition in ein solches Projekt lohnt sich aber, denn sie ist „enabler“ für das Geschäftsmodell IT-Service-Integrator und gibt Transparenz über den Leistungserbringungsprozess. Aber auch wenn die IT-Abteilung noch mit überwiegend einem Outsourcer zusammenarbeitet, ist die detaillierte Spezifikation der Services ein großer Vorteil. Denn erstens müssen die Teilleistungen des Outsourcers mit den eigenen integriert werden, und zweitens sind die Spezifikationen die Regeln in dem Spiel, das IT-Abteilung und Outsourcer spielen. Entwickelt die IT-Abteilung (der Service-Integrator) die Service-Architektur und die Spezifikationen, dann wird nach ihren Regeln gespielt. Ansonsten diktiert der Outsourcer die Regeln.

Die Thematik der Lieferantensteuerung gewinnt mit steigendem Kostenbewusstsein an Relevanz. IT-Dienstleister tun gut daran, den Lieferanten einen angemessenen Platz in ihrer Strategie einzuräumen und deren Integration schon heute konsequent voranzutreiben. Automatisierung der Zusammenarbeit muss in diesem Bereich mittelfristig umgesetzt werden. Ein freier Handel standardisierter IT-Dienstleistungen hat bereits eingesetzt. Wir erwarten, dass die Supply-Chain-Automation für IT-Dienstleister bis 2009 zur „conditio sine qua non“ wird.

Prof. Dr. K.-P. Fähnrich, Tonio Grawe