In meinen Architektur-Beratungseinsätzen geht es immer wieder um ähnliche Themen: Wie kann man ein System aufteilen und strukturieren? Wie geht man mit Legacy um? Während der Beratung stellt sich dann häufig heraus, dass auch die technischen Herausforderungen unklar sind: Soll das System besonders wartbar sein? Oder sicher? Benutzerfreundlich? Irgendwie ist das natürlich alles immer wichtig, aber was ist am wichtigsten? Und wann erfüllt das System die technische Herausforderung ausreichend? Wann ist es beispielsweise benutzerfreundlich genug? Bei diesen Fragen geht es um die nicht-funktionalen Anforderungen beziehungsweise die Qualität der Systeme. Im Gegensatz zu den fachlichen Anforderungen sind diese häufig unklar. Aber ohne klare Qualitätsziele können Architekt:innen keine technischen Lösungen entwerfen oder Technologien auswählen, weil nicht klar ist, welche technischen Herausforderungen das System lösen soll.

Drei typische Herausforderungen in Projekten

Im Kern sind es also drei Themen, die in der Praxis oft ein Optimierungspotential für den Entwurf von Softwarearchitekturen bieten:

Viele Projekte würden profitieren, wenn sie in diesen drei zentralen Bereichen besser aufgestellt wären. Es lohnt sich also, Wissen in genau diesen Bereichen aufzubauen. Und das Wissen fehlt offensichtlich sehr vielen – sonst hätten nicht so viele Projekte in diesen Bereichen Nachholbedarf.

Das notwendige Wissen, um diese Herausforderungen zu lösen, passt auf wenige Folien oder Buchseiten. Wer zu den Themen ein Buch liest oder eine Präsentation anschaut, kann aber höchstens einen Teil des Wissens aufnehmen. Selbst wenn man das gesamte Wissen so vermitteln könnte: Das ist nur die Theorie. Eine Technik theoretisch kennen oder eine Technik anwenden können sind zwei unterschiedliche Dinge. Deswegen kommt keine Fahrschule nur mit Theorie aus. Sie ist zwar wichtig, aber nicht ausreichend.

Es gilt also, konzentriert diese Techniken zu vermitteln.

Learning by Doing

Daher legt der neue Architektur-Kickstart den Fokus auf das Machen. Die Teilnehmer:innen bekommen einen theoretischen Input und setzen diesen dann anhand beispielhafter Szenarien direkt um. Wer im Rahmen einer Fortbildung eine Technik bereits eingesetzt hat, wird sie mit einer höheren Wahrscheinlichkeit auch später umsetzen. Und genau darauf kommt es an, wenn man den Erfolg einer Weiterbildung bewerten will. Nur Wissen zu vermitteln, ohne dass es genutzt wird, hilft nicht weiter.

So vermittelt der Kickstart genau die Themen, die für eine erfolgreiche Architektur-Arbeit tatsächlich notwendig sind, und zwar so, dass die Teilnehmer:innen das Wissen tatsächlich im Projekt erfolgreich anwenden werden.

Aus Fehlern lernen

Die Techniken wenden sie in Gruppen an, so dass sie dort voneinander lernen können. Außerdem sehen sie die Ergebnisse der anderen Gruppen und geben Feedback dazu. Sie lernen also nicht nur eine Umsetzung kennen, sondern mehrere. Dadurch sehen alle Teilnehmer:innen verschiedene Probleme und Fehler, die beim Anwenden der Techniken entstehen können. Neu Erlerntes kann man beim ersten Mal praktisch nie fehlerfrei anwenden. Beim Architektur-Kickstart finden die ersten Versuche in einer sicheren Umgebung statt. Fehler haben dort keine echten Konsequenzen. So sind Fehler nichts anderes als Möglichkeiten zu lernen. Das wäre ganz anders, wenn die Teilnehmer:innen die neuen Ansätze zum ersten Mal in echten Projekten ausprobieren würden. Ohne die Praxis vom Kickstart könnten Teilnehmer:innen aus Angst vor Fehlern sogar davor zurückschrecken, die erlernten Techniken in echten Projekten anzuwenden. Dann war die Weiterbildung eigentlich nutzlos. Das verhindert der Architektur-Kickstart.

Aus den verschiedenen, möglicherweise fehlerhaften Lösungen kann man nicht unbedingt erkennen, wie man die Techniken richtig anwendet. Daher zeigt die Trainer:in noch, wie sie das Problem lösen würde. Das geschieht aber nachdem die Teilnehmer:innen ihre eigenen Ansätze ausprobiert haben. Sie können dadurch selber darüber reflektieren, wo sie von der Lösung der Trainer:in abgewichen sind und was die Konsequenzen sind. Gegebenenfalls können die unterschiedlichen Lösungen dann auch noch einmal diskutiert werden.

Zeit: Flexibilität

Statt den Kickstarter in einem Block zu veranstalten, findet jede Woche eine halbtägige Einheit statt. So lässt sich die Teilnahme besser mit dem Tagesgeschäft kombinieren. Diese kurzen Einheiten unterstützen außerdem den Lernerfolg, weil Teilnehmer:innen sich durch die Kürze nicht so lange konzentrieren müssen. Bei einem halben Tag ist das realistisch möglich. Weil der Kickstarter remote stattfindet, sind auch keine kostspieligen Reisen notwendig. So ist die Maßnahme kostengünstig und gleichzeitig effektiv.

Coaching statt im Regen stehen

Nach der Lernphase sollten Teilnehmer:innen das Erlernte im Job anwenden. Dabei treten typischerweise Fragen und Unsicherheiten auf. Schließlich ist die Praxis immer noch etwas anderes als ein Beispiel aus einem Training. Zudem werden Personen, die mit den Ansätzen besser vertraut sind, sicher weitere Optimierungspotenziale auffallen. Daher ist es wichtig, die Teilnehmer:innen bei der ersten Umsetzung des Erlernten auf keinen Fall alleine zu lassen.

Zum Kickstarter können drei Coaching-Termine zusätzlich gebucht werden, bei denen die Teilnehmer:innen zusammen mit der Trainer:in über die Anwendung der Techniken im konkreten Beispiel sprechen. Dadurch werden nicht nur Fehler vermieden, sondern die Teilnehmer:innen gewinnen auch Sicherheit bei der Nutzung der Techniken. Daher werden sie so eher die neuen Techniken auch tatsächlich umsetzen.

Fazit

Mit dem Architektur-Kickstarter lernen Teilnehmer:innen genau die Techniken, die heute in der Praxis die größten Herausforderungen darstellen, und zwar so, dass sie die Techniken auch tatsächlich in der Praxis umsetzen können – und das mit einem übersichtlichen zeitlichen und finanziellen Investment. Und weil es so viel Praxis gibt, macht das ganze auch noch Spaß. Also: Sehen wir uns bei einem der Architektur-Kickstarter?

TAGS