Praxisleitfaden. Bild: zettberlin, SOA, das IT-Zukunftsprojekt überhaupt! Auch für Sie?

Transkript

1 Praxisleitfaden SOA Bild: zettberlin, SOA, das IT-Zukunftsprojekt überhaupt! Auch für Sie?

2 Praxisleitfaden SOA, das IT-Zukunftsprojekt überhaupt! Auch für Sie? Um auf dem global vernetzten Markt langfristig wettbewerbsfähig zu bleiben, müssen Unternehmen einerseits schnell und flexibel auf neue Marktanforderungen am Markt reagieren können, andererseits stetig ihre Kosten reduzieren. Beides ist oftmals mit einer Anpassung der Organisationsstruktur und der Geschäftsprozesse verbunden, was aber teilweise durch inflexible IT-Architekturen und Anwendungen erschwert wird. Bei vielen Unternehmen besteht daher der Wusch die bislang eher monolithischen IT-Infrastrukturen in flexiblere und agilere Lösungen umzugestalten, bei denen die IT-Prozesse des Unternehmens konsequent an den zugrunde liegenden betrieblichen Abläufen ausgerichtet werden. Klassische Client-Server- oder Mainframe-Architekturen bilden die Geschäftsprozesse des Unternehmens normalerweise mehr oder weniger statisch ab, so dass Änderungen nur begrenzt oder mit hohem Aufwand möglich sind. Dieses Korsett stellt somit eine gewisse Einschränkung für das unternehmerische Handeln dar. Eine Lösung für dieses Problem verspricht die in letzter Zeit vieldiskutierte Service-orientierte Architektur (SOA). SOA ist allerdings keine IT-Architektur im klassischen Sinne, sondern eher eine Art neues Konzept. Dieses beschreibt den Aufbau einer Anwendungslandschaft aus einzelnen fachlichen Anwendungsbausteinen, die jeweils eine klar definierte Aufgabe erfüllen. Die einzelnen Bausteine sind nur lose miteinander gekoppelt und bieten ihre Funktionalitäten in Form von Services an. Idealerweise werden diese Services an den ihnen zugrunde liegenden betrieblichen Abläufen ausgerichtet. Durch ihre im Vergleich zu monolithischen Anwendungen deutlich geringere Komplexität und durch definierte Schnittstellen lassen sich diese Services schneller verändern und neuen Bedingungen anpassen. Damit wird das Unternehmen nicht nur flexibler, sondern Änderungen und Anpassungen sind deutlich kostengünstiger und schneller realisierbar. SOA erfreut sich wachsender Beliebtheit Eine Studie von Roland Berger im Auftrag des BITKOM ergab, dass sich in Deutschland derzeit etwa 50 Prozent der Unternehmen mit SOA beschäftigen und in den kommenden zwölf bis 24 Monaten eine schrittweise Umstellung ihrer IT-Systeme planen. Besonders Finanzdienstleister scheinen in Sachen SOA zu den Pionieren zu gehören. Nach Informationen von Forrester Research nutzten in 2005 von 60 befragten Finanzdienstleistern in Europa bereits 40 Prozent Service-orientierte Architekturen und 37 Prozent planten einen Umstieg auf SOA. Nur 23 Prozent wollten noch nicht umsteigen oder waren noch unschlüssig. Der Marktforscher IDC hatte in 2007 insgesamt 2077 Unternehmen mit mehr als 20 Mitarbeitern aus fünf westeuropäischen Ländern befragt. Auch hier zeigte sich ein zunehmendes Interesse an SOA. Hier lag ebenfalls der Bankensektor vorn, wo laut IDC bereits 25 Prozent der Befragten SOA bereits eingeführt haben, 21 Prozent gerade eine Plattform implementieren und weitere 27 Prozent dies in den kommenden zwei Jahren in Angriff nehmen wollen. Selbst bei Behörden verfügen schon 18 Prozent der Befragten über eine SOA und 8 Prozent arbeiten derzeit am Aufbau einer Service-orientierten Architektur. Rund 26 Prozent der befragten Behörden wollen in den nächsten 24 Monaten in SOA investieren.

3 Beweggründe für eine SOA-Umstellung Was versprechen sich die Unternehmen nun von einem Umstieg auf eine Service-orientierte Architektur? Eines der wichtigsten Argumente für eine SOA-Umstellung ist die anfangs bereits erwähnte einfachere Anpassung der IT-Infrastruktur an die sich stetig ändernden Geschäftsprozesse und Organisationsstrukturen eines Unternehmens. Darüber hinaus werden als Motivation für eine Umstellung auf eine Service-orientierte Architektur auch eine Senkung der operativen IT-Kosten und ein einfacheres Outsourcing von Prozessen genannt. Alle diese Vorteile sind auf die sehr modulare und flexible Struktur einer Service-orientierten Architektur zurückzuführen. Anstatt wie bisher möglichst umfassende, monolithische, damit aber inflexible Anwendungen einzusetzen, baut SOA auf eine IT-Infrastruktur aus einfach zusammensetzbaren, wiederverwendbaren, austauschfähigen und stabilen Komponenten. Jeder einzelne dieser Anwendungsbausteine erfüllt dabei jeweils eine klar umrissene fachliche Aufgabe. Das Hinzufügen neuer oder die Modifikation bestehender Bausteine ist somit schnell und ohne großen technischen Aufwand möglich. Damit lassen sich Änderungen in der Organisationsstruktur und den Geschäftsprozessen mit deutlich geringerem Zeit- und Kostenaufwand auf die zugrunde liegende IT-Architektur abbilden. SOA bietet noch weitere Vorteile Durch die lose Kopplung der einzelnen Anwendungsbausteine lassen sich die verschiedenen Bausteine auch unabhängig voneinander planen und realisieren. Die Kommunikation dieser Services untereinander erfolgt dabei über definierte Schnittstellen. Durch diese Struktur kann nun nicht nur die Komplexität der einzelnen Bausteine, sondern auch des Gesamtsystems deutlich reduziert werden. Dies ermöglicht zudem eine Verbesserung der Qualität der IT-Infrastruktur. Dieses Konzept bietet indes noch weitere Vorteile. So verursachen die in vielen Unternehmen vorhandenen älteren Anwendungen und Hardware-Lösungen meist hohe Betriebs-, Lizenz- und Wartungskosten, so dass eine rasche Ablösung zwar wünschenswert wäre, meist aber an der umfassen-den Funktionalität und Komplexität scheitert. Besonders bei sehr umfangreichen Anwendungen ist eine vollständige Erneuerung oder Ablösung aber nur mit hohem Zeit- und Kostenaufwand möglich. Bei einem Umstieg auf SOA lassen sich derartige Legacy-Systeme einerseits weiternutzten, andererseits einfacher schrittweise ablösen. Die definierten Schnittstellen einer Service-orientierten Architektur erleichtern mittels Kapselung eine Weiternutzung, aber auch eine Partitionierung derartiger Legacy-Systeme in erneuerbare Bestandteile. Ältere Systeme lassen sich so schrittweise auf eine moderne und zukunftssichere Lösung umstellen, ohne dass dies mit hohen Risiken und umfangreichen Investitionen verbunden ist. Durch das Konzept eigenständiger Anwendungsbausteine und definierter Schnittstellen wird auch die Standardisierung von Services vereinfacht. Dies wiederum ermöglicht eine bessere Herstellerunabhängigkeit, da sich Lösungen von unterschiedlichen Anbietern durch die definierten Schnittstellen einfacher ersetzen bzw. kombinieren lassen. Aus demselben Grund wird ein temporäres oder dauerhaftes Outsourcing einzelner Geschäftsprozesse oder von Teilen von Geschäftsprozessen begünstigt. Dem Unternehmen ermöglicht dies flexible Kapazitätserweiterungen, so dass sich Engpässe bei einem stark steigenden Auftragseingang oder bei Großprojekten vermeiden lassen.

4 Herausforderungen einer SOA-Umstellung Entsprechend dem grundlegenden Konzept einer SOA-Architektur erfordert ein Umstieg von wenigen monolithischen Anwendungen auf eine Vielzahl kleiner, lose miteinander gekoppelten Anwendungsbausteine vorab eine umfassende Analyse aller Geschäftsprozesse des Unternehmens. Allein durch diese Analyse der Arbeits- und Geschäftsprozesse ergeben sich häufig zahlreiche Verbesserungspotenziale, wie beispielsweise eine rationellere Abwicklung von Aufgaben durch Verlagerung, Neuverteilung oder Zentralisierung. Anschließend lassen sich die optimierten Prozesse dann auf flexibel miteinander kombinierbare Services abbilden. Allerdings wird wohl kaum ein Unternehmen das Risiko eingehen wollen, die bestehende IT-Infrastruktur von einem Tag auf den anderen auf ein völlig neues Konzept umzustellen. Wie die Praxis zeigt ist es praktikabler und sicherer eine SOA-Umstellung mit einem kleineren und überschaubareren Einstiegsprojekt zu beginnen. Ein derartiges Einstiegsprojekt muss dabei einen leicht erkennbaren und nachweisbaren Business-Nutzen bieten und in überschaubarer Zeit realisierbar sein. Nur so lassen sich die beteiligten Fachabteilungen und das Top-Management von den Vorteilen einer derartigen Umstellung überzeugen und die damit verbundenen Kosten und Risiken minimieren. Obwohl mit einem kleinen Projekt begonnen werden soll, darf das Endziel einer vollständigen SOA-Umstellung dabei nie aus den Augen verloren werden. Eine SOA-Umstellung erfordert eine stark vorausschauende Vorgehensweise und zwar sowohl bei der IT-Organisation, als auch bei den beteiligten Fachbereichen. Ein wichtiger Ratschlag in diesem Zusammenhang lautet daher: Think big, start small Während die Vorteile von SOA der IT-Abteilung des Unternehmens meist offensichtlich sind, gilt dies nicht unbedingt auch für die beteiligten Fachabteilungen und das Management. Hier ist von der IT-Abteilung oftmals zusätzliche Überzeugungsarbeit zu leisten. Die Fachabteilungen und das Management sind im Gegensatz zur IT-Abteilung weniger daran interessiert, ob die IT-Infrastruktur eher monolithisch oder aus einzelnen Bausteinen aufgebaut ist, sondern einzig die Funktionalität ist entscheidend. Gleichwohl denken beide Seiten in Prozessen und wollen Abläufe schnell und unkompliziert verändern und an neue Rahmenbedingungen anpassen können. Im Grunde genommen damit stellt SOA die ideale Voraussetzung hierfür zur Verfügung. Dies muss von der IT-Abteilung daher entsprechend und verständlich kommuniziert werden. SOA-Umstellung streng nach Plan? Wie bereits anfangs erwähnt, ist SOA kein fertiges Rezept sondern eher ein Architekturmuster, das den Aufbau einer Anwendungslandschaft aus einzelnen, lose gekoppelten Anwendungsbausteinen beschreibt. Diese Bausteine (Services) erfüllen jeweils klar umrissene fachliche Aufgaben und werden konsequent an den ihnen zugrunde liegenden betrieblichen Abläufen ausgerichtet. Derzeit gibt es allerdings noch keine etablierte Methodik, wie eine SOA-Anwendungslandschaft fachlich modelliert werden kann. Auch die Begriffswelt der Service-orientierten Architektur ist noch nicht gefestigt und selbst für grundlegende Begriffe gibt es noch keine einheitlichen Definitionen. Auf der anderen Seite existieren bereits zahllose Standards rund um das Thema SOA. Dies führt bei der Vorbereitung und Realisierung von SOA-Projekten oftmals zu Verwirrung, Reibungsverlusten und Ineffizienz. Erschwert wird das Ganze durch meist fehlendes Know-how und Erfahrungen mit SOA im eigenen Unternehmen. Außerdem sind SOA-Experten am Markt derzeit Mangelware. Für Unternehmen, die SOA-Projekte durchführen wollen, bedeutet dies in der Regel, dass sie sich einen starken Partner suchen sollten, und sich auf dessen Erfahrungen und Können verlassen müssen.

5 Fazit Ein festes Rezept für eine SOA-Umstellung gibt es nicht, so dass jedes Projekt individuell angegangen werden muss. Zudem lässt sich der wirtschaftliche Nutzen von SOA vorab nur schwer abschätzen, wodurch auch die Argumentation für die Einführung von SOA zumindest gegenüber dem Management schwierig ist. Gleichwohl bietet SOA aber wie hier dargestellt im Hinblick auf eine langfristige Kostensenkung und Sicherstellung der Wettbewerbsfähigkeit des Unternehmens ein großes Potential. Gemäß dem Motto Think big, start small sollte anstatt einer kompletten Umstellung besser ein überschaubares Einstiegsprojekt mit eindeutigem Business-Nutzen gesucht werden. Ebenso wichtig ist, dass vorab eine umfassende Analyse der Geschäftsprozesse durchgeführt wird. Dabei sollte stets die komplette Umstellung als Fernziel im Auge behalten werden. Oftmals lassen sich bereits durch diese Analyse der Arbeits- und Geschäftsprozesse erste Verbesserungspotenziale erkennen. Da die meisten Unternehmen bislang über keine SOA-Erfahrungen verfügen und entsprechende Experten am Arbeitsmarkt derzeit nur schwer zu bekommen sind, bietet es sich in der Regel an mit einem starken Partner zusammenzuarbeiten, der nicht nur über die entsprechenden SOA-Erfahrungen verfügt sondern auch ein umfassendes Portfolio von SOA-Produkten und Dienstleistungen anbieten kann. Dann dürfte einer erfolgreichen Umstellung auf eine Service-orientierte Architektur wohl nichts mehr im Wege stehen. Die dargestellten Ausführungen sind ohne Gewähr und sollen Ihnen die Anforderungen und Perspektiven einer SOA-Architektur näher bringen. Natürlich können diese Hinweise nicht alle gesetzlichen Regelungen und sonstigen Aspekte einer derartigen Architektur beleuchten, und dienen daher nur der allgemeinen Information.

6 Checkliste Checkliste 1 Ist SOA überhaupt für uns interessant? Aktion Priorität ja nein Lassen sich die Organisationsstruktur und Geschäftsprozesse kurzfristig und mit geringem Aufwand geänderten Marktbedingungen anpassen? Sind noch ältere Anwendungen bzw. Systeme im Einsatz, die sehr hohe Wartungs- und Betriebskosten verursachen? Soll die IT-Infrastruktur modernisiert werden? Sollen bei einer Modernisierung bewährte Anwendungen weitergenutzt werden? Könnte durch ein temporäres oder dauerhaftes Outsourcing von Geschäftsprozessen die Marktposition verbessert werden? Unterliegen die Geschäftsprozesse häufigen Veränderungen und müssen diese kontinuierlich optimiert werden? Sind bereits Web-Services im Einsatz? Wird eine größere Unabhängigkeit von einzelnen Anbietern angestrebt? Checkliste 2 Vor dem Start eines SOA-Projekts zu klären Aktion Priorität ja nein Ist den betroffenen Fachabteilungen klar welchen Nutzen die SOA-Umstellung bringt? Lässt sich der wirtschaftliche Nutzen des SOA-Projektes quantifizieren? Wird die SOA-Umstellung vom Top-Management voll unterstützt? Ist das notwendige SOA-Know-How im Hause vorhanden bzw. wurde ein entsprechender Partner bereits gefunden? Wurde bereits eine umfassende Analyse der Geschäftsprozesse durchgeführt? Wurde ein erstes überschaubares Einstiegsprojekt definiert? Welche Ziele sollen mit dem Einstiegsprojekt erreicht werden? Welche Schritte folgen nach der Realisierung des Einstiegsprojektes?

7 Glossar Begriff Architektur BPEL BPM Business Process Execution Language Business Process Management Compliance EAI Enterprise Application Integration Enterprise Service Bus ESB extensible Markup Language Geschäftsprozess Geschäftsprozessmanagement GPM Interoperabilität IT-Infrastruktur Kapselung Legacy Anwendungen monolithische Anwendung OASIS Service Erklärung Struktur eines IT-Systems einschließlich der Hardware- und Software- Komponenten und deren Beziehungen untereinander. Siehe Business Process Execution Language Siehe Business Process Management Eine XML-basierende Sprache zur technischen Abbildung von Geschäftsprozessen in Form von Web-Services. Abkürzung: BPEL Systematische Analyse und Optimierung von Geschäftsprozessen mit dem Ziel der Umsetzung und Implementierung in Software und der Integration in ein dynamisches IT-Umfeld. Abkürzung: BPM Einhaltung bzw. Erfüllung bestimmter gesetzlicher oder gesetzesähnlicher Regelungen oder Vorgaben Siehe Enterprise Application Integration Ansatz zur Integration verteilter Systeme mittels einer gemeinsamen Infrastruktur. Abkürzung: EAI Zentrale Integrationseinheit bzw. Architekturansatz für den Datenaustausch zwischen Services über verschiedene Plattformen hinweg. Ein zentraler Bestandteil von SOA. Abkürzung: ESB Siehe Enterprise Service Bus Strukturierte Datenbeschreibungssprache. Abkürzung: XML Strukturierte Beschreibung von Geschäftsaktivitäten zur Erfüllung einer bestimmten fachlichen Aufgabe. Siehe Business Process Management Abkürzung: GPM Abkürzung für Geschäftsprozessmanagement; siehe Business Process Management Die Fähigkeit unterschiedlicher Systeme miteinander kommunizieren zu können. Gesamtheit der IT-Systeme, Software und Netzwerk(e), die den Anwendungen als Basis für deren Ausführung dient. Definition einer Schnittstelle für eine oder mehrere Funktion(en), wobei deren interne Arbeitsweise verborgen bleibt. Anwendungen, die bereits längere Zeit in Betrieb sind und nicht mehr dem derzeitigen Stand der Technik entsprechen. Umfassende Anwendung, die einen größeren Aufgabenkomplex abdeckt (z.b. Finanzbuchhaltung) und meist nur komplett ersetzt werden kann. Abkürzung für Organization for the Advancement of Structured Information Standards, eine Standardisierungsorganisation, die u.a. Standards für SOA veröffentlicht. Erfüllung in sich abgeschlossener und eigenständig nutzbarer Aufgaben. Die Nutzung ist meist plattformunabhängig und erfolgt über eine definierte Schnittstelle, wobei Kenntnisse über die Details der Implementierung nicht erforderlich sind.

8 Glossar Begriff Service Oriented Architecture Simple Object Access Protocol SOA SOAP Outsourcing Web-Service Web-Services Description Language Workflow WS WSDL XML Erklärung Architekturkonzept aus einfach zusammensetzbaren, wiederverwendbaren, austauschfähigen und stabilen Komponenten. Jeder einzelne Anwendungsbaustein erfüllt eine klar umrissene fachliche Aufgabe (Service). Durch eine lose Kopplung lassen sich die vollständige Geschäftsprozesse abbilden. Abkürzung: SOA Das Basisprotokoll von Web-Services. Es definiert in einem XML-basierten Format die Struktur der zwischen den einzelnen Web-Services ausgetauschten Nachrichten. Abkürzung: SOAP Siehe Service Oriented Architecture Siehe Simple Object Access Protocol Auslagerung von Aufgaben oder Geschäftsaktivitäten an externe Anbieter. Web-Services sind verteilte, lose gekoppelte Software-Komponenten, die über Standard Internetprotokolle und über definierte Schnittstellen Informationen austauschen. Sie bilden eine grundlegende Komponente einer SOA-Architektur. Eine XML-basierende Schnittstellenbeschreibung für Web Services. Abkürzung: WSDL Regelbasierte Aktivitätenabfolge zur Erledigung einer Aufgabe innerhalb einer Prozesskette. Definiert wer, was, wie zu erledigen hat, um eine bestimmte Aufgabe zu erfüllen. Siehe Web-Service Siehe Web-Services Description Language Siehe extensible Markup Language ORACLE Deutschland GmbH Riesstrasse 25 D München Tel.: Oracle, JD Edwards and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.