Monthly Archive for August, 2007

Ansätze zur ROI-Messung für SOA-Projekte

Die Ermittlung eines Return-of-Investment (ROI)-Wertes für SOA-Projekte ist in der Tat alles andere als einfach. Neben einer in der Regel nur auf Spekulationen ausgelegten Nutzwertbetrachtung auf der Ebene der Geschäftsprozesse ist ferner auch eine eindeutige Zuordnung von Kosten dadurch erschwert, dass die in SOA-Projekten eingesetzten Integrationstechnologien fast immer multifunktional ausgerichtet sind. Im Klartext bedeutet dies, dass SOA-Technologien – wie z.B. auch klassische Middleware-Technologien – immer mehreren Zwecken dienen, und deren zuordenbare Kosten demnach nicht nur auf das entsprechend betrachtete SOA-Projekt beschränkt sind. Gerade im Zusammenhang mit der Ermittlung von Betriebs- und Wartungskosten wird diese Problematik zu einem Dilemma für die Aufstellung einer objektiven und korrekten ROI-Betrachtung.

Doch wie können diese Herausforderungen bewältigt werden?

Der potentielle SOA-Wertbeitrag umfasst sowohl die Nutzen- als auch die Kostenseite:

NUTZEN: Steigerung der Veränderungsfähigkeit und der Agilität
- Verbesserte Reaktionsgeschwindigkeit in Bezug auf Veränderungen
- Verbesserte Dienstleistungserbringung

KOSTEN: Wiederverwendung und „Sharing“
- Verminderung der Kosten durch Effizienz- und Skaleneffekte
- Höhere Performanz durch verbesserte Konsistenz und Visibilität

Da – wie oben bereits ausgeführt – eine direkte Zuordnung des auf Steigerung der Effektivität bezogenen SOA-Nutzens äusserst schwierig ist, empfiehlt Gartner diesen ROI-Aspekt erst vollständig im Rahmen einer Projektnachbetrachtung durchzuführen. Hier sollten ausgewählte Performanz-Indikatoren, wie z.B. „Time-to-Market“ oder „Umsatz“, vor Projektbeginn gemessen werden und dann nach Abschluss des Projektes einer vergleichenden Nachbetrachtung unterzogen werden.

Anders gestaltet sich die Betrachtung in Bezug auf mögliche, kostenrelevante Produktivitätsvorteile, die mit SOA-Projekten verbunden sind: hier können bereits vor Projektbeginn ganz konkrete Effizienzpotentiale in den Bereichen Anwendungsentwicklung und Anwendungsintegration geschätzt werden. Eine mögliche Reduzierung der Kosten ist in diesen Bereichen an Einsparungen durch Wiederverwendung von Applikationskomponenten und vor allem Schnittstellen gekoppelt. Hier können die zukünftigen Gesamtaufwendungen für die Entwicklung und Wartung von Anwendungen durch systematische SOA-Integration um 25-40% gesenkt werden (Basis: vorläufige empirische Untersuchungen). Dabei gilt die Regel: je höher die Schnittstellenkomplexität, je höher das Einsparungspotential.

Abschliessende Einschränkung: potentielle SOA-Wertbeiträge sind zunächst immer relativ und abhängig von der Konsequenz der späteren Nutzung!

SOA-Methologie für erfolgreiche IT-Projekte

Die SOA-Methologie ist eine wichtige Komponente innerhalb eines SOA-Projekts, die das Zusammenspiel aller strategischen und taktischen Schritte beschreibt. Sie umfasst also das gesamte Vorgehen in einem SOA-Projekt von der strategischen Steuerung über die operative Umsetzung bis hin zur fortlaufenden Optimierung.

Insbesondere große Konzerne arbeiten sehr strukturiert an einem IT-Bebauungsplan mit Hilfe eines Enterprise-Architektur-Management-Werkzeugs (EAM). Die SOA-Methologie setzt bereits hier ein und entwickelt aus der vorhandenen IT-Governance eine SOA-Governance. Beispielsweise entscheiden Unternehmen hierbei, welche Personen welche Geschäftslogik zur Wiederverwendung innerhalb der Service-Landschaft anbieten dürfen. So kann aus der SOA-Methologie auch eine ganz neue Mitarbeiter-Rolle entstehen, wie die eines Service-Portfolio-Managers als oberster Editor des SOA-Repository/Registry.
Continue reading ‘SOA-Methologie für erfolgreiche IT-Projekte’

„Es muss nicht überall „SOA“ draufstehen, wo SOA drin ist“: die Rollen und Verantwortlichkeiten eines Integration Competence Center

Neben dem Aufbau einer viel zu hohen Erwartungshaltung und einer ungeeigneten Technologieauswahl gehören unzureichende Organisationsstrukturen und Governance zu den Hauptgründen des Scheiterns von SOA-Projekten. Die Spannbreite der Fehlentwicklungen beeinhaltet die folgenden Situationen:

  1. „Wild West SOA“: Wahllose Verbreitung von Services ohne formelle Rahmenbedingungen
  2. „Duplicated SOA“: Wildwuchs durch Duplizierung von Services (statt: „Re-Use“)
  3. „Shelfware SOA“: Keine durchgängige Nutzung von Services

Gartner geht davon aus, dass nur auf der Basis eines kontrollierten Governance, die SOA-Ziele – nämlich u.a. konsequente Wiederverwendung und Vermeidung unnötiger Duplizierung – auch erreicht werden können. Zu den wichtigsten Koordinationsaufgaben der SOA-Governance zählen:

  • Definition und Anpassung von Geschäftsprozessen, die durch SOA-Technologien unterstützt werden sollen
  • Definition, Entwicklung, Zugriff, Ausführung, Betrieb und Wartung von wiederverwendbaren Services
  • Identifikation der benötigten Service-Level und entsprechender Zugriffsrechte
  • Festlegung der Service-Ownership und einer angemessenen Kostenverteilung
  • Bestimmung von Richtlinien und Verantwortlichkeiten für alle SOA-relevanten Tätigkeiten (siehe obige Punkte)
  • Messung des Grades der Wiederverwendung und Compliance sowie die Spezifizierung von Anreizen zur permanenten Verbesserung des Richtlinieneinhaltung.

Diese Aufgaben der SOA-Governance werden in vielen Unternehmen in einem sogenannten SOA Center of Excellence (SOA CoE) zusammengefasst. Vor allem für unternehmensübergreifende und grosse Projekte empfiehlt sich ferner eine Erweiterung des Aufgabenspektrums um die Rollen und Verantwortlichkeiten, welche sowohl zentral als auch dezentral innerhalb eines übergreifenden Integration Competence Centers (ICC) wahrgenommen werden:

Abbildung 1: Rollen und Verantwortlichkeiten eines Integration Competence Centers (ICC)

Eine Zusammenarbeit zwischen Fachabteilungen und IT findet in diesem Zusammenhang vor allem innerhalb der Aktivitätenblöcke „Enterprise Architecture“ und „Business Analysts“ statt. Hier werden koordiniert durch das SOA CoE die Rahmenbedingungen für die zu implementierenden Geschäftsprozesskonzepte gemeinsam festgelegt.

Service Systems

Im Zentrum einer SOA steht der Service. Selbstverständlich steht im Rahmen einer Software-Architektur der technische Service, der mit einer Web Service Schnittstelle versehen ist, im vordergrund. Der Service kann jedoch auch etwas genereller betrachtet werden; im weiteren Sinn als Dienstleistung. Was für den technischen Service eine SOA darstellt ist für den nicht-technischen Service ein Service System.

Was sind Service Systeme?

Service Systeme versehe ich als Netzwerke bestehend aus Menschen, Technologie und Organisationen mit dem Ziel, wertschöpfende Leistungen zu erbringen. Die Schaffung solcher Netzwerke wird in naher Zukunft einen neuen Berufzweig beschäftigen – den Service Engineer. Unter dem Begriff Service-Sciences Management and Engineering (SSME) entstehen zurzeit auf internationaler Ebene eine Reihe von Initiativen.

Ein Service ist mehr als ein Web Service

Aus technischer Sicht ist ein Service eine sich selbst beschreibende, offene Komponente, die eine schnelle und kostengünstige Zusammenstellung von verteilten Anwendungen ermöglicht. In einer SOA stellt der Service einen Schritt in einem ausführbaren Geschäftsprozess dar. Der ausführbare Geschäftsprozess wird in BPEL (Business Process Execution Language) modelliert, der Service selbst wird als standardisierter Web Service realisiert. Ein technischer Service ist in jedem Fall eine Unterstützungsfunktion für eine betriebliche Tätigkeit. Aus betrieblicher Sicht ist ein Service “eine Veränderung des Zustandes einer wirtschaftliche Entität – einer Person oder einer Ware -, die durch die Aktivität einer anderen wirtschaftlichen Entität im Einverständnis mit der zu verändernden Entität durchgeführt wird.” So definiert das neue Produktklassifikationssystem der USA den Service. Der Begriff “Service” stammt aus den 30er Jahren des letzten Jahrhunderts. Diejenigen Branchen, die nicht in die Bereiche Produktionsgewinnung (Landwirtschaft) und Produktionsverarbeitung (Herstellung) passten, wurden unter “Service” zusammengefasst, der auch als “Tertiärer Sektor” definiert wird. Die Aktivität in diesem Sektor sind sehr breit, sie umfassen Bereiche wie die öffentliche Verwaltung, das Gesundheitswesen, die Finanzen, den Verkehr, die Bildung, die Kommunikation und das Business. Eines ist jedoch jedem Service gemeinsam, es ist in jedem Fall ein Netzwerk bestehend aus Menschen, Technologie und Organisationen mit dem Ziel, wertschöpfende Leistungen zu erbringen.

Die Konsequenzen der ökonomischen Bedeutung des Service

Der tertiäre Sektor oder auch der Dienstleistungssektor ist die dominante Form ökonomischer Tätigkeit, die in hoch entwickelten Ländern bis zu 80% eines BIP ausmacht. Die enormen Produktivitätssteigerungen in der Landwirtschaft und in der Güterherstellung sind nicht zuletzt dadurch bedingt, dass Menschen, die beispielsweise in der Landwirtschaft gearbeitet haben, neu in wissensintensiven Berufen tätig sind, die die landwirtschaftliche Produktion unterstützten. So sind spezialisierter Branchen, wie die Herstellung von hochwertigem Saatgut, der Produktion von Landwirtschaftsmaschinen, der Organisation von Warenterminbörsen, Logistikbetriebe und Verwaltungen, entstanden. Dieselbe Entwicklung hat die industrielle Produktion durchlaufen. Die dominante Form ökonomischer Tätigkeit ist der Service. Diese Tätigkeit unterscheidet sich grundlegend von der Warenproduktion. Der zentrale Gegenstand eines wirtschaftlichen Austausches ist nicht mehr eine Ware, sondern ein immaterieller Gegenstand, die Dienstleistung. Im Gegensatz zum Warenaustausch bedingt die Bereitstellung von Services einen möglichst detaillierten Austausch von Kontextinformationen. Eine gute Dienstleistung ist optimal auf das Geschäft des Kunden abgestimmt. Dies bedeutet, dass der Leistungserbringer das Geschäft des Kunden möglichst gut verstehen muss. Ein weiterer wichtiger Unterschied ist der Charakter der Service-Transaktion. Der Austausch wird durch beide Parteien gleichzeitig initiiert und die Leistungserbringung und der Leistungsbezug erfolgt parallel. Die Tiefe der Beziehung zwischen dem Leistungserbringer und dem Kunden hängt von der Art des Kunden ab. Ein B2B Service bedingt eine langfristige und umfassende Beziehung, während B2C Services auf episodische Bedürfnisse ausgerichtet sind. Zentrales Element einer Servicebeziehung ist der Austausch von explizitem und implizitem Wissen zwischen allen Beteiligten. Der Austausch des expliziten Wissens ist durch den Datenaustausch bereits heute möglich, wenn auch die entsprechenden formalen Standards und die notwendige Transparenz der Unternehmen erst in Zukunft – beispielsweise mit SOA – realisiert werden wird. Der Austausch des impliziten Wissens gestaltet sich jedoch wesentlich schwieriger. Das klassische Beispiel für implizites Wissen ist die Fähigkeit Fahrrad zu fahren. Es ist sehr einfach, zu zeigen, wie man ein Fahrrad fährt, es ist jedoch sehr aufwändig, diese Fähigkeit explizit zu beschreiben. Das implizite Wissen eines Unternehmens macht jedoch in vielen Fällen den strategischen Marktvorteil der Firma aus. Der Austausch dieses Wissen wird neue Arten der Interaktion zwischen Leistungserbringer und Kunden erfordern.

Der Service Engineer der Zukunft und seine Hilfsmittel

In Zukunft werden Services mehr und mehr als zentraler Bestandteil der unternehmerischen Tätigkeit anerkannt und organisiert werden, so werden neben bestehendenn F&E Abteilungen und Produktfactories neue Service Creation Groups Entstehen. Service Systems werden zu einer wichtigen Grundlage der Unternehmensstrategie und es wird ein neuer Berufsstand entstehen; der Service Engineer. Er ist für die Innovation von Services und für die Überwachung der Leistungserbringung zuständig. Ausserdem ist er der Impulsgeber für die Transformation von Unternehmen von der traditionellen Produktionsstätte in Richtung Service System Provider. Sein wichtigstes Hilfsmittel sind Informationssysteme, die den Austausch von expliziten und impliziten Informationen während der Serviceleistung erlauben. Diese Informationssysteme unterstützen die Innovation von Services durch die Bereitstellung von Instrumenten, die eine dynamische Modellierung Sozio-Technologischer Systeme beispielsweise durch “Agent-Based Modelling” erlauben. Solche Modelle werden dann in Geschäftsprozesse abgebildet und als ausführbare Prozesse in die entsprechenden IT-Systeme umgesetzt. Während der Austausch von expliziten Informationen durch “Service based Computing” bereits absehbar ist, wird der Austausch impliziter Informationen den Einsatz neuer Technologien in Unternehmen und Organisationen mit sich bringen. So ist ein Service System als Netzwerk nur dann vollständig, wenn alle Beteiligten in Echtzeit implizite Informationen austauschen, sich also bei der Arbeit gegenseitig über die Schultern schauen können, unabhängig davon, wo sie sich gerade aufhalten. Dies wird durch den Einsatz von Technologien, wie beispielsweise einer Weiterentwicklung der Second Life Plattform für Unternehmen oder der Anpassung von Online Game Engines für Service Value Chains, möglich.

SOA – Sein oder Nichtsein?

IT sollte kein Selbstzweck und auch keine isolierte Insel im Unternehmen sein. Ihre Aufgabe ist es, mit möglichst kurzen Reaktionszeiten informationstechnische Strukturen aufzubauen und anzupassen, um alle zentralen Aspekte professioneller Betriebswirtschaft wie Performance-Management, Risikomanagement und Compliance-Anforderungen bestmöglich abzubilden und zu unterstützen. Wenn aber speziell das Zusammenspiel von betriebswirtschaftlichem Management und Unternehmens-IT zum dominanten Faktor für langfristigen Geschäftserfolg wird, stehen wir vor einigen entscheidenden Fragen:
• Wie lösen wir das Dilemma, dass Betriebswirtschaft und IT sich in weiten Teilen unversöhnlich wie 0 und 1 gegenüberstehen – in der Substanz ohne gemeinsame Sprache und mit unzureichenden Methoden, dafür belastet von Vorurteilen und Misstrauen?
• Wie schließen wir den „Results-Gap“ – jene Kluft zwischen der erhofften Effizienz und Produktivität von Geschäftsanwendungen und dem tatsächlichen Nutzen für die Anwender im Unternehmen.
• Wie schließen wir den IT-Gap? jene Lücke, die aus der langsamen Reaktionszeit der IT auf betriebswirtschaftliche Anforderungen entsteht: Bis zum Lieferzeitpunkt haben sich die Anforderungen an IT-Services und Applikationen schon substanziell weiterentwickelt. Was eine Lösung sein sollte, ist schon bei der Implementierung unzureichend, zum Teil veraltet, wirft neue Probleme auf und provoziert im Endeffekt Unzufriedenheit, mangelndes Vertrauen in die Leistungsfähigkeit der IT-Abteilung und langfristig auch hohe Kosten. Analysten wie Gartner schätzen, dass Unternehmen aktuell rund zwei Drittel der IT-Kosten in Maintenance statt in Neuinvestitionen und Zukunftssicherung investieren.
• Wie gelingt der Quantensprung der IT: Interoperabilität innerhalb der digitalen Welt und kurze Reaktionszeiten auf externe Einflüsse und Anforderungen? Dies betrifft insbesondere das betriebswirtschaftliche Management, die Berücksichtigung neuer gesetzgeberischer Herausforderungen wie Basel II oder Sarbanes Oxley und andere wesentliche Bestimmungsfaktoren sich rasant entwickelnder Märkte.
Stehen diese Fragen im Zusammenhang mit SOA? Ansichtssache, aber eine zukunftsweisende Geschäftsarchitektur muss sich diesen Fragen stellen und auch überzeugende Antworten geben!