Der Erfolg ist eine Frage der Organisation

Detecon Management Report 08/2002 Strategien 9 Von der klassischen Anwendung zur Komponenten-Architektur Der Erfolg ist eine Frage der Christiane Eckardt, Rolf-Peter Täger, Uwe Weber Organisation Beim Wachstum der IT-Systeme vieler Unternehmen nach der Erstentwicklung, sind im Laufe der Zeit oft die berühmten „Blumenkohl“-Effekte zu beobachten: ein regelrechter Wildwuchs von heterogenen Anwendungen. Über Jahrzehnte wurden einzelne Systeme optimiert, während eine Gesamtbetrachtung der IT-Landschaft nicht stattfand. Das führte zu System- und Prozess-Schwächen: Medienbrüche erschweren Arbeitsabläufe und verursachen unnötige Kosten. Der Herausforderung, Arbeitsabläufe neu zu organisieren und Anwendungen darauf und aufeinander abzustimmen, können Unternehmen mit Hilfe einer Komponenten-Architektur begeg- nen. Neben den reinen Entwicklerfähigkeiten für eine bestimmte Programmiersprache und entsprechenden Tools sind hierfür vor allem Planung, Organisation und Methodik gefragt. >> Die Komponenten-Architektur (Component Applikationen zur Risikoabschätzung. Bei all diesen Based Architecture, kurz: CBA) hat ihre Wurzeln im Beispielen betonen die Unternehmen, wie wichtig und Modul-Konzept der 70er-Jahre. Der Grundgedanke dabei bedeutsam eine gründliche Geschäftsprozessanalyse ist, dass Software-Applikationen aus einer Reihe von war. Nur das genaue Verständnis der Kernprozesse einfachen und standardisierten Software-Bausteinen – ermöglicht es, die abgeleiteten Komponenten den aktu- den Komponenten – zusammengesetzt werden. Durch ellen und auch künftigen Anforderungen flexibel anzu- geeignetes Kombinieren lassen sich komplexe passen. Geschäftsprozesse abbilden. Eine Komponente reprä- sentiert eine bestimmte Dienstleistung, die über eine Vorgehen bei CBD definierte Schnittstelle angesprochen wird. Die Schnitt- stelle beschreibt die Benutzung der Komponente – sie Eine Komponenten-basierte Software-Entwicklung (Com- ist die Gebrauchsanweisung – und basiert auf einem ponent Based Development, kurz: CBD) einzuführen, Standard. So ist es einfach, beliebige Komponenten mit- erfordert neben der notwendigen Management-Unter- einander zu koppeln. Die großen Softwarehersteller stützung auch eine Veränderung der Entwicklungskultur haben verschiedene Standards vorgeschlagen, um im Unternehmen. CBD ist mehr als ein objektorientierter Komponenten zu programmieren: Von Microsoft gibt Entwicklungsprozess. Eine mit CBD entwickelte Software- es COM, DCOM und COM+. Die Object Management Architektur muss sich an den Rollen der Menschen Group setzt dagegen auf CORBA, während Sun, IBM orientieren, die im Arbeitsalltag die Software-Systeme und Oracle wiederum Enterprise Java Beans (EJB als Teil (weiter-)entwickeln. von J2EE) propagieren. So sollten die verschiedenen Interessen der Beteiligten – Komponenten-Architektur für verteilte Anwendungen Geschäftsprozess-Verantwortliche, Anwender, IT-Spezia- listen – bei der Planung ebenso genau betrachtet werden Neu bei der Komponenten-basierten Entwicklung ist wie die alten Anwendungen (s. Abb. 1). Beispielsweise ist nun der Einsatz objektorientierter Typ-Konzepte und aus Unternehmenssicht wichtig, welche Geschäftspro- Hersteller-übergreifender Standards. Sie ermöglichen zesse sich in wiederverwendbaren Komponenten abbil- den verteilten Betrieb von Komponenten in einem hete- den lassen. Für die Anwender stellt sich die Frage nach rogenen Rechnernetz, ohne dass der Entwickler dies in Benutzerschnittstelle und den dazugehörenden Service- seinem Programmcode explizit berücksichtigen muss. möglichkeiten. Beim Thema Sicherheit interessiert, wel- Beispiele für den erfolgreichen Einsatz gibt es genug: che Sicherheitsfunktionen erforderlich sind und wie sie So hat die Hapag Lloyd Container Linie GmbH erfolg- mit den Anwendungen verzahnt werden. reich eine zentrale Komponenten-basierte Anwendung zur weltweiten Ortung ihrer Container entwickelt. Die Zwei Grundregeln sollten bei CBD immer gelten: Erstens Deutsche Leasing entschied sich für eine eigenent- ist der Geschäftsprozess stets der Ausgangspunkt der wickelte Software zur Angebotskalkulation, um sich Betrachtung – so verliert man sich nicht in lokalen Opti- von den Wettbewerbern zu unterscheiden. Die Zürich mierungslösungen. Zweitens müssen die Verantwort- Versicherung verkürzte ihre Software-Entwicklungszeit lichkeiten zwischen Komponenten-Entwicklung und Pro- durch eine Komponenten-basierte Architektur bei jektabwicklung sauber getrennt werden. >> 10 Strategien Detecon Management Report 08/2002 Abb. 1: Das Lösungsentwicklung unter Berücksichtigung aller Interessen Zusammenwirken der verschiedenen Interessensgrup- Neue Anforderungen pen bei Business- Anforderungen Prozess- an die Lösung Generieren aus Fach- verbesserung der Lösung und IT-Alignment abteilungen und Component Based Develop- Wiederverwend- ment (CBD). Architektur- barkeit Komponenten- Komponenten- planung bereitstellung Entwicklung Integrationsbedarf Integration Betrieb Neue Anforderungen aus den Fachabteilungen werden hung der Anwender, die technische und organisatori- zuerst analysiert. Gemeinsam mit der Architekturpla- sche Integration der neuen Komponente zu leisten. nung wird dann entschieden, ob und wie neue Prozess- schritte zu ändern sind. In den meisten CBD-Projekten Das Team zählt werden für die Beschreibung der fachlichen Anforde- rungen – der so genannten „Use Cases“ – Vorgehens- Um den Entwicklungsprozess zu optimieren, können modelle eingesetzt, die auf UML („Unified Modeling neue agile Modelle im objektorientierten Umfeld wie Extreme Program- Language“) aufbauen. Ein bekanntes Beispiel ist „Cata- „Extreme Programming“ (XP) helfen. ming ist eine lysis“ (siehe www.catalysis.org) mit der Tool-Unter- Methode zur evo- stützung „Advantage” des Software-Unternehmens Die Agilität wird nicht durch Praktiken bestimmt, sondern lutionären Soft- „Computer Associates” (CA). durch kulturelle Werte. Vier Kernthesen beschreiben die- ware-Entwicklung sen Ansatz: Erstens sind Einzelpersonen und Interak- im Team, die am Architekturplaner sind die Schaltstelle zwischen Einzel- tion wichtiger als Prozesse und Werkzeuge. Zweitens Kunden und am projekten und Komponenten-Bereitstellung. Sie wirken sind laufende Systeme wichtiger als umfangreiche Doku- schnellen Wandel bei allen Projekten in der Analyse- und Designphase mentationen. Drittens ist die Zusammenarbeit mit dem orientiert ist. mit, um die geeigneten Komponenten für neue Anfor- Anwender wichtiger als formale Prozeduren und viertens derungen herauszufiltern. So überprüft die Architektur- ist die Fähigkeit, auf Änderungen zu reagieren, wichti- planung, ob sich vorhandene Komponenten direkt oder ger als das Verfolgen eines Plans. durch eine Erweiterung wiederverwenden lassen (manchmal geschieht dies auch in einem „Komponen- Bei allen agilen Verfahren ist das Team Dreh- und Angel- ten-Komitee“). Besteht ein genereller Bedarf an neuen punkt. So zeigen sämtliche professionellen Teams einen Komponenten, wird ein „Vertrag“ mit der Komponen- hohen Grad an Selbstorganisation, wenn sie das nötige ten-Bereitstellung auf Basis einer formalisierten Schnitt- Vertrauen erhalten. Metaprozess-Verfahren wie Adaptive stellenbeschreibung abgeschlossen. Systems Development überlassen es – je nach Erfahrung und Professionalität – dem Team, den Prozess festzule- Das Ermitteln von dauerhaft einsetzbaren Komponenten gen. Konkrete Verfahren wie XP beschränken sich darauf, kann nur auf der Basis einer gründlichen Kenntnis der dem Team Ratschläge zu unterbreiten, wie sich die Soft- Geschäftsprozesse erfolgen und nicht aus den Anfor- ware möglichst variabel entwickeln lässt.