Die Veranstaltung richtet sich an ein internationales Publikum, so dass alle Vorträge auf Englisch gehalten wurden – auch wenn sicherlich ein Großteil der Teilnehmer als auch Redner deutschsprachig waren. Zielgruppe sind primär Softwarearchitekten – von denen das iSAQB laut eigener Aussage übrigens seit 2008 schon 30.000 zertifiziert hat.

Die Agenda umfasste ca. 45 Programmpunkte, darunter 4 Keynotes, 8 Workshops und 33 Vorträge. Die Workshops fanden am ersten und letzten Tag statt, während Keynotes morgens und abends an den mittleren Tagen gehalten wurden. Die parallelen Vortrags-Tracks machten einen Besuch aller Vorträge unmöglich, unsere zweiköpfige Präsenz erlaubte uns aber eine recht gute Abdeckung.

Ein inhaltlicher Blick auf die Agenda der Konferenz zeigt eine bunte Mischung an Themen, wobei “Künstliche Intelligenz” (KI) – oh Wunder – dieses Jahr dominierte. 8 Vorträge oder 18 % des Programms beschäftigten sich explizit mit KI. Indirekt kam das Thema sogar in fast der Hälfte der Vorträge vor. Das Top-Thema der vergangenen Dekade – Microservices – ist mit nur noch 4 ausdrücklichen Erwähnungen in der Agenda damit vom Thron gestoßen, obwohl sie auch noch in mindestens drei weiteren Sessions, in denen sie zwar nicht im Titel aufgeführt waren, thematisiert wurden. Agile und DevOps sowie Security waren mit jeweils 4 bzw. 3 Vorträgen vertreten. Abgerundet wurde das Programm durch Themen wie bspw. Legacy-Modernisierung oder Teamstrukturen im Umfeld Softwareentwicklung.

Der Kreis der Vortragenden bot wenig Überraschungen, es handelte sich um eine Mischung aus Vertretern der Industrie sowie Beratung und den “üblichen Verdächtigen” der Szene wie z.B. Carola Lilienthal, Gernot Starke, Eberhard Wolff, Michael Plöd, Rebecca Parsons oder Uwe Friedrichsen.

Vorträge

Die erste Keynote von Dr. Gernot Starke, „Tiger Alert: Better Run Away!“ [2], begann vielversprechend, entpuppte sich jedoch größtenteils als Zusammenfassung von Daniel Kahnemanns bekanntem Buch „Thinking, Fast and Slow“. Obwohl die Zusammenfassung gut präsentiert und mit zusätzlichen Quellen angereichert war, fehlte uns hier neben der Aktualität der Bezug zur Softwarearchitektur. Kahnemanns Werk ist zweifellos wertvoll, aber auf einer Konferenz, die sich an Softwarearchitekten richtet, hätten wir uns mehr Transferleistung, also Einblick in die Anwendung dieser Konzepte auf Herausforderungen in unserem Bereich gewünscht.

Als ein mögliches Beispiel könnten wir hier die Schwachstelle CWE-1007 [3] aufzeigen, bei der Anwender, und dazu zählen in diesem Fall auch Entwickler und Architekten, durch visuell ähnliche Zeichen in die Irre geführt werden. Hierbei wird einem nicht das berühmte X für ein U, sondern bspw. eine Null für ein “O” oder das lateinische „e“ für das zum Verwechseln ähnliche kyrillische „е“ vorgemacht. Kahnemans System 1, die Intuition bzw. der Autopilot schlagen hier zu und wir klicken als Anwender auf die gefälschte URL, wodurch z.B. ein Trojaner heruntergeladen wird. Als Entwickler wird uns im Sourcecode so bspw. eine ähnlich lautende Methode mit anderer Funktionalität untergeschoben. Was kann ich als Softwarearchitekt dazu beitragen, damit so etwas nicht passiert? Bspw. darauf hätten wir uns als Teilnehmer dieses Vortrags Antworten erhofft.

Als nächsten Vortrag haben wir uns “Generative AI Meets Software Architecture” von Lars Röwekamp [4] angeschaut. Über Fragen der Modellauswahl und -integration sowie Grundlegendem zum Prompting führt der rote Faden hier zielgerichtet zum Thema Retrieval Augmented Generation (RAG) um aktuelles und Domänen-spezifisches Wissen in GenAI-Abfragen zu integrieren.

Für Anfänger im Umfeld Integration von GenAI, an die sich dieser Vortrag richtet, gab er einen durchaus interessanten Überblick.

Ein für uns interessanter, aber unbestätigter Fakt aus dem Vortrag besagt, dass der Bau der großen Large Language Modelle rund 50 Millionen USD alleine an Rechenkapazitäten kosten soll. Was aber erklären würde, warum die unserer Wahrnehmung nach oft leichtfertig dahin gesagte Aussage „Dann bauen wir eben unser eigenes Modell“ in der Praxis für die meisten Unternehmen absehbar nicht umsetzbar sein wird – und es wohl beim RAG bleibt.

Unser Fazit – aus dem Vortrag, aber auch allgemein zum Thema:

• GenAI ist mächtig – aber teuer.
• (Gutes) Prompting ist der Schlüssel.
• Jedes Modell hat seinen eigenen Charakter.
• RAG, um Domänenwissen einzubinden und aktuell zu bleiben.
• GenAI ist auch nur Software – behandle sie auch so.
  

Sowohl inhaltlich als auch hinsichtlich des Anspruchsniveaus (“Intermediate”) anschließend, war dann Robert Glasers “The Architecture of Reliable AI: RAG” [5]. Wenn auch technisch detaillierter hergeleitet, lautet aber auch seine Aussage, dass RAG das Mittel der Wahl für GenAI im Unternehmenseinsatz ist: “Put everything in the prompt”. Hier kommen allerdings die Begrenzungen der verschiedenen Modelle zum Tragen. Was u.a. erklärt, warum ich nicht einfach mein ganzes Unternehmens-Intranet in jede meiner GenAI-Abfragen packen kann, sondern relevante sogenannte Chunks finden (“retrieve”) muss, um die ich meine Abfrage (“Prompt”) erweitere (“augment”).

Für das Retrieval setzt der Redner auf einen hybriden Ansatz aus klassischer Volltextsuche (für spezifische Anfragen) und Vector-Suche mit Embeddings (für allgemeine Anfragen), deren Funktionsweisen er jeweils gut erläutert. Die Vorteile der Vector-Suche liegen demzufolge darin, dass sie immer Ergebnisse liefert, diese nach Ähnlichkeit sortiert, sprachübergreifend aufgrund semantischer Ähnlichkeit funktioniert und relevante Inhalte trotz unterschiedlicher Formulierungen findet. Ergänzt wird dies durch die klassische Volltextsuche, die insbesondere die Unschärfe in vektorbasierten Ergebnissen ausgleichen soll.

Das Ganze wird an einem Beispiel aus dem Leben eines Softwarearchitekten (“Wie kam es zu der Architektur unseres Online-Shops?”) durchgängig verdeutlicht – in Summe also ein runder Vortrag.

Technischer wurde Allard Buijze in seinem Vortrag “Event Sourcing – Technical Detail or Architectural Powerhorse?” [6]. Nun ist Event Sourcing kein ganz neues Pattern, Martin Fowler erwähnt es bspw. bereits 2005 [7], wir nehmen es in deutschen Softwareorganisationen seit rund 10 Jahren vermehrt wahr. Somit ist der Ansatz aber etabliert genug, um aus Softwarearchitektursicht zu hinterfragen, ob es sich dabei eher um ein zu vernachlässigendes Implementierungsdetail handelt oder er sich vielleicht doch zum Allzweckmittel (“Zugpferd”) des modernen Softwarearchitekten gemausert haben könnte.

In dem Vortrag wurde über eine historische Einordnung des Themas den Anwesenden zunächst der Spiegel vorgehalten. So hat sich sicherlich jeder Softwarearchitekt schon mal dazu hinreißen lassen, einer klassischen Mehrschichtarchitektur einfach eine weitere Abstraktionsschicht hinzugefügt zu haben, um das gerade anstehende Problem “elegant”, also schnell, gelöst zu bekommen. Meist dauert es dem Redner zufolge dann nicht lange und es werden in den Schichten Caches aufgebaut, um die – durch die vielen Schichten langsamer werdenden – Zugriffe wieder zu beschleunigen. Am Ende entsteht auch so dann doch wieder der gern zitierte Big Ball of Mud der Softwareentwicklung, für den es auch in diesem Vortrag ein schönes Bild gab:

Die Umsetzung von Änderungen an der Software werden bei diesem Architekturstil also zwangsläufig über die Zeit länger dauern. (Etwas) Besserung kam dann mit Domain-Driven Design (“DDD”) [8] ins Spiel:

Im weiteren Verlauf des Vortrags wurden dann Event-Sourcing und die dazugehörigen Konzepte wie Event-Streaming, CQRS, Messaging, etc. und insb. ihre Vorteile wie z.B. Testbarkeit, Skalierbarkeit, einfache Anpassung an veränderte Business-Anforderungen (insb. in Kombination mit DDD) ausführlich dargestellt. Nicht ganz verwunderlich, da er Gründer und CTO einer Softwarefirma für Tools zum Event Sourcing ist, kommt der Redner zum Schluss des durchaus guten Vortrags zu der Erkenntnis, dass Event Sourcing sowohl Implementierungsdetail als auch Allzweckmittel für Softwarearchitekten sei.

Wir sehen die Vorteile von Event Sourcing und kennen auch zahlreiche erfolgreiche Implementierungen, sehen aber auch deren Komplexität und wissen, dass sie nicht immer passen, sondern es, wie so oft, auf den Use Case ankommt.

Gregor Hohpe hat in seiner Keynote „Architects Aren’t the Smartest People in the Room“ [9] einen Nerv bei uns getroffen. Wir stören uns schon länger daran, dass ein guter Softwarearchitekt laut manchen Quellen so etwas wie der mysteriöse Superheld eines jeden IT-Projekts ist. So soll dieser (laut ChatGPT) über

• technische Fähigkeiten von Programmierkenntnissen, über Designprinzipien, Cloud- und Sicherheitsarchitekturen, DevOps und CI/CD bis hin zu Expertise in Datenbank-Systemen (natürlich relational wie auch non-relational) und Schnittstellendesign,
• analytische und Problemlösungsfähigkeiten, insbesondere natürlich Komplexitätsmanagement und Abstraktionsvermögen,
• Kommunikations- und Sozialkompetenzen, wie etwa Präsentations- und Moderationsfähigkeiten, Verhandlungskompetenzen, Erfahrungen im Stakeholdermanagement sowie idealerweise auch Führungserfahrung,
• strategische Kompetenzen sowie
• Expertise in agiler sowie klassischer Projektmanagementmethodik

verfügen. Natürlich hätten wir alle gerne nur solche Kolleginnen und Kollegen in unseren Projekten, jedoch ist diese Beschreibung wenig hilfreich, um das ohnehin schon überladene Bild eines Software Architekten [10] besser einzugrenzen.

Gregor Hohpe hat sich in seinem Vortrag nun in gewohnt launiger und kurzweiliger Art mit genau diesem Punkt beschäftigt. Wie bereits der Titel angibt, seien Architekten hierbei nicht die schlauesten Personen im Raum. Im Gegenteil: Es sei genau die Kernaufgabe eines Architekten, sein Umfeld smarter zu machen.

Hierzu stehen einem guten Architekten verschiedene Werkzeuge zur Verfügung, beispielsweise über Abstraktion oder Analogien (Gregor selbst liebt Analogien zu Automotoren), komplexe technische Fragestellungen diskutier- und entscheidbar zu machen. An dieser Stelle wurde der Vortrag für unseren Geschmack ein wenig generisch / oberflächlich, was aber für eine Keynote, die ein möglichst großes Publikum ansprechen soll, absolut im Rahmen war.

Insbesondere ein Prinzip ist uns lebhaft im Gedächtnis geblieben, vermutlich weil wir uns auch ein wenig ertappt gefühlt haben: “Don’t dumb things down”. Laut dem Redner gehören Top-Entscheider oftmals zu den am besten ausgebildeten, intelligenteren sowie hochmotivierten Personen innerhalb eines Unternehmens. Trotzdem neigen IT-Experten dazu, Zusammenhänge im Austausch mit IT-fremden Entscheidern sehr stark zu vereinfachen. Dass sie hierbei wirklich, wie humorvoll angemerkt wurde, beginnen besonders langsam zu sprechen, wenn eine Erklärung beim ersten Mal nicht verstanden wird, haben wir zwar noch nicht beobachten können, aber der Quintessenz, dass man diesem Gegenüber durchaus eine gewisse Komplexität zutrauen kann und es unsere Aufgabe als Architekten ist, sie genau zu dieser Diskussion zu befähigen (bspw. mit Abstraktion und Analogien), stimmen wir absolut zu.

Fazit

Dies war nur ein Auszug einiger der von uns besuchten Vorträge auf dem iSAQB Software Architecture Gathering 2024, welche unserer Einschätzung nach aber einen guten Eindruck von der Konferenz geben.

Durch die Corona-Pandemie sicherlich erzwungenermaßen, aber auch thematisch war es die vergangenen Jahre recht ruhig rund um Softwarearchitektur. Der ”KI”-Hype bietet unserer Zunft hier nun nach längerer Zeit wieder mal ein echtes Thema – “KI” ist schließlich auch “nur” Software – was es architekturell zu verstehen gilt. Echte Neuheiten bot die Konferenz in dem Umfeld allerdings nicht, durchgängiges Thema war Retrieval Augmented Generation (“RAG”), welches hier als das Mittel der Wahl beim Unternehmenseinsatz von generativer “KI” besprochen wurde – aber tatsächlich auch schon seit über einem Jahr diskutiert wird:

Das iSAQB Software Architecture Gathering bietet insgesamt eine gute Gelegenheit, sich einen umfassenden Überblick über aktuelle Themen und Trends im Bereich der Softwarearchitektur zu verschaffen. Allerdings hätten wir uns eine größere inhaltliche Vielfalt gewünscht – insbesondere bei tiefergehenden Formaten. Stellvertretend dafür steht die Tatsache, dass das Veranstaltungsprogramm ausschließlich Vorträge und Workshops der Kategorien „Beginner“ und „Intermediate“ umfasste.

Trotzdem ist das Gathering eine wertvolle Plattform für Softwarearchitekten verschiedener Erfahrungsstufen. Wir sind gespannt darauf, wie sich die Konferenz in den kommenden Jahren weiterentwickeln wird.

Michael Schwarze

Geschäftsführer

Michael ist ein erfahrener Softwareentwickler, -architekt und -manager mit über 30 Jahren Erfahrung in der Technologiebranche. Er hat sowohl in Startups als auch Konzernen auf Anwender- als auch Entwicklungs- und Beratungsseite gearbeitet.  Coden ist für ihn nicht nur Beruf, sondern Leidenschaft, am liebsten mit dynamisch-typisierten Sprachen wie Ruby. Neben der Entwicklung langlebiger Softwaresysteme liegt ihm auch die Verbesserung des Managements in der Softwareentwicklung am Herzen. Wenn er nicht gerade mit seiner Familie und seinen zwei Kindern beschäftigt ist, findet man ihn in den Bergen, beim Joggen oder anderen sportlichen Aktivitäten.

m.schwarze@atra.consulting    

• LinkedIn

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Quellenangaben

[1]: https://conferences.isaqb.org/software-architecture-gathering/ (abgerufen: 5. Dez. 2024).

[2]: https://www.youtube.com/watch?v=u5XMypmSXVQ (abgerufen: 19. Dez. 2024).

[3]: https://cwe.mitre.org/data/definitions/1007.html (abgerufen: 16. Dez. 2024).

[4]: https://conferences.isaqb.org/software-architecture-gathering/session/generative-ai-meets-software-architecture/ (abgerufen: 30. Dez. 2024).

[5]: https://conferences.isaqb.org/software-architecture-gathering/session/the-architecture-of-reliable-ai-rag/ (abgerufen: 30. Dez. 2024).

[6]: https://conferences.isaqb.org/software-architecture-gathering/session/event-sourcing-technical-detail-or-architectural-powerhorse/ (abgerufen: 11. Jan. 2025).

[7]: https://martinfowler.com/eaaDev/EventSourcing.html (abgerufen: 11. Jan. 2025).

[8]: https://martinfowler.com/bliki/DomainDrivenDesign.html (abgerufen: 11. Jan. 2025).

[9]: https://conferences.isaqb.org/software-architecture-gathering/session/architects-arent-the-smartest-people-in-the-room/  (abgerufen: 11. Jan. 2025).

[10]: https://atra.consulting/blog/die-vielen-gesichter-von-softwarearchitekten/ (abgerufen: 13. Jan. 2025).

Die Auswahl an wohltätigen Organisationen und karitativen Einrichtungen ist riesig. Alleine eine kurze Online-Suche nach dem Stichwort „Weihnachtsspende“ ergibt unzählige Treffer – mit vielen wunderbaren Projekten, die jede Unterstützung verdient hätten. Doch die schiere Vielfalt macht es schwierig, gezielt auszuwählen.

Da wir als IT-Beratungsgruppe täglich im technologischen Umfeld arbeiten, möchten wir unsere Spende deshalb auf einen Bereich konzentrieren, der direkt zu unserem beruflichen Alltag passt. Unsere Wahl fiel auf Open-Source-Software (OSS). Durch OSS werden nicht nur moderne Technologien ermöglicht, sondern auch Innovationen und Stabilität in der IT-Infrastruktur gefördert. Uns ist es wichtig, auch hier einen Beitrag zu leisten und uns für eine „karitative Technologie-Spende“ zu engagieren, die sich für viele Menschen langfristig positiv auswirken kann.

Das Rückgrat unserer digitalen Welt

Open-Source-Software ist das unsichtbare Rückgrat der digitalen Welt, auf das sich viele unserer Projekte und Technologien stützen. Oft denken wir gar nicht daran, dass hinter dieser Software kleine Entwicklerteams oder sogar Einzelpersonen stehen, die diese Infrastruktur ehrenamtlich und ohne finanzielle Rückendeckung aufrechterhalten.

Die Open-Source-Community sieht sich einem Spannungsfeld gegenüber: Auf der einen Seite ist “ihre Software” enorm erfolgreich und weit verbreitet. So läuft Android, ein auf dem Linux-Kernel basierendes Betriebssystem, auf über 2 Milliarden Geräten weltweit. Linux selbst, mittlerweile 25 Jahre alt, ist aus der digitalen Welt nicht mehr wegzudenken. Sein Einsatzgebiet reicht von Alltagsgeräten wie Smartphones und Druckern über Webserver und Cloudinfrastruktur bis hin zu Supercomputern, wo es auf 498 der 500 leistungsstärksten Systemen läuft. Die Weltherrschaft von Linux ist unbestritten.

Linux und Android sind zwar bekannte Beispiele, aber bei weitem nicht die einzigen. Die Datenbank SQLite, beispielsweise, ist außerhalb der IT-Welt kaum jemandem ein Begriff. Trotzdem wird sie Schätzungen zufolge auf über einer Billion Geräten aktiv genutzt.

Schattenseiten: Herausforderungen in der Open-Source-Welt

Obwohl Open-Source-Software das unsichtbare Rückgrat unserer modernen digitalen Welt darstellt, gibt es auch weniger beachtete Schattenseiten. Dieses Rückgrat ruht auf den Schultern engagierter Freiwilliger, die ihre Arbeit mit Leidenschaft und ohne kommerziellen Anreiz der Allgemeinheit zur Verfügung stellen. Doch von dieser Arbeit können sie oft nicht leben. Kritische Software-Infrastruktur wird deshalb häufig von Einzelpersonen in späten Nachtstunden oder am Wochenende – zusätzlich zu ihrem regulären Job – entwickelt und gepflegt.

Ein markantes Beispiel hierfür ist die Programmbibliothek OpenSSL, die rund zwei Drittel des gesamten Internetverkehrs verschlüsselt und damit eine Schlüsselrolle in der digitalen Sicherheit einnimmt. Ein über Jahre unentdeckter Fehler in OpenSSL führte zum berühmten Heartbleed-Bug, der eine erhebliche Sicherheitslücke darstellte und private Daten im Internet anfällig für Angriffe machte. Nach der Behebung des Bugs machte das Entwicklungsteam deutlich auf die strukturellen Probleme in der Open-Source-Welt aufmerksam und bat um Hilfe.

Ein etwas aktuelleres Beispiel wurde von Heise gar als größtes Fiasko in der Geschichte des Internets bezeichnet, dem wir gerade so entgangen sind. Vermutlich staatliche Akteure nutzten eine technisch hochentwickelte Methode, um die Paketierungssoftware XZ zu kompromittieren. Dabei setzten sie auf raffiniertes Social Engineering, indem sie die angeschlagene psychische Gesundheit von Lasse Collin, dem Hauptentwickler der Software, gezielt ausnutzten. Diese Aktion, die zunächst unscheinbar wirken mag, hätte fast eine Backdoor in nahezu jedes System weltweit geöffnet.

Open Source: Stärke durch Transparenz, aber wer trägt die Verantwortung?

An dieser Stelle möchten wir betonen: Open Source Software ist nicht per se unsicherer oder weniger nachhaltig als kommerzielle Software (Closed Source Software). Ganz im Gegenteil – die breite und öffentliche Aufarbeitung, wie im Fall von XZ, sehen wir als eine Stärke, die langfristig Sicherheit und Stabilität fördert. Gleichzeitig wirft dies aber auch die wichtige Frage nach einer fairen Lastenverteilung auf – ein Punkt, der in folgendem xkcd-Comic auf amüsante Weise illustriert wird.

Ob insbesondere große Unternehmen, alleine in Deutschland nutzen 71% dieser Open-Source-Software, sowie Staaten hier zum Erhalt unseres digitalen Rückgrats genug investieren und „zurückgeben“, ist ein sehr berechtigter Aspekt dieser Frage, bspw. erst kürzlich wieder von der Wikimedia gestellt.

Das Spannungsfeld zwischen der erfolgreichsten Idee der IT-Geschichte und vielen engagierten “stillen Helden” ist auch hier offensichtlich. Glücklicherweise werden auch Themen wie Burnout immer offener diskutiert.

Weihnachtsspende: Immer noch viel Auswahl

Nun gibt es auch bei der Suche nach geeigneten Spendenzielen im Open-Source-Bereich unzählige inspirierende Organisationen und Projekte, die jede Unterstützung verdienen. Statt selbst eine Auswahl zu treffen, haben wir innerhalb von atra.consulting eine kleine Umfrage gestartet. Der Rahmen war einfach: Für jedes Teammitglied stand eine Spendensumme von 50 € zur Verfügung. Alle Kolleginnen und Kollegen waren eingeladen, ihr persönliches Herzensprojekt vorzuschlagen. Anschließend wurde gemeinsam über die eingereichten Vorschläge abgestimmt.

So starten wir die Weihnachtszeit nun mit Spenden an folgende Projekte:

Signal – Der sichere, E2E-verschlüsselte Open-Source-Messenger überzeugte unser Team auf ganzer Linie. Neben innovativer Entwicklung, etwa im Bereich Post-Quantum-Verschlüsselung, leistet die Signal Foundation unschätzbare Arbeit. Mit Abstand auf Platz 1 erhält Signal 50 % der Spendensumme.

Wikipedia – Zwar keine klassische Open-Source-Software, aber ein unverzichtbares Open-Knowledge-Projekt. Es bereichert unseren Alltag und ist eine essenzielle Grundlage, auch für die Entwicklung moderner Technologien wie LLMs. Wikipedia erhält 30 % der Spendensumme.

Notepad++ – Ein einfacher, aber wertvoller Texteditor, der für viele von uns tägliches Werkzeug ist. Notepad++ erhält 20 % der Spendensumme und würdigt damit die Bedeutung kleiner, effektiver Tools.

Mit unserer Spendenaktion möchten wir nicht nur einen Beitrag leisten, sondern auch das Bewusstsein für die Bedeutung von Open-Source-Software schärfen. Wir laden alle ein, sich dieser Idee anzuschließen und die Open-Source-Community aktiv zu unterstützen.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Einleitung

Bei der Besetzung von Rollen in IT-Projekten ist eine gewisse Findungsphase mit dem Auftraggeber nicht unüblich. Während viele Rollen im Lehrbuch (recht) eindeutig definiert sind, spricht die Praxis oftmals eine andere Sprache. Eine besonders komplexe Rolle hierbei ist die des Softwarearchitekten, bei welcher sich Anforderungen und Erwartungen von Organisation zu Organisation teils stark unterscheiden. Dies hat sicherlich auch damit zu tun, dass selbst der Begriff von Softwarearchitektur in der Literatur nicht einheitlich und erst recht nicht präzise definiert ist. Gleichzeitig trägt die Rolle aber wesentlich zum Erfolg von IT-Projekten bei. Grund genug für uns, den vielen Facetten von Softwarearchitektur eine kleine Blogserie zu widmen.

Einleiten wollen wir diese Blogserie mit einer nicht ganz ernst gemeinten Betrachtung verschiedener (Stereo-)Typen von Softwarearchitekten, wie sie die meisten Menschen, die sich im Kontext von IT-Projekten bewegen, wohl schon erlebt haben. Die durchaus sinnvollen Unterscheidungen zwischen Enterprise, Solution und Technical Architecture klammern wir an dieser Stelle erst einmal bewusst aus, da sich unserer Erfahrung nach untenstehende Typen auf eigentlich jedem Abstraktionslevel finden lassen. Aber Achtung – der Beitrag kann Spuren von Ironie enthalten. 

Der Powerpoint-Architekt

Für ihn bestehen Softwaresysteme aus Kästchen und Pfeilen. Alles andere sind doch auch nur lästige Implementierungsdetails. Wird von agilen Teams häufig nach oben weggelobt und zeichnet seine Powerpoints nun auf höherer Ebene.

Der Elfenbeinturm-Architekt

Durchaus verwandt mit dem Powerpoint-Architekten befindet sich der Elfenbeinturm-Architekt im… nun ja, in seinem persönlichen Elfenbeinturm. Oftmals zeichnen Elfenbeinturm-Architekten sich gleichzeitig durch ein tiefes, zumeist akademisch geprägtes Fachwissen auf der einen und eine komplette Ignoranz für die (Projekt-)Bedürfnisse der Entwicklungsteams auf der anderen Seite aus. Liebt Gremien, in welchen die Entwicklungsteams sich ihre Architekturen abnehmen lassen müssen. Oder es zumindest versuchen. Der natürliche Feind agiler Teams.

Der Chronisten-Architekt

Sieht sich als Wächter der Dokumentation, welche in ihrer Bedeutung der Bibliothek von Alexandria quasi in nichts nachsteht. Etwas, was nicht ausführlich dokumentiert ist, existiert für ihn nicht und kann auf gar keinen Fall funktionieren. Idealerweise wird die Architektur und ihre Dokumentation in mehrstufigen Gremien freigegeben. Im Gegensatz zum Elfenbeinturm-Architekten sieht der Chronisten-Architekt seine Rolle aber eher in der Vorbereitung und Dokumentation der Gremienarbeit.

Der Podcast-Architekt

Hört wirklich jeden Architektur – und Technologie-Podcast auf dem Markt. In mehr als einer Sprache. Der Podcast-Architekt predigt die neuesten Technologien und Methoden und versucht, jeden in seinem Umfeld davon zu überzeugen. Hält sich auch liebend gerne auf Konferenzen und Meetups auf. Seine Wahrnehmung in den Projektteams variiert stark – manche lieben ihn und seine Impulse, manche möchten doch einfach nur das Projekt zu Ende bringen.

Der Prototypen-Architekt

Dieser Architekten-Typus ist der natürliche Gegenpart zum Powerpoint-Architekten. Architektur findet für ihn direkt im Code statt, neue Pattern oder Ideen stellt er am liebsten als Prototyp direkt in seinem Repo zur Verfügung. Die Entwicklungsteams lieben ihn, auch wenn sein sonstiges Umfeld sich durchaus ein wenig mehr Dokumentation und Struktur wünschen würde.

Der U-Boot-Architekt

Nicht zu verwechseln mit dem Elfenbeinturm-Architekten, ist sein natürliches Wirkungs-Habitat der Besprechungsraum. Hier weiß er zu brillieren und durch die geschickte Platzierung von Fragen und Prüfaufträgen jede noch so kleine Entscheidung zielsicher zu torpedieren. Nur um dann wieder abzutauchen – bis zum nächsten Mal.

Der basisdemo­kra­tische Architekt

Architektur ergibt sich für ihn nur evolutionär aus der Diskussion im Team und hat sich dem Code unterzuordnen. Vorabentschei­dungen sind unbedingt zu vermeiden, zentrale Beschlüsse oder übergreifende Einschränkungen werden als persönlicher Affront aufgefasst. Auf diese Weise hat der basisdemokratische Architekt immer ein lokales Optimum fest im Blick – oftmals jedoch nicht das große Ganze. 

Uns selbst laufen eigentlich alle oben genannten Typen regelmäßig in Rein- oder Mischform in unseren Projekten über den Weg. Sehr gerne denke ich an einen großen Kunden zurück, bei dem der Auf­trag­geber selbst von 3-6 Monaten Onboarding ausge­gangen ist, um die komplexen Dokumentations- und Prozess­anforderungen an die Entwicklung der Software­architektur zu verinnerlichen. Ein typischer Fall von (in diesem Fall gewollten) Chronisten-Architekten. 

Aber was lernen wir nun aus den verschiedenen Typen von Softwarearchitekten? Auch wenn die Darstellung bewusst überspitzt war, verdeutlicht die Betrachtung sehr schön, mit welchen komplexen Anforderungen sich ein Softwarearchitekt konfrontiert sieht. Persönlich mag ich das Bild des Softwarearchitektur-Aufzuges von Gregor Hohpe, in welchem der Architekt sich vom Maschinen­raum im Keller (Technik, Programmiersprache, Design Pattern) bis zum Vorstands-Penthouse auf dem Dach (IT-Transformation, Organisationsentwicklung) bewegt. Auch wenn man durchaus hinterfragen kann, ob es sinnvoll ist, so viele Aufgaben und Anforderungen in eine einzige Rolle zu projizieren. Im nächsten Blogpost beschäftigen wir uns etwas ausführlicher damit, was Softwarearchitektur für uns eigentlich bedeutet – ganz ohne Ironie.

Daniel Wochnik

Geschäftsbereichsleitung »Finanzdienstleistungen«

Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter für Finanzdienstleistungen bei atra.consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Als leidenschaftlicher Läufer und bekennender 1. FC Köln-Fan hat er seine Leidensfähigkeit auch privat mehrfach unter Beweis gestellt. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.

d.wochnik@atra.consulting    

• LinkedIn

Die in diesem Artikel verwendeten Bilder wurden mit Hilfe von DALL·E 2, einer KI zur Bildgenerierung, erstellt.