ATAM: Welchen Preis zahle ich?

Software-Architekten ist ATAM sehr vertraut. Die Architecture-Tradeoff-Analysis-Method legt bei bekannten fachlichen Zielen Zielerreichung und Risiken im Software-Lebenszyklus offen.

Die Methodik ist einfach. Und als Methode vollständig übertragbar auf das Gesamtprojekt. Es lohnt sich also ein Blick auf diese Methode - auch für Nicht-Softwarearchitekten. ATAM - eine Einführung.

ATAM (siehe auch: Wikipedia) sorgt für Kommunikation über fachliche Ziele, Umsetzungsform und sich daraus ergebenden Folgeerscheinungen (Risiken, TradeOffs) mit allen Projektpartnern. Kommunikationsfördernd und -einfordernd. ATAM folgt damit der Philosophie, dass nicht bestimmte Projekttools für den Erfolg entscheidend sind, sondern das richtige Verständnis untereinander.

Mit ATAM durchläuft das gesamte Projektteam, d.h. Vertreter aller Projektparteien, den folgenden Prozess:

• Vorgehen und Zielsetzung ATAM erklären
  Methoden funktionieren nur, wenn alle Projektpartner diese kennen und akzeptieren. Typischerweise werden bei Projektstart Projektpartner übersehen. Kandidaten sind der Kunde (!), dessen Geschäftsführung, Deine Geschäftsführung, die Marketingabteilung, die IT-Abteilung, die umsetzt und das Projekt unterhalten wird, die QA-Abteilung, und schließlich der Betrieb, der auch dieses Projekt für die nächsten fünf bis sechs Jahre betreuen wird - auch wenn die Zeitdauer so nicht geplant ist.
• Ziele definieren
  • Jeder der Projektpartner benennt die Ziele an das Projekt
  • Jeder Projektpartner stellt diese Anforderungen vor.
  • Alle Projektpartner stellen darüber Einvernehmen her.
  In Projekten werden gerne nur - weil diese so offensichtlich sind - fachlichen Ziele genannt. An dieser Stelle ist es wichtig, dass die "IT-Seite" ihrerseits Anforderungen formuliert, die auf das fachliche Ziel einzahlen bzw. der existierenden :
  • Wartbarkeit: globales Redesign innerhalb von fünf Personentagen realisierbar
  • Maintenance: Einarbeitungszeiten, Aussagen zu möglichen Erweiterungen
  Wichtig ist, dass alle Projektpartner die Ziele der anderen Projektpartner verstehen und akzeptieren. In der Praxis werden nur zu oft IT-Abteilungen als langsame, dem Gesamtergebnis nicht dienliche Behinderer, nicht aber als gleichberechtigte Projektpartner gesehen. Es gilt hier auf Augenhöhe zu verhandeln.
• Anforderungen im UtilityTree aufzeichnen
  Aus den Zielen leiten sich die Anforderungen ab. Fachlichen und technische Anforderungen werden im UtilityTree als UseCases aufgenommen. Die UseCase sind möglichst konkret formuliert.
  ATAM fragt für den Endkunden, die fachliche und technische Seite Qualitätskriterien ab. Damit die Darstellung im UitilityTree übersichtlich bleibt, werden die Anforderungen an Hand von (technischen) Qualitätskriterien sortiert dargestellt.

• Architektonische Szenarien entwickeln und jeweils in einem UtilityTree darstellen.
  Im UtilityTree wird jeweils vermerkt, wie wichtig die Anforderung in Bezug auf die fachliche Zielerreichung ist - und wie gut der jeweilige UseCase durch das gewählte architektonische Modell gelöst wird. Es entsteht daraus eine klare Darstellung zukünftiger Risiken und aktueller TradeOffs.
  Auch hier wird die Bewertung entsprechend der formulierten Qualitätskriterien (Endkunde, fachliche, technische Kriterien) vorgenommen.
• Diskutieren & entscheiden
  Die Modelle werden vorgestellt. Die Bewertungen (zusammen mit angenommenen Risiken & TradeOffs) werden allen Projektpartnern offengelegt. Durch die gemeinsame Entscheidung für ein bestimmtes Modell nach Diskussion aller Bewertungen entsteht daraus eine stabile Basis für das Projekt.

ATAM zwingt alle Projektpartner dazu,

1. die eigene Zielsetzungen sehr klar zu formulieren und auf priorisierte UseCases herunterzubrechen
2. miteinander über Zielerreichung - gerade von konkurrierenden Zielen - zu sprechen
3. eine gemeinsame Sicht auf mögliche Risiken und TradeOffs zu entwickeln und folgend
4. eine gemeinsame Entscheidung zum Vorgehen zu treffen

Damit unterstützt ATAM die interdisziplinäre Diskussion über Projekte. Ein guter Ansatz, der sich sicherlich ausbauen lässt.

Wohl an! Ausprobieren!

Mit Dank an Johann-Peter Hartmann für die Inspiriation zu diesem Thema ;-)

Dieser Blog-Post ist ein privater Beitrag von Judith Andresen.