aim42

Offene Methode zur systematischen Verbesserung bestehender Software („Architecture Improvement Method“), mitentwickelt von Gernot Starke. Sie verbessert iterativ in den Phasen Analyze, Evaluate und Improve. Der Kern: Probleme und Massnahmen werden in Geld bewertet, damit Technik in der Sprache des Managements argumentieren kann.

Grundidee

Die meisten Entwickler pflegen bestehende Systeme, statt neue zu bauen. Die Informatikausbildung konzentriert sich trotzdem auf Neuentwicklung (Quelle - Effektive Softwarearchitekturen, S. 319). aim42 ist ein Open-Source-Projekt (aim42.org, aim42.github.io). Der Methodenleitfaden ist in AsciiDoc geschrieben, mit Gradle gebaut und unter einer Creative-Commons-Lizenz veröffentlicht (S. 322, 335).

Probleme verursachen Kosten. Üblich ist, nur die Kosten von Massnahmen zu schätzen. aim42 schätzt auch, was ein Problem kostet und wie oft: Mehraufwand in Entwicklung und Betrieb, zusätzliche Hardware, entgangener Umsatz, Opportunitätskosten, anfallend pro Änderung, pro Release oder pro Aufruf (S. 322).

Begriffe

• Issues (Probleme) und Improvements (Massnahmen) stehen im m:n-Verhältnis: Eine Massnahme kann mehrere Probleme lösen, ein Problem mehrere Massnahmen brauchen.
• Beide verursachen Kosten; Massnahmen bergen Risiken, etwa neue Probleme.
• Manche Probleme sind nur Symptome einer tieferen Ursache (root cause). Eine träge Oberfläche kann an einer schlecht konfigurierten Datenbank liegen (S. 323).

Die drei Phasen und das Querschnittliche

1. Analyze: Probleme sammeln (Issue-Liste) und das System verstehen. Empfohlen sind Stakeholder-Analyse und -Interviews, Kontext- und Dokumentationsanalyse, Prozessanalyse, statische Codeanalyse, das Erfassen der Qualitätsanforderungen, qualitative Bewertung nach ATAM (Architekturbewertung), Laufzeitanalyse und Datenanalyse (S. 327). Ursache und Symptom unterscheiden (Root-Cause-Analysis).
2. Evaluate: Probleme und Massnahmen in Geld bewerten. Wer sagt „das können wir nicht schätzen“, bringt eine faule Ausrede. Man schätzt in Intervallen (Estimate-in-Interval): Die Breite zeigt die Unsicherheit. Annahmen werden offengelegt (Explicit Assumption) (S. 329).
3. Improve: Massnahmen planen und umsetzen (S. 330–333).
4. Crosscutting: laufend Massnahmenvorschläge im Improvement Backlog sammeln und die Issue-Liste pflegen. Das Muster Expect Denial warnt: Mit Widerstand „aus Prinzip“ fest rechnen (S. 334).

Alles läuft iterativ, wie im Deming-Kreis (PDCA): Problem finden, Massnahme finden, bewerten, anwenden, prüfen (S. 324). Bewertungen ändern sich mit der Zeit und müssen regelmässig überprüft werden.

Maximen

Die Grundregeln für jedes Verbesserungsprojekt (S. 330):

• Improve Iteratively – in kleinen Schritten verbessern;
• Fast Feedback – früh Rückmeldung holen;
• Reduce Complexity – unnötige (accidental) Komplexität entsorgen, KISS;
• Prototype Improvement – Massnahmen im Kleinen ausprobieren (Prototyping);
• Verify Every Change – auch angeblich nebenwirkungsfreie Änderungen prüfen;
• Explicit Assumptions – Annahmen offenlegen.

Widen Your Options: Der Suchraum für Massnahmen sollte breit sein, nicht nur der Code. Man kann einen Teil austauschen oder kapseln, die Anforderung wegdiskutieren, das Problem jemand anderem geben oder bessere Hardware kaufen (S. 325).

Kategorien von Massnahmen

• Vorgehen festlegen: schrittweise ablösen (Legacy Strangulation), Feature-Toggles oder Frontend-Switch (die Oberfläche leitet Anfragen an alte oder neue Teile weiter) oder Big-Bang-Ablösung. Dazu eine gemeinsame Branch-Strategie.
• Prozesse verbessern und Architektur-Governance aufbauen: Warum konnten die Probleme überhaupt entstehen? (S. 331)
• Codestrukturen verbessern: Refactoring, Restrukturierung, Modularisierung. Grundlage sind automatisierte Tests (Softwaretest).
• Querschnittliche Konzepte verbessern: Fachlichkeit nachträglich von Technik trennen (extract business domain, Domain-Driven Design), Technologie sachgerecht einsetzen, gezielt an Qualitätsmerkmalen arbeiten (Softwarequalität).
• Infrastruktur verbessern: Selbstgebautes durch Fertigteile ersetzen, Make-or-buy überdenken, Testautomatisierung, Continuous Integration und Delivery (S. 333).
• Analysierbarkeit verbessern: Logging, Tracing und Controlling schaffen Fakten, wo vorher keiner Durchsatz, Aufwände oder Fehlerzeiten kannte.

Beispiele aus dem Methodenkatalog

Der Leitfaden katalogisierte 2015 gut 80 Praktiken (S. 326), darunter:

Es sind Heuristiken, keine Algorithmen; sie brauchen Fingerspitzengefühl (S. 326, Heuristiken in BWL und Informatik).

Heute: Der Methodenleitfaden steht weiter öffentlich unter aim42.github.io, das Repository unter der Apache-Lizenz 2.0. Laut Suchergebnis wurde es zuletzt im Mai 2024 geändert; das Projekt wirkt ruhiger als arc42 (Quelle - Recherche - Softwarearchitektur heute 2026, unsicher).

Literatur: Zur Evolution gibt es wenig. Starke empfiehlt „Managed Evolution“ von Stephan Murer u. a. über die IT einer Schweizer Grossbank und „Working Effectively with Legacy Code“ von Michael Feathers (S. 335).

Verwandt

• Technische Schulden – das Problem, das aim42 angeht
• Architekturbewertung – ATAM und Metriken in der Analysephase
• arc42 – das Schwesterprojekt für Dokumentation
• Gernot Starke – Mitbegründer
• Problemlösungsprozess – derselbe Kreislauf aus Analyse, Bewertung und Umsetzung in der BWL
• Risikoanalyse – Kosten und Häufigkeit bewerten, aus Sicherheitssicht