Liebe GPI Blogleserinnen, lieber GPI Blogleser,
in unserer Rubrik “Blick durchs Schlüsselloch” haben wir uns mit Peter Stömmer unterhalten. Peter ist einer der ersten Mitarbeiter der GPI und ist nun schon über 10 Jahre bei uns! Er startete 2010 als Projekt Manager, begleitete seither die Entwicklung und Einführung von Software als Technical Manager und bildet mit seiner Expertise den Fels in der Brandung unserer Support- und Softwareprojekte. Er ist zertifizierter Architekt und Product Owner.
Heute erfahren wir von ihm, was eine erfolgreiche IT-Architektur ausmacht und was diese im Zusammenspiel mit der agilen Entwicklung voraussetzt!
Hallo Peter, du bist zertifizierter Architekt und Product Owner und verbindest damit zwei wichtige Aspekte für erfolgreiche Software-Entwicklung. Kannst du zunächst Bezug darauf nehmen, was ein Architekt im Bereich IT so tut?
Bei Architektur denken die Meisten an Software-Architektur. Darüber hinaus gibt es jedoch noch einige Benennungen und verschiedene Facetten der Architektur. Hierbei gibt es verschiedene Architekten-Rollen: von Software über System-, Solution- und Enterprise-Architekt.
Abgrenzen lassen sich die Rollen und Aufgaben wie folgt: Ein Software-Architekt ist eigentlich ein richtig guter Entwickler und nimmt selbst auch Einfluss auf die Software, die genutzten Frameworks und die Software-Qualität. Der Solution-Architekt ist einfach gesagt für die Systeme, die die Software tragen zuständig, sowie die Schnittstellen zwischen den Systemen. Der Enterprise-Architekt macht das dann, wie der Name schon sagt, auf Unternehmensebene und somit über verschiedene Großsysteme und Plattformen hinweg.
Allgemein ist das Ziel auf Solution- und Enterprise-Ebene eine möglichst tragfähige und offene Architekturlandschaft zu gestalten.
Architektur und Agilität
Für den perfekten Architekturentwurf sollten doch möglichst alle Anforderungen von Anfang an bekannt sein – wie lässt sich das mit einer agilen Entwicklung verbinden? Oder bremsen Architekturentwürfe eine eher agile Entwicklung aus?
Die agile Form der Entwicklung wurde ja unter anderem geschaffen, um das „Wasserfall-Problem“ zu lösen: erst am Ende der Entwicklungszeit wird das fertige Produkt präsentiert, meist mit dem Ergebnis, dass an Kundenwünschen und End-User-Perspektive vorbei gearbeitet wurde…wir alle kennen die Comics dazu.
Agile Entwicklung dahingegen bedeutet, in kurzen Zyklen (Sprints) und mit häufigen Releases ständig einen aktuellen Stand zu zeigen. So ist eine engere Verzahnung zwischen Entwicklung und User und somit eine customer-zentrierte Entwicklung möglich.
Kurzfristigen Änderungen sind für die Architektur allerdings nicht immer einfach oder gar machbar. Oft gibt es hier den Mismatch zwischen klassischer Architektur und der agilen Software-Entwicklung.
Modularer Aufbau und die Nutzung von Cloud Lösungen sind wichtig
Kannst du diesen Mismatch genauer erläutern? Liegen in einer agilen Vorgehensweise nicht auch Vorteile sowohl für die Architektur als auch die Softwareentwicklung?
Ein gutes Bild ist der klassische Architekt. Auch er muss wissen, wie das fertige Gebäude aussehen soll. Braucht es 100m² oder 250m²? Soll es ein, zwei oder drei Obergeschosse geben? Wenn ich auf Erdgeschoss und 120m² plane, kann ich später vermutlich keinen Pool im zweiten Stock einbauen. Zumindest nicht ohne Umbauzeit, einen Statiker und die entsprechenden Kosten. In solchen Fällen wird die Umsetzung auch in der IT-Architektur oft schwierig und es müssen Kompromisse oder kreative Lösungen gefunden werden.
Was hierbei sehr hilft und eine gewisse Flexibilität schafft, ist ein modularer Aufbau mit Microservices und die Nutzung von Cloud Lösungen, da hier Kapazitäten schneller zusätzlich genutzt werden können.
Eine Architektur sollte somit offen und skalierbar gestaltet sein. Die Architektur rein nach dem aufzubauen, was ich aktuell brauche führt meist dazu, dass es später Probleme oder hohe Umbaukosten gibt.
Offene Architektur und dennoch Rahmenbedingungen nicht außer Acht lassen
Und wie entwirft man offene Architekturen, die mit den Anforderungen wachsen können und trotzdem tragfähig bleiben? Gibt es so etwas wie „agile Architektur“?
Wichtig ist der Zeitpunkt, zu dem die Architektur festgelegt werden soll. Hier bewährt sich das in den letzten Jahren aufkommende Vorgehen, welches einem klassischen Vorgehen widerstrebt: Architektur Entscheidungen möglichst spät im Prozess zu treffen. Eigentlich würde man denken, das geht in die Hose – man reagiert, statt dass man agiert.
Aber so ist es nicht! Es bewährt sich, erst dann wenn ich meine Informationen habe, die Entscheidungen zu treffen. Vor allem Entscheidungen auf Basis von gefährlichem Halbwissen sind schädlich. Sobald absehbar ist, welche software-technischen Rahmenbedingungen u.a. bzgl. Qualität, Flexibilität und Skalierbarkeit der Systeme notwendig sind, wenn bekannt ist, welches die Performance- und Antwortzeiten sein sollen, dann kann eine erfolgreiche Entscheidung über tragfähige Architektur geschehen. Somit setzt die Software den Rahmen, und nicht die Architektur.
Früher gab es eine Anforderungsanalyse, auf deren Basis entstand die Architektur und dann begann die Implementierung der Software. Davon ist man heute weg. Architektur wird etwas Dynamisches, auch hier sollte der End-User im Fokus stehen.
Ein bekannter Ratschlag hierzu ist, auf hoher Flugebene einen gewissen Rahmen zu setzen. Sprich: Vorgaben bspw. bezüglich Schnittstellen oder Datenbanken zu machen, die eingehalten werden müssen. Die genaue Ausgestaltung wird dem Projekt überlassen und schafft so die notwendigen Freiräume.
Teilweise wird auch erfolgreich mit Instanzen gearbeitet, an welche gewissen Änderungen gemeldet werden müssen. Diese werden dann geprüft und freigegeben. So kann auch übergreifend ein einheitliches, der Effizienz dienendes Modell geschaffen werden.
Austausch und Erfahrung sind wichtig!
Welche weiteren Ratschläge hast du, um zu einer dynamischen und tragfähigen Architektur zu kommen?
Es ist und bleibt ein schmaler Grat und hat viel mit Erfahrung zu tun. Es bringt nichts, ein System zu entwerfen, das augenblicklich passt (aber oft ist das aus Budgetgründen der Fall). Genauso wenig bringt es etwas von Anfang an mit dem Dampfhammer zuzuschlagen und ein Over-sized-System aufzubauen. Die Mitte zu treffen braucht Erfahrung und Austausch mit Stakeholdern.
Die gewünschte Flexibilität kann durch Möglichkeiten wie Plattform-as-a-Service, quasi buchbarer Rechenleistung bei einem Plattformanbieter per Cloud, oder Infrastructure-as-a-code, also vom Anbieter automatisch konfigurierte Infrastruktur, geschaffen werden.
Weiterhin sollte es eine Instanz geben, die den Überblick bewahrt und bei unabhängigen und übergreifende Fragestellungen Entscheidungen herbeiführen kann. Im kleineren Rahmen kann dies der Product Owner oder ähnliches sein, bei mehreren Teams und skalierten Modellen empfiehlt sich ein Architekt.
Die Rolle Architekt gibt es in einem Scrum-Team zum Beispiel gar nicht. Hier liegt die Verantwortung zumeist bei den Entwicklern und im Team. Das läuft generell auch gut, sobald jedoch skaliert wird, läuft das Gemeinwohl um die Architektur gerne auseinander. Hier kommt dann der Software- oder der System-Architekt ins Spiel.
Wovon ich abrate, ist, einen Prototyp zu übernehmen. Nicht falsch verstehen! Ich bin Fan davon Prototypen zu bauen und diese zum Verproben der Anforderungen und zum Experimentieren zu nutzen. Aber meistens gilt danach aus meiner Sicht: aus dem Prototyp lernen, dann aber sorgfältig wegschließen und neu, sauber aufsetzen! Wir wissen ja, ein Haus steht auch nur so fest wie sein Untergrund und bleibt nur bei stabiler Basis lange schön und ohne Risse 😉
Danke dir Peter, das war wirklich spannend und aufschlussreich!
