Vom Entwickler zum Architekten: Teil 1

Einem erfahrenen Softwareentwickler kann es passieren, dass er im Lauf der Zeit immer mehr in die Arbeit eines Softwarearchitekten rutscht und den Übergang vom Schreiben von Code zum Design von Systemen vollzieht – zuerst für Offerten, bald aber auch in der Umsetzungsphase. So ist es auch mir ergangen. Trotz eines Informatikstudiums im Rücken fühlte ich mich in der Vergangenheit bei kniffligen Architekturaufgaben aber manchmal etwas unsicher: Mache ich das richtig? Gibt es vielleicht einen besseren Weg Architekturfragen anzupacken als den von mir eingeschlagenen? Um meine Methodik der Erstellung von Softwarearchitekturen auf eine solidere Basis zu stellen, habe ich beschlossen, mich im Rahmen eines Kurses intensiver damit auseinanderzusetzen. Meine Erfahrungen auf diesem Weg möchte ich in drei Blogposts schildern – willkommen bei Teil 1!

Folgende Fragen haben mich in den letzten Jahren als Softwarearchitekt beschäftigt:

  • Was genau umfasst eine Softwarearchitektur?
  • Was genau umfasst die Arbeit eines Softwarearchitekten?
  • Gibt es eine Methodik, der ich folgen kann?
  • Wie kann ich die Softwarearchitektur den diversen Stakeholdern im Projekt gut kommunizieren?
  • Wie kann die Güte einer Architektur gemessen werden?

Der oben angesprochene Kurs, der in meiner Zertifizierung als Softwarearchitekt ISAQB Foundation Level gipfelte, hat mir dabei geholfen, diese Fragen zu klären. Und auch Fragen, die ich mir bisher nicht gestellt hatte (aber besser hätte sollen). Im Vorfeld des Kurses hatte ich mich intensiv mit dem Buch «Effektive Softwarearchitekturen – Ein praktischer Leitfaden» von Dr. Gernot Starke auseinandergesetzt. Da mein Informatikstudium bereits ein paar Jahre zurückliegt, kam das Studium dieses Buches gelegen, um festgefahrene Mechanismen und Meinungen meinerseits zu hinterfragen und aufzubrechen.

Architektensicht: Der Blick auf das grosse Ganze

Die Gretchenfrage

Beginnen wir mit der Gretchenfrage: Was ist Softwarearchitektur?

In erster Linie unterstützt die Architektur den herausfordernden Übergang von der Problemanalyse zur konkreten technischen Lösung. Schliesslich wird ein zu implementierendes System basierend auf seinen Komponenten und deren Beziehungen untereinander beschrieben. Wichtig ist, dass Architektur weit mehr ist als das Skizzieren einer technischen Lösung! Eine gute Architektur ermöglicht:

  • Herr werden über Einflüsse: Neben den funktionalen Anforderungen wird die Architektur unter anderem auch von Budget, Qualitätsanforderungen (auch «nicht-funktionale Anforderungen» genannt), organisatorischen Randbedingungen, rechtlichen Vorgaben oder gar von Politik beeinflusst. Softwarearchitektur kann diese Einflüsse aufzeigen und behandeln.
  • Herr werden über Komplexität: Architekturen dienen dazu, komplexe Anforderungen explizit zu machen und sie in umsetzbare Strukturen zu übersetzen.
  • Effektive Kommunikation: Architektur kann technische Systeme aus verschiedenen Blickwinkeln («Sichten») zeigen und hilft so allen Beteiligten, verständlich und wirksam miteinander über ein System zu sprechen. Diesem Thema widme ich Teil 2 dieser Blogserie.
  • Iterative Verbesserungen: Eine Softwarearchitektur entsteht iterativ und somit begleitend zur eigentlichen Entwicklung des Systems. Entscheidungen, die zu Beginn des Projektes gefällt wurden, sollen während der Umsetzung kritisch hinterfragt und gegebenenfalls angepasst werden.
  • Ziele im Blick behalten: Die Architektur eines Systems soll langfristige Ziele abbilden und mögliche Zielkonflikte mit (eher kurzfristigen) Projektzielen auflösen.
  • Unterstützung des Lebenszyklus: Richtig angegangen unterstützt Architektur den gesamten Lebenslaufs eines Systems: Von der Anforderungsanalyse über Entwicklung bis zum Betrieb von Systemen.

Nun da wir eine Idee davon bekommen haben, was Softwarearchitektur ist: Was ist denn die Rolle des Architekten? Softwarearchitekt zu sein bedeutet viel mehr, als nur Anforderungen des Kunden in eine geeignete technische Struktur abzubilden und dann den Entwicklern die Umsetzung zu überlassen.

Folgende Grafik zeigt die wesentlichen Aufgaben des Softwarearchitekten.

Stacks Image 114

(Quelle: Arc42)

Von der Wichtigkeit des breiten technischen Portfolios

Der Architekt klärt die Anforderungen und Randbedingungen und giesst diese in ein System, indem er Strukturen (Komponenten und ihre Beziehungen) sowie querschnittliche Konzepte entwirft und festhält. Er kommuniziert die Architektur gegenüber den relevanten Stakeholdern – zum Beispiel dem Product Owner, dem Entwicklungsteam, der Projektleiterin, dem Testteam, dem Betreiber etc.) – und begleitet die Umsetzung. Die Pfeile in der obigen Grafik signalisieren, dass es sich um einen agilen Prozess handelt. Ein Softwarearchitekt ist also nicht «nur» ein «Techie», er ist auch Vermittler zwischen den Stakeholdern. Im Endeffekt verantwortet er das System, das umgesetzt wird. Dieser Umstand setzt mich etwas unter Druck: Kenne ich

genügend gut, um stets zur richtigen Entscheidung zu gelangen? Nützlich ist hier der Aufbau eines eigenen breiten technischen Portfolios, das man im Sinn des persönlichen Wissensmanagements stetig erweitert (was bei EBP angesichts der Fülle unserer Projekte gut gelingt). Meines dokumentiere ich vorzu in Form eines Mindmaps.

Das ewige Balance-Spiel: Ausgleich von Zielkonflikten

Darüber hinaus stellt sich immer die Frage, ob man mit seinen Architekturentscheidungen allen Anforderungen und Rahmenbedingungen gerecht wird. Folgendes Zitat von Philippe Kruchten bringt das bisweilen herrschende Gefühl etwas düster auf den Punkt:

«The life of a software architect is a long and rapid succession of suboptimal design decisions taken partly in the dark».

Offenbar bin ich nicht alleine mit meinen Sorgen! Zeit, diese zu teilen: Softwarearchitektur darf nicht im stillen Kämmerlein entstehen. Wenn Sie mit Architekturfragen betraut sind: Beziehen Sie die wesentlichen Stakeholder früh in den Prozess mit ein – etwa die (Senior-)Softwareentwickler und -entwicklerinnen, an die Sie technische Abklärungen delegieren. Holen Sie rechtzeitig Feedback ein von den Security-Profis und den Betriebsspezialisten. Diese und ähnliche Schritte steigern meiner Erfahrung nach die Qualität von Entscheidungen massgeblich. Und sie sorgen gleichzeitig dafür, dass das Wissen im Projekt besser verteilt und somit ein gängiges Projektrisiko eliminiert ist.

Next up: In Teil 2 meiner Blogserie möchte ich gezielt auf ein weiteres Kästchen im obigen Bild eingehen, nämlich auf das Kommunizieren der Architektur.

Modernes Wissensmanagement

In unserer scheinbar immer schnelleren Wissensgesellschaft wird die Aufnahme von Information, Lernen und das Umsetzen von Wissen immer wichtiger. Zu diesem Thema lese ich manchmal Beiträge über die Personal Knowledge Mastery (PKM)-Konzepte von Harold Jarche. In diesem Blogpost möchte ich kurz auf Wissensmanagement generell und als Beispiel auf das PKM-Konzept eingehen.

Wieso Wissensmanagement?

Wissensmanagement bezeichnet die positive Beeinflussung der Wissensbasis einer Person oder einer Organisation. Im Fall einer Person spricht man auch vom „persönlichen Wissensmanagement“, im zweiten Fall vom „organisatorischen Wissensmanagement“.

Wissen soll nicht in Karteikästchen verschwinden

Wissen ist zunehmend ein wichtiger Produktionsfaktor. Das organisatorische Wissensmanagement kümmert sich deshalb darum, das individuelle Wissen, das in einer Firma, Behörde, Verwaltung oder Verein bei den einzelnen Personen vorhanden ist, nachhaltig in der Organisation zu verankern. Dabei wird oft zwischen explizitem und implizitem Wissen unterschieden – die unterschiedlich angegangen werden müssen:

  • Explizites Wissen ist niedergeschrieben bzw. kann niedergeschrieben werden, beispielsweise in Handbüchern oder Handlungsanweisungen. Hier muss Wissensmanagement geeignete Prozesse und Verantwortlichkeiten definieren und Gefässe finden für das Festhalten von Wissen (people-to-document), um so zum Beispiel Gatekeeping (dass eine Information nur bei einer Person vorhanden ist und diese bei Bedarf stets danach gefragt werden muss) möglichst zu minimieren.
  • Implizites Wissen ist Wissen, das nicht (richtig) verbal vermittelt werden kann (auch: tacit knowledge, also stilles Wissen). Gute Beispiele sind das Wissen, wie man velofährt oder wie man Schuhe schnürt. Die Methoden für explizites Wissen können bei implizitem Wissen nicht greifen. Hier geht es stattdessen häufig darum, die richtigen Massnahmen zu finden, um zwischenmenschliche Lernprozesse zu fördern (people-to-people).

Grundlegender Baustein: Persönliches Wissensmanagement

Das persönliche Wissensmanagement steht unterhalb der systemischen Sicht der Organisation. Es ist aber natürlich notwendige Voraussetzung für gelungenes organisatorisches Wissensmanagement. Besonders klar wird dies gerade anhand des bereits erwähnten PKM-Konzepts von Harold Jarche. Er definiert PKM als „a set of processes (…) to help each of us make sense of our world and work more effectively.“

Ein wichtiger Baustein dieses Konzepts ist das Framework Seek > Sense > Share:

Seeking is finding things out and keeping up to date. Building a network of colleagues is helpful in this regard. It not only allows us to “pull” information, but also have it “pushed” to us by trusted sources. Good curators are valued members of knowledge networks.

Sensing is how we personalize information and use it. Sensing includes reflection and putting into practice what we have learned. Often it requires experimentation, as we learn best by doing.

Sharing includes exchanging resources, ideas, and experiences with our networks as well as collaborating with our colleagues.

Betrachten wir persönliches Wissensmanagement durch diese Brille, ist es keine rein individuelle Aufgabe: Für Seeking benötigen wir gute soziale Netzwerke (reale und virtuelle) – also Netzwerke, die beim Lernen für Aufgaben unterstützen. Aus einem gut kuratierten Netzwerk kann eine Person wertvolle Informationen selber extrahieren (Pull-Prinzip) aber auch erhalten, etwa wenn ein Partner im Netzwerk die Person auf etwas aufmerksam macht, das für diese relevant ist (Push-Prinzip). Gutes persönliches Wissensmanagement braucht also gute soziale Vernetzung.

Sensing umfasst die Verinnerlichung, Reflexion und Anwendung von neu erschlossenem Wissen. Dieser Prozess benötigt Zeit, Freiräume und Gelegenheiten, das Wissen anzuwenden. Auch Sensing kann neben der individuellen Ebene eine soziale Dimension haben: Reflexion und Beüben neu erworbenen Wissens können zum Beispiel im Team geschehen.

Sharing bezeichnet die Weitergabe und den Austausch von Ressourcen rund um Wissen und bildet den Abschluss des Frameworks. Auch beim Sharing ist die Einbettung des Wissensmanagements und des Lernens in soziale Strukturen wieder wichtig. Hier wird Wissen im Austausch mit anderen gefestigt, und man lernt neue Sichtweisen, Ideen und Ressourcen kennen.

Hin zur intelligenten Organisation

Gemäss Harold Jarche sind die Schritte Seeking, Sensing und Sharing besonders in innovativen interdisziplinären Settings (wie zum Beispiel EBP eines ist) besonders wichtig:

The multiple pieces of information that we capture and share can increase the frequency of serendipitous connections, especially across organizations and disciplines where real innovation happens.

Aus diesen Betrachtungen lassen sich zum Beispiel entlang der folgenden Fragen Handlungsempfehlungen für intelligente Organisationen oder solche, die es werden wollen, erarbeiten (hier mit einem technischen Fokus):

  • Wie kann eine Organisation das organisatorische und das persönliche Wissensmanagement gewinnbringend miteinander verknüpfen? Wie kann eine Organisation das persönliche Wissensmanagement der Mitarbeiterinnen und Mitarbeiter fördern und so die Grundvoraussetzungen für ein effizientes und effektives Organisations-Wissensmanagement legen?
  • Welche Tools gibt es, die beim organisatorischen und persönlichen Wissensmanagement (z.B. mit dem Modell Seeking, Sensing, Sharing) unterstützen können? Wäre zum Beispiel Slack für meine Organisation gut geeignet? Weshalb nicht bzw. weshalb? Für welche Anwendungen, Informationen und Rollen in der Organisation?
  • Wie setze ich diese Tools passend zum jeweiligen Wissen und Kontext ein? Welches Wissen kann ich Zeitschriften, Fachtagungen oder Expertengesprächen entnehmen? Welche anderen Kanäle sind für meine Organisation, meine Aufgabe, mein Fachgebiet relevant?
  • Welches Wissen und welche Erfahrungen teile ich beispielsweise in einem Enterprise Social Network wie Yammer? Worüber schreibe ich einen Artikel in der internen Zeitschrift oder im internen Wiki? Was teile ich mit einer Fachgruppe auf LinkedIn, Xing oder einem anderen virtuellen sozialen Netzwerk? Worüber spreche ich mit Kolleginnen und Kollegen im Rahmen eines Erfahrungsaustauschs?

Allesamt spannende Fragen, die sich in unserer Zeit alle Organisation stellen sollten. Falls Sie sich für diese Themen interessieren, unterstützen wir Sie gerne.