Was macht ein Lösungsarchitekt?

Eine der wichtigsten Personen, um gute Softwarelösungen zu erhalten, ist der Lösungsarchitekt. Das Problem in den meisten Teams und Projekten ist, dass ein wirklicher Lösungsarchitekt, also einer der den Job macht und nicht nur auf der Visitenkarte stehen hat, nicht vorhanden ist.

Im Microsoft CRM Sure Step Projekt Methodenset ist diese Person als Rolle in jedem Softwareprojekt benannt und dort findet Ihr auch die Microsoft Definition der Rolle. Ich werde dies in meinen eigenen Worten beschreiben.

Was also tut ein Lösungsarchitekt?

In einem Projekt wird er folgendes tun:

  1. Sein Framework kennen
  2. Die Anforderung des Kunden wirklich verstehen
  3. Fachkonzepte schreiben
  4. Teams koordinieren
  5. Konfliktsituationen erkennen und lösen
  6. Anwalt des Teams und des Kundens sein
  7. Ein Ruhepol im Team sein

Für kleine Softwareprojekte genügt wohl ein Lösungsarchitekt, für größere wird man mehr als einen brauchen. Jeder ist dann verantwortlich für ein Teilprojekt, eine Menge von gut teilbarer Arbeit. Gute Beispiele hierfür sind Oberflächen, Systemarchitektur und Integration von Fremdsystemen. Alle beteiligten Lösungsarchitekten müssen sich in regelmäßigen Abständen und bei Bedarf
eng abstimmen, insbesondere müssen die Schnittstellen der einzelnen Bereiche genau definiert sein, so dass klar ist, was der eine Teil vom anderen Teil geliefert bzw. liefert. Je ein Lösungsarchitekt für drei bis vier Entwickler ist eine gute Faustregel und falls es schwerfallen sollte, die Arbeit in Teilprojekte aufzuteilen, so sollte man diese funktional weiter unterscheiden, so dass sich im Bereich der Oberflächenentwicklung beispielsweise ein Team für die Benutzerinteraktion mittels Controls verantwortlich ist und ein zweites Team die Geschäftsprozesslogik implementiert.

Das ist das Fachkonzept, nicht das technisches Konzept, d.h. es spricht darüber, was der Benutzer sehen will und nicht darüber, wie die Anforderung implementiert werden soll. Ein Lösungsarchitekt kümmert sich nicht darum, wie das Entwicklerteam die Sachen intern implementiert. Der Punkt ist: das es nicht sein Job ist dies zu tun, er muss wissen was der Auftraggeber – der
Kunde – braucht und wie er es einsetzen will und er muss dafür Sorge tragen, dass das Entwicklungsteam dies umsetzen kann.

Wenn der Prozess verstanden und das Konzept geschrieben ist, muss sich der Löungsarchitekt um die Umsetzung kümmern. Er muss das Entwicklungsteam koordinieren und vor Einflüssen von innen und außen schützen, er ist der Garant für eine Kommunikation in und aus dem Team heraus. Er trifft sich mit dem Kunden zu Meetings mit anderen Teams, um etwa Schnittstellen
abzustimmen oder Tests durchzuführen. Damit dies die Entwickler nicht tun müssen und sich voll und ganz auf das Softwaredesign und die Umsetzung konzentrieren können. Dies
ist ein kreativer Prozess und es gibt mehr als ein Buch darüber, dass Entwickler in einen ‚Flow‘ kommen müssen, um wirklich effektiv zu sein. Bis diese Phase erreicht ist, vergeht schon mal eine halbe Stunde und eine Störung wirft sie immer weit zurück und frustriert diese auch. Denn Entwickler wollen Codes schreiben und sonst fast nichts.

Dies führt in der Realität des wirklichen Lebens zu Konflikten und zwar in der eigenen Organisation und auch in zum Kunden hin. Was nichts Schlimmes ist, denn Konflikte sind in unserer Gesellschaft an der Tagesordnung und ein Lösungsarchitekt muss diese Konflikte annehmen und aussitzen. Aussitzen, nein, er muss dieses lösen. ‚Konflikte erkennen und lösen‘ ist nach dem ‚echten Verstehen‘ und  ‚erstellen von Lösungsdesign‘  die dritte Kernkompetenz des Lösungsarchitekten.

Konflikte erkennen und lösen

Ohne einen Lösungsarchitekt wird es passierten, dass ein SupaDupa-Entwickler mit seiner technischen Sicht an die Lösung herangeht und ein Benutzerinterface entsteht, das für den Endbenutzer verworren bzw. nicht durchdacht ist. In die Modellierung der Softwareprozesse wird so viel Kraft und Konzentration gesteckt, dass am Ende eine Lösung entsteht, die zwar alle Fälle eines endlichen Automaten abdeckt, aber nicht mehr den Prozess, wie ihn der Benutzer benötigt widerspiegelt.

In meinem Entwicklungsteam kommen die Entwickler aus den verschiedensten Kategorien zusammen, die Pragmatiker, die Theoretiker und die Schöngeister, allen zusammen haben sie den Anspruch, gute Software (aus ihrem Blickwinkel) zu schreiben. Was sie auch tun. Wenn die Energie, die mein Team produziert, nicht kanalisiert und zielgerichtet gesteuert werden würde, hätte der
Kunde seine Software entweder ganz pragmatisch, ganz theoretisch oder ganz verspätet. Wenn aber die Energie gebündelt wird und das Team zusammen an der Lösung arbeitet, kommt in der Regel immer eine Lösung heraus, mit dem alle zufrieden sind. Die Entwickler, die Kunden, die Endbenutzer und auch der Lösungsarchitekt.

Der Lösungsarchitekt bringt sein Wissen zur Software, sein Verständnis des Kundenwillens und die Sicht der Endbenutzer mit in den Entwurfsprozess ein. Was aber viel wichtiger ist, er ist ein Diskussionspartner, der die Dinge aus einer anderen Sicht sieht und seine Meinung fachlich vertreten kann. So wird er seine eigenen Ideen zum Konzept beisteuern, die besser oder auch
schlechter als die der Entwickler sein können. Typischerweise schlägt der Lösungsarchitekt etwas für die Benutzer einfach zu verstehendes und zu benutzendes vor. Die Entwickler bevorzugen es schön bzw. einfach zu kodierend. Der Architekt sieht den Benutzer – der Entwickler den Code. In diesem Diskurs wird aus technischer und Prozesssicht und ein valides Softwarekonzept.

Damit man sicher sein kann, dass diese Diskussionen mit Respekt und auf Basis von Fakten stattfinden, müssen Lösungsarchitekt und Entwickler gleichgestellt sein. Ist der Entwickler nämlich dem Lösungsarchitekt unterstellt, so wird der irgendwann genug von der Diskussion haben und verkünden: “So, genug geredet! Jetzt machen wir das, wie ich es sage.” Sind sie gleichgestellt, kann das nicht passieren. Die Diskussion ist nur dann fair, wenn keine Seite einen unfairen Vorteil besitzt.

Der häufigste Fehler in den allermeisten Firmen ist der, dass der Chef-Programmierer das Konzept schreibt und das Produkt hoheitlich gestaltet. Warum ist dies ein Fehler? Weil die Lösung einen verkürzten und monopolisierten Weg der Entscheidungsfindung aufgesetzt bekommt. Seine Genese ist nicht aus Konflikt und Diskussion herausgekommen und kann deshalb nicht so gut sein, wie wenn mehrere Personen aus verschiedenen Disziplinen es erstellt haben.

Um als Lösungsarchitekt effektiv arbeiten zu können muss er also:

  1. Ahnung von dem was man sagt haben und
  2. bei den Entwicklern Respekt und Anerkennung haben, so dass diese auch die Ahnung anerkennen und damit dem Architekten das Rechthaben zugestehen können.

Die offene Frage ist nur noch: „Wie verdient man sich Respekt bei Programmierern?

Es ist hilfreich, wenn der Lösungsarchitekt selbst auch gut codieren kann. Allerdings ist das nicht seine Kernkompetenz. Von einem Lösungsarchitekten wird erwartet, dass er Konzepte schreibt, steuert und Konflikte löst, nicht das er Codes schreibt. Entwickler neigen dazu ihresgleichen eher zu respektieren als Nichtentwickler, ganz egal wie schlau sie sind. Ich bin der Überzeugung,
dass man auch ohne ein Code-Künstler zu sein, ein guter Lösungsarchitekt sein kann, nur ist es mühsamer, sich den Respekt der Entwickler zu verdienen.

Man kann sich alternativ den Respekt beim Entwicklerteam erwerben, indem man Intelligenz, Offenheit, und Fairness in allen Diskussionen zeigt und die fachliche und technische Welt miteinander kombinieren kann. Ein Lösungsarchitekt soll nie den Blick aufs Ganzheitliche vernachlässigen und in Lösungen denken, ein Entwickler denkt oft in Codes und Implementierungsstrategien. Wenn nun der Lösungsarchitekt die Muster der Lösungsstrategie mit der Ganzheitlichkeit der Anforderung verbinden kann, kann er auch ohne zu codieren dem Entwickler hilfreich sein und sich hierdurch den
Respekt erarbeiten.

Erzählt ein Lösungsarchitekt allerdings dummes Zeug, wird er von Entwicklern schnell als ‚Papiertiger‘ entlarvt. Wird es persönlich, die Angelegenheit emotional besetzt oder gar komplett irrational, wird man eine Menge Vertrauen verlieren, dies gilt für alle beteiligte Rollen (Personen). Aber insbesondere der Lösungsarchitekt muss in der Debatte sachlich bleiben und Willens sein, neue Erkenntnisse zuzulassen. Er muss fähig sein, eigene Fehler einzugestehen und die eigene Meinung zu ändern, wenn die Argumente das erfordern. Und schlussendlich verliert der Lösungsarchitekt das Vertrauen der Entwickler, wenn diese bemerken, dass die Architekten die Debatte mit unsachgemäßen Mitteln beenden wollen oder gar auf deren Rücken vorankommen wollen oder diese hinter
ihrem Rücken beim Kunden oder den Chefs diskreditieren. Und dies hat dann zur Folge, dass das Team in sich zerrüttet werden kann, die Motivation und Anreiz sinkt, Gutes zu machen. Die Entwickler werden sich schlussendlich ausklinken und tun, was sie sowieso am liebsten tun wollen, nämlich frei codieren. Das führt zu schlechterem Code, zu Ressourcen- und Zeitverschwendung. Deshalb kann ich Euch nur den Rat geben, authentisch zu sein und offen und ehrlich zu spielen. Denn es ist wie im guten alten wilden Westen, irgendwann hängen die Falschspieler, es ist nur eine Frage der Zeit.

Um eins nicht zu vergessen, der Lösungsarchitekt produziert auch etwas, seine Fachkonzepte, doch…

Was ist mit Fachkonzepten? Sollen die wirklich erstellt werden? Das macht uns doch nur langsamer!

Es gibt Konzepte, die schreibt man nur des Konzeptes willen und produziert da nur viel nichtssagendes Papier, das einem im besten Fall im Konflikt mit dem Kunden ‚den Arsch rettet‘. Diese ‚cover your ass stategy’ Papiere sind im Projekt unnütz und werden im besten Fall nur nicht gelesen, im schlimmsten Fall werden diese noch umgesetzt. Dies Art Konzepte zu schreiben ist meiner Meinung nach in vielen Firmen immer noch weit verbreitet, die Gegenbewegung hierzu aus der ‚extrem programming‘ Umgebung ist ohne Konzept direkt einen Code zu schreiben. Das geht bestimmt in einigen weniger komplexen Fällen und in kleinen Teams mit Entwicklern, die ein Konzept im Kopf haben. Also wenn es zur klassischen Arbeitsteilung kommt und Entwickler, Tester, Dokumentierer in Teams zusammenarbeiten müssen, braucht es ein Fachkonzept.

Das Fachkonzept ist das Herzstück jeder flexiblen Entwicklung, weil es schnelles Iterieren über viele mögliche Entwürfe erlaubt. Verglichen mit dem Programmcode ist ein schriftliches Konzept sehr leicht zu ändern. Der Vorgang des Konzeptschreibens alleine zwingt dich schon dazu, den Entwurf, von dem du glaubtest, es wäre in deinem Kopf bereits fertig, nochmal zu durchdenken. Es hilft, schnell, die Schwachstellen zu finden und durch weitere Varianten zu iterieren. Teams mit Fachkonzepten machen bessere Produkte, weil sie die Chance hatten, mehrere mögliche Lösungen zu erkunden. Sie schreiben auch ihren Code schneller, weil sie zu Beginn schon ein klareres Bild davon haben, was gebraucht wird. Fachkonzepte sind dermaßen wichtig, dass es bei euch eine strikte Regel geben sollte Kein Code ohne Konzept.

Die Art und Form des Fachkonzepts ist an sich egal. Wichtig ist, dass es alles enthält, was umgesetzt werden soll und für den der es umsetzen soll, verständlich ist. Es muss nichts (kann aber) über die Arbeitsweise des Codes, die eingesetzte Technik oder das Softwaredesign aussagen, dies ist die Domäne der Entwickler.

Ich beginne immer auf der obersten Ebene und beschreibe die Anforderung(en), definiere die Begrifflichkeiten und grenze verwandte Teilbereiche ab. Dieses bildet die Essenz für das weitere Dokument. Danach beschreibe ich den Prozess mittels eines Prozessdiagramms und erstelle ein ER Diagramm mit allen beteiligten Entitäten und deren Hauptkardinalitäten. Von Zeit zu Zeit und je nach Konzept bis auf Feldebene der Tabellen. Wenn dieses Mal zementiert ist beschreibe ich die einzelnen fachlichen Funktionen und das jeweilige Lösungsdesign. Je mit Prozess, Ursache und Wirkung. Eine Erstellung von Masken kann in manchen Projekten hilfreich sein, dies muss aber nicht immer der Fall sein. Danach beschreibe ich die Umsetzung der Lösung im Use Case Design, so dass auch komplexe Funktionalität, mit nicht direkt offensichtlichem Verhalten, gut beschrieben sind. In unserem Fall beschreiben wir noch die Möglichkeiten der Code Konfiguration und wie der Code deployt werden soll. Dies ist im klassischen Sinne allerdings kein Bestandteil eines Fachkonzeptes.

In jedem Fall und egal wie die Darstellung ist, wird der Prozess des Schreibens Probleme und Konflikte offenlegen und das lange bevor der Code geschrieben wird. Wenn die Entwicklung dann das Konzept umsetzen wird, kommt es zu weniger Überraschungen, so dass ein weitergehendes optimales Design schon vorab möglich ist und nicht durch Refactoring und Umschreiben des Codes
herbeigeführt werden muss.

Und wie wird man nun ein echter “Lösungsarchitekt”?

Ein Lösungsarchitekt zu werden besteht vor allem aus Lernen: Techniken lernen, Kommunikationsmethoden lernen, Zuhören lernen, Verstehen lernen, Menschen und Ihre Bedürfnisse verstehen und seiner Organisation effektiv handeln zu lernen.

Ein guter Lösungsarchitekt verbindet also Politik und Technik, denn zu guter Letzt werden unsere Produkte von Menschen erdacht, von Menschen benutzt, von Menschen entwickelt und von Menschen verdammt oder aber akzeptiert.

Ich hoffe, das hilft Euch und wenn es Kommentare gibt, helfen mir diese bestimmt.

In diesem Sinne

Gruß Markus

 

,

No comments yet.

Leave a Reply