Software-Architektur (IEC 62304 konform)

Schlagwort: Software-Architektur (IEC 62304 konform)

Die Software-Architektur ist die Beschreibung des inneren Aufbaus eine Software-Systems. Üblicherweise identifiziert die Software-Architektur die Komponenten und beschreibt deren Zusammenspiel und Abhängigkeit. Finden Sie in diesem Artikel Informationen zu folgenden Themen:

Typische Fehler beim Erstellen der Software-Architektur

Fehler 1: Keine up-front Software-Archiektur

Mit Architektur-Refactoring überfordert

Mancher Freund der agilen Software-Entwicklung wird bei dieser Überschrift aufjaulen. Obwohl ich in meinen Firmen selbst agil entwickle, warne ich davor, die Software-Architektur während der Entwicklung bei jeder Iteration anzupassen. Nahezu alle Software-Entwickler bzw. Software-Architekten sind mit einem kontinuierlichen Architektur-Refactoring überfordert — auch wenn das keiner zugegen möchte.

Die meisten Firmen bzw. Software-Architekten sind bereits damit überfordert, eine Upfront-Software-Architektur zu erstellen. Ich sehe wirklich viele Firmen, und fast alle scheitern daran. Also glauben Sie nicht, Sie könnten „im laufenden Betrieb“ Ihre Software-Architektur anpassen. Das wird man Ihrer Software-Architektur nachher ansehen: „Historisch gewachsen“.

Ging auch mir so

Ich habe eine harte Schule durchlaufen: Wie entscheidend die Software-Architektur für den Erfolg eines Produkts ist, musste ich gleich zweimal lernen.

Das erste Mal, als im Lauf der Jahre meine Software immer unwartbarer und undurchschaubarer wurde und jede Änderung im Code zu zumindest überraschenden Ergebnissen geführt hat. Ich glaubte, ohne explizite Architektur auszukommen. Eine teure Lehre! Das zweite Mal hatte ich einen strengen Lehrmeister: die Software-Architekten von IBM in Rochester, MN. Ihre Botschaft war eindeutig: „Christian solve your problems in the model“. Und wenn ich mich daran nicht halten würde, würden sie die Zusammenarbeit beenden. Klare Botschaft oder?

Die meisten Probleme, die in der Software-Architektur gelöst werden müssen, sind komplex. Das macht man nicht nebenher.

Aber die IBM-Jungs hatten Recht. Die eigentliche Entwicklung und Wertschöpfung findet beim Entwerfen der Software-Architektur statt – und (hoffentlich) nicht beim Programmieren. Wer das nicht verstehen will, bezahlt gleich mehrfach:

Man benötigt länger, denn Iterationen und Nachbesserungen gelingen in einem Dokument oder auf einem Flipchart um Größenordnungen schneller als im Code. Man entwickelt potenziell unsichere Produkte, weil durch unzureichend strene Modularisierung die Risiken nicht beherrscht werden können. Eine saubere, einfach zu verstehende und konsistente Architektur ist eine zwingende Voraussetzung für eine wartbare Software. „Historisch gewachsen“ zähle ich zu den Unworten in diesem Kontext.

Beachten Sie die regulatorischen Anforderungen an die Software-Architektur

Also, machen Sie es gleich richtig, lösen Sie Ihre „Probleme“ (Requirements) in der (Software-)Architektur und nicht während des Kodierens. Genau das verlangt auch die IEC 62304. Lesen Sie hier mehr zu den regulatorischen Anforderungen an die Dokumentation der Software-Architektur.

Wünschen Sie Unterstützung dabei, eine präzise und gesetzeskonforme Software-Architektur zu erstellen? Melden Sie sich bei mir, ich freue mich darauf! Kontakt aufnehmen

Fehler 2: Keine standardisierte Notation wie UML

Die Forderung der IEC 62304, die Software-Architektur zu dokumentieren, führt bei manchen Entwicklern zum reflexartigen Öffnen von PowerPoint und dem Malen irgendwelcher Kästchen.

Davon abgesehen, dass diese Kästchen meist die Architektur gar nicht korrekt abbilden, sind solche Diagramme teilweise wertfrei. Denn ein Modell ist nur dann aussagekräftig, wenn die Notationselemente definiert sind. Doch was bedeutet ein Pfeil bei einer „eigenen“ Modellierungssprache?

Eine Abhängigkeitsbeziehung?

Eine Assoziation? Komposition oder Aggregration?

Eine Vererbungsbeziehung?

Eine Datenflussrichtung?

Eine Richtung der Methodenaufrufe?

Eine Implementierung?

Bevor Sie eine eigene Notation erfinden, nutzen Sie doch UML. Über ein Dutzend Diagrammtypen stehen Ihnen zur Verfügung, mit denen Sie so ziemlich alles ausdrücken können, was Sie benötigen, um Software konzeptionell zu entwickeln.

Ganz automatisch (über)erfüllen Sie damit die Forderungen der IEC 62304.

Review / Verifizierung der Software-Architektur

Die IEC 62304 verlangt, dass die Hersteller die Software-Architektur prüfen, die Norm spricht von verifizieren. Die wichtigesten Aspekte bei der Prüfung sollten sein:

Sind alle Software-Anforderungen erfüllt? Mit Traceability-Matrix oder mit Werkzeug prüfen

Ist die Risikomanagementakte aktualisiert? Sind alle risikominimierenden Maßnahmen in der Architektur umgesetzt? Sind Risiken, die sich aus der Wahl der Software-Architektur ergeben, analysiert und beherrscht?

Erfüllt das Software-Architektur-Dokument die Vorgaben aus dem Entwicklungsplan?

Ist die Software-Architektur so verständlich, dass die Entwickler sie ohne weitere Rückfragen umsetzen können?

Review der Software-Architektur als Rollenspiel

Dabei ist die Architektur nur dann eine gute, wenn sie die Komponenten (bei einer Schichten-Architektur die Schichten – bestmöglich getrennt hält (also wirklich komponentenorientiert ist) und wenn Sie geeignet ist, die Systemspezifikation zu erfüllen.

Zumindest letzteres können Sie beim Architektur-Review mit einem Rollenspiel wirkungsvoll prüfen:

Eine Person spielt beispielweise die GUI (also Dialog- und/oder Präsentationsschicht), eine andere Person die Geschäftslogik. Dann geht die GUI stückweise ihre Bildschirmmasken durch und schaut, was sie an Nutzungsobjekten hat. Wenn es beispielsweise eine Tabelle gibt, die alle weiblichen Patienten über 65 mit eine Nephropathie und mit einem Hämoglobinwert unter 10mg/dl und mit einer bestimmten EPO-Dosis anzeigt, dann bittet der „GUI-Schauspieler“ seinen Geschäftslogik-Kollegen, genau diese Daten zu besorgen und dazu im UML-Diagramm zu erklären, welche Methodenkaskade genau diese Daten berechnet und zurückliefert.

Sie gehen dieses Spiel nicht nur für alle Nutzungsobjekte, sondern auch für alle Werkzeuge durch. Die GUI-Vertreter bittet z.B. den Geschäftslogik-Vertreter zu beschreiben, wie die Architektur auf das Klicken des Speichern-Buttons reagiert. Bei einem Ultra-Thin-Client müsste es für jedes Nutzungsobjekt und jedes Werkzeug eine Methode im Backend geben.

Das Ziel der Person, die die Rolle der GUI vertritt, besteht darin, der Architektur nachzuweisen, dass sie nicht in der Lage ist, alle notwendigen Daten zu besorgen oder abzuspeichern. Nach einer Weile – das wäre mein Tipp – sollten die beiden „Schauspieler“ die Rolle wechseln. Glauben Sie mir, intensiver lässt sich eine Architektur kaum prüfen. Das bedingt natürlich, dass Sie Ihre Architektur modelliert haben.

Schlechte Software-Architektur: Ein Problem im Audit?

Die Vertreter der meisten benannten Stellen haben mich am Institut besucht, um über die gesetzeskonforme Software-Entwicklung zu sprechen. Das gab mir die Gelegenheit zu fragen, wie sie mit schlechten Software-Architekturen umgehen würden.

Die Antworten waren eindeutig, für mich aber überraschend: Die Auditoren würden bei einer schlechten Software-Architektur kein „Finding“ notieren. Eine schlecht dokumentierte Software-Architektur (unabhängig davon ob die Architektur selbst gut oder schlecht ist) könnte hingegen zu einem Problem in Audit führen.

Diese Denkweise kann ich einerseits nachvollziehen, weil es kein Gesetz und keine Norm gibt (z.B. IEC 62304), das eine gute Software-Architektur vorschreibt. Andererseits kann eine schlechte Software-Architektur zum Problem werden, wenn sie beispielsweise dafür verantwortlich ist, dass Risiken damit nicht beherrscht oder dadurch sogar verursacht werden.

Güte der Dokumentation

Eine gute Dokumentation der Software-Architektur ist eine Voraussetzung dafür, um die Güte dieser Architektur überhaupt beurteilen zu können. Lesen Sie hier mehr zur Software-Architektur Dokumentation.

Für den Auditgarant habe ich mehrere Videotrainings erstellt, in denen ich Schritt für Schritt erkläre, wie man nicht nur eine gute Dokumentation verfasst, sondern auch eine gute Architektur erstellt.

Als Richtschnur, für eine „gute“ Dokmentation von Software-Architekturen können Sie die ISO/IEC 42010 (guter Wikipedia-Artikel) oder das Template von arc42 nutzen.

Güte der Architektur

Hier stellt sich die Frage nach den Kriterien und dem Bewertungsmaßstab für die Güte der Architektur. Die Architektur wird im Wesentlichen durch die „nicht-funktionalen“ Anforderungen getrieben. D.h. Sie sollten prüfen, ob hinreichend viele – für die Architektur relevante – Qualitätsanforderungen definiert sind. Da hapert es bei den meisten Software-/System-Anforderungen. Und muss man eine Methode festlegen, mit dem man die „Angemessenheit“ der Architektur für diese Qualitätsanforderungen überprüft. Z.B. ATAM oder SAAM. Da stoßen wir auf das nächste Problem: Das kennst geschweige denn beherrschen nur wenige.

Mit den Videotrainings des Auditgarants, lernen Sie Schritt für Schritt, eine „gute“ und normenkonforme Architektur zu dokumentieren.

Benötigen Sie noch Hilfe beim Modellieren oder Prüfen („Reviewen“) Ihrer Architektur? Dann melden Sie sich doch bei mir, ich helfe gerne.

Lehrmaterialien und Checklisten

Videotrainings zur Software-Architektur

Wenn es um die Dokumentation der Software-Architektur für Medizinprodukte geht, treffe ich auf zwei verschiedene Typen an Menschen:

Die Software-Entwickler, die regelmäßig Probleme damit haben, weil sie den Sinn nicht immer einsehen und nicht wissen, was man dokumentieren muss, um den Forderungen der Gesetze (auch FDA) und Normen gerecht zu werden.

Die Regulatory-Affairs-Manager, die zwar die Gesetze und Normen kennen, aber nicht genau wissen, wie man die Forderungen in der Praxis ohne großen Overhead erfüllen kann.

Deshalb enthält der Auditgarant mehrere Videotrainings zum normenkonformen Entwickeln und Dokumentieren von Software-Architekturen.

Sie lernen in diesen Trainings:

Weshalb Sie eine Architektur erstellen und dokumentieren sollten

Was die Merkmale einer guten Architektur sind

Welche regulatorische Anforderungen Sie erfüllen müssen

Wie Sie Ihre Architektur dokumentieren können

Wie man eine Architektur prüft/reviewed/verifiziert

Mit diesem Wissen, sehen Sie im nächsten Audit gut aus!

Checklisten zur Dokumentation von Software-Architekturen

Ergänzend empfehlen wir Ihnen den Auditleitfaden, die komplette Checkliste für alle Entwicklungsphasen, auch für die Dokumentation der Software-Architektur. Diesen Auditleitfaden haben wir für benannte Stellen entwickelt, die damit Software-Audits durchführen. Sie ersparen sich damit tagelanges Studieren der Normen und können Ihre „Auditfähigkeit“ selbst prüfen.

Persönliche Unterstützung

Falls Sie Ihre Software-Architektur bereits dokumentiert haben, helfen wir Ihnen gerne mit einem Review. Wir können Ihnen ebenso schnell wie preisgünstig wertvolles Feedback geben.

Nehmen Sie gleich Kontakt mit uns auf!

Die Bauarchitektur und die Softwarearchitektur haben viele Gemeinsamkeiten, aber auch einige fundamentale Unterschiede. Dieser Beitrag zeigt Ihnen, wo Sie als Medizinproduktehersteller die Metapher der Bauarchitektur nicht über Gebühr strapazieren sollten.

Software-Architektur versus Bauarchitektur

Das normale Vorgehen

Stellen Sie sich vor, Sie wollen ein Haus bauen – Ihr neues Haus. Wie würden Sie vorgehen?

Wahrscheinlich würden Sie sich überlegen, was Sie in und mit dem Haus machen wollen. Beispielsweise darin die Schwiegermutter beherbergen. Oder das vielleicht gerade nicht. Oder Sie benötigen einen Raum, in dem Sie Ihre Modellflugzeuge bauen und aufbewahren.

Anschließend werden Sie mit Ihren Wünschen zum Bauarchitekten gehen und sich einen Plan entwerfen lassen. Einen Plan, den Sie wahrscheinlich noch ein oder zweimal revidieren. Erst dann bestellt der Bauunternehmer die Maurer, die das Haus gemäß dieses Plans, der Bauarchitektur, hochziehen.

Sie stimmen mir sicher zu, dass dies das absolut normale Vorgehen beim Hausbau ist.

(istockphoto)

Bauarchitektur á la Software

Wie würden Sie folgende Variante einschätzen? Zuerst bestellt man die Maurer. Denn die haben ja gerade Zeit und wollen beschäftigt sein. Während diese mit dem Mauern beginnen, überlegt sich der Architekt noch schnell den Bauplan, die Bauarchitektur. Was Sie vom Haus wünschen, wird er schon richtig erahnen.

Das halten Sie für schwachsinnig? Zugegeben, ich auch. Aber genauso wird Software oft entwickelt:

Die teuren Programmierer müssen beschäftigt sein. Man kann sie ja nicht sinnlos ohne Arbeit rumsitzen lassen, bis man endlich weiß, was man will, und dann die Softwarearchitektur entworfen hat.

Und so wird programmiert. Die Änderungen, die sich dann im Lauf der Zeit zwangsläufig ergeben, werden während der Programmierung (des Mauerns) umgesetzt. Das nennt man dann vornehm Refactoring.

Und wenn man, wie das fast immer der Fall ist, feststellt, dass der Kunde doch etwas anderes wünscht (die wissen ja nie, was sie wollen), dann ändert man eben die Anforderungen, danach die Architektur (so man überhaupt eine erstellt) und danach die bereits entwickelte Software. Meistens muss man diesen Zyklus mehrfach durchlaufen, bis die Anforderungen des Kunden erfüllt sind (oder dieser entnervt aufgibt). Das nennt man dann agile Entwicklung.

Bin ich jetzt zu zynisch? Vielleicht ein wenig. Aber von den Jungs am Bau können wir noch verdammt viel lernen.

Unterschied von Bauarchitektur und Softwarearchitektur

Zumindest einen Unterschied zwischen Bauarchitektur und Softwarearchitektur sollten Sie aber bedenken: Die Bauarchitekten ermitteln die Anforderungen und erstellen den Bauplan. Die Softwarearchitekten sollten nur den Bauplan (die Softwarearchitektur) erstellen. Die Anforderungen zu erheben, ist Aufgabe des Requirements Engineers.

Software-Architektur: Worauf es ankommt

Wenn man die wesentlichen Aspekte von Software-Architektur beschreiben soll, muss man zunächst den Begriff „Software-Architektur“ selber klären. Wikipedia und der Standard ISO/IEC 42010 definieren Software-Architektur als die grobgranulare Strukturierung eines Software-Systems. Dazu passt der Begriff „Architektur“: Die Architektur eines Gebäudes gibt die groben Strukturen vor. Die meisten Architektur-Entwürfe zeigen dementsprechend die Aufteilung des Systems in größere Komponenten.

Ein Gedankenexperiment zeigt, ob diese Definition ausreichend ist: Eine Software geht nicht in Produktion. Es ist ein Sicherheitsproblem entdeckt worden und ein Problem mit der Compliance. Einen solchen Fehlschlag kann man wohl kaum als erfolgreiche Architektur bezeichnen. Aber das Sicherheitsproblem ist wahrscheinlich nicht auf der Ebene der Strukturierung des Systems zu erkennen. Es kann ein einfacher Programmierfehler oder eine unsichere Technologie sein, die zu dem Problem geführt hat. Also muss Software-Architektur etwas anderes umfassen als nur die Struktur des Systems, denn offensichtlich können auch andere Faktoren zu einem Architektur-Fehlschlag führen.

Martin Fowler als anerkannter Experte sieht Software-Architektur als die Menge aller wichtigen und schwer änderbaren Entscheidungen . Das passt besser zu dem Gedanken-Experiment: Offensichtlich waren die Entscheidungen im Sicherheitsbereich wichtig, denn sie haben verhindert, dass das System in Produktion geht. Und sie sind nicht einfach zu ändern, sonst wäre das Problem schnell und einfach gelöst werden. Also ist die Definition eigentlich ganz gut. Genau genommen kann man vorab nicht wissen, welche Entscheidungen schwer zu ändern sind. Wie schwierig das ist, findet man nur sicher heraus, wenn man die Entscheidung tatsächlich revidiert.

Eine andere Möglichkeit, Software-Architektur zu definieren ist relativ schlicht: Software-Architektur bedeutet, dass man eine technische Software-Lösung für das jeweilige Problem entwirft. Diese Definition ist nicht sonderlich spezifisch. Sie passt zu allen Arten von technischen Ingenieursdisziplinen. Aber die Definition zeigt wie wichtig es ist, das Problem zu kennen, das gelöst werden muss.

Der Hinweis auf das zu lösende Problem mag trivial erscheinen. Allerdings enthalten Architektur-Dokumentationen zwar fast immer eine Darstellung der grobgranularen Struktur des Systems aber fast nie Informationen dazu, welches Problem das System eigentlich überhaupt lösen soll. So ist es schwierig, die konkreten Entscheidungen nachzuvollziehen oder zu bewerten.

Für die Darstellung einer Architektur haben sich mittlerweile viele unterschiedliche Wege etabliert und werden auch breit genutzt. Es gibt auch Werkzeuge, um das Problem besser zu verstehen und darzustellen. Die sind aber bei weitem nicht so bekannt. ISO 25010 definiert dafür den Qualitätsbaum. Auch Standards für Architektur-Dokumentation wie arc42 beinhalten diese Aspekte.

Ausschnitt aus dem Qualitätsbaum (Abb. 1)

Abbildung 1 zeigt einen Ausschnitt aus dem Qualitätsbaum. In dem Qualitätsbaum sind verschiedene Qualitätsmerkmale wie Sicherheit oder Zuverlässigkeit aufgelistet.

Für jedes Qualitätsmerkmal gibt es eine Liste von Teilmerkmalen. Die Teilmerkmale machen es einfacher, ein Qualitätsmerkmal wirklich vollständig zu betrachten. Bei Zuverlässigkeit geht die Diskussion oft schnell in die Richtung der Verfügbarkeit. Ein Blick in den Qualitätsbaum zeigt weitere Teilmerkmale wie Fehlertoleranz. Fehlertoleranz bedeutet, dass ein System trotz des Ausfalls einiger Komponenten weiter funktionieren muss. Ein weiteres Teilmerkmal ist die Wiederherstellbarkeit: Es kann wichtig sein, dass ein System nach kurzer Zeit wieder zur Verfügung steht.

Bei Sicherheit in der Abbildung ist nur ein beispielhaftes Teilmerkmal aufgelistet: Die Nachweisbarkeit. Es kann sein, dass Benutzerinterkationen beispielsweise vor Gericht nachgewiesen werden müssen.

Durch den Qualitätsbaum wird offensichtlich, welche Merkmale Software überhaupt erfüllen kann. Architekten können mit dem Qualitätsbaum überprüfen, ob wirklich alle wesentlichen Qualitätsmerkmale der Software betrachtet worden sind.

Dennoch reicht der Qualitätsbaum nicht aus: Die Einhaltung der Qualitätsmerkmale können nur schlecht verifiziert werden. Doch auch dafür gibt es ein geeignetes Software-Architektur-Werkzeug: Das Qualitätsszenario (siehe Abbildung 2).

Qualitätsszenarien (Abb. 2)

Ein Qualitätsszenario beschreibt ein Ereignis, das auf das System einwirkt, und eine Metrik, um das gewünschte Verhalten des Systems zu definieren. Ein Qualitätsszenario ist konkret und leicht zu verifizieren, weil es eine Metrik festlegt.

Es gibt verschiedene Arten von Szenarien:

Bei Benutzungsszenarien geht es um Anforderungen, die sich aus der Benutzung ergeben. Ein Beispiel: „Wenn sich ein Benutzer registriert, soll nur einer von 1.000 Benutzern die Hotline anrufen.“ Das Ereignis ist die Registrierung. Die Metrik ist die Anzahl der Anrufe bei der Hotline. Das Szenario beschreibt das Qualitätsmerkmal der Benutzbarkeit. Durch die Metrik ist sichergestellt, was mit einem „einfach zu benutzenden System“ gemeint ist. Um dieses Qualitätsszenario zu erfüllen, kann man beispielsweise UX-Experten zum Projekt hinzuziehen oder Benutzer-Tests einplanen. Solche Maßnahmen gehören nicht zur klassischen Architektur-Arbeit, sind aber die richtigen Maßnahmen, um das Projektziel zu erreichen.

Ein Änderungsszenario beschreibt, wie ein System auf eine Änderung reagieren soll. Ein Beispiel: „Wenn eine neue Sprache oder ein neues Land unterstützt werden soll, darf dazu keine Änderung am Code notwendig sein. Die Änderung muss mit einem Aufwand von höchstens zwei Personentagen umgesetzt werden können.“ Dieses Szenario gehört zum Qualitätsmerkmal der Änderbarkeit. Die Lösung ist offensichtlich: Es muss eine Konfiguration mit den entsprechenden Texten und weiteren Einstellungen für die verschiedenen Länder geben.

Schließlich gibt es Ausfallszenarien. „Wenn ein Server ausfällt, dann muss das System spätestens nach zwei Stunden wieder zur Verfügung stehen. Es dürfen keine Daten verloren gehen.“ Hier geht es um das Qualitätsmerkmal „Zuverlässigkeit“ und genauer gesagt um die Fehlertoleranz. Um die Anforderungen zu erfüllen, könnte ein redundantes Speicher-System oder ein Backup ausreichen. Ein Cluster wäre zwar auch als Lösung denkbar, aber wegen der recht langen Zeit, in der das System nicht verfügbar sein darf, ist ein Cluster nicht zwingend notwendig.

Die Qualitätsszenarien zeigen klar, was das System leisten muss, um die Anforderungen zu erfüllen. Idealerweise sollte die Architektur nicht nur Qualitätsszenarien auflisten, sondern auch Lösungen aufzeigen, um die Qualitätsszenarien zu erfüllen. Das ist leider die absolute Ausnahme bei typischen Architektur-Beschreibungen. So kann aber nicht garantiert werden, dass die entwickelten Systeme die Probleme überhaupt lösen.

Oft wird eine „gute“ Architektur mit hoher Codequalität, einer sauberen Struktur oder guter Skalierbarkeit gleichgesetzt. Aber keine dieser Eigenschaften hätte auch nur ansatzweise dabei geholfen, irgendeines der oben genannten Qualitätsszenarien zu erfüllen. Ebenso ist die Benutzung bestimmter Frameworks oder Programmiersprachen völlig unerheblich dafür, ob diese Qualitätsszenarien erfüllt werden oder nicht. Mit anderen Worten: Wenn man wirklich eine Lösung für die Anforderungen im Projekt entwickeln will, ist die traditionelle Architektur-Arbeit höchstens ein Teil der Lösung und oft noch nicht einmal der wichtigste.

Ein weiterer Aspekt, der bei der Architekturarbeit oft unterschätzt wird, sind die Rolle und das Selbstverständnis der Software-Architekten. Obwohl dieser Aspekt so ein Schattendasein führt, ist er dennoch sehr wichtig.

Traditionell ist „Software Architekt“ ein Titel und oft auch eine Stufe auf der Karriereleiter. Die moderne Interpretation von „Software Architekt“ ist anders: Es ist die Person, die Architektur macht. Und es ist eine Rolle: Zu unterschiedlichen Zeiten können unterschiedliche Personen die Rolle „Software Architekt“ haben. Diese Personen können den Titel „Software Architekt“ haben oder auch nicht. Wenn man die oben erwähnten Qualitätsszenarien betrachtet, deren Erfüllung zur Architektur gehört, dann können klassische Architekten nur wenige dieser Qualitätsszenarien erfüllen.

Oft haben traditionelle Software-Architekten an sich die Anforderung, die bezüglich Technologien erfahrensten Personen im Team zu sein. Schließlich treffen Architekten Entscheidungen, die weitreichende Konsequenzen haben. Zweifellos müssen sie daher die beste Qualifikation mitbringen. Wenn jemand an sich die Anforderung stellt, für jedes Detail und jede Technologie die erfahrenste Person im Projekt zu sein, dann ist das schlicht unrealistisch. Kommt noch der Anspruch dazu, alle wichtigen Entscheidungen zu fällen, dann setzen sich Software Architekten selbst gewaltig unter Druck. Es ist unklar, warum Architekten freiwillig solche Rollen spielen wollen. Aber eigentlich ist schon der Anspruch, dass der Architekt die mit allen Technologien erfahrenste Person im Team sein soll, ziemlich traurig. In einem solchen Team hätte der Architekt niemanden, von dem man lernen kann.

Die moderne Interpretation der Rolle „Software Architekt“ geht anders mit den technischen Skills um. Der Architekt soll die Expertise des gesamten Teams nutzen. Um das Team noch erfolgreicher zu machen, soll er dafür sorgen, dass sich die Team-Mitglieder weiterentwickeln und neue Fähigkeiten erlernen.

Es gibt nicht nur Unterschiede bei der Interaktion im Team, sondern auch bei den konkreten Tätigkeiten. Der traditionelle Architekt ist dafür verantwortlich, das gesamte System zu verstehen. Das ist aber kaum möglich: Software-Entwicklung ist vor allem eine Herausforderung, weil bis auf wenige Ausnahmen Systeme entwickelt werden, die so groß sind, dass eine einzelne Person sie nicht entwickeln und auch nicht vollständig verstehen kann. Also kann auch ein Software Architekt das System nicht vollständig detailliert verstehen. Er muss auch für das Verständnis des Systems auf die Expertise des Teams zurückzugreifen. Jeder Mitarbeiter im Team kennt einen bestimmten Teil und Aspekt des Systems. Es ist die Aufgabe des Architekten, diese Expertise zu nutzen und auf dieser Basis das System gemeinsam mit dem Team weiterzuentwickeln.

Der klassische Architekt würde eine Architektur definieren, alle relevanten Entscheidungen treffen und dann diese Architektur im Projekt durchsetzen. Dazu muss der Architekt eine Rolle im Projekt haben, die das Durchsetzen der Architektur ermöglicht. Oft werden Projekt agil nach Scrum entwickelt. Scrum kennt die Rolle des Product Owner. Diese Person definiert die zu implementierenden Features als Stories. Das Team implementiert diese Stories und organisiert sich dabei selbst. Der Scrum Master beseitig Hindernisse und sorgt dafür, dass die Scrum-Regeln eingehalten werden.

In der Scrum-Organisation kann der Architekt „nur“ ein einfaches Team-Mitglied sein. Dann kann der Architekt aber die Architektur nicht durchsetzen. Schließlich ist das Team selbst organisiert und daher entscheidet das Team als Ganzes, wie es arbeiten will. Wenn diese Regel nicht eingehalten wird, sollte der Scrum Master einschreiten, denn dann wird eine wesentliche Scrum-Regel verletzt.

Also kann der Architekt die Architektur in einem agilen Projekt gar nicht durchsetzen. Aber selbst wenn der Architekt die Architektur durchsetzen dürfte, bleibt die Frage offen, wie er zum Durchsetzen der Architektur konkret vorgehen soll. Da der Architekt nicht wissen kann, was alles im Projekt vorgeht, ist es schwierig, die Architektur durchzusetzen. Es kann passieren, dass das Team die Architektur gar nicht umsetzt, aber der Architekt das nicht merkt, weil er eben nicht das gesamte System verstehen kann.

So kommt es leicht zu dem Elfenbeinturm-Effekt: Der Architekt versteht die Herausforderungen des Systems nicht, weil er das System nicht vollständig verstehen kann und mit den anderen Team-Mitgliedern nicht ausreichend kommuniziert. Auf Basis dieser falschen Informationen trifft er Architektur-Entscheidungen, die gegebenenfalls nicht umgesetzt werden, weil sie keine realen Probleme lösen. Das wiederum merkt der Architekt nicht, weil er eben nicht das gesamte System verstehen kann. So lebt er von der Realität entkoppelt in einem Elfenbeinturm: Er kennt das System eigentlich nicht und seine Tätigkeit hat auch keine Auswirkung auf das Projekt.

Eine moderne Interpretation der Rolle „System Architekt“ setzte auf die Kollaboration im Team, um die gesamte Expertise des Teams zu nutzen und so bessere Architekturen zu erarbeiten. Entscheidungen, an denen das gesamte Team intensiv mitgearbeitet hat, haben außerdem eine höhere Wahrscheinlichkeit, tatsächlich umgesetzt zu werden. Schließlich haben sich alle an dem Thema beteiligt. Daher gibt es kaum einen Grund, die gemeinsame Entscheidung nicht auch gemeinsam umzusetzen. So vermeidet dieses Vorgehen den Elfenbeinturm-Effekt.

Die Rolle „Software Architekt“ ist eher die Rolle eines Moderators, der die Entscheidungsprozesse unterstützt. Dabei macht er seine technische Expertise nutzbar und bringt sich daher auch inhaltlich in die Diskussion ein. Aber im Mittelpunkt steht die Zusammenarbeit.

Software Architektur erinnert damit an kollaborative Spiele wie Pandemie . Im Gegensatz zu anderen Spielen gewinnen bei einem kollaborativen Spiel alle gemeinsam oder sie verlieren gemeinsam. Das ist bei einem Software-Projekt nicht anders: Wenn das Projekt nicht erfolgreich ist, verlieren alle dabei. Bei Pandemie geht es darum, den Ausbruch einer Pandemie zu vermeiden. Die Figur jedes Spielers hat dabei bestimmte Stärken: Der Arzt kann Infizierte besser heilen und der Logistiker andere Figuren einfacher durch die Welt reisen lassen. Diese Stärken können kombiniert werden, um so besondere Vorteile zu erreichen. So kann der Logistiker den Arzt dahin schicken, wo gerade besonders viele Infizierte sind. Diese besten Synergien herauszufinden und ein gemeinsames Handeln zu planen und umzusetzen, sind der Kern des Spiels. Das bedeutet, dass alle Beteiligten dauernd miteinander reden, um das gemeinsame Vorgehen abzusprechen. So sind alle Spieler ständig involviert – auch wenn gerade jemand anders am Zug ist. Spezielle Fähigkeiten und spezielles Wissen zeichnen auch die Teammitglieder in einem Software-Projekt aus. Und auch in einem Software-Projekt ist Kommunikation der Schlüssel, um das Projekt erfolgreich umzusetzen.

Konkret geht es bei der Architektur-Arbeit meistens darum, Entscheidungen zu treffen. Es müssen Lösungen für die aktuellen Herausforderungen gefunden werden. Dabei gibt es oft mehrere Optionen und eine der Optionen muss ausgewählt werden. Allerdings sind die Informationen über das System und über das zu lösende Problem meistens nicht vollständig. Dass nie alle Informationen vorliegen, ist eine grundlegende Herausforderung bei der Software-Entwicklung. Das gilt vor allem für die Anforderungen. Dennoch muss das Team Entscheidungen treffen. Und es kann schwierig und teuer sein, weitere Informationen zu bekommen. Selbst wenn es möglich ist, mehr Informationen zu bekommen, kann es dauern, bis die Informationen tatsächlich vorliegen und dann kann es auch schon zu spät sein.

Also muss man sich daran gewöhnen, ständig Entscheidungen mit zu wenig Informationen zu treffen. Das setzt Mut voraus. Es gibt dennoch eine Optimierungsmöglichkeit: Wenn man eine Entscheidung später trifft, dann gibt es mehr Informationen, weil man in der Zwischenzeit mehr Erkenntnisse gesammelt haben wird. Außerdem: Wenn man Entscheidungen zu früh fällt, kann es gut sein, dass man Entscheidungen über Dinge trifft, die erst sehr viel später relevant werden oder vielleicht sogar nie, weil doch andere Dinge als gedacht implementiert werden. Also sollte man sich vor jeder Entscheidung fragen, ob man sie jetzt fällen muss und was passiert, wenn man die Entscheidung später oder sogar zu spät trifft.

Ein konkretes Beispiel: Ein Startup entwirft ein IT-System. Das System soll natürlich Rechnungen erstellen können, denn sonst gibt es keinen Umsatz. Offensichtlich ist das Erstellen der Rechnungen ein wichtiges Feature und man muss eine Architektur dafür definieren. Aber um Umsatz zu generieren, muss es erst Kunden geben. Wer schon selbstständig war, kennt das manuelle Schreiben von Rechnungen. Man kann also durchaus auch Rechnungen ohne Automatisierung erstellen. Außerdem hat dieses IT-System ein Abo-Modell, das am Monatsende abgerechnet wird. Wenn die ersten Kunden da sind, hat man also noch einen Monat Zeit, das Schreiben der Rechnungen zu implementieren. Also kann man die Arbeit an diesem Teil der Architektur erstmal zurückstellen. Wenn man tatsächlich mit der Architektur für die Erstellung der Rechnungen beginnt, hat man auf jeden Fall mehr Informationen und kann so zu einer besseren Architektur kommen. Die besten Entscheidungen sind also die, die man noch nicht getroffen hat.

Aus der Unsicherheit bei dem Treffen der Entscheidungen kann man ableiten, dass man sicher suboptimale Entscheidungen treffen wird. Wenn man nun aber noch mehr Aufwand investiert, um bessere Entscheidungen zu treffen, wird das nicht viel helfen. Die Unsicherheiten lassen sich nicht wirklich auflösen. Also sollte man sich eher darauf einstellen, dass man Entscheidungen wird revidieren müssen. Wenn man nicht auf neue Informationen reagiert, wird die Architektur darunter leiden. Die Erklärung für die meisten Architektur-Probleme ist nicht, dass sich die Architekten nicht genug angestrengt haben. Die Erklärung ist, dass es neue Erkenntnisse gab, die nicht in die Architektur eingeflossen sind, weil die Architektur nicht revidiert worden ist.

Eine weitere wichtige Frage ist, ob Architekten selbst programmieren. Traditionelle Architekten tun das nicht. Schließlich arbeiten sie nicht auf der Ebene von Code sondern auf der abstrakteren Ebene der Architektur. Das kann zu dem Elfenbeinturm-Effekt führen, weil Architekten dann das System auf Ebene von Code und damit die Details des Systems nicht sehen. Um dieses Problem zu lösen, ist es aber wie schon erwähnt viel besser, auf die Kommunikation mit dem Team zu setzen. Also ist der Elfenbeinturm-Effekt kein ausreichender Grund, um als Architekt zu coden.

In einem größeren Projekt kann die Architektur-Arbeit so umfassend sein, dass eine Person damit vollständig beschäftigt ist. Da Software-Architekt aber eine Rolle ist, können sich natürlich auch mehrere Personen die Arbeit teilen. Weil Architektur kollaborativ ist, werden sowieso mehrere Personen an der Architektur beteiligt sein. Dennoch kann es sinnvoll sein, die Arbeit auf möglichst wenige Personen zu konzentrieren, um weniger Abstimmung zwischen Architekten zu erreichen. Ein weiteres Problem ist, dass Architekten in erster Linie für die Architektur zuständig sein sollten. Wenn sie dringend Architektur-Arbeit leisten müssen, werden sie das Programmieren vernachlässigen. Das kann sie zu unzuverlässigen Programmierern machen.

Also können Architekten selbst programmieren oder auch nicht. Beides sind Möglichkeiten, wie man die Rolle ausgestalten kann. Den Elfenbeinturm-Effekt kann und muss man bei beiden Ansätzen vermeiden, und zwar durch intensive Kommunikation.

Eine Analogie kann ein Fußball-Trainer sein: Eine solche Person weiß, wie man Fußball spielt, aber tut es nicht mehr selbst aktiv. Insbesondere wird sich der Trainer nicht selbst einwechseln, um das entscheidende Tor zu schießen. Für Software-Architekten gilt ähnliches: Sie sollten wissen, wie man programmiert, aber sie müssen es nicht mehr zwangsläufig selbst tun. Insbesondere komplexe Aufgaben oder Aufgaben, bei denen ein hoher Druck existiert, sollten sie lieber anderen überlassen.

Artikel Softwarearchitektur (Teil II)

Der Softwarearchitekt (Teil II)

Softwarearchitekten übernehmen in Projekten eine zentrale Rolle und tragen eine große Verantwortung. Dass sie über ein ausgezeichnetes technisches Know-how verfügen müssen, ist allseits bekannt, aber auch wichtige Softskills sind unabdingbar. Im folgenden Artikel wollen wir beleuchten, welche Aufgaben der Architekt übernimmt und welche Fähigkeiten er dazu benötigt.

Mythos Elfenbeinturm

Das Bild von einem Softwarearchitekten, der sich in seinen Elfenbeinturm zurückzieht, einsam einen Plan ausarbeitet und diesen anschließend einem Heer von Entwicklern zur Ausführung vorlegt, ist längst überholt.

Softwarearchitekten stellen heute das Binde­glied zwischen den unterschiedlichen Interes­sensgruppen eines Projektes dar. Dazu zählen neben den Anwendern, Auftraggebern und dem Betrieb auch die Projektmanager sowie das komplette Entwicklungsteam. Entsprechend vielfältig und anspruchsvoll sind die Aufgaben, die die Softwarearchitekten zu bewältigen haben. Die Fähig­keiten, die sie auszeichnen sollen, machen sie zu echten Allroundern der IT.

Rollenverteilung

Die Rolle des Softwarearchitekten ist nicht immer klar definiert, in manchen Projekten wird sie von Personen in einer Doppelfunktion wahrgenommen.

Um der Verantwortung für eine hochwertige Softwarearchitektur im Projekt gerecht werden zu können, sollte der Architekt aber klassische Interessenskonflikte vermeiden. So sollten die Rollen des Projektleiters und des Software­architekten möglichst getrennt vergeben werden.

Während der Softwarearchitekt bzgl. der Architektur eher langfristige Ziele verfolgt (z.B. Wartbarkeit), neigen Projektleiter dazu, entsprechende Qualitätsmerkmale, Zeit- oder Budgetaspekten unterzuordnen.

In agil vorgehenden Projektteams kristallisiert sich meist relativ schnell, sofern der Aspekt der Selbstorganisation auch gelebt wird, eine Person (oft ein erfahrener Entwickler) heraus, der die Aufgaben eines Architekten übernimmt. Das gilt auch für jene agilen Vorgehensmodelle, die keine explizite Rolle eines Softwarearchitekten definieren.

Entwerfen von Architekturen

Zu den offensichtlichen Aufgaben des Architekten gehört das Entwerfen von Architekturen. Er konstruiert ein System aus einer Reihe von Subsystemen, die sich wiederum aus Komponenten zusammensetzen. Dieses Entwerfen beinhaltet die Definition der Verantwortlichkeiten der einzelnen Komponenten und deren Schnittstellen. Die eigentliche Funktionalität des Systems, das aus statischen und dynamischen Strukturen besteht, wird dann durch die Interaktion der Komponenten bestimmt.

Der Konstruktionsprozess beruht auf einer Reihe von Anforderungen und Annahmen, aus denen der Softwarearchitekt seine Entwurfsentscheidungen folgert. Daraus leitet sich eine sehr wichtige Aufgabe ab, die Überprüfung und Klärung der Anforderungen. Insbesondere die nicht-funktionalen Anforderungen haben entscheidenden Einfluss auf das Design eines Softwaresystems. Folgende Aspekte muss der Architekt deshalb im Vorfeld bezüglich der Anforderungen unbedingt klären:

Abgrenzung

Durch das Feststellen der Systemgrenzen lassen sich die eigenen Aufgaben­gebiete abgrenzen. Gleichzeitig werden dadurch die Schnittstellen zu benachbarten Systemen klarer.

Durch das Feststellen der Systemgrenzen lassen sich die eigenen Aufgaben­gebiete abgrenzen. Gleichzeitig werden dadurch die Schnittstellen zu benachbarten Systemen klarer. Vollständigkeit

Ein vergessenes oder unterschätztes Qualitätsmerkmal kann im Nachhinein eine Architektur als ungeeignet disqualifizieren. Es muss also zu Beginn, am besten anhand von Checklisten, die Vollständigkeit der Anforderungen geprüft werden. Werden hier Lücken festgestellt, muss der Architekt die fehlenden Aspekte unbedingt in eigener Initiative einholen und ergänzen.

Ein vergessenes oder unterschätztes Qualitätsmerkmal kann im Nachhinein eine Architektur als ungeeignet disqualifizieren. Es muss also zu Beginn, am besten anhand von Checklisten, die Vollständigkeit der Anforderungen geprüft werden. Werden hier Lücken festgestellt, muss der Architekt die fehlenden Aspekte unbedingt in eigener Initiative einholen und ergänzen. Qualität

Sind alle Anforderungen vollständig erfasst, müssen sie detailliert beschrieben und priorisiert werden. Insbesondere die impliziten Annahmen (z.B.: „Das System muss performant sein.“) müssen konkretisiert werden (z.B.: „Das System muss mindesten 10 Aufträge mit jeweils 5 Positionen in weniger als 10 Sekunden verarbeiten können.“). Da nicht alle Qualitätsmerkmale gleichzeitig optimiert werden können, ist die Priorisierung wichtig (z.B.: Die Performance ist im Zweifelsfall wichtiger als die Erweiterbarkeit). Hierfüreignen sich beispielsweise Utility Trees hervorragend.

Design-Entscheidungen

Der Softwarearchitekt trifft während des Entwurfs der Architektur, basierend auf den Anforderungen, laufend Entscheidungen zum Design des Gesamtsystems. Das betrifft nicht nur die abstrakten Strukturen, sondern auch deren Abbildung auf konkrete technische Konzepte. Er bedient sich dabei neben seines eigenen Know-hows auch immer aus der Schatzkiste von Erfahrungen, die er oder andere Architekten bereits gesammelt haben.

Trotzdem wird es ihm nie gelingen, auf alle Eventualitäten vorbereitet zu sein. Er bewegt sich mit seinen Design-Entscheidungen in einem Spannungsfeld, in dem nicht alle Anforderungen gleichwertig erfüllt werden können (siehe Abbildung 1).

Abb. 1: Spannungsfeld der Design-Entscheidung.

Daher muss er ein besonderes Maß an Selbstvertrauen und Mut aufbringen und in der Lage sein, die getroffenen Entscheidungen anhand von vorliegenden Anforderungen und Randbedingungen begründen zu können und die damit verbundenen Risiken zu bewerten.

Oft wird er seine Lösung gegen andere Vorschläge verteidigen müssen. Das Wissen um suboptimale Entwurfsentscheidungen während der Architekturentwicklung fordert aber auch entsprechende Möglichkeiten zur Korrektur. So sollte die Entwicklung der Architektur sinnvollerweise in kurzen Iterationen durchgeführt werden (siehe Abbildung 2).

Abb. 2: Architekturentwicklung.

Daraus ergibt sich für den Architekten zeitnah die Möglichkeit, einmal getroffene Entscheidungen zu überdenken und ggf. mit kalkulierbarem Aufwand anzupassen. So kann er auf neue oder veränderte Situationen reagieren, ohne zu große Risiken für das Gesamtsystem eingehen zu müssen.

Dokumentation und Kommunikation

Die Ergebnisse aus der oben beschriebenen Klärung der Anforderungen müssen genauso, wie die entwickelte Softwarearchitektur und die Wahl der technologischen Konzepte dokumentiert werden.

Die Anforderungen sind die Grundlage und damit die Begründung aller Design-Entscheidungen. Sie müssen von allen Projektbeteiligten akzeptiert und vertreten werden. Für die Dokumentation gibt es unterschiedliche Methoden, von einfachen handschriftlichen Aufzeichnungen bis zur komplexen Software­lösung ist alles möglich. Wichtig ist, ein gutes Maß für den Umfang und die Art der Dokumentation zu finden, denn die Dokumentation soll gelesen werden. Zuviel Dokumentation ist mindestens genauso schädlich wie fehlende Dokumentation.

In diesem Zusammenhang kommt eine weitere wichtige Fähigkeit des Architekten zum Tragen. Er muss in der Lage sein, die Architektur zu kommunizieren. Da er gegenüber allen Projektbeteiligten in der Verantwortung steht, muss er für jede Zielgruppe die angemessene Form sowie den richtigen Umfang und Inhalt finden.

Während für das Management die Personal-, Zeit- und Budget-Aspekte von Interesse sind, trifft dies für die Systemadministratoren eher nicht zu. Sie benötigen für die betrieblichen Belange vielmehr Informationen bzgl. der Verfügbarkeit oder Skalierbarkeit des Systems. Dies ist für das Entwicklerteam zwar auch relevant, aber von nicht so entscheidender Bedeutung wie beispielsweise einzusetzende Technologien, Frameworks oder Entwurfsmuster.

Die richtige Sprache für alle Beteiligten zu finden ist ein entscheidender Faktor, um die Akzeptanz einer Architektur im gesamten Projekt zu erreichen. Der Softwarearchitekt muss hier vereinfachen, filtern und kanalisieren, damit die Informationen bei den einzelnen Personen bedarfsgerecht ankommen.

Außerdem ist der Softwarearchitekt gut beraten, Informationen aktiv einzufordern und das Feedback der unterschiedlichen Interessensgruppen in seine Überlegungen einfließen zu lassen. Die Kommunikation ist und bleibt einer der wichtigsten Aspekte.

Allerdings gelten hier ähnliche Regeln wie bei der Dokumentation. Auf das richtige Maß kommt es an. Projekte, in denen man vor lauter Meetings nicht mehr zur eigentlichen Tätigkeit kommt, gibt es leider immer noch.

Implementierung

Sobald das Entwicklerteam mit der Umsetzung der Architektur beginnt, ist der Softwarearchitekt mit weiteren Aufgaben gefordert. Es gilt nun die Umsetzung der Architektur zu begleiten und zu überprüfen, ob die Gesamt­lösung auch wie geplant den Anforderungen genügt.

An dieser Stelle muss der Architekt im Dialog mit allen Beteiligten immer wieder prüfen, ob es neue oder geänderte Anforderungen und Randbedingungen gibt. Er bewertet die aktuelle Architektur, wägt Chancen und Risiken ab und führt Anpassungen an der Architektur und der technischen Umsetzung durch. So führt er die Architektur Schritt für Schritt auf die gewünschte Lösung hin.

Für die Bewertung der Architektur stehen dem Softwarearchitekten verschiedene Möglichkeiten zur Verfügung. Oft werden Kombinationen von unterschiedlichen Vorgehensweisen verwendet, die aus dem gesamten Spektrum, beginnend vom subjektiven Erfahrungsschatz des Architekten bis hin zu stark formalisierten Verfahren, der Situation entsprechend ausgewählt werden.

Beratung

Neben der Kommunikation der eigentlichen Softwarearchitektur kommt dem Architekten immer die Aufgabe der Beratung zu. Auch diese Aufgabe betrifft alle Projektbeteiligten.

Dem Management und der Projektleitung steht der Architekt in Fragen der Projekt- oder Teamorganisation zur Seite. Die Teamorganisation wird z.B. nach Conways Gesetz („Wenn Sie einen Compiler durch vier Teams entwickeln lassen, werden Sie mit sehr hoher Wahrscheinlichkeit als Ergebnis einen 4-Phasen-Compiler bekommen.“) Einfluss auf die Architektur haben.

Der Betrieb wird Informationen zu Anforderungen an Hardware und Infrastruktur benötigen und Hinweise zur Inbetriebnahme, Migration und Wartung.

Das Entwicklerteam wird Unterstützung bei der Implementierung benötigen. Die Schulung bestimmter Technologien und Methoden, die Erläuterung von Einzelheiten der Architektur oder der Aufbau von Umgebungen für Tests und Migration gehören genauso, wie die Beratung bei der Wahl von Werkzeugen zu den Aufgaben des Architekten.

Nicht zuletzt ist es wichtig, dass ein Architekt in der Lage ist, die Implementierung zu unterstützen. Im Gegensatz zu der Ansicht „Architects don‘t implement“ kann der Architekt beim Entwicklungsteam großes Vertrauen gewinnen, wenn er genau weiß, was er von den Entwicklern verlangt und auch in der Lage ist, dies vorzuleben und zu unterstützen.

Fazit

Der Softwarearchitekt besitzt in einem Projekt eine zentrale Rolle. Er bildet die Schnittstelle zu allen Beteiligten. Zudem trägt er eine hohe Verantwortung für den erfolgreichen Ausgang eines Projektes und entsprechend breit ist sein Spektrum an Aufgaben und Fähigkeiten (siehe Abbildung 3).

Abb. 3: Umfeld der Softwareachitekten.

Neben seiner technischen Expertise ist besonders seine Rolle als Vermittler und Moderator hervorzuheben. Er muss zwischen unterschiedlichen Interessen ausgleichen, was nicht nur die klassischen nicht-funktionalen Qualitätsmerkmale oder Zeit- und Budget-Aspekte betrifft, sondern auch persönliche oder politische Ziele der Beteiligten.

Wegen seiner exponierten Stellung ist und bleibt ein guter Softwarearchitekt für den Erfolg eines IT-Projektes eine wichtige Grundvoraussetzung.

Im nächsten Artikel dieser Reihe werden wir betrachten, wie eine Software­architektur konkret entwickelt wird.