Suche
Knigge für Software-Architekten

Erfolgsmuster: Der technische Risikomanager

Peter Hruschka und Gernot Starke

Willkommen in der vierzehnten Ausgabe unserer Kolumne rund um Verhaltensmuster von Softwarearchitekten.

Sicher kennen Sie Murphy. Ein Fehler tritt immer dann auf, wenn Sie es am wenigsten gebrauchen können. Und der Rauch zieht immer zum Nichtraucher.

In jedem Projekt oder System drohen solche „Murphy-Effekte“, egal mit welcher Technologie, Infrastruktur oder Organisationsform Sie arbeiten. Erfolgreiche Architekten gehen ganz bewusst mit Murphy (= Risiken) um. Zwischen „Yes, we can“ und „Das haben wir schon immer so gemacht“ finden sie einen angemessenen Weg.

Architekt = Berater des Projektleiters

Was hat ein Softwarearchitekt mit Risikomanagement zu tun? Diese Aufgabe erfüllen doch Projektleiter, oder? Wir sehen das auch so – aber Softwarearchitekten müssen die technischen und architektonischen Murphy-Drohungen in Systemen finden und behandeln. Softwarearchitekten sollten Projektleiter auf technische Risiken aufmerksam machen und bezüglich des Umgangs mit ihnen beraten.

Risiken durch Bewertung finden

Ein Risiko (= Murphy-Drohung) ist ein potenzielles Problem. Und ein Problem ist ein eingetretenes Risiko. Wie finden Sie jedoch die Risiken in Ihrer Architektur? In der sechsten Folge dieser Kolumne („Blick in den Rückspiegel„) haben wir Ihnen systematische Architekturbewertung ans Herz gelegt. Sie bringt vor allem Risiken (und Chancen!) Ihrer Architektur ans Tageslicht. Integrieren Sie also qualitative Bewertung, etwa mit ATAM, zur Offenlegung von Stärken und Schwächen, Chancen und Risiken in Ihre Arbeit als Softwarearchitekten.

Was tun mit Risiken?

Eine Übersicht der technischen Risiken ist die notwendige Voraussetzung, um gezielt mit ihnen umgehen zu können. Sie können grundsätzlich eine der folgenden vier Möglichkeiten für jedes Risiko ergreifen:

  • vermeiden (risk avoidance)
  • bewusst in Kauf nehmen (risk taking),
  • durch gezielte Maßnahmen abmildern (risk mitigation) oder
  • ignorieren
Manche Risiken vermeiden

Risiken vermeiden heißt z. B. risikobehaftete Teile der Architektur komplett anders zu lösen – mit einer weniger risikobehafteten Alternative. Sollten Sie versuchen, alle Risiken zu vermeiden? Nein, keinesfalls. Tom DeMarco und Tim Lister behaupten im „Bärentango“ [1]: „Alle risikoarmen IT-Projekte wurden bereits in den 60er und 70er Jahren des letzten Jahrhunderts durchgeführt.“

Vermeiden sollten Sie beispielsweise Risiken mit katastrophalen Auswirkungen oder sehr hoher Eintrittswahrscheinlichkeit.

Risiken in Kauf nehmen

Risiken bewusst in Kauf zu nehmen, heißt die Auswirkung des Risikos ertragen zu können. Das ist eine gute Taktik, wenn die Vermeidung dieses Risikos für das Projekt teurer ist, als die eventuelle Auswirkung zu beseitigen. Vielleicht ist auch die Eintrittswahrscheinlichkeit derart klein, dass Sie ein solches Risiko akzeptieren können. In Kauf nehmen kann auch bedeuten, sich gegen die Auswirkung abzusichern – etwa eine Versicherung gegen den Eintrittsfall abzuschließen.

Risk Mitigation = Plan B

Risk Mitigation heißt, sich mit dem Risiko auseinanderzusetzen und gezielte Maßnahmen im Projekt einzuplanen, die das Risiko oder seine Auswirkung abmildern. Und zwar zu einem Zeitpunkt, bevor das Risiko zum Problem geworden ist. Zu solchen Maßnahmen gehören beispielsweise Anpassung betroffener Teile der Architektur, gezieltes Prototyping neuer Technologien, Coaching des Teams oder der berühmte Plan B. Wir sind uns ganz sicher: Wenn Sie das Risiko kennen, dann fallen Ihnen und Ihrem Team vernünftige Maßnahmen zur Abhilfe ein!

Risiken ignorieren = Waghalsigkeit

Ignorieren bedeutet z. B. mit einem neuen Framework zu arbeiten, das weder Sie noch irgendein vertrauenswürdiger Kollege in einem ähnlichen Projekt bisher eingesetzt hat, und einfach zu sagen: Wird schon gut gehen. Aus unserer Sicht stellt das ein waghalsiges oder fahrlässiges Verhalten dar, das Sie sich als verantwortungsbewusster Softwarearchitekt nicht erlauben sollten!

Fazit

Egal wie optimistisch Sie im wirklichen Leben auch sein mögen – achten Sie explizit auf die Architekturrisiken Ihrer Systeme. Schreiben Sie erkannte Risiken auf und kommunizieren Sie diese offen – ebenso wie Ihre Strategien zum Umgang damit.

Peter Hruschka und Gernot Starke haben vor einigen Jahren www.arc42.de ins Leben gerufen, das freie Portal für Softwarearchitekten. Sie sind Gründungsmitglieder des International Software Architecture Qualification Board (www.iSAQB.org) sowie Autoren mehrerer Bücher rund um Softwarearchitektur, Softwareentwurf und Entwicklungsprozesse. Mehr finden Sie unter www.systemsguild.com (Peter) und www.gernotstarke.de (Gernot). Seit Jahresanfang ist Gernot auch innoQ-Fellow.
Geschrieben von
Peter Hruschka und Gernot Starke
Kommentare

Schreibe einen Kommentar

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