Bevor wir aber in dieses Thema einsteigen, möchte ich die Begriffe kompliziert und komplex klären. Das wird uns später helfen, die Rolle der Software- oder IT-Architektur in größeren Projekten zu verstehen. Meine Erläuterungen basiere ich auf dem bekannten Cynefin Framework des britischen Forschers Dave Snowdon.

Kompliziert

Kompliziert (lateinisch complicare, „zusammenfalten“ im Sinne von „verwickelt“)

Komplizierte Systeme bestehen aus vielen Teilen oder Details - deren Zusammenwirken wir aber konkret und exakt vorhersagen. Eine Nähmaschine besteht aus vielen Einzelteilen und Wirkzusammenhängen, ihr Verhalten können wir sehr präzise vorhersagen. Den Umgang mit komplizierten Systemen können Menschen anhand von Regeln und vorgegebenen Handlungsvorschriften erlernen.
Beispiele solcher Systeme sind:

Für den Umgang mit komplizierten Systeme genügen feste Regeln und Prozesse.

Abbildung 1: Kompliziertes mechanisches System mit Zahnrädern und Achsen, generiert von midjourney
Abbildung 1: Kompliziertes mechanisches System mit Zahnrädern und Achsen, generiert von midjourney

Frühe Software- oder IT-Systeme waren häufig kompliziert, d.h. wir konnten deren Verhalten ziemlich präzise vorhersagen [1]. Nehmen Sie einfache Algorithmen wie QuickSort oder Single-User CRUD-Anwendungen als Beispiel.

Komplex

Richtig - auch kompliziert kann schon ganz schön schwierig sein, aber es geht noch wesentlich schlimmer:

Komplexität (lateinisch complexum) bezeichnet das Verhalten eines Systems mit vielen Elementen, deren Wirkzusammenhänge oft nicht deterministisch und vorhersehbar sind. Das Verhalten solcher Systeme ist kaum vorhersehbar.

Quellen: Wikipedia, Cynefin

Das Gesamtverhalten eines komplexen Systems können wir nicht aus der Summe der Einzelverhaltensweisen vorhersagen. Ergebnisse komplexer Systeme sind daher oft nicht wiederholbar. Komplexe Systeme sind gekennzeichnet von Unvorhersehbarkeit und (scheinbar) zufälligen Einflüssen.

Betrachten wir als Beispiele Finanzmärkte, Ökosysteme oder das mittelfristige Wetter: Für keines davon können wir deterministisch (im Sinne einer Formel) belastbare und konkrete Vorhersagen für die Zukunft machen. Trotz viel Erfahrung und Aufwand können wir für komplexe Systeme höchstens Näherungswerte für zukünftige Zustände ermitteln. Feste Regeln oder Prozesse scheitern hier. Es helfen kurze Feedbackzyklen, Heuristiken und Erfahrung.

In Tabelle 1 fasse ich die wesentlichen Charakteristika komplizierter und komplexer Systeme zusammen und stelle diese gegenüber.

Für komplexe Systeme benötigen wir Erfahrung, Heuristiken und vor allem Feedback.

Kompliziert Komplex
Viele Einflussfaktoren  Viele Einflussfaktoren
Stabile, lineare Beziehungen Dynamische, nicht lineare Beziehungen
Ursache-Wirkung-Beziehungen sind nicht-trivial, aber deterministisch und verständlich. Keine unbedingt wiederholbaren Ursache-Wirkung-Beziehungen
Berechenbar, deterministisch Nicht berechenbar, nicht deterministisch,
Planbar Nicht planbar

Tabelle 1: Kompliziert versus Komplex [2]

Wozu helfen uns diese Begriffe beim Verständnis der Rolle von Softwarearchitektur?

In größeren Projekten/Systemen lauert Komplexität

Abbildung 2: Yoda jongliert im Regen mit vielen Objekten, generiert mit midjourney
Abbildung 2: Yoda jongliert im Regen mit vielen Objekten, generiert mit midjourney

Größere Software- oder IT-Projekte mit mehreren Beteiligten erweisen sich als komplexe Systeme mit sehr geringer Planbarkeit. In solchen Systemen müssen die Architekt:innen oftmals viele Faktoren gleichzeitig berücksichtigen, ohne die Konsequenzen ihrer Entscheidungen exakt berechnen oder konkret planen zu können. In Abbildung 3 (inspiriert von Uwe Friedrichsen aus [3]) zeige ich schematisch, dass IT-Projekte heutzutage eher komplexer Natur sind, natürlich mit Sprenkeln von Kompliziertheit: In typischen IT-Projekten gibt es in der Regel Aufgaben, die wir mit schematischem Vorgehen zuverlässig lösen können. Leider halt auch andere…

Abbildung 3: IT-Projekte waren früher eher kompliziert, heute sind sie eher komplex, nach Uwe Friedrichsen
Abbildung 3: IT-Projekte waren früher eher kompliziert, heute sind sie eher komplex, nach Uwe Friedrichsen

Architektur enthält Unsicherheit

Architekt:innen größerer (und damit komplexerer) Systeme haben mit erheblichen Unsicherheiten und Unwägbarkeiten zu tun. Der Begriff Größe bezieht sich dabei nicht nur auf den rein technischen Umfang (etwa: Lines of Code) von IT-Systemen, sondern auch auf weitere Elemente, beispielsweise:

Abbildung 4: Die Menge an Unsicherheit steigt mit der Größe von Systemen
Abbildung 4: Die Menge an Unsicherheit steigt mit der Größe von Systemen

Erstellen wir eine Zwischenbilanz:

In größeren (komplexeren) Systemen müssen Sie als Architekt:in Entscheidungen unter erheblicher Unsicherheit treffen. Ihre Arbeit besteht in hohem Maße aus der Balance vieler Einflußfaktoren, von denen Sie nur wenige nach Schema-F behandeln können.

Klingt schwierig, was tun?

Korrekt, das klingt alles schwierig, und vermutlich auch schwammig.

Für eher einfache (also lediglich komplizierte) Systeme hatten wir in Folge 3 dieser Serie die Aufgaben der Softwarearchitektur erläutert.
Zur Erinnerung finden Sie die in Abbildung 5 noch einmal. Als Ergänzung habe ich in dieser Version allerdings die Stellen markiert, an denen besondere Risiken für Komplexität drohen. Mehr Farbe bedeutet auch mehr Risiko.

Abbildung 5: Architekturaufgaben, wiederholt aus Folge 3
Abbildung 5: Architekturaufgaben, wiederholt aus Folge 3

Zum Glück haben wir in der IT seit einigen Jahren ein probates Mittel zum Umgang mit solchen schwierigen Situationen gelernt und erprobt, nämlich schnelles Feedback und adaptives Verhalten. Sollten Sie als Architekt:in in einem komplexen Entwicklungsvorhaben stecken, und darin wichtige Entscheidungen treffen müssen, dann:

Insgesamt sollten Sie in solchen Projekten proaktiv arbeiten, und sich eher als Unternehmer:in denn als Befehlsempfänger:in sehen. Der Anteil kommunikativer Tätigkeiten steigt gegenüber einfachen Projekten erheblich an. Gehen Sie davon aus, dass für’s reine Coding keine Zeit mehr bleibt: Das ist ja primär eine komplizierte Aufgabe, die Sie delegieren können.

Fazit

Ein steiniger Weg führt von kleineren (aka komplizierten) zu den ganz großen (aka komplexen) Systemen oder Projekten. Sie brauchen dazu erheblich mehr kommunikative (aka Soft-) Skills, Empathie und Durchsetzungsvermögen bei sehr unterschiedlichen Stakeholdern Kenntnisse in Diplomatie, Unternehmenspolitik, Projektmanagmeent, Enterprise-Architekture-Management und Requirements-Engineering helfen weiter, ebenso ein fundierter Überblick aktueller und weniger-aktueller Technologien[5]. Als Belohnung winken große Verantwortung und erheblicher Einfluss auf langfristige Projekt-/Architekturentscheidungen. Nachteil: Ihr Kontakt zu konkretem Source-Code beschränkt sich in solchen Rollen vermutlich auf Ihre (spärliche) Freizeit.

In diesem Sinne - möge auch im Großen die Macht kluger Entscheidungen mit Ihnen sein.

Danksagung

Danke an Gerrit Beine für Inspiration, „m“ für gründliches Review.

Quellen

  1. Für die ganz exakten Zeitgenoss:innen: Ja, auch ich kenne die Unentscheidbarkeit des Halteproblems.  ↩

  2. Dave Snowdon: Cynefin Framework. Konzeptionelles Framework zur Entscheidungsunterstützung, unterscheidet fünf Kategorien (Klar, Kompliziert, Komplex und Chaotisch, Konfus), und versucht für diese Entscheidungshilfen zu geben. Kompakte Einführung bei Wikipedia, Original auf https://thecynefin.co  ↩

  3. Uwe Friedrichsen: Komplexität – Na und?  ↩

  4. Gregor Hohpe nennt das Architecture Elevator, und bezeichnet die oberen (Management–) Ebenen als das Penthouse, und die reine Technik als den engine room. Persönlich finde ich fürs Management die Bezeichnung Board Room treffender. Wesentlich: die starke Abstraktion von konkreter Technik, und der enge Bezug zum Business.  ↩

  5. Falls Sie jetzt an die schöne Metapher der „eierlegenden Wollmilchsau“ denken, willkommen. Mir ist auch klar, dass ein solch breites Spektrum an Kenntnissen und Fähigkeiten sehr selten ist, aber was davon wollen Sie weglassen? Falls Ihnen selbst noch einiges davon fehlt, arbeiten Sie auch in größeren Systemen doch als eine kleine Gruppe von Architekt:innen zusammen, in der Folge 4 dieser Serie habe ich unter dem Namen „Architecture Agents“ dazu einen Vorschlag unterbreitet.  ↩

Mehr zum Thema Softwarearchitekturen? Wir bieten ein 3-Tages-Training an.

iSAQB® Training buchen

TAGS