Agile Architektur ist änderbar!

Wer iterativ entwickeln will, hat ein grundsätzliches Problem: Er weiß nicht, ob er in der Zukunft eine Anforderung erhält, die es notwendig machen wird, Grundannahmen umzuwerfen. Das kann im extremsten Fall dazu führen, dass große Teile des Produkts nachträglich verändert werden müssen. Dieses Wissen treibt viele Softwareentwickler zu der Überlegung: Man müsste ein Framework entwickeln, das möglichst robust ist, sodass man möglichst flexibel auf zukünftige Wünsche eingehen kann.
Dieser Ansatz wird immer wieder versucht, immer wieder entstehen neue Frameworks, immer wieder wird zu Anfang eines Projekts in der Produktentwicklung versucht vorherzusehen, was möglicherweise in der Zukunft auf uns zukommen könnte.
Gehen wir das Thema doch mal von einem anderen Standpunkt aus an. Stellen wir uns einfach mal vor, wir müssten heute eine Applikation anpassen. Eine Applikation, die wir nicht selbst geschrieben haben, die wir überhaupt erst zum ersten Mal sehen. Wir wissen nur, dass wir etwas Grundsätzliches an der Applikation ändern müssen, da der Kunde ein vollkommen neue Anforderung hat. Was würde uns in dieser Situation als Entwickler helfen, die Veränderungen an der Software schnell und sicher, zufriedenstellend für alle,  durchzuführen?

Reise zum Mittelpunkt des Sinns

Nun – wir müssten die Applikation, mit der wir es zu tun haben, verstehen. Richtig? Wir steigen also in den Keller unserer Applikation, in die Eingeweide und versuchen zu ergründen, was diese Software tut, wie die Dinge zusammenhängen. Grob: Wir wollen die Frage beantworten, wie dieser “Organismus” Applikation im Detail funktioniert.
Vergleichbar ist das mit der Arbeit von Archäologen. Wenn diese zu ergründen suchen, wie vergangene Kulturen gelebt und gearbeitet haben, können sie die Menschen von damals nicht direkt fragen. Wir wollen genauso wie die Archäologen herausfinden, was die Softwareentwickler vor uns getan haben.
Uns als Software-Archäologen würde es

  1. helfen, wenn das, was wir vorfinden, möglichst selbsterklärend ist. Es würde uns
  2. auch helfen, wenn wir Hinweise finden würden, die uns erklären, wieso die Erbauer dieser Ruinen die Dinge gerade so gestaltet haben, wie sie sie gestaltet haben. Wir bräuchte also ihre damaligen Entscheidungen nicht zu interpretieren, wir bräuchten keine Hypothesen, denn es stünde ja da.
  3. Drittens wäre es toll, wenn wir eine Referenz hätten. Wenn wir Vergleiche mit ähnlichen Städten oder Ruinen hätten, die wir schon verstanden haben.

Bei dem Vortrag, den ich vor einigen Tagen vor 80 Softwarearchitekten gehalten habe, fragte ich diese Gruppe, wie ein solcher Zustand in unseren Applikationen zu erreichen sei. Sie gaben mir eine Liste von 5 Punkten:

  • Einfachheit: Nur das sollte implementiert sein, was die Software wirklich braucht. Je weniger Code, desto besser. Lieber weniger Implementieren und die nächste Funktionalität in ein anderes Modul stecken.
  • Modularität: Das führt natürlich sofort dazu, dass die Applikation möglichst modular aufgebaut sein sollte. Die Schnittstellen zwischen den Modulen sollten ebenfalls klar sein.
  • Lesbarkeit: Der Code sollte so strukturiert und geschrieben sein, dass er leicht verständlich und lesbar ist.
  • Inline-Dokumentation der Entscheidungen: Es sollte im Code erklärt sein, warum gewisse  Entscheidungen so getroffen wurden, wie sie getroffen wurden. Der Code selbst ist ja die Dokumentation dessen, was der Code macht. Nur wieso man die Dinge so angegangen ist, wie sie vorliegen, wäre wichtig zu wissen.
  • Testbarkeit: Der Code sollte eine hohe Testabdeckung haben und der Testcode selbst ist ja auch eine Form der Dokumentation.

Ich stelle mir vor, ich wäre Software-Archäologe und würde diese Situation in der mir anvertrauten Applikation vorfinden. Das wäre doch toll. Ich hätte die Chance sehr schnell zu verstehen, um was es geht. Die Zusammenhänge innerhalb der Software wären leichter erkennbar oder durch Wegweiser ausgewiesen. Ich könnte mich in Baby-Steps durch die Applikation hindurch bewegen. Und wenn ich etwas falsch mache, würde das sofort auffallen, weil ich den Testcode habe.
So und nun schauen wir nicht mehr als Software-Archäologe auf die Situation, sondern von meiner heutigen Situation in die Zukunft. Ich selbst bin es, der möglicherweise die Applikation in der Zukunft verändern muss. Also wieso mache ich es mir nicht selbst einfach in der Zukunft etwas zu ändern. Ja, ich muss dafür möglicherweise heute etwas sorgfältiger und klarer und deutlicher arbeiten, aber das macht sich doch in der Zukunft mehr als bezahlt.
Agile Architektur bedeutet nicht, die besten robustesten Patterns zu benutzen oder alles vorherzusehen.  Ihr Wesen liegt darin, dass man die Applikation so leicht und schnell wie möglich ändern kann.

Geschrieben von

bgloger-redakteur bgloger-redakteur

TEILE DIESEN BEITRAG

7 Antworten zu “Agile Architektur ist änderbar!”

  1. Ralf Bürger sagt:

    Sorry Boris, aber das ist genau die Erkenntnis, die in den 90ern den Begriff der Architektur in der Softwareentwicklung eingeführt hat, und das hat noch nichts mit Agilität, sondern mit gutem Stil und Erfahrung zu tun. Man sollte nicht versuchen, die Architektur im Code zu beschreiben, denn die Architektur zerlegt das Problem in Komponenten und definiert dessen Zusammenspiel – und dann erst wird der Code erstellt. Für die Nachvollziehbarkeit der Entstehung gibt es Tools, die den Code mit der Architektur verbinden können. Die Architektur zu ändern, heißt Komponenten umzugestalten und/oder das Zusammenspiel zu verändern – und dann die Software selbst daran anzupassen. Wenn du keine Doku und keine Architektur vorliegen hast, wirst du aus dem Code auch höchstwahrscheinlich keine brauchbare Architektur herauslesen können, denn das Verständnis ist entweder da und man macht es, oder eben nicht. Wenn du die eigentliche Architektur flexibler und den Umgang damit agiler gestalten willst, landest du eher bei serviceorientierten Architekturen (SOA) oder in Zukunft vielleicht bei Agenten; aber nicht beim richtigen Umgang mit dem Code! Da haben meiner Meinung nach aber gleich 80 Softwarearchitekten auf einmal gepennt!
    lg Ralf Bürger

    • Boris Gloger sagt:

      Hi Ralf,
      mir geht es nicht darum zu schreiben, alles was man braucht sei der Code. Das steht da oben auch nicht. Aber denkst du wirklich, es braucht den Bauplan um die Architektur eines Gebäudes zu verstehen, wenn das Gebäude schon steht? 
      Sicher sind Analogien immer nur eingeschränkt zu verwenden und sie treffen meist nur den Kern der Sache, nicht aber jedes Einzelteil. Aber darum geht es eben bei Analogien. Sie sollen das Prinzip verstehen. 
      Ich denke auch nicht, dass die Architekten dort “gepennt” haben. Sie haben einer Argumentationslinie folgen können, die ich aufgestellt habe. 
      Mich würde interessieren, ob du die 5 Punkte nachvollziehen kannst. Wenn das so ist würde es mich natürlich freuen zu erfahren, was noch fehlt, was noch verbessert werden muss, wo noch ein Aspekt dabei  helfen kann, agile Architektur zu verstehen. 
      Denn ehrlich, ich weiss nicht was agile Architektur in Wahrheit ist. Wie kann man agile “architekten”? Was ist ist eine Architektur, die es erlaubt “schnell und einfach” die Richtung zu wechseln? Eine Architektur, die im Fluss” ist? Wie erzeugt man eine “fließende” Archtektur? Was muss der Entwickler beachten, damit das geht? 
      Die traditionelle Idee der service-orientieren Architektur, der Modularisierung, der Komponenten-Bauweise ist doch nicht verkehrt, aber sich auf sie zu berufen, greift doch offensichtlich zu kurz. Wäre es nicht so, hätten die Architekten, die wir treffen, doch die Werkzeuge in der Tasche, um auf die Anforderungen von agilen Software Entwicklungsteam reagieren zu  können.
      Es kann nicht an den Leuten liegen, die wir treffen, bitte nicht falsch verstehen, sie sind alle gut ausgebildet und erfahren. Die vorhandenen überkommenen Tools, die Ideen, die traditionellen Antworten greifen nicht, denn wir erleben hilflose Teams, hilflose Architekten, die nicht locker sagen: Ah, na klar, wir machen das und das, dann dies und schon können wir in die richtige Richtung arbeiten. Wir erleben Diskussionen, Unsicherheit, und die Suche nach dem neuen Weg. Das Thema agile Architektur (und ehrlich, ich finde dass es den Begriff “agile Architektur” gar nicht geben kann, obwohl viele davon sprechen, brisant und für alle ein echtes und wichtiges Thema, dass von Software Engineers weltweit endlich einmal prinzipiell gelöst gehört.
      Ich selbst hätte Ideen dazu, wie man agil “architektet”. Was man dazu mindestens braucht, habe ich oben beschrieben, was noch fehlt sind klare Rahmenbedingungen für Entwickler und vieles mehr, was ich möglicherweise einmal demnächst hier aufschreiben werde. Derzeit sind das noch Überlegungen.
      Ein schönes Wochenende
      Boris

      • Ralf Bürger sagt:

        Hallo Boris,
        zunächst zum Einstieg meine Antwort auf deine Einstiegsfrage:
        Wenn das Gebäude von einem Architekten entworfen wurde, auf Basis dieses Entwurfs ein Bauingenieur einen Bauplan erstellt hat, und das Gebäude dann nach diesem Plan gebaut wurde, nein. Dann wirst du auch aus dem fertigen Gebäude rückwärts einen ähnlichen Bauplan erstellen können (allerdings nicht in die Wände schauen können) und auch rückwärts einen Architekturentwurf erstellen können (allerdings nicht mit den Ideen des Architekten, die der Bauingenieur verwerfen musste). Das ist genau die Arbeit von professionellen Sprengmeistern, die ein Gebäude kontrolliert zum Einsturz bringen müssen. Sprich mal mit denen, wie sehr es ihnen hilft, wenn sie die Baupläne und Architekturentwürfe vorliegen haben! Dann wissen die nämlich, für welche Erweiterungen das Gebäude schon vorbereitet wurde und was in den Wänden steckt!
        Wenn aber das Gebäude ohne Architekt (und damit ohne Architekturentwurf) und ohne Bauingenieur (und damit ohne Bauplan) quasi im Eigenbau einfach irgendwie hingestellt wurde, dann wirst du auch rückwärts aus dem Gebäude keinen sinnvollen Bauplan und schon gar nicht einen sinnvollen Architekturentwurf erstellen können. Deshalb wirst du bei so einem Gebäude auch niemals was Grundsätzliches an der nicht vorhandenen Architektur ändern können und musst ganz anders vorgehen.
        Du sprichst in deiner These oben von „Software-Archäologie“ und „Organismus“, also implizit von etwas mit Eigenleben. Deshalb war ich in meinem Kommentar auch eher von der zweiten Situation ausgegangen. Wenn Code ohne vorherige Architektur entwickelt wurde, wirst du durch Reverse Engineering wohl nie eine ordentliche Architektur finden. Wenn vorher eine Architektur entwickelt wurde, dann liegt sie wohl vor. Es sei denn, wir sprechen von einer unvollständigen Lieferung, weil nur der Code ohne Modelle und Doku geliefert wurde – und das ist bei professioneller Arbeit tabu und kommt Fall 2 gleich.
        Also: Entweder es wurde ordentlich gearbeitet und es liegt eine Architektur vor, oder nicht, und du wirst auch keine herzaubern können.
        Wenn also zuerst eine Architektur entwickelt werden soll, können wir darüber diskutieren, wie man das agil tun kann. Wenn die Architektur so sein soll, dass sie später agil (oder überhaupt) änderbar sein soll, können wir darüber diskutieren, welche Voraussetzungen dafür gegeben sein müssen, also welche Anforderungen durch Agilität gestellt werden.  Ich will damit sagen: Die Erstellung oder Änderung einer Architektur kann vielleicht agil sein, aber die Architektur selbst doch nicht! Eine Architektur ist ein Arbeitsergebnis, ein Output eines Prozesses, ein Artefakt, ein Dokument, … – das kann doch nicht agil sein. Das war der Grund, warum mich die Überschrift so angezogen hat.
        Ich meine also, statt „Agile Architektur ist änderbar!“ müsst der Ansatz – wenn schon – heißen: „Architektur ist agil änderbar!“. Du hast in deinem Kommentar oben an einer Stelle formuliert: „Wie kann man agil ‘architekten’?“. Und am Ende deines Kommentars sagst du selbst, dass es auch deiner Meinung nach den Begriff „agile Architektur“ gar nicht geben kann – geht auch nicht. Aber der Fokus muss da bewusster drauf. Vorsicht mit saloppen Formulierungen im Engineering! Und damit kommen wir zu der Frage, was agile Änderung an sich bedeutet und welche Anforderungen wir an die Architekturerstellung oder –änderung formulieren müssen, damit dies möglich wird.
        Und damit komme ich dabei zu deiner Liste mit den 5 Punkten. „Punkte“ ist mir zu unspezifisch und ich würde es deshalb gerne zumindest schon mal „Anforderungen“ nennen wollen. Diesen Anspruch hätte ich hier.
        Einfachheit: Das ging vor vielen Jahren als „Kiss“ (Keep it small and simple) rum und ist immer gut. Natürlich sollte man nur codieren, was gebraucht wird, und das gibt die Architektur vor. Einfachheit kann sich auf Architektur wie auf Code beziehen.
        Modularität: Wie ich schon geschrieben habe, bedeutet der Entwurf einer Architektur die Zerlegung des Problems in Komponenten und die Definition des Zusammenspiels der Komponenten. Modularer Aufbau mit Schnittstellen heißt, dass man eine Architektur baut. Und davon gehe ich aus. Diese Anforderung adressiert also das Vorhandensein einer Architektur.
        Lesbarkeit: Dies wird in der Liste oben nur auf den Code bezogen und hat somit nichts mehr mit der Architektur zu tun. Aber man könnte es natürlich auch auf die Architektur beziehen.
        Inline-Dokumentation der Entscheidungen: Wie jetzt – wollt ihr die Entscheidungen, die zu der Architektur geführt haben, in den Code schreiben? Das wäre in der Tat mal was Neues – warum schreibt Ihr es nicht einfach in die Architektur, wo es hingehört und wie es seit Jahren gemacht wird?
        Testbarkeit: Dies wird in der Liste oben wieder nur auf den Code bezogen, also wohl eher auf Modultests. Die fertige Software testet man ja auch gegen die Akzeptanzkriterien der Anforderungen, weil die Produktqualität ja nun mal über den Grad der Erfüllung der Anforderungen beschrieben wird. Bei einer Architekturdiskussion halte ich die Integrierbarkeit der Software für viel wichtiger, also einen Review der Integrationsstrategie und einen Test der Softwareintegration.
        Diese Punkte oder Anforderungen haben meines Erachtens alle nichts damit zu tun, ob ich die Architektur agil erstellen und ändern möchte oder nicht. Das sind alles alte Hüte, die allgemeingültig und/oder abgefrühstückt sind.
        „Agile“ Softwareentwicklung heißt doch zunächst mal „sehr iterative“ Softwareentwicklung, d.h. in vielen kleinen Schritten. Und jeder Schritt (nenne ihn Iteration oder Sprint oder wie auch immer) muss zunächst die Architektur und dann die Codierung betrachten (und natürlich alle anderen Teilprozesse). Ich habe so jetzt fast zehn Jahre lang ein größeres System projektiert und wir habe im Raster von durchschnittlich maximal zwei Monaten bisher insgesamt 69 Releases geliefert. Wir haben das am Anfang nicht „agil“ genannt, weil das Wort noch nicht in diesem Kontext verwendet wurde, aber aus heutiger Sicht war es genau das, nämlich iterativ inkrementell.
        Und damit bin ich in deinem Kommentar bei deinem drittletzten Absatz über dem schönen Wochenende: Wenn der Architekt auf die Anforderungen des Entwicklerteams reagieren soll, ist meines Erachtens genau hier schon der Fehler! Agil oder nicht, Scrum oder nicht, Sprints oder nicht, alles egal: grundsätzlich reagiert der Architekt auf die Anforderungen bzw. Änderungsanforderungen bzw. Anforderungsänderungen. Und nach der Änderung der Architektur reagieren die Implementierer/Codierer auf die Architekturänderungen, gepaart mit den zugehörigen funktionalen Anforderungen. Alle sind „Entwickler“ und alle müssen meines Erachtens Teil des Teams sein. Oder – wenn die Änderungen gravierender sind – es wird in einer Iteration die große Architekturänderung für die nächste Iteration vorbereitet, während gleichzeitig in derselben Iteration nur Fehler behoben und nur kleinere Änderungen vorgenommen werden.
        Als oberste Anforderung an „agil veränderbare Architekturen“ würde ich eine möglichst lose Kopplung der Komponenten sehen, als nächste möglichst polymorphe Schnittstellen. Diese Ideen haben ja auch zu Webservices (SOA) geführt. Aber das Zusammenspiel der Komponenten (oder Webservices) muss als dritte Anforderung dann zentral gesteuert werden, was ja auch zum ESB (Enterprise Services Bus) mit entsprechenden Orchestrierungstools geführt hat. Damit wurde ja ein Teil der Probleme schon gelöst und größere Konzerne – beispielsweise RWE – verwenden solche Architekturkonzepte ja auch schon seit etwa drei Jahren. Genau das wollte ich ja auch Anfang 2009 in deinem Hamburger CSM-Kurs diskutieren, aber ich musste einsehen, das dafür weder Zeit und Raum war, noch dass die agile Lehre des Scrum dafür schon weit genug offen war. Es
        wird auch jetzt noch dauern, bis sich diese drei Anforderungen in das Tooling der „kleineren“ Software-Welten vererbt. Ich erlebe gerade, wie sich das mit IBM Rhapsody bei Embedded Software anfühlt.
        Wir sprechen ja gleichzeitig auch von der Wiederverwendung von Komponenten in verschiedenen Produkten mit verschiedenen Architekturen; das wäre meine vierte Anforderung an Architekturen in agilen Umgebungen (wenn ich es mal so nennen darf). Und der nächste Schritt in der Evolution des Reuse von lose gekoppelten Komponenten sind vielleicht sowas wie autonome intelligente Agenten, deren Interaktion von ihnen selbst geplant wird. Da wirst du aber noch nicht viel drüber finden.
        Eine solche Diskussion müsste man mal mit den einschlägigen Experten führen, die wohl nicht bei deinen 80 dabei waren und die wir wohl leider auch nicht in diesen Blog bekommen können. Denn wir bräuchten dann auch gleichzeitig Leute, die sich mit Software-Product-Line-Engineering und der Behandlung von Generationen genug auskennen. Und das sind leider nicht viele. Aber das wäre meine fünfte Anforderung: Iterationen führen zu Releases und grundsätzliche Architekturänderungen zu Generationswechseln und damit Versionen. Das muss bei einer agilen Weiterentwicklung von Architekturen berücksichtigt werden!
        Ist jetzt etwas länger geworden, aber letztendlich nur die ausführlichere Darstellung meines ersten Kommentars und für mich auch Teil eines schönen Wochenendes!
        Ich wünsche dir einen schönen Sonntag!
        be agile,
        Ralf

        • Bernd Krehoff sagt:

          Ein spannender Ideenaustausch!
          Wie stelle ich mir Architektur vor? Für mich ist Architektur nichts, das irgendwie da steht und von agilen Teams in den Iterationen zu berücksichtigen wäre. Das, was wir unter Architektur verstehen, sollte nicht neben, sondern mit jeder Iteration Stück für Stück gebaut und fortgeschrieben werden.
          Um die Haus-Metapher fortzuführen: Wenn ich umziehe, kann ich vorher einen Plan erstellen, in dem ich festlege, wo genau welches Modul zu stehen hat. Wo der Arbeitsbereich, wo der Wohnbereich, wo die Küche. Das Zusammenspiel aller Module ergibt dann das Gesamtprodukt “Wohnung”. Solche Gedankenspiele machen sicher Spaß. Sie sind aber letztlich nur Modelle, (mehr oder weniger gute) Abbilder der Realität.
          Ich kann diese Planung aber auch sein lassen und schnurstracks in die Implementation gehen: Ich fange mit dem Sofa an, stelle es in diese Ecke – und schaue dann, wie dazu der Schreibtisch passt, wo die Regale am besten stehen usw. Kurzum: Ich plane, indem ich umsetze. Planung und Umsetzung sind dann nicht mehr getrennt voneinander, sondern fließen in einer Handlungseinheit zusammen.
          Warum kann das nicht auch bei der Software-Entwicklung so laufen? Ich schreibe Code – und indem ich das tue, kann ich immer auch die Auswirkungen auf die Gesamtheit im Blick haben – und aus dieser Perspektive die sicherlich erforderlichen Rahmenbedingungen gestalten.
          Ob ich diese Rahmenbedingungen dann in einem Dokument namens “Architektur” festhalte oder nicht – das ist für mich erstmal zweitrangig.
          Es kommt doch darauf an, ein Produkt zu erzeugen, dass in sich so stimmig ist, dass ich den inneren Aufbau durch das Produkt selber erkennen kann. Wenn die Nähte, die das Produkt zusammenhalten, auch für Außenstehende erkennbar sind, dann hat auch unser Archäologe den Zugang für eine Rekonstruktion zur Hand.

        • Spannende Diskussion! 
          Zum Thema Analogien / Metaphern:  Ich bin da immer skeptisch, denn auch wenn eine Analogie im Prinzip funktioniert, bedeutet es noch lange nicht, dass man sie weitertreiben kann um manche Details zu begründen, oder zu widerlegen.  Und trotzdem bemühe ich jetzt noch mal eine:
          Städtebau ist die bessere Analogie zur Softwareentwicklung als Architektur eines Gebäudes.  Und genauso, wie Städte wachsen und in der Regel nicht am Anfang durchgeplant werden, muss auch ein Softwaresystem wachsen und nicht am Anfang durchgeplant werden.
          Softwaresysteme sind immer komplexe Systeme.  Und in der Theorie der komplexen Systeme ist es wichtig zu erkennen, dass sie innerhalb eines bestimmten Rahmens wachsen und sich ständig selbst kalibrieren und optimieren.  Auf Software Systeme übertragen, bedeutet es (noch) nicht, dass die einzelnen Komponenten sich selbst anpassen und ihre Services bzw. Schnittstellen verändern, sondern dass die Entwicklerteams unter den gegebenen Voraussetzungen die für die zu implementierende Funktionalität notwendigen Veränderungen in den Rahmen einpassen, bzw hinzufügen und dabei das System besser machen.
          Geht das von selbst?  Nein, genau dazu ist der Rahmen richtig zu setzen.  Die Systemarchitektur (oder der Bebauungsplan?) ist also ein Rahmenwerk, das vorgibt, wie einzelne Komponenten in dem komplexen System interagieren können, wo Komponenten erlaubt sind und wo nicht und insbesondere wie ich verifiziere, dass die Komponenten und das gesamte System immer noch das Ergebnis produzieren, das gewünscht ist.
          Und damit schließt sich der Kreis auch ein wenig zu dem Dokumentationsthema.  Ich glaube, dass in einem komplexen System die Dokumentation eigentlich nicht so gut sein kann, dass ein Außenstehender durch lesen von Code und Modellen / Diagrammen das System verstehen kann.  Entscheidender ist für mich, dass ich gute Tests als Bestandteil meiner Software habe, mittels derer ich verifizieren kann, dass das System immer noch das tut, was es soll, nachdem ich es verändert habe.  Und wenn ich im Rahmen der Änderungen etwas umbauen oder gar neu schreiben muss (vielleicht sogar weil ich es nicht verstehe), dann ist das eben so.  Refactoring halt!  Und die Tests sollten mir sagen, ob des System noch funktioniert, nachdem ich es umgebaut habe.
          Auf diese Art und Weise wird ein System wachsen.  Und wenn die Entwickler nicht ständig wechseln, so wird dabei auch eine Architektur entstehen, die den (auch über die Zeit entsehenden) Anforderungen entspricht.
          Soweit erstmal… Das ist ein wetes Feld und man kann da ganz sicher noch Seiten über Seiten zu schreiben.  Aber jetzt ist erst mal wieder ein anderer dran…

  2. Heiko Dietz sagt:

    Ich kann schon mit dem Titel nichts anfangen. “Agile Architektur ist änderbar!”. Da stellt sich bei mir die Frage, die auch Ralf aufwirft, was soll das überhaupt sein? Was ist Agile Architektur? Und warum ist nur diese änderbar? Architektur kann ich IMMER ändern, die Frage ist, ob der zugrundeliegende Code das auch mitmacht und wie teuer es wird.
    Gehen wir doch mal etwas anderes an die Sache ran: Was ist Softwarearchitektur überhaupt? Softwarearchitektur beschreibt doch in letzter Konsequenz das Zusammenspiel von vielen Einzelkomponenten und elementareren Einheiten. Es ist üblicherweise das Arbeitsergebnis eines Softwarearchitekten.
    Was ist Code? Code ist die Lösung eines elementaren Problems. Wenn ich eine Funktion xyz() schreibe, muss ich nicht die gesamte Architektur im Blick haben, sondern ich muss dafür sorgen, das die Funktion “tut”, was von ihr gefordert wird. Codierung hat mit Architektur wenig zu tun, genauso wir ITONG Steine wenig mit realer Architektur zu tun haben. Codierung ist auch nicht die Aufgabe eines Architekten, Code ist in einem Team der Output eines Entwicklers. Somit ist glaube ich die Diskussion doch völlig hinfällig, das Architektur im Code dokumentiert werden sollte. Das ist in keinster Weise zielführend. Erstens sind es wie oben dargestellt völlig unterschiedliche Rollen, die beteiligt werden müssten und die Erstellung der Architektur würde durch viel zu viele Hände gehen. Nebenbei ist es auch noch völlig unpraktisch. Das neue Entwickler in ein Team kommen, ist ja nichts ungewöhnliches. Wenn dieser dann fragt, wie die Architektur beschaffen ist, soll dann die Antwort lauten: “Hier ist das Source Repository: Wenn du alle Kommentare in der 17.000 Quellen gelesen hast, hast du einen guten Überblick.” Eine gute Architekturdokumentation ist eine, die in kurzen Dokumenten und Diagrammen das Zusammenspiel der Einzelkomponenten beschreibt. Noch wichtiger ist, das hier die Ideen und Gedanken des Architekten beschrieben sind, warum das Problem so aufgeteilt wurde und welche Anforderungen hier zu Grunde liegen. Auch sollten die Grenzen dokumentiert sein, die dem Architekten beim Entwurf schon bekannt sind.
    Zu dem Basispost mit den Frameworks. Warum wollen Entwickler immer neue Frameworks entwicklen? Warum wird oft behauptet, das aktuelle Frameworks und Ideen nicht ausreichen? Die Antwort ist ketzerisch gesagt einfach und ich könnte sie aus 20 Jahren in der Softwareentwicklung aus zig Beispielen belegen: 
    Erstens macht es mehr Spass Frameworks zu entwicklen als Routinearbeit, daher versuchen Entwickler dem Management oft zu verkaufen, das dies nötig ist.
    Zweitens haben viele Leute überhaupt keinen Überblick was es überhaupt an fertigen Lösungen und Konzepten gibt und bauen es dann lieber selber.
    Drittens gibt es einen riesigen Markt von Firmen, Beratern und Zeitschriften, die jedes Jahr eine neue Sau durchs Dorf treiben müssen um ihr Geld zu verdienen und ein finanzielles Interesse daran haben, das ständig über Frameworks diskutiert wird.
    Und Last but not Least: Weil es viele Teams und Unternehmen gibt, die die Position des Architekten (Also der der das große und ganze im Blick hat) garnicht besetzt haben.
    Noch ein letztes Wort, was mir bei deinem Artikel aufgefallen ist, ich zitiere mal die Einleitung Zitat: 
    “Wer iterativ entwickeln will, hat ein grundsätzliches Problem: Er weiß nicht, ob er in der Zukunft eine Anforderung erhält, die es notwendig machen wird, Grundannahmen umzuwerfen. Das kann im extremsten Fall dazu führen, dass große Teile des Produkts nachträglich verändert werden müssen. Dieses Wissen treibt viele Softwareentwickler zu der Überlegung: Man müsste ein Framework entwickeln, das möglichst robust ist, sodass man möglichst flexibel auf zukünftige Wünsche eingehen kann.” 
    Ich bezweifle, das ein erfahrener Architekt Anforderungen bekommt, die sein ganzes Produkt über den Haufen werfen. Der grundsätzliche Projektauftrag und Scope sollte schon aus dem Rahmen des Auftrags was zu entwicklen ist recht klar sein. Was sollen für Anforderungen an eine Software und damit auf eine Architektur zukommen, die die gesamte Architektur über den Haufen werfen und nicht schon beim Projektstart bekannt sein könnten? Ich gehe soweit, zu behaupten, das es diese Anforderungen so gut wie nie gibt, wenn der Architekt sein Handwerk und den Sinn für seinen Projekt- oder Produktauftrag versteht.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.