Definition

Die Probleme, wenn es um Softwarearchitektur geht, fangen schoneinmal beim Begriff selbst an. Ich selbst musste schon erleben, wie Mitarbeiter eines Architekturteams, welche schon Jahre zusammenarbeiteten, keinerlei gemeinsame Definition finden konnten und unterschiedliche Ziele unter dem Vorwand verfolgten. Es wird uns nichts anderes übrig bleiben, als die diversen Definitionen, welche es gibt, der Reihe nach anzuführen und zu überprüfen welche davon wirklich valide ist. Dann picken wir uns eine raus (die Beste?) und gehen näher auf diese ein.

Softwarearchitecture is about the important stuff (whatever that is) - Ralph Johnson

Bei dieser Definition, welche auch der Favorit von Größen der Branche wie Martin Fowler ist, geht es als Softwarearchitekt darum, sich um alles wichtige zu kümmern in einem Softwareentwicklungs-Unterfangen. Nehmen wir also an, dem Kunden ist es besonders wichtig, dass neue User sich in einer Webplattform besonders schnell zurechtfinden. Ein klassisches Usability Thema also. Dafür ist also der Archuitekt zuständig? Das glaube ich irgendwie ganz und gar nicht. Für mich besteht bei dieser Definition die Gefahr, dass das Thema Architektur dabei verwässert, falsch verstanden wird oder auch als Vorwand für eine - sorry - Besserwisserei hergenommen wird, die bei keinem Team wirklich gut ankommt.

Erfüllung nichtfunktionaler Anforderungen

Bei Nichtfunktionalen Anforderungen (NFAs) handelt es sich um gewünschte Qualitätsaspekte der Softwarelösung des Auftraggebers. Also Dinge wie Antwortzeitverhalten, Usability, Korrektheit, etc. Ich find es wiederum kurzsichtig, die Erfüllung der Qualitsaspekte nur einer Disziplin bzw. Rolle umzuhängen. Es invalidiert die Fähigkeiten der einzelnen Teammember, und untergräbt evtl. sogar deren Motivation. Manchmal wird der Architekt auch dafür verantwortlich gemacht, diese NFAs beim Kunden zu erheben. So, als ob die Rolle des Requirements Engineers nie erfunden wurde. Das Gegenargument, dass diese NFAs aber nur der Architekt für seine Arbeit braucht, und daher selber erheben sollte, kannn ich auch nicht gelten lassen. Schließlich sind es die Developer, welche die Funktionalen Anforderungen zur Umsetzung benötigen, trotzdem kommt niemand deswegen auf die Idee, dass diese sich selbst darum kümmern.

Kommunikation

Eine zu breite Definition der Architektur führt nicht selten dazu, dass dem Architekten nichts anderes übrig bleibt, als sich auf die Koordination der Aspekte während der Umsetzung mit dem Team zu konzentrieren. Er wird also dem Projektleiter (oder Scrum Master / Product Owner) dessen Arbeit abnehmen. Diese Tätigkeit sollte aber genau dort bleiben.

Entscheidungen, welche später schwierig zu ändern sind

Viele Definitionen von Softwarearchitektur legen fest, dass es dabei darum ginge, auf alle wichtigen Entscheidungen Einfluss zu nehmen. Tatsache ist dabei allerdigns, dass ich als Architekt darauf nur bedingt Einfluss habe. Die wirklich wichtigen Entscheidungen werden meiner Erfahrung nach "am Golfplatz" getroffen. Als Architekt wird man nicht selten vor vollendete Tatsachen gestellt, in manchen Fällen auch nach vorheriger Evaluation, welche zu einem vernichtenden Ergebnis gekommen war. Was ich damit sagen möchte: Es ist und bleibt der Job der Unternehmensführung vernünftige Entscheidungen zu treffen. Dabei ist es wichtig, bei dieser abstrakten und wichtigen Aufgabe nicht den Konnex zur Realität zu verlieren, was gar nicht so einfach ist. Als CxO ist man automatisch auf einer entsprechenden "Flughöhe" und kann nicht mehr jedes Detail verstehen. Auf diese abstakte Art und Weise noch rational treffsichere Entscheidungen zu treffen ist eine Kunst für sich. Ich bewundere alle Unternehmen, wo dies gut klappt. Eine Kultur, welche dies möglich macht, muss zweifelsohne gefördert werden. Ein "Architekt" kann dies nicht ersetzen.

Umsetzung

Manchmal sind die Führungskräfte mit der Performance ihrer Developer nicht zufrieden. Eine typische reflexartige Reaktion ist dann manchmal, ihnen einen Architekten zur Seite zu stellen. Architektur ist aber bestimmt nicht dadurch definiert, besonders gut umsetzen zu können, indem man besonders guten Code schreibt. Meist liegen bei solchen Problemfällen die Ursachen ganz wo anders (seltsame Bürokratie, wechselnde Anforderungen, fehlende Makrostrukturen etc.), aber auch wenn nicht: Wenn die Probleme im Development liegen, dannn hat dieses an seiner Qualität zu arbeiten. Nicht mehr und nicht weniger, sei es durch Coaching erfahrener Entwickler, oder auch Externe. Aber nicht unbedingt durch einen "Architekten". Versetzen Sie sich bitte mal in die Lage eines Developers, dem eine andere Rolle vorgesetzt wird, wenn es Probleme mit seinen Arbeitsergebnissen gibt (für deren Ursachen er evtl. gar nicht verantwortlich ist). Das entwertet die hohe Kunst des Entwickelns von Algorithmen, welches eine komplexes Thema ist. Development Probleme sollten also zunächst mal auf ihre Ursache hin untersucht werden (z.B. mit der 5-Why-Methode), um danach die Situation entsprechend zu verbessern. Sonst sind u.U. Konflikte vorporgrammiert.

Dokumentation

Wir sind uns vermutlich einig: Was auch immer Architektur ist, sie gehört in angemessener Weise (!) dokumentiert. Anzeichen, dass das Architekturthema aus dem Ruder gerät ist für mich immer, wenn der Architekt auch verantwortlich dafür ist, den Betrieb zu dokumentieren. Welche Komponente läuft auf welcher Maschine? Frage: Warum macht das nicht der Betrieb und kümmert sich selbst um seinen Kram?

Technologien

Oft soll der Architekt die Technologien, welche verwendet werden, auswählen. Manchmal auch "die eine Technologie", weil der Führungsebene hier jedwede Vielfalt zuwider ist. Entscheiden kann ein Architekt das aber unmöglich alleine. Es gilt dabei den Betrieb zu berücksichtigen, die Kenntnisse und Vorlieben der Entwickler welche dann damit arbeiten müssen, etc. Prinzipiell denke ich, dass dieses Thema etwas überschätzt wird. Am Server genügt meist ein Stück Java Code welcher ausschließlich mit einer Abhängigkeit zur JEE Api auskommen sollte, für das UI reicht meist das, was das Web mit seinen Standards schon heute beherrscht (zur Not mit polyfills). Jede neue Technologie bedeutet eine Abhängigkeit, die man sich gut überlegen sollte. Versuchen Sie daher immer, Anforderungen mit der langweiligsten noch passenden Technologie zu erfüllen.

Strukturen und Modularisierung

Aus dem Buch "Lehrbuch der Softwaretechnik: Entwurf, Implementierung, Installation und Betrieb" von Helmut Balzert (Affiliate Link) stammt folgende Definition für Softwarearchitektur: Eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen. Damit sind wir endlich beim Kern des Themas angelegt. Es geht also tatsächlich darum Strukturen zu bauen, die Komplexität eines Systems dadurch in geordnete Bahnen zu lenken, indem man sie Schritt für Schritt in ihre Einzelteile zerlegt. Nicht mehr und nicht weniger ist Softwarearchitektur. Dabei machen die folgende Aspekte gute, weil langlebige Komponenten bzw. Module aus:

  • Sie verbergen ihre Implementierugnsdetails vor der Außenwelt. Dadurch können andere Komponenten keine Abhängigkeiten zu diesen ihnen unbekannten Aspekten entwickeln.
  • Eine möglichst passende, gezielt gebaute Schnittstelle ermöglicht die Interaktion mit einer Komponente. Die Rahmenbedingungen sind dabei möglichst gut definiert, sodass es bei Änderungen nicht zu Überraschungen bei den Consumern der Schnittstelle kommen kann.
  • Es werden keine zukünftig erwarteten Änderungen bei der Festlegung der Komponentenstruktur vorweggenommen. Es werden keine Abstraktionen auf Verdacht gebaut. Das Design bleibt so einfach wie nötig, aber nicht einfacher. Dadurch wird dauerhafte Flexibilität erreicht, und eine Vorwegnahme von Anforderungen ist gar nicht erst notwendig.
  • Strukturen haben ab einer gewissen Komplexität eine fraktale Natur. Komponenten zerlegen sich selbst wieder in andere Komponenten, und bilden auf ihrer Ebene mit anderen Komponenten wiederum Komponenten.
  • Bei der Interaktion zwischen Komponenten werden möglichst wenige Annahmen, wie Datenformate und Schnittstellenmodelle, zeitliche Verfügbarkeit und Technologie des Gegenübers getroffen. Dadurch ist die Kopplung der Komponenten möglichst gering.

Aber: Warum? Wieso soll man das machen? Wir kommen nicht herum eine Zielsetzung für so eine Modularisierung eines Systems zu definieren, denn ohne Ziel ist ja bekanntlich jeder Weg richtig. Außerdem wird damit allen subjektiven Cargo-Kulten die es in der Branche gibt der Wind aus den Segeln genommen. Diese erkennt man übrigens immer an der entlarvenden Argumentation, die da meistens heißt: "Das muss so sein" (siehe zB die TOGAF SOA Referenz Enterprisearchitektur). Mit einer vernünftigen Modularisierung soll also das Folgende erreicht werden:

  • Die einzelnen Komponenten bzw. Module können unabhängig voneinander verstanden, bzw. auch möglichst unabhängig voneinander weiterentwickelt werden. Dabei sollte es zu möglichst wenig Seiteneffekten auf andere Komponenten kommen.
  • Jedes Modul ist für sich testbar, für jedes kann unabhängig von den anderen eine Aussage bez. seiner Qualität getroffen werden. Der Bedarf nach einer Enterprise-Weiten Testumgebung ist meist ein Anzeichen für fehlende Makro-Architekturen.
  • Falls es Probleme welcher Art auch immer gibt, so sollten diese möglichst auf eine der Komponenten beschränkt bleiben. Im Notfall lässt sich dann eine solche Komponente noch recht einfach auswechseln.
  • Es ist möglichst wenig Abstimmung zwischen den Mitarbitern (Mikro-Ebene) bzw. Teams (Makro-Ebene) nötig zur Weiterentwicklung. Lähmende Bürokratie und mieserable Time-to-Market sind meist klare Anzeichen für fehlende Modularisieurng auf der Ebene der Makro-Architektur (Kann aber meist nicht mehr als deren Ursache erkannt werden).

Der letzte Punkt ist besonders interessant: Vor allem auf der Makro-Ebene klappt es meistens nicht mit den langfristig effizient wartbaren Strukturen. Meist wird dies als Enterprise Architektur bezeichnet, bzw. falsch verstanden. Techniken wie das EAM unterstützen die Softwarearchitektur, ersetzen diese aber keineswegs! Tatsächlich sehe ich es so, dass viele Unternehmen durch die zunehmende Lähmung der Produktivität ihrer Software Entwicklungstätigkeiten im Laufe des 21. Jahrunderts in gewaltige Probleme kommen werden. Die Ursachen und Lösungsmöglichkeiten zu beschreiben würde den Rahmen dieses Blog-Postings sprengen, daher kann ich hier nur bei Andeutungen bleiben. Falls Sie sich näher für dieses komplexe Thema interessieren, so möchte ich Ihnen an dieser Stelle noch in eigener Sache die Lektüre meines Buches zum Thema empfehlen, welches im Mai 2018 erscheinen wird (Affiliate Link).

Fazit

Bei Softwarearchitektur geht es in erster Linie um den Bau langfristig gut wartbarer Strukturen, und das dadurch, dass man die Gesamtkomplexität durch saubere Abgrenzung in einzelne Teile zerlegt. Dabei ist es gar nicht so wichtig, wer sich um das Thema kümmert, und wie diese Rolle genannt wird, Hauptsache es wird nicht darauf vergessen. Alle anderen Themen, welche manchmal gerne dem Architekten umgehängt werden, sind natürlich ebenfalls wichtig, aber überlegen Sie sich bitte, wer im Team für die jeweilgen Aufgaben am besten geeignet ist, ohne eine davon zu vergessen. Alles einfach "einem Architekten" umzuhängen halte ich nicht für besonders zielführend, weil man diesen damit automatisch überfordert. Außerdem wird er sich als der Wichtigtuer, zu dem man ihn (oder sie) somit macht, auch nicht unbedingt beliebt machen. Darüber hinaus besteht noch die Gefahr, dass diese zentrale Person (bzw. dieses zentrale Team) zu einem organisatorischen Flaschenhals im Unternehmen wird, wodurch die Architektur die Time-to-Market bremsen würde, anstatt, wie sie es eigentlich zum Ziel haben sollte, diese zu beschleunigen. Es gibt also viele gute Gründe, diese Skills auf das Team zu verteilen, trauen Sie ihren Mitarbeitern ruhig mal etwas zu! Und vergessen Sie dabei bitte nicht auf den Bau effizienter und modularer Strukturen.