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.
- Wartbarkeit: globales Redesign innerhalb von fünf Personentagen realisierbar
- Maintenance: Einarbeitungszeiten, Aussagen zu möglichen Erweiterungen
-
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,
- die eigene Zielsetzungen sehr klar zu formulieren und auf priorisierte UseCases herunterzubrechen
- miteinander über Zielerreichung - gerade von konkurrierenden Zielen - zu sprechen
- eine gemeinsame Sicht auf mögliche Risiken und TradeOffs zu entwickeln und folgend
- 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.
- Nächster Artikel: Respekt!
- Vorheriger Artikel: "Löffelstellung", die Suche im Web und ich
- Kategorie: Projekt, Leitung
Kommentar schreiben