JAXenter.de

Das Portal für Java, Architektur, Cloud & Agile

Robustheit und Flexibilität: Widerspruch oder perfekte Symbiose?

Gegensätze ziehen sich an

Robustheit und Flexibilität: Widerspruch oder perfekte Symbiose?

Business Tecnology Magazin 2.13

Architektur ist darauf ausgerichtet, allgemein anerkannte Prinzipien für den Bau einer Sache auf längere Sicht stabil zu halten und anzuwenden. Unternehmensarchitektur im Speziellen soll langfristig stabil und robust sein. Auf der anderen Seite gilt es, bei der Entwicklung von Anwendungen in der IT größtmögliche Flexibilität und schrittweises Verbessern, eben Agilität, anzuwenden. Dies scheint ein Gegensatz zu sein.

In einem größeren, mehrjährigen Projekt wurde durch entsprechende Vorgehensweise, Teamzusammensetzung und Architekturarbeiten versucht, diesen scheinbaren Gegensatz aufzulösen. Wir berichten über unsere Erfahrung, die gezeigt hat, dass sich diese Gegenpole in der Praxis sogar anziehen.

Vorgehensweise

Jede von Menschenhand gebaute Sache – sei es ein Softwareprodukt oder ein komplexes System – unterliegt einem Lebenszyklus. Jede Phase (Konzeption, Entwicklung, Produktion, Betrieb und Wartung, Entsorgung) verfolgt einen ganz bestimmten Zweck. Die Anwendung entsprechender Prozesse und Aktivitäten stellt die zur Zweckerfüllung erforderlichen Resultate jeder Phase her. Ein Entscheidungspunkt (Review, Meilenstein) stellt sicher, dass Aktivitäten einer Folgephase erst dann gestartet werden, wenn die Ergebnisse der Vorphase – auf denen im weiteren Verlauf der Entwicklung aufgebaut wird – eine ausreichende Robustheit aufweisen.

Doch IT-Anwendungen werden nicht zum Selbstzweck entwickelt; die Balance zwischen den technischen, geschäftlichen und den finanziellen Aspekten muss stimmen. Die Geschäftsleitung wird keine Zustimmung zur Durchführung von Folgeaktivitäten geben, wenn der Business Case nicht klar ersichtlich ist oder die Kosten aus dem Ruder laufen (Abb. 1).

Abb. 1: Managed Evolution [1]

Die ISO/IEC 12207 (Abb. 2) ist ein international anerkannter Standard [2], der einen umfassenden Satz von Prozessen, Aktivitäten und Aufgaben definiert, die den kompletten Lebenszyklus eines Softwareprodukts beschreiben, das Teil eines Gesamtsystems oder allein stehend sein kann. Aus System-Engineering-Sicht interessant ist dabei die so genannte Kategorie der technischen Prozesse, aus Sicht der IT die SW-Implementierungsprozesse, die sich nahtlos ins übergeordnete Korsett der Systemprozesse einfügen.

Abb. 2: ISO/IEC 12207 Development Processes

Es gibt nun verschiedene Vorgehensmodelle, die beschreiben, in welcher Abfolge die Entwicklungsaktivitäten zur Herstellung eines IT-Produkts durchzuführen sind. Als klassisches Modell gilt das Wasserfallmodell, bei dem jede Entwicklungsphase einen vordefinierten Start- und Endpunkt mit eindeutig definierten Ergebnissen hat. Das Wasserfallmodell ist ein lineares und nicht iteratives Vorgehensmodell, sehr robust und wird dort eingesetzt, wo präzise beschriebene Anforderungen, Liefergegenstände und Termine vorhanden sind. Sind diese Voraussetzungen allerdings nicht gegeben, so muss das Vorgehensmodell mit diesen Risiken umgehen.

Genau das ist der wesentliche Aspekt des Spiralmodells, in dem die Entwicklungsphasen im Unterschied zum Wasserfallmodell mehrfach spiralförmig durchlaufen werden. Es gehört daher zu den inkrementellen und iterativen Vorgehensmodellen, bei denen die Geschäftsleitung immer wieder steuernd in den Entwicklungsprozess eingreifen kann.

Das in Deutschland entwickelte V-Modell fordert im Gegensatz zu den phasenorientierten Vorgehensmodellen keine strikte zeitliche Abfolge, betont aber die frühzeitige Berücksichtigung von Integration und Verifikation bereits während der Spezifikation und Dekomposition. Das V-Modell lässt sich sowohl auf das Wasserfallmodell als auch das Spiralmodell abbilden, das V-Modell XT unterstützt sogar agile Ansätze.

Bei der Gegenüberstellung der Vorgehensmodelle wurden nun drei verschiedene Ansätze angesprochen, die hier nochmal explizit genannt sein sollen:

  1. Der phasenorientierte Ansatz (Plan-driven)
  2. Der inkrementelle und iterative Ansatz (Incremental and Iterative Development, kurz IID)
  3. Der agile Ansatz (Agile Development)

Das Spektrum in dieser Aufzählung reicht von sehr systematisch, formal und schwerfällig (Plan-driven) bis zu selbstorganisierend und leichtgewichtig (Agile Development). Die Stärken des phasenorientierten Ansatzes sind Stabilität, Reproduzierbarkeit und Berechenbarkeit, was vor allem in sicherheitskritischen Produkten oder Systemen wichtig ist. Allerdings kann bei diesem Ansatz nur schwerlich auf unerwartete Änderungen reagiert werden. Genau diese Flexibilität ist die Stärke des agilen Ansatzes, bei dem das Hauptaugenmerk darauf ausgerichtet ist, trotz sich häufig ändernder Anforderungen in möglichst kurzen Abständen lauffähige Software ausliefern zu können.

IID bewegt sich zwischen diesen beiden Extremen und ist der Ansatz, der in dem eingangs erwähnten, größeren, mehrjährigen Projekt für die Entwicklung der Software gewählt wurde. Bei diesem Projekt handelt es sich um ein Systemprojekt, das phasenorientiert, nach exakten Zeitplänen und Lieferlisten gemäß zahlreichen Standards abgewickelt wird. Die Anforderungen auf Systemebene sind vorhanden und stabil, allerdings vergehen in so einem Systemprogramm mit diesem Ansatz Jahre, bis ein ausreichend detaillierter Satz von Anforderungen an die Software abgeleitet wurde. Da es aber trotzdem schon sehr früh im Programm die erste lauffähige Software auszuliefern galt, wurde für die Softwareentwicklung der IID-Ansatz gewählt. Dieser Ansatz eignet sich besonders dann, wenn die Anforderungen unklar oder nicht stabil sind bzw. die Möglichkeit neue Technologie einzubauen lange offen gehalten werden soll. IID erlaubt es, eine anfängliche Funktionalität relativ früh auszuliefern, gefolgt von nachfolgenden Lieferungen bis zum funktionalen Vollausbau.

Im referenzierten Projekt wurde die Entwicklung des gesamten Funktionsumfangs auf sechs Inkremente verteilt, die eine Laufzeit von ca. einem halben Jahr aufweisen. Da eine serviceorientierte Architektur (SOA) ausgewählt wurde (mehr dazu im Architekturteil am Ende dieses Artikels) galt es, das komplette Serviceportfolio entsprechend der Liefertermine in mehrere Releases aufzuplanen, sodass am Ende eines jeden Inkrements lauffähige Services zur Auslieferung bereitstanden. Vor jedem neuen Inkrement wurde zusätzlich in einem Configuration Control Board (CCB) entschieden, ob ein bereits ausgelieferter Service aufgrund von Anforderungsänderungen aus dem Business oder aus der IT einer Iteration unterzogen und im neuen Inkrement nochmal überarbeitet wird.

Betrachtet man das beschriebene IID genauer, lassen sich einige Parallelen zu Scrum, einer der bekanntesten agilen Methoden, erkennen: Inkrement vs. Sprint, Release Planung vs. Sprint Backlog, Serviceportfolio vs. ProductBacklog, CCB vs. Retrospektive usw. Die Releasezyklen im beschriebenen IID unterscheiden sich doch signifikant von der typischen Dauer eines Sprints, die zwischen einer und vier Wochen liegt. Zudem ist das Vorgehen innerhalb eines Inkrements eher vergleichbar mit dem V-Modell bzw. einem iterativen Wasserfall über alle Entwicklungsphasen, weniger mit agilen Methoden. Da aber alle Aktivitäten des SW-Implementierungsprozesses innerhalb eines Inkrements durchschritten werden, ist wie bei Scrum ein interdisziplinäres Entwicklungsteam für ein inkrementelles und iteratives Vorgehen erforderlich, ein so genanntes integriertes Produktentwicklungsteam (Integrated Product Development Team, kurz IPDT).

Mehr aus dieser Ausgabe

Artikel erschienen in

Business Tecnology Magazin 2.13
Viele Projekte, die sich mit Unternehmensarchitektur beschäftigen, sind starr,…
Business Tecnology Magazin 2.13
Die fiktive Firma Amazine hat ein Problem: Das Geschäft wird gebremst durch die…
Manchmal verändert ein einziges Element Dinge von Grund auf. Der Wechsel vom…
Business Tecnology Magazin 2.13
Architektur ist darauf ausgerichtet, allgemein anerkannte Prinzipien für den…
Business Technology Magazin 2.13
Sie werden sich beim Lesen der Überschrift sicherlich fragen, was eine Notation…
©Shutterstock/CoraMax
Im Laufe der Zeit wird Software oft zunehmend weniger änderbar und flexibel:…
©Shutterstock/kentoh
Die fiktive Firma Amazine hat ein Problem: Das Geschäft wird gebremst durch die…
Zum Vertriebserfolg in der Softwarebranche gehören heute nicht nur klassische…
Agile Methoden haben sich in vielen Softwareentwicklungsvorhaben als sinnvolle…
©iStockphoto.com/danleap
Die IT-Landschaft von rund der Hälfte der gesetzlichen Krankenversicherungen in…
©Shutterstock/Sergey Nivens
Viele Projekte, die sich mit Unternehmensarchitektur beschäftigen, sind starr,…
©Shutterstock/Raywoo
Manchmal verändert ein einziges Element Dinge von Grund auf. Der Wechsel vom…
Norm Judah
Norm Judah ist Chief Technology Officer of Worldwide Services bei Microsoft. In…
©Shutterstock/Sergey Nivens
Durch Produktinnovationen und regulatorische Anforderungen sind kontinuierliche…
Es gibt viele Möglichkeiten, gewachsene Anwendungslandschaften in Unternehmen…
 
Verwandte Themen: 

Kommentare

Ihr Kommentar zum Thema

Als Gast kommentieren:

Gastkommentare werden nach redaktioneller Prüfung freigegeben (bitte Policy beachten).

Übersicht zu diesem Beitrag