Kai-Uwe Herrmann
  Senior Software Architect and Technical Lead

Es bedarf lediglich des richtigen Managements, des richtigen Architekten, eines guten Testmanagers, einer Schar hervorragender Entwickler, Tester, Configuration-Manager, Rollout-Manager, Experten für Datenbanken, User Interfaces und solcher, die sich mit Applikationsservern auskennen. All diese Menschen müssen nichts weiter tun, als ein Team zu bilden, gut zu kommunizieren, motiviert Ihrer Aufgabe nach zu gehen, präzise zu analysieren, konzentriert an ihren Designs zu arbeiten, grosse Mengen an Code zu produzieren und tausende von Testfällen zu berücksichtigen. - Nicht einfach? - Stimmt. Und doch - Gute Software zu machen ist möglich.

Bei all den Projekten, die ich im Laufe der Jahre begleiten durfte, war es mein primäres Ziel, den Auftraggebern die Software zu liefern, die sie am Ende wollten. Natürlich, denken Sie jetzt: "Was denn sonst!?" - und selbstverständlich haben Sie Recht. Nur ist es eben oft nicht der Fall, dass Auftraggeber von Anfang an wissen, was sie am Ende wollen, noch herrscht Einigkeit zwischen allen Interessensgruppen, was gute Software ist.

Architektur

Als Architekt verstehe ich meine Aufgabe darin, genau das herauszufinden: Die Anforderungen der Interessensgruppen an die Qualität des Systems zu verstehen, sowie deren Gewichtung. Und dann gilt es, eine Lösung zu finden, die diesen Anforderungen genügt. Es sind also die wichtigen Anforderungen zu ermitteln, die wichtigen Entscheidungen zu treffen und die Grobarchitektur zu definiern. Dabei gilt es die Struktur des oder der Systeme zu definieren, Interfaces klar zu benennen, Objekt-Modelle zu gestalten, Funktionale Komponenten und das Grob-Design des Systems festzulegen, Deployment-Szenarien auszuloten, sowie die Entwicklungsumgebung zu berücksichtigen. Dabei dürfen die Testbarkeit und auch der spätere Betrieb nicht aus den Augen verloren gehen: Testautomatisierung und Mechanismen zum Monitoring und zur Analyse von Produktions-Vorfällen  müssen mit brücksichtigt werden.

Agile Entwicklung

Ich habe agile Evangelisten kennen gelernt,  die jetzt die Nase rümpfen und behaupten, man müsse nur in kurzen Sprints die jeweils am höchsten priorisierten Anforderungen von einem Team bauen lassen und schon entstünde die richtige Software - zugegeben: das ist etwas vereinfacht dargestellt :-). Dennoch - dieser Meinung bin ich nicht! Ich möchte dabei nicht falsch verstanden werden - ich bin kein Gegner agiler Software-Entwicklung. Meiner Erfahrung nach muss jedoch einer wie auch immer gearteten Bau-Phase - im einen oder anderen Vorgehensmodell - eine Phase der Projektierung vorausgehen. In dieser frühen Phase müssen Features oder Epics, also High-Level-Requirements und High-Level-Architektur definiert sowie die grobe Projektplanung vorgenommen werden. Anderenfalls irrlichtern Projekte im Dschungel der Möglichkeiten endlos und mit hohen Kosten verbunden umher. Ob Gebäude, Maschinen oder Software - ohne sein Ziel zu kennen, kann niemand dort ankommen. 

Jemand der ein Passivhaus haben möchte, der wird Schwierigkeiten haben, diese Anforderung umgesetzt zu bekommen, wenn das Dach bereits aufs Haus gesetzt wurde, denn passiv bauen fängt bei der Grundplatte an. Und analog ist es schwierig, wenn man ein grosses Software-System baut und nach 2 Jahren Entwicklung  auf die Idee kommt, dass die Geschäftslogik doch eigentlich für andere Systeme wiederverwendbar und daher mit Service-Schnittstellen ausgestattet sein sollte. - Hat man die Geschäftslogik aber nun nicht konsequent in wohldefinierten Komponenten gebaut, dann stellt man oft fest, dass selbst mit enormen Refactoring-Aufwänden - dieser Zusatand kaum mehr erreichbar ist.

Mein bevorzugter Weg

SAFe (Scaled Agile Framework) bietet meiner Meinung nach eine wunderbare Möglichkeit die Komplexität grosser Software-Systeme und -Organisationen in den Griff zu bekommen. Agiles Vorgehen bei gleichzeitigem gut organisierten Miteinander mehrerer Teams. Begleitet durch Product-Owner, Release-Train-Engineer und Architects Office. Dieser Weg adressiert die Schwächen puren Scrums in umfangreicheren Kontexten und vermeidet dennoch Überorganisation und unflexible Entwicklungen.

Das Wichtigste

Wie bei fast allem ist aber das Miteinander entscheidend. Kein Vorgehensmodell, kein Plan, keine Architektur und keine Requirements-Dokumentation können es ersetzen, dass Menschen miteinander dem definierten Ziel entgegen streben, miteinander die Änderungen während des Projekts akzeptieren und miteinander daran arbeiten, das beste zu bauen, das ihnen möglich ist. Es gilt, die vielen unterschiedlichen Sichten aller Interessensgruppen zu verstehen und zu berücksichtigen, ihnen offen zu begegnen. Es gilt aber auch - und das ist essentiell - Entscheidungen zu treffen und einmal gemeinsam getroffene Entscheidungen nicht wieder und wieder und ohne wichtigen Grund  zu überdenken oder in Frage zu stellen. So richtig es ist die vielen Aspekte zu diskutieren und in den Entscheidungsprozess einzubeziehen, so wichtig ist es eben auch, danach zu einer getroffenen Entscheidung zu stehen. Ein stabiles, nachhaltiges Softwaresystem basiert auf der konsequenten Umsetzung von grundlegenden Konzepten - ohne stabile Entscheidungen kann es das nicht geben. Die konzeptionellen Entscheidungen geben uns den Rahmen und können dann flexibel und mit viel Freiheit dazwischen mit Leben gefüllt werden.

Sollte ich also zusammenfassen, was für mich das Wichtigste beim Bau einer Software ist, dann würde ich sagen: Bringt die richtigen Menschen mit viel Know-How und mit Teamgeist zusammen. Lasst sie Lösungen und Konzepte diskutieren und beschliessen. Wenn sich später beim Bauen herausstellt, dass es ein noch besseres Konzept gibt - dann müssen alle akzeptieren, dass sie nun am zweit besten Konzept arbeiten. Nur wenn sich herausstellt, dass ein gemeinsam beschlossenes Konzept nicht funktioniert, dann lasst sie wieder miteinander ein neues beschliessen und dann ebenso konsequent an der Eliminierung des alten sowie der Umsetzung des neuen Konzeptes arbeiten - das ist teuer, noch teuerer ist es jedoch in der Regel, mehrere Konzepte zu haben.

Kai-Uwe Herrmann im November 2015.

... man findet mich auf XING oder LinkedIn