„Willkommen bei The Hüb – einem Ort, an dem unsere Fachleute offen ihre Meinungen und Ideen sowie ihr Wissen zur Branche, zu deren Zukunft und zu wichtigen Trends weitergeben, die Du kennen solltest.“

In der heutigen 18. Folge der Serie sprechen wir mit Branko Tripković, Lead Software Engineer Consultant.

Die Software Architektur soll Softwarelösungen schneller und mit höherer Qualität hervorbringen, und das heißt, die Komplexität in den Griff zu bekommen. Komplexität kommt von allen Seiten, aber am relevantesten ist die wirtschaftliche Komplexität, weil wir Business-Probleme lösen, und allgemeine organisatorische Entscheidungen treffen, die sich nicht immer mit den rein technischen Projektanforderungen decken. Andere Aspekte der Komplexität ergeben sich aus der Technologie selbst, die meist sehr viel umfangreicher und leistungsfähiger ist als die Teilmenge davon, die Du für ein bestimmtes Projekt brauchst. Du musst entscheiden, welche Technologie eingesetzt werden soll und in welchem Umfang.

Als Architekt:in hast Du die Aufgabe, im Projekt bei der Bewältigung dieser Komplexität zu helfen. Die eigentliche Herausforderung dabei ist, dass nichts Bestand hat – es gibt immer Veränderungen. Der Umgang mit diesen Veränderungen und die Vorbereitung des Projekts auf diese Veränderungen, ohne dass dabei zu hohe Kosten entstehen – darum geht es im Wesentlichen.

Business und Technologie unter einen Hut zu bringen ist ein Balanceakt, der nie ganz beherrschbar ist. Aber zuallererst geht es immer um Wirtschaftlichkeit. Du versuchst, Business-Aufgaben zu lösen, und dafür brauchst Du die Technologie. Also musst Du über umfangreiches technologisches Wissen verfügen, und wenn es Dir irgendwo an Kenntnissen oder Expertise fehlt, musst Du in der Lage sein zu delegieren oder Leute zu finden, die Dir helfen, in die richtige Richtung zu gehen.

Dass zu Projektbeginn der Kenntnisstand immer am geringsten ist, ist natürlich eine Binsenweisheit. Aber das lässt sich nun einmal nicht ändern. Im Laufe der Arbeit am Projekt und während der Entwicklung findest Du aber neue technologische und vor allem auch geschäftliche Perspektiven. Während die Teams entwickeln, erkennen auch die Geschäftsleute immer mehr Optionen und treffen bessere Entscheidungen. Um es mit Steve Jobs zu sagen: „Die Kunden wissen nicht, was sie wollen, bis wir es ihnen zeigen.“ Das heißt aber nicht, dass die Kunden „dumm“ sind. Uns allen fallen Entscheidungen leichter, wenn wir die Dinge erst einmal klar vor Augen haben. Im Vertrieb und im Marketing geht es deshalb meistens darum, Dir das Produkt zu zeigen, damit Du Deine Kaufentscheidung triffst. In der Projektentwicklung ist das im Grunde derselbe. In diesem Sinne ist Architektur etwas Lebendiges und kein statischer Zustand.

Was die Werkzeuge angeht, finde ich Containerumgebungen enorm wertvoll, und endlich scheinen sie sich durchzusetzen. Container lösen gleich mehrere Probleme. Vor allem hast Du die Möglichkeit, mehrere Versionen derselben Software in verschiedenen Containern zu installieren und auszuführen oder zu testen. Das ist gerade in Multi-Tier-Umgebungen nützlich, in denen verschiedene Dienste unter Umständen verschiedene Versionen derselben Software erfordern. Das zu organisieren war immer eine ziemliche Herausforderung. Dasselbe gilt für Datenbanken und Versionen.

Ein weiterer wichtiger Aspekt ist, dass man mit Containern sehr nah an einer Produktionsumgebung arbeiten kann. In der Vergangenheit kam es vor, dass Implementierungen lokal funktionierten, aber bei der Bereitstellung in einer Test- oder Produktionsumgebung versagten. Mithilfe von Containern können wir eine Umgebung betreiben, die mit der Produktionsumgebung nahezu identisch ist, und derartigen Problemen vorbeugen.

Manche halten Paarprogrammierung noch immer für Ressourcenverschwendung. Dem würde ich aber ganz entschieden widersprechen. Methoden wie Git-Flow und Pull Requests sind im Grunde eine Form des Vier-Augen-Prinzips. Aber bei der Paarprogrammierung erfolgt das Feedback umgehend, und die Arbeit profitiert von den Sichtweisen zweier Personen. Die Lösung, die dabei herauskommt, ist oft besser, als wenn man auf einen herkömmlichen Code Review warten muss. Leider geht das nicht immer, aber es wird noch immer zu selten gemacht, vor allem, wenn es die Möglichkeit gibt, das erfahrenere Teammitglieder mit Neulingen zusammenarbeiten. Dabei sollte der Nachwuchs für die Programmierung zuständig sein, weil dann ein Wissens- und Erfahrungstransfer von den älteren zu den jüngeren Teammitgliedern stattfindet.

Unsere Kund:innen nutzen immer häufiger die Cloud. Fast alle wechseln in die Cloud, und manche betreiben sogar ihre eigenen Clouds. Das ist also ein wichtiges Thema für alle in diesem Bereich, nicht nur für professionelle Engineers. Die Cloud-Technologie wird in Zukunft ganz sicher eine wichtige Rolle spielen. Sie vereinfacht auch die Abläufe. In der Vergangenheit gab es separate Entwicklungsphasen, von der Geschäftsanalyse über die Programmierung bis hin zum Testen und so weiter. Die Cloud rationalisiert den gesamten Prozess und ermöglicht eine bessere Integration und Zusammenarbeit während des gesamten Entwicklungszyklus. Früher war der Entwicklungsprozess fragmentiert, mit vielen Übergaben zwischen verschiedenen Funktionen. Dabei kam es auch zu Ineffizienzen und Abstimmungsfehlern. Aber mit DevOps übernehmen die Entwicklungsteams jetzt mehr Verantwortung für die Bereitstellung von Lösungen. Das beschleunigt und verbessert die Sache. Das sofortige Feedback ist gut, und es macht zufrieden, wenn man das Ergebnis der eigenen Arbeit in der Praxis funktionieren sieht. Das ist ein wichtiger und sicherlich beständiger Trend.

Engineers müssen in der Lage sein, Businessanalysen zu erstellen, zu programmieren, zu testen und zu implementieren, d. h. eine Person erfüllt mehrere Funktionen.

Menschen sind bereit zu geben, wenn sie selbst etwas bekommen. Wenn sie keine Möglichkeit haben, sich einzubringen, schöpfen sie ihr Potenzial niemals voll aus. Wenn wir Leute einstellen, geht es um ihren Verstand, nicht nur um ihre Programmierkenntnisse. Programmierkenntnisse kann man sich weiter aneignen; Problemlösungsfähigkeiten sind das, was wir eigentlich brauchen. Architekt:innen haben die wichtige Aufgabe, zu Projektbeginn ihre Lösungen zu präsentieren, denn Projekte brauchen einen Ausgangspunkt. Dabei müssen sie die verschiedensten Stakeholder überzeugen, vom Unternehmen bis hin zu den Teams, die die Lösungen umsetzen sollen. Sie müssen dafür sorgen, dass die Teammitglieder verstehen, warum bestimmte Entscheidungen getroffen wurden und wie das Gesamtbild für das Unternehmen aussieht. Es ist wichtig, dass die Teams hinter den Entscheidungen stehen und das Gefühl haben, dass ihre Rückmeldungen und ihre Verbesserungsvorschläge jederzeit willkommen sind. Diese Feedback-Schleife ist sehr wichtig, damit die Teams keine Entscheidungen umgehen und das Projekt ausbremsen. Die Architektur soll letztlich die Lösungen schneller verfügbar machen: Die Feedback-Schleife ist hierfür essenziell. Architektur ist das sensible Gleichgewicht von Leadership, Beteiligung, Entscheidungsfindung und Anpassungsfähigkeit an veränderte Situationen.