|
|
|
»manage
it«
als
|
Die serviceorientierte Architektur und ihre Baustellen Ohne Fleiß kein Preis Die serviceorientierte Architektur verspricht auf Basis autonomer, lose gekoppelter und auf fachliche Anforderungen ausgerichteter Services flexible und agile Anwendungslandschaften zu schaffen. Bis es soweit ist, müssen allerdings noch einige offene Baustellen geschlossen werden.
ie serviceorientierte Architektur SOA, so versichern unisono alle Betroffenen und Beteiligten, sei »kein Allheilmittel« – und unterstreichen mit diesem Dementi nur, auf was die IT sehnlichst wartet: Endlich eine finale Lösung für alle Probleme zu finden, endlich Systeme entwickeln zu können, die überschaubar und trotzdem skalierbar, die performant und trotzdem flexibel, die leicht zu warten sind und dennoch nichts kosten. Dieses Wundermittel ist SOA also auch nicht, aber doch immerhin ein Konzept, das einen Ausweg weist. Die Weiterentwicklung der Systeme entlang rein fachlicher Aufgabenstellungen hatte bereits Anfang der 90er-Jahre in eine Sackgasse geführt. Die Systeme wurden immer komplexer und waren immer schwerer zu manövrieren. Zugleich stiegen durch veränderte Geschäftsprozesse die Anforderungen und neue Technologien drängten in die Unternehmen, Anpassungen wurden schwieriger und mussten doch in immer kürzeren Zyklen vorgenommen werden. Die Folge waren zum einen ein permanenter Applikationsstau zum anderen massive Qualitätsprobleme. Zwar gelang es mit Objektorientierung und Komponententechnologie, den Wartungsaufwand für Softwaresysteme zu reduzieren, als aber im Umfeld der Web-Economy neue Anforderungen in bisher nicht gekanntem Ausmaß auf die IT einstürmten, war auch diese Karte ausgereizt. Es zeigte sich, dass die Komponentenwelt rund um Standards wie Corba oder DCOM kaum weniger komplex war als die vorherige monolithische. Darüber hinaus verhinderten differierende, in der Praxis oft proprietäre Schnittstellenkonzepte die Integration der Systeme, die doch eine wesentliche Voraussetzung für deren Weiterentwicklung war. Von Komponenten zu Services. Dennoch, mit der Komponententechnologie war schon ein Schritt in die richtige Richtung erfolgt. Vieles von dem, was in der SOA-Welt heute diskutiert wird, geht auf Middleware-Lösungen wie Corba zurück und ist nicht ganz so neu wie das mittlerweile verwendete Etikett. Die wesentlichen Fortschritte von SOA liegen nicht in der Adaption des »Service-Gedankens« als solchen, den man ja auch für die Komponenten hätte verwenden können, sondern in einer neuen Art seiner Umsetzung. Services im Sinn einer SOA verfügen wie ehedem Komponenten über gekapselte Algorithmen und kommunizieren mit ihrer Außenwelt ausschließlich über ihre definierten Schnittstellen. Darüber hinaus darf, was innerhalb einer derartigen Komponente geschieht, keine Auswirkungen auf andere Komponenten oder andere Bereiche des Systems haben, und umgekehrt – Komponenten wie Services agieren autonom. Der Unterschied zu Komponenten besteht vor allem in dem, was als Algorithmus in einen Service hineingesteckt wird. Services sind in SOA nämlich nicht wie im Corba-Umfeld unter technischen, sondern unter fachlichen Aspekten definiert. Services bilden also rudimentäre Geschäftsprozesse ab, wobei sie über eine relativ grobe Granularität verfügen müssen. Ein Service führt also zum Beispiel nicht einen Datenbankaufruf durch, sondern könnte eine komplette Bonitätsprüfung vornehmen. Auf dieser Grundlage lassen sich die Services dann zu Geschäftsprozessen zusammenstellen, orchestrieren wie es auf SOA-Deutsch heißt. Da die einzelnen Services nur lose gekoppelt werden, können sie auch immer wieder neu zusammengestellt werden, was der Architektur große Flexibilität verleiht. In einer idealen SOA-Welt würde man also über eine Sammlung von fertigen Prozessmodulen in Serviceform verfügen, die man je nach den jeweiligen Anforderungen zu einer Prozesskette zusammenfügt, ohne dass dafür Softwareentwicklung im eigentlichen Sinn notwenig wäre: orchestrieren statt programmieren. Bei neuen Anforderungen würde man die Sammlung ergänzen, wobei man sich nur den betreffenden Service kümmern muss, alle anderen könnten weiter bestehen, da sie mit dem neuen Service ja nur über ihre bereits vorhandenen Schnittstellen kommunizieren und das Einfügen der neuen Service in eine Prozesskette per Orchestrierung erfolgt. Softwareentwicklung würde damit deutlich schneller werden und auch die Qualitätsprobleme ließen sich so besser in Griff bekommne, da neue Abläufe im Wesentlichen aus bereits fertigen Servicemodulen bestehen. So könnte die SOA für eine bisher unerreichte Flexibilität, Agilität und Skalierbarkeit der IT-Systeme sorgen. Die SOA-Baustellen. Zurück zur Wirklichkeit, in der es rund um SOA durchaus noch eine Reihe offener Baustellen gibt. * Es ist derzeit nicht einheitlich festgelegt, was überhaupt ein Service ist. Zwar besteht Einigkeit, dass die SOA eine »grobe« Granularität benötigt, offen ist freilich wie grob sie sein darf oder muss: umfasst ein Service einen kompletten Geschäftsprozess oder nur Teilstücke? Ist die erwähnte Bonitäts-Prüfung schon der Service oder erst die komplette Kreditbearbeitung? Wo hört ein Geschäftsprozess sinnvollerweise auf, wo fängt der nächste an? Hier muss noch eine konsistente Methodologie entwickelt werden, die bestimmt wie aus einer Anwendungslandschaft fachlich sinnvolle Services abgeleitet werden können. Servicekomponenten müssen systematisch entwickelt werden und beispielsweise hinsichtlich Granularität und Funktionalität zusammenpassen. Dazu müssen Übergänge von der Modellierung zur SOA geschaffen werden. Die SOA muss bereits im Softwaredesign angelegt sein. * Das Design von Services im Hinblick auf eine künftige Nutzung in ganz anderen Zusammenhängen, erfordert ein hohes Maß von Vorschau und vorbereitender Organisation, vor allem auch bezüglich der (kommenden) Geschäftsprozesse. Dieser Aspekt reicht weit über die Softwareentwicklung hinaus und betrifft die gesamte IT-Organisation, die betroffenen Fachbereiche aber auch das Management. Individuelle, abgegrenzte Softwareprojekte müssen neben ihren eigenen Anforderungen auch mögliche zukünftige Anforderungen sowie Anforderungen anderer, unbeteiligter Fachabteilungen bei Planung und Design berücksichtigen. Neuere, ganzheitliche Ansätze wie Borlands IT-Management und IT-Governance adressieren genau diese Problematik indem sie die betriebswirtschaftlich orientierten Entscheidungen in IT-Projekten mit dem Management operativer IT-Aufgaben verbinden. * Die Verwendung von beliebigen Kontrakten für die Beschreibung der Schnittstellen kann zur Interoperabilität führen. Gerade die Flexibilität und Offenheit der SOA könnte proprietäre Systeme durch die Hintertüre ermöglichen. * Die Optimierung von Services für die Wiederverwendbarkeit und die Verwendung standardisierter Protokolle führen tendenziell zu geringerer Performance, »Individuelle Punkt-zu-Punkt-Systemkopplungen können wesentlich stärker auf höhere Durchsätze optimiert werden als Kommunikationsmechanismen in einer SOA-Infrastruktur«. Der höheren Effizienz bei der Erstellung der Komponenten, entspricht eine geringere Effizienz beim Betrieb. Dieses Problem ist in der IT altbekannt, so bei den alternativen Assembler versus Hochsprachen, bei maschinennaher Programmierung © versus Objektorientierung (C++), bei realen versus virtuellen Maschinen. Die Vergangenheit hat auch gezeigt, dass derartige Perfomance-Probleme lösbar sind, und sei es durch neue Hardwaregenerationen. Niemand würde heute aus Performance-Gründen zu Assembler greifen, obwohl es unbestritten ist, dass dies den schnelleren Code liefert. * Auch für SOA gibt es keine »grüne Wiese«. Zwar lassen sich auch bestehende Systeme in eine SOA einbinden, die wenigsten – und insbesondere nicht die zahlreichen unternehmenskritischen Legacy-Systeme – verfügen über eine Struktur, die es erlaubt aus geschlossenen Applikationen Services herauszulösen. Hier ist womöglich viel Detailarbeit nötig und die Anwender sollten sich auch bewusst sein, dass sich nicht jedes System nachträglich in eine SOA einpassen lässt. * Die Orchestrierung der Services muss im Rahmen einer Infrastruktur erfolgen, aber auch dafür gibt es noch keine Standards, sondern erst einige Ansätze wie etwa den Enterprise Service Bus, die ihre Tragfähigkeit erst noch erweisen müssen. Je weiter SOA in die Praxis vordringt, desto mehr zeichnet sich allerdings ab, dass auch SOA-Projekte von einiger Komplexität sind, zumal wenn damit nicht Teilbereiche, sondern umfangreiche Geschäftsprozesse abgedeckt werden sollen. Gerade der Business-Aspekt, der für eine SOA konstituierend ist, erfordert die Integration in ein unternehmensweites Konzept, das nicht ausschließlich IT-orientiert sein darf. SOA-Projekte müssen daher auch betriebswirtschaftliche Fragestellungen aufgreifen und eng mit Aufgaben wie Portfolio-, Financial-, Ressource-, Asset- oder Project-Management verbunden werden, wie das beispielsweise in Borlands ITM&G-Konzept umgesetzt wird. Solche ganzheitlichen Ansätze passen sehr gut zur Grundidee von SOA, weil in beiden die IT nicht mehr ausschließlich funktionell und operativ gesehen wird. So besehen ergibt sich rund um die SOA ein nicht unerheblicher Klärungs- und Handlungsbedarf. Die offenen »Baustellen« stellen jedoch nirgends das Konzept als solches in Frage. Sie scheinen mit verfügbaren Methoden und Werkzeugen durchaus lösbar. Man sollte nur immer im Blickfeld behalten, dass die SOA kein primär technischer Ansatz ist, sondern die jeweiligen Geschäftsprozesse in den Mittelpunkt stellt, also ein enges Zusammenwirken von IT und Business voraussetzt. Tatsächlich ist SOA ein viel versprechender Ansatz für einen – vorsichtig formuliert – besseren Umgang mit Komplexität und Qualität. Wem es ein Trost ist: Allheilmittel gibt es nirgends. Matthias Zieger
Merkmale von Services in einer SOA * Fachliche Orientierung mit grober Granularität * Gekapselte und autonome Logik * Kommunikation über definierte Schnittstellen, Aufruf nur über diese Schnittstellen * Lose Koppelung der Services untereinander * Einbettung in eine (standardisierte) Infrastruktur
Vorteile einer SOA * Modellierung von Geschäftsprozessen durch Orchestrierung von Services * Schnellere Softwareentwicklung und bessere Wartbarkeit durch wieder verwendbare Services * Reduktion von Komplexität durch Unabhängigkeit der Services von konkreten Implementierungen * Unabhängigkeit von bestimmen Technologen oder Protokollen
ITM&G mit Borland Borlands ITM&G-Lösung verbindet die betriebswirtschaftlich orientierten Entscheidungen in IT-Projekten (IT-Governance) mit dem Management rein operativer IT-Aufgaben (IT-Management). Sie umfasst die Unterstützung für Demand-, Portfolio-, Financial-, Ressource-, Asset- und Project-Management. Die Lösung stellt sicher, dass IT-Teams über das Know-how, die Services und Werkzeuge zur Beurteilung von unternehmensweiten IT-Investitionen verfügen. Sie beinhaltet außerdem ein Set von automatisierten Best Practices. Die Planung und Durchführung von Maßnahmen findet sowohl auf Projekt-Niveau als auch über das gesamte IT-Portfolio hinweg statt. Auf diese Weise können Unternehmen ihre Investition genauer steuern sowie vorhersehbare Leistungen und nachprüfbare Ergebnisse erreichen. Borlands ITM&G-Lösung schließt die aktuelle Version von Borland Tempo, der Suite nahtlos integrierter IT-Management- und Governance-Lösungen, ein. Die vollständig Web-basierte Technologie verfügt über ein neues Dashboard zur Darstellung von Projektsichten sowie über ein integriertes Projekt-, Portfolio- und Dokumenten-Management. Weitere Informationen über Borland Tempo finden sich unter: www.borland.com/us/products/tempo/index.html. Borlands ITM&G-Lösung ist ab sofort verfügbar. Für Unternehmen, die für Teilbereiche von IT-Management und IT-Governance schnell realisierbare Lösungen benötigen, stellt Borland »Accelerators« bereit. Dabei handelt es sich um abgestimmte Sets von Trainings-Maßnahmen, Beratungsleistungen und Werkzeugen für spezifische Aufgabenstellungen. So bietet beispielsweise ein Portfolio Management Accelerator jenen Unternehmen, die kritische Lücken in ihrem Portfolio Management schließen wollen, ein auf diese Aufgabe abgestimmtes Lösungs-Set.
SOA an der Leine
Die Servicekomponenten kommunizieren nur über ihre Schnittstellen mit der Außenwelt; durch Orchestrierung lassen sie sich zu komplexen Geschäftsprozessen verbinden.
»Die IT träumt davon endlich Systeme entwickeln zu können, die überschaubar und trotzdem skalierbar, die performant und trotzdem flexibel, die leicht zu warten sind und dennoch nichts kosten.«
|
|
