Oliver Zeigermann und Kim Nena Duggen
19.05.2021
Eine Landkarte für die Softwareentwicklung
Software-Entwicklung ist ein komplexes Unterfangen mit vielen Stakeholdern, Prozessen und Rollen. Das Modell der Software-Raute bietet eine Landkarte der für eine erfolgreiche Entwicklung notwendigen Aspekte und deren Zusammenhänge. Damit kann sie in schwierigen und sogar dysfunktionalen Situation zur Aufklärung beitragen. Dieser Beitrag führt die Raute ein und erläutert sie anhand von Beispielen.
Die Software-Raute zerteilt ein Software-Projekt in die vier Aspekte Vorhaben, Schärfung, Lösungsansätze und Implementierung. Alle vier Aspekte sind für ein erfolgreiches Projekt wichtig und brauchen daher Beachtung, aber nicht alles bedingt sich gegenseitig. Es gibt dabei nicht notwendigerweise eine Reihenfolge in der man ein Projekt startet, sondern je nachdem wo die Entwicklung beginnt, ergeben sich unterschiedliche Stile, die alle für sich einen Platz und eine Berechtigung haben.
Meist geht man davon aus, dass Projekte so beginnen: Man überlegt sich, was man machen will oder hat eine Problemstellung, die eine Lösung erfordert. Es gibt eine offensichtliche Beziehung zur Umsetzung, die das Vorhagen widerspiegeln sollte und eine Schärfung durch die Rahmenbedingungen und Anforderungen. Bei der Schärfung ergeben sich die ersten Schwierigkeiten, weil eine Idee aus dem wolkigen in eine klarere Vision umgesetzt werden muss. Dabei kommt es nicht selten zu Ernüchterung, da Machbarkeit die Idee einschränken und Klärung der Details aus einer ganz tollen Idee eher Arbeit machen kann.
Die passende Rollen sind hier das Management und/oder eine Fachabteilung. Diese sorgen für die Ausgabe eines Ziels oder einer Mission und stecken den Rahmen des Vorhabens ab. Außerdem sind sie vielfach Auftraggeber des Vorhabens.
Eine Idee braucht eine Schärfung in Form von konkreten Anforderungen und des Herausarbeitens von Rahmenbedingungen und dem Kontext im dem die Idee umgesetzt werden soll.
Diese Arbeit wird typischerweise von Personen mit der Rolle des Product Owners oder Requirements Engineers durchgeführt. Häufig erstellen diese ein Backlog oder eine Sammlung von Anforderungen und eine Reihe von Meilensteinen oder Teil-Zielen. Darüber hinaus arbeiten sie Rahmenbedingungen wie Budget, Umsetzungsvorgaben, etc. heraus.
Die Summe der wichtigen Lösungsansätze macht die Architektur eines Software-Projekts aus. Dabei sind diejenigen Ansätze wichtig, die
In diesem Aspekt kommen die Rollen des Architekten und des Scrum Masters o.ä. zum tragen. Diese legen zum einen die Architektur und zum anderen das Vorgehensmodell fest, das zu den geschärften Anforderungen passen muss. Nicht jedes Projekt eignet sich für Scrum oder kann in sinnvollen Inkrementen erzeugt werden. Die Architektur muss zu dem passen, was umgesetzt wird. Auch hier ist eine Kommunikation in beide Richtungen notwendig. Im schlimmsten Fall verkommt die Architektur zu einem sinnleeren Hemmschuh und die Entwicklung läuft daher komplett an ihr vorbei, um überhaupt etwas Brauchbares oder Machbares zu produzieren. Im besten Fall gibt die Architektur jedoch einen sinnvollen Rahmen und passt sich dem an, was in der Entwicklung überhaupt möglich ist.
Ein Software-Projekt ohne eine Umsetzung in der Implementierung der Software, ist kein Software-Projekt. Diese ist besonders wichtig, weil die funktionierende Software das wichtigste Artefakt ist und dazu die Schnittstelle zum Vorhaben bildet. Gemäß der Apple-Philosophie wird aber die User-Experience für den technisch Uninteressierten zum Produkt. Als Fahrer eines tollen Autos interessiert nur den technisch Interessierten, wie der Turbolader funktioniert und ob es überhaupt einen gibt. Alle anderen freuen sich, wenn sie die Existenz des Laders möglichst gar nicht bemerken. Hier erleben wir oft einen Bruch zwischen dem, was die unterschiedlichen Rollen toll finden - dieser drückt sich in gegenseitiger Frustration aus. Die Entwickler sind traurig, dass am Ende keiner die technische Meisterleistung schätz und die geschäftlichen Stakeholder sind enttäuscht, dass das bei Apple alles irgendwie flüssiger läuft und fragen sich, wie dies in der eigenen Entwicklung möglich wäre.
Insbesondere in großen Unternehmen, deren Kerngeschäft nicht Software ist, kommt es also häufig zu einer Entkopplung von den Lösungsansätzen zum ursprünglichen Vorhaben. Der Abstand von den Leuten, die Ideen haben und denen, die sie umsetzen, ist hier vielfach so groß, dass man nicht einmal von einander weiß. Das ist sehr unvorteilhaft, da die Umsetzung im Idealfall die ursprüngliche Idee wiederspiegelt, aber auch durch Schaffung einer Realität diese im objektiven einschränkt. Gibt es hier keine regelmäßige Kommunikation und ein Ausbleiben von interaktiven Arbeitsprozessen sind Frustrationen vorprogrammiert.
Ebenso oft passiert es, dass ausgewiesene Architekten Lösungsansätze entwickeln, die zu aufwändigen oder gar nicht erfolgreichen Umsetzungen führen. Wenn auch hier die Rückkopplung fehlt oder in einer Art Wasserfall entwickelt wird, ist ein Erfolg nicht wahrscheinlich.
Im Idealfall gibt die Architektur also der Entwicklung einen sinnvollen Rahmen und Orientierung. Ohne eine solche klare Architektur ist es bei der Umsetzung eher Glückssache, ob die Lösungsansätze richtig gewählt sind und die Implementierung die Vision dauerhaft widerspiegeln kann. Die Vision selbst ist dabei das Korrektiv und die Metrik einer erfolgreichen Umsetzung und eines erfolgreichen Projektes. Passt die Umsetzung nicht zur Vision, ist dies eben nicht gelungen. Wiederkehrend hört man dann von Entwicklern “das war ja gar nicht gefordert” und vielleicht stimmt es auch, dass die Anforderungen und vorgegebenen Lösungsansätze nicht zur Vision passen, aber nichts destotrotz ist das Projekt nicht gelungen, egal an welcher Ecke Dinge schief gegangen sind.
Die Umsetzung erledigen Software-Entwickler und das erzeugte Artefakt ist Software. Neben der gewünschten Software gibt es aber weitere Ergebnisse, die wir als Kollateralnutzen und Kollateralschäden bezeichnen. Im positiven Bereich können Dinge entstanden sein, die über das gewünschte hinaus gehen und zu eigentlichen Innovationen führen können. Häufig ist das Umgesetzte aber nicht das Gewünschte, da über viele Aspekte hinweg stille Post gespielt wurde. Im schlimmsten Fall stellt sich bei der Umsetzung sogar eine Unmöglichkeit des Vorhabens heraus.
Laut unseres Modells funktioniert Kommunikation nur zwischen direkt benachbarten Aspekten und in einer typischen Entwicklung nur im Uhrzeigersinn. Dabei kann ein Projekt aber an jedem Aspekt und nicht nur bei der Formulierung des Vorhabens beginnen. In jedem größeren Projekt ergeben sich wiederkehrende Zyklen, die gewollt und sinnvoll sind und ein modernes Projekt von einem Wasserfallprojekt unterscheiden.
Nehmen wir an, die Architektur-Abteilung erwägt die Einführung von Machine Learning als einen sinnvollen Lösungsansatz. Da hier aber nicht in der Sprache einer Fachabteilung gesprochen wird, ist eine direkte Kommunikation schwer möglich und misslingt oft. Der Schritt über eine Implementierung („Kann man schon was sehen?"), ist in diesem Fall sinnvoll, und man kann zeigen, was dieser Ansatz bewirkt. Daraus kann sich ein Vorhaben mit einem geschäftlicher Nutzen ableiten lassen und durch die Schärfung gehen.
Ein Review einer Lösung geht oft gegen den Uhrzeigersinn vor: eine Implementierung wird betrachtet und bestehende Lösungansätze abgeglichen. Danach wird geklärt, ob diese auch zu den ursprünglichen Anforderungen und der Vision passen.
Bei embarc befassen wir uns mit einer ganzheitlichen Idee von Software-Entwicklung und decken daher alle Aspekte der Raute durch unsere Expertise ab. Wir tauschen uns regelmäßig zu diesen Themen aus und sehen keine der Aspekte getrennt.
In unserer Praxis erleben wir regelmäßig Beispiele, in denen Teile der Raute ausgelassen oder Artefakte der verschiedenen Bereiche von „falschen“ Rollen vorgegeben werden. Und hier interessiert uns Ihre Meinung: welche Anti-Beispiele kennen Sie und wie ließen sich diese mit der Raute herleiten?
Haben Sie Fragen oder Anregungen oder sogar ein Anti-Beispiel für uns, dann nehmen Sie gern Kontakt auf. Per Email, oder über unser Kontakt Formular.
Mehr Anregungen können Sie am 24. Juni 2021 bei unserem Architektur-Midsommar 2021 bekommen. Save the date…