Suche
Gegensätze ziehen sich an

Robustheit und Flexibilität: Widerspruch oder perfekte Symbiose?

Hermann Schlamann, Tobias Fleischmann
24_31_fleischmann_schlamann
©iStockphoto.com/Rike_

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).

[ header = Seite 2: Teamzusammensetzung ]

Teamzusammensetzung

Entscheidend bei einer integrierten Produktentwicklung ist, dass alle Aspekte des Produktlebenszyklus innerhalb eines Inkrements betrachtet werden, und dass alle entsprechenden Rollen kontinuierlich über die gesamte Dauer eines Inkrements zur Verfügung stehen. Es kann während der Anforderungsanalyse ausreichend sein, dass eine Person zusätzlich zur Rolle des Analysten auch noch die Rolle des Testers einnimmt. Während der Testphase wird diese Rolle von mehreren Personen exklusiv eingenommen. Ein IPDT ist eine integrierte Gruppe von fachlichen Teams und arbeitet stark prozessorientiert, um die Zeit bis zur Auslieferung zu verkürzen, die Produktqualität zu erhöhen, und um Entwicklungskosten zu sparen.

Im Teamorganigramm des angesprochenen Projekts gibt es drei wichtige Säulen: Architektur, Entwicklung, Integration und Test (I und T). Die Architektur legt anzuwendende Architekturmuster und Designprinzipien fest und definiert den Grobentwurf (v.a. Serviceschnittstellen). Die Entwicklungsteams, sortiert nach fachlichen bzw. technischen Domänen, zeichnen sich für die fachliche Analyse, den Feinentwurf, das Coding sowie die Entwicklungstests verantwortlich. Integration und Test ist für die Bereitstellung lauffähiger Software zuständig, was neben der Verifikation der Anforderungen auch den Nachweis zur Einhaltung von Architekturvorgaben inkludiert – führt also die inhaltliche Qualitätsprüfung durch. Diese wird im SOA-Umfeld auch Governance genannt und begleitet den ganzen Entwicklungsprozess (Abb. 3).Abb. 3: Governance-Prozess

Die Governance ist für alle Prozessaktivitäten relevant, im Besonderen aber ist Kontrolle und Nachsteuerung für die Umsetzung einer Architektur unerlässlich. Gemäß dem Leitsatz:

YOU CAN’T MANAGE WHAT YOU DON’T MEASURE

YOU CAN’T MEASURE WHAT YOU DON’T SPECIFY

wird der Grundstein dafür bereits in der Definition der Architektur selbst gelegt. Stellt sich die Frage: Wie lässt sich eine Architektur sauber und möglichst eindeutig spezifizieren? Im zitierten Projekt wurden von den Architekten beispielsweise Kommunikations-Pattern bzw. für die Modellierung das produktspezifische Vokabular in Form eines Metamodells definiert (Details dazu im Architekturabschnitt). Werden diese Spezifikationen nun im Architekturprozess verankert bzw. im CASE-Tool implementiert, minimiert sich die Zahl der Verstöße bereits signifikant. Durch entsprechende Metriken, so genannte Key-Performance-Indikatoren (KPIs), kann das Integration-und-Test-Team die Konformität zu den Architekturvorgaben messen und bei Nichteinhaltung entsprechende Nacharbeiten durch die Entwicklung anstoßen.

[ header = Seite 3: Architektur ]

Architektur

IT-Architektur, insbesondere Unternehmensarchitektur, ist langfristig ausgerichtet und versucht allgemein anerkannte Prinzipien für den Bau oder den Betrieb einer Sache stabil zu halten. Der Inhalt einer Architektur setzt sich aus Regeln und Verfahren zusammen, die in einem konkreten Fall angewendet werden sollen. Nun ist nicht jeder Anwendungsfall gleich. Es gibt immer Unterschiede, die berücksichtigt werden müssen. Darauf sollten die Architekturen abgestimmt sein, was bedeutet, dass Architekturregeln so allgemein abgefasst werden müssen, dass möglichst viele Anwendungsfälle davon abgedeckt werden. Dennoch sollen die Regeln so konkret sein, dass für den Anwender ein brauchbarer Lösungsansatz dabei herauskommt.

Als eine sinnvolle und in der Praxis bewährte Strukturierung der Architektur hat sich die Trennung zwischen Business- und IT-Architektur herausgestellt. Die Object Management Group (OMG) [3] hat mit ihrer Model-driven Architecture (MDA) [4] dafür eigens einen Standard geprägt. Für alle drei dort genannten Ebenen (Computational Independent Model [CIM], Platform Independent Model [PIM], Platform Specific Model [PSM]) gibt es eigene Architekturmodelle, die mittels Transformationen ineinander überführt werden können.

Im zuvor genannten Projekt war die Anwendung dieses Standards eine der ersten grundlegenden Entscheidungen. Eine weitere auf Stabilität und gleichzeitig Flexibilität ausgerichtete Architekturentscheidung ist die Verwendung des Paradigmas der Serviceorientierung (SOA). Die Verwendung des SOA-Paradigmas hatte zur Folge, dass bereits auf Businessebene Anforderungen formuliert und „Business Services“ entworfen wurden. Eine Typenunterscheidung dieser Business Services in solche, die „von der Stange“ zu kaufen sind, also Commodity Services darstellen, und solche, die „wertschöpfende“ Services für das Unternehmen darstellen, machte zu einem recht frühen Zeitpunkt deutlich, für welche zu automatisierenden Business Services eine „Make or Buy“-Entscheidung zu fällen ist.

Commodity Services sind eindeutige Kandidaten für Automatisierungslösungen, die zugekauft und integriert werden und vom Projektteam nicht selber zu entwickeln sind.

In den wertschöpfenden Services steckt das eigentliche Know-how des Unternehmens. Daher sind diese Business Services Kandidaten für selbst zu entwickelnde Automatisierungslösungen und dürfen (können) nicht von Drittparteien zu fertigende Lösungen außer Haus gegeben werden.

Bleiben noch Business Services, die weder in die eine noch in die andere Kategorie fallen. Für diese Services muss von Fall zu Fall entschieden werden, ob eine Commodity-Lösung vorhanden ist, bzw. sinnvoll erscheint, oder ob die Anfertigung einer eigenen Lösung zielführender ist.

Im vorliegenden Projekt sind dies alles die Teile der Lösung, die zwar auf einer Standardautomatisierung beruhen (Commodity), aber projektspezifische Erweiterungen der Commodity-Lösung notwendig machen.

Dabei musste stets das Risiko solcher Erweiterungen auf die Releasefähigkeit der zugrunde liegenden Commodity-Lösung bewertet werden. Wir kennen das Thema von kundenspezifischen Anpassungen beim Einsatz von Standardlösungen – z. B. SAP.

Die Beschreibung bzw. Definition der Business Services führte bei den Projektbeteiligten zunächst zu Diskussionen über den Umfang und die Struktur der Beschreibungselemente. UML als Notation war durch den Auftraggeber vorgegeben. Darüber hinaus sollte dem Entwicklungsteam ein Satz von produktspezifischem Vokabular zur Verfügung stehen, um die zu modellierenden Sachverhalte in der Sprache der Fachexperten formulieren zu können.

In der UML kann mithilfe von produktspezifischen Stereotypen und der Möglichkeit des Profilings auf die Belange der Fachexperten Rücksicht genommen werden. Die Definition einer solchen Ontologie ist eine Aufgabe, die von einem erfahrenen Architekturteam vor Beginn der eigentlichen Modellierungsarbeiten zu erledigen ist. Verschiedenste Organisationen bieten für solche Arbeiten unterschiedliche Frameworks an, sodass „das Rad nicht immer wieder neu erfunden“ werden muss.

Als beherrschbares aber nicht geringes Projektrisiko stellte sich die Umsetzung der Ontologie in einem entsprechenden UML-Modellierungswerkzeug dar. Wir befanden keines der kommerziell verfügbaren Werkzeuge als ausgereift genug, um die Anforderungen des Profilings mit vertretbarem Aufwand bedarfsgerecht umzusetzen.

Zentrales Element einer Modellierungsebene bilden die jeweiligen Services (Business Services, Software Services und Run-time Services) und deren Beziehungen zueinander. Die Entwicklungsteams wurden nach den Hauptthemen der zu erstellenden Lösung gegliedert. Um sicherzustellen, dass gleichartig entwickelt wird und damit die erarbeiteten Ergebnisse vergleichbar sind, hat das Architekturteam eine Übersicht der Modellierungsartefakte zusammengestellt, die für die entsprechende Modellierungsebene als Pflichtergebnis zu erstellen sind (Abb. 4). Konkrete Guidelines in Verbindung mit entsprechendem Tooling unterstützen die Entwicklungsteams bei der Erstellung der Ergebnisse.

Abb. 4: Business-Service-Artefakte

[ header = Seite 4: Architekturlebenszyklus ]

Architekturlebenszyklus

Die Arbeiten auf Seiten des Architekturteams bleiben ungenutzt, wenn nicht innerhalb des Projekts dafür gesorgt wird, dass die anzuwendenden Regeln den Projektbeteiligten auch bekannt sind. Ein bedarfsgerechter Kommunikationsprozess aus der Architektur heraus sorgt für entsprechende Akzeptanz der Regeln.

Definition und Kommunikation von Architektur sind notwendige aber nicht hinreichende Bedingungen für erfolgreiche Lösungserstellung. In einem weiteren Prozessschritt ist die Einhaltung der Architekturregeln zu überprüfen. Wo Regeln nicht eingehalten wurden, ist durch ein Review (evtl. sogar automatisch) prüfbar. Bei Regelverletzungen ist nachzubessern (Abb. 3).

Wie eingangs dargelegt, sind Architekturregeln allgemein anerkannte, grundsätzliche Prinzipien, die auf Erfahrung beruhen. Obgleich langfristig stabil kann es vorkommen, dass Architekturregeln auch mal an neue Gegebenheiten angepasst werden müssen. Daher ist für ein Architekturregelwerk ein letzter Prozessschritt vorzusehen, der neue Erkenntnisse und Verbesserungen in das Regelwerk einarbeitet. Der vollständige Architekturlebenszyklus stellt sich wie in Abbildung 5 dar.

Abb. 5: Architekturlebenszyklus

Im genannten Projekt wurden diese Prozessschritte auf verschiedene Teams verteilt: Das Architekturteam war für die Spezifikation der IT-Architektur verantwortlich, das Integration-und-Test-Team für die Durchsetzung zuständig, beide Teams waren in die Verbesserung involviert.Für die Kommunikation, oft eine heikle Aufgabe, die Fingerspitzengefühl und langjährige Erfahrung erfordert.

[ header = Seite 5: Fazit ]

Fazit

Zusammenfassend konnten wir feststellen, dass zwischen Flexibilität zur Anpassung an unterschiedliche (Projekt-)Anforderungen und der gebotenen Stabilität einer Architektur kein Gegensatz bestehen muss. Im Gegenteil: Richtig angewandt und entsprechend zeitlich gestaffelt ergibt sich aus dem scheinbaren Gegensatz eine perfekte Symbiose, mit der sich erfolgreiche Projektarbeit umsetzen lässt.

Geschrieben von
Hermann Schlamann
Hermann Schlamann
Hermann Schlamann ist unabhängiger Berater, erfahrener IT-Architekt, Trainer und Coach und seit vielen Jahren mit dem Thema ITUnternehmensarchitekturund Serviceorientierung befasst. Er hat lange Jahre bei Schweizer Großbanken die Einführung von SOA maßgeblich mitgestaltet. Hermann ist regelmäßigerReferent auf nationalen und internationalen Fachtagungen und Verfasser von Fachbeiträgen. Er ist Autor eines Buchs über Serviceorientierung und gibt Trainings für IT-Unternehmensarchitektur und SOA.
Tobias Fleischmann
Tobias Fleischmann
Tobias Fleischmann ist System Ingenieur bei Cassidian, einer EADS-Tochtergesellschaft. Er beschäftigt sich schwerpunktmäßig mit der Entwicklung von Aufklärungssystemenund deren Vernetzung zu komplexen Sicherheitslösungen. Sein Fokus liegt im Bereich Systemarchitektur und Prozess. Er berichtet von seinenErfahrungen aus einem Projekt, in dem er als Enterprise-Architekt und stellvertretender Chief SW Engineer agiert.
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>