Viele Teams entwickeln agil, aber ihre Softwarearchitektur hält dem Tempo nicht stand. Anforderungen ändern sich, Oberflächen wachsen, Logik wandert dorthin, wo gerade Platz ist – und nach wenigen Monaten ist das System schwer verständlich. Der Werkzeug‑ und Materialansatz (WAM – Werkzeug Automat Material; international auch als Tools & Materials Approach bezeichnet) adressiert genau dieses Problem. Er ist konkret, leichtgewichtig und kognitiv ergonomisch. Und er harmoniert mit agilen Arbeitsweisen besser, als man zunächst vermuten würde.
Konkrete Metaphern statt abstrakter Modelle
WAM arbeitet mit Begriffen, die jeder intuitiv versteht:
- Materialien sind fachliche Objekte, die bearbeitet werden.
- Werkzeuge sind Oberflächen, mit denen Anwender arbeiten.
- Automaten erledigen Hintergrundprozesse.
- Fachwerte definieren präzise, unveränderliche fachliche Größen.
- Services bündeln Logik, die weder in Werkzeuge noch in Automaten gehört.
Diese Metaphern sind nicht dekorativ, sondern strukturierend.
Sie schaffen Klarheit, weil sie an reale Arbeitssituationen anknüpfen – Menschen bearbeiten Materialien mit Werkzeugen. Software sollte genau das widerspiegeln.
Mini‑Beispiel:
Eine Bestellung ist ein Material.
Die Bestellmaske ist ein Werkzeug.
Der Lagerabgleich ist ein Automat.
Der Preis ist ein Fachwert.
Die Berechnung der Versandkosten ist ein Service.
Schon dieses einfache Beispiel zeigt, wie WAM Orientierung schafft.
Saubere Trennung der Verantwortlichkeiten
WAM definiert eine klare Hierarchie:
- Fachwerte kennen nur sich selbst.
- Materialien kennen Fachwerte und andere Materialien.
- Services kennen Materialien und Fachwerte.
- Werkzeuge enthalten keine Fachlogik.
- Automaten arbeiten autonom im Hintergrund.
Diese Struktur verhindert Kopplung, reduziert Komplexität und sorgt dafür, dass Systeme auch nach Jahren noch verständlich bleiben.
WAM ist damit nicht nur ein Modell – es ist ein mentales Ordnungssystem.
Natürliche Kompatibilität mit Agile
Agile beschreibt, wie Teams arbeiten: iterativ, inkrementell, mit schnellem Feedback.
WAM beschreibt, wie Software strukturiert wird: klar, stabil, modular.
Beide ergänzen sich perfekt:
- Agile erzeugt Veränderung.
- WAM absorbiert Veränderung.
Wenn Anforderungen sich ändern, ändert sich im WAM nicht das ganze System, sondern nur das betroffene Werkzeug oder Material. Die Architektur bleibt stabil, obwohl das Produkt sich weiterentwickelt.
Das reduziert Entscheidungslast und verhindert, dass Teams „Architektur später nachziehen“ müssen.
Unterstützung für iterative Entwicklung
WAM ist modular aufgebaut:
- Materialien können einzeln entwickelt werden.
- Werkzeuge können entstehen, bevor alle Automaten existieren.
- Fachwerte sind von Anfang an stabil.
- Services lassen sich schrittweise erweitern.
Diese Modularität passt perfekt zu kurzen Sprints und inkrementeller Lieferung.
Teams können unabhängig arbeiten, ohne dass die Architektur zerfällt.
Vermeidung technischer Schuld
Viele agile Teams geraten in die Falle, schnell zu liefern und Architektur später „nachzuziehen“.
WAM verhindert das, weil die Struktur von Anfang an klar ist:
- Werkzeuge enthalten keine Fachlogik.
- Materialien mutieren nicht zu Mini‑Services.
- Automaten bleiben reine Hintergrundprozesse.
- Fachwerte sind eindeutig und unveränderlich.
Diese Regeln sind leichtgewichtig, aber wirkungsvoll.
Sie schützen die Architektur, ohne die Agilität zu bremsen – und sie machen entstehende technische Schuld früh sichtbar.
Menschenzentriert und kognitiv ergonomisch
WAM stammt aus der Arbeitspsychologie und Soziologie.
Er orientiert sich an realen Arbeitssituationen, nicht an theoretischen Modellen.
Das hat einen entscheidenden Vorteil:
Die Begriffe sind kognitiv ergonomisch.
Sie reduzieren mentale Last, weil sie an vertraute Tätigkeiten anknüpfen.
Agile verfolgt denselben Gedanken: Menschen zuerst, Klarheit vor Bürokratie.
WAM und Agile passen kulturell und methodisch zusammen.
Erstaunlich modern
Obwohl WAM in den 1990ern entstand, findet man seine Ideen heute in vielen modernen Architekturen wieder:
- Fachwerte entsprechen Value Objects.
- Materialien entsprechen Entities.
- Services entsprechen Domain Services.
- Werkzeuge entsprechen UI‑Layern.
- Automaten entsprechen Background Jobs.
Dass WAM und Domain‑Driven Design sich unabhängig voneinander entwickelt haben, aber ähnliche Strukturen besitzen, zeigt, wie robust die Grundideen sind.
Schlussgedanke
Agile braucht eine Architektur, die Veränderung nicht fürchtet.
WAM liefert genau das: eine klare, menschliche Struktur, die Teams entlastet, Systeme stabil hält und Weiterentwicklung erleichtert.
Es ist kein Ersatz für moderne Architekturansätze – es ist ihre gemeinsame Wurzel.
Weiterführende englischsprachige Literatur zum Werkzeug‑ und Materialansatz findet sich im Buch Object-Oriented Construction Handbook – Developing Application-Oriented Software with the Tools and Materials Approach von Heinz Züllighoven.