Agile Unternehmen und flexible IT durch Serviceorientierung

DIE WIRKLICHKEIT

Das in Abbildung 2 beschriebene Szenario ist jeder IT-Abteilung leidlich bekannt. Es zeigt, wie Anwendungen direkt miteinander kommunizieren.

Abbildung 2: Der Ist-Zustand in der IT – eine unflexible und schwer wartbare Anwendungsarchitektur

Bei diesem Modell muss jede Anwendung „wissen“, auf welche Weise sie andere Anwendungen aufrufen muss. Die Ablauflogik der Geschäftsprozesse ist in mehreren Anwendungen partiell kodiert. Die Datenformate und Strukturen einer Anwendung müssen jeder Anwendung bekannt sein, die mit ihr kommunizieren möchte. Die Zahl der Verbindungen steigt dabei quadratisch mit der Anzahl der miteinander kommunizierenden Anwendungen. Um 10 Systeme zu verbinden, sind 90, bei 50 Systemen bereits 2450 Verbindungen notwendig. Sollen Anwendungen geändert oder erweitert werden, steigt der Schwierigkeitsgrad. Zudem ist es extrem schwierig, diese Anwendungen zu warten.

Trotz Objektorientierung und Client-Server- und Enterprise-Application-Integration-Technologien (EIA) steckt die Entwicklung von Unternehmensanwendungen in einer Krise. Es werden riesige Summen in die Wartung starrer und nicht wiederverwendbarer IT-Systeme gepumpt. Für Investitionen in Innovation fehlen meistens das Geld und die Zeit. Die IT in den Unternehmen ist den Anforderungen einer schnellen und kostengünstigen Implementierung der notwendigen und gleichzeitig rasanten Veränderungen der Geschäftsprozesse nicht gewachsen. Meist harmlos erscheinende Änderungen für den Fachbereich werden in der Praxis schnell zu kaum überschaubaren Eingriffen in bestehende IT-Landschaften. Es werden daher dringend neue Wege benötigt, um effiziente, flexible und kostengünstige Umsetzungen der geforderten Änderungen zu gewährleisten. Um Lösungen zu entwickeln, welche die IT-Anwendungsentwicklung aus ihrer Krise holen, müssen die Ursachen der heutigen Probleme erkannt werden.

DIE URSACHEN DER IT-KRISE

Die softwaretechnischen Ursachen der aktuellen IT-Krise sollen im Folgenden an einem Beispiel skizziert werden. Abbildung 3 zeigt als Beispiel eine Bestellanforderung, die aus den Entitäten Bestellantrag, Genehmigung und Bestellung besteht.

Abbildung 3: Eine Bestellanforderung als Beispiel für ein monolithisches Anwendungsmodell

Jedes Teilsystem implementiert die Geschäftslogik (gelber Kreis) für die Geschäftsfunktionen, die Ablauflogik (blaue Raute) für die Abfolge der Teilschritte und die Änderung von Datentransformaten (rotes Rechteck) entsprechend den Erfordernissen der Nachfolgeanwendungen. Solche Systeme können die Wünsche nach flexiblen Geschäftsprozessen nicht erfüllen. Änderungen der Geschäftsregeln (zum Beispiel erforderliche Genehmigungen bei einem anderen Bestellbetrag) erfordern das Programmieren der Ablauflogik innerhalb des Bestellantrags. Soll das Budget des Projekts, für das die Artikel bestimmt sind, zuerst geprüft werden, muss vor der Genehmigung vom Bestellantrag ausgehend ein Budgetprüfungsmodul aufgerufen werden. Nicht nur die Ablauf-, sondern auch die Datentransformationslogik des Bestellantrags müssen dann geändert werden. Eine Wiederverwendung des Moduls zur Budgetprüfung in einem anderen Prozess, zum Beispiel zur Personaleinstellung, erweist sich als sehr schwierig. Es müsste so geändert werden, dass es „weiß“, ob es zum Beispiel im Prozess Bestellung oder im Prozess Genehmigung aufgerufen wurde.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.