Umso erstaunter war ich, als mir kürzlich in einem ruhigen Moment auffiel, dass ich mich selbst im Arbeitsalltag erstaunlich selten daran halte. Und schlimmer noch: dass ich ziemlich gut darin geworden bin, mir das auch noch schönzureden.

Eisenhower ist aus meiner Sicht weiterhin ein sinnvolles Werkzeug – das ist mir wichtig vorwegzuschicken. Gleichzeitig stößt dieses Zeitmanagement-Modell aus der Mitte des 20. Jahrhunderts – entwickelt von einem US-General und späteren Präsidenten – im Arbeitsalltag moderner Wissensarbeiter erstaunlich schnell an seine Grenzen.

Dafür gibt es mehrere Gründe.

Kognitive Überlastung: Wenn zu viele Reize um Aufmerksamkeit konkurrieren

Wissensarbeiter – egal ob Fachspezialisten, Berater oder Entscheider – leiden heute weniger an fehlender Priorisierung als an kognitiver Überlastung. Die ständige Notwendigkeit, zwischen konzentrierter Arbeit an komplexen Fragestellungen und reaktiver Kommunikation zu wechseln, erzeugt Kontextwechselkosten (siehe auch [1]), die Fokus, Entscheidungsqualität und letztlich auch die eigene Zufriedenheit spürbar beeinträchtigen.

Die Eisenhower-Matrix verspricht an dieser Stelle eigentlich Orientierung, scheitert jedoch häufig an der psychologischen Realität der Illusion of Urgency [2]: Aufgaben fühlen sich dringend an, erzeugen Handlungsdruck und verlangen Aufmerksamkeit – ohne deshalb, um in der Sprache von Eisenhower zu bleiben, automatisch auch wichtig oder tatsächlich dringend zu sein.

Für mich hat sich daraus eine einfache, bewusst pragmatische Regel ergeben: Aufgaben, die sich in weniger als fünf Minuten erledigen lassen, versuche ich unmittelbar abzuschließen. Nicht aus Effizienzgründen im klassischen Sinne, sondern um kognitive Last zu reduzieren. Jede nicht beantwortete Rückfrage, jede angefangene, aber nicht abgeschlossene Kleinigkeit bleibt im Kopf präsent – und konkurriert dort mit eigentlich wichtigeren Themen um Aufmerksamkeit.

Das Problem: In meinem hochfragmentierten Arbeitsalltag gibt es überraschend viele „kurze Anfragen“. Und so schlägt die Fünf-Minuten-Regel bei mir erstaunlich oft Eisenhower.

Und ja, ich weiß: Man muss Mails und Chatnachrichten nicht sofort lesen. In der Theorie leuchtet mir das vollkommen ein. In der Praxis stressen mich 13 ungelesene Teams-Nachrichten jedoch zuverlässig. Disziplinierte Zeitfenster für Mail- und Chatkommunikation funktionieren für manche hervorragend. Für mich nicht. Und so stößt auch Eisenhower an seine Grenzen.

Kognitive Last der Organisation: Wenn zu viele Themen gleichzeitig offen sind

Nun ist kognitive (Über-)Last kein individuelles Versagen. Sie ist in vielen Fällen ein übergreifendes organisatorisches Problem. Organisationen arbeiten selten an einem Thema zur gleichen Zeit. Sie arbeiten an sehr vielen. Projekte, Initiativen, Abstimmungen, Eskalationen, strategische Themen und operative Kleinigkeiten laufen parallel – oft über Monate oder sogar Jahre. Jeder offene Vorgang erzeugt kognitive Last. Nicht nur bei Einzelpersonen, sondern im System insgesamt: in Meetings, Statusrunden, Entscheidungsprozessen oder auch nur, weil ich diese eine nervige Aufgabe nun schon zum dritten Mal in die Folgewoche verschiebe.

Diese systemische kognitive Last entsteht unabhängig davon, wie dringend oder wichtig ein einzelnes Thema gerade ist. Allein die Tatsache, dass etwas „noch offen“ ist, bindet Aufmerksamkeit. Ein psychologisches Fundament dieser Beobachtung liefert übrigens der Zeigarnik-Effekt, der besagt, dass uns unterbrochene, unerledigte Aufgaben kognitiv stärker beschäftigen als abgeschlossene [4]. Das kostet Energie – selbst dann, wenn faktisch gerade niemand daran arbeitet.

Ein besonders plastisches Beispiel dafür habe ich im behördlichen Umfeld erlebt. Eine Broschüre sollte aktualisiert werden – kein besonders dringendes Thema, von mittlerer Wichtigkeit. Der erste Entwurf war schnell erstellt. Danach passierte lange Zeit: nichts. Aufgrund interner Prozesse mussten verschiedene Einheiten involviert werden, zwischen den einzelnen Abstimmungen lagen jeweils mehrere Wochen.

Das Ergebnis? Ein Prozess über 20 Monate. Durch unzählige Abstimmungsrunden und Liegezeiten musste sich jeder Beteiligte in jedem Termin neu eindenken („Wo standen wir nochmal?“). Am Ende wurde konservativ geschätzt mindestens das Zehnfache der eigentlichen Arbeitszeit investiert, nur weil das Thema immer wieder liegen blieb. Ein klassisches Beispiel dafür, wie „nicht dringende“ Themen durch reinen Zeitverzug zu hocheffizienten Ressourcenfressern mutieren.

Die Eisenhower-Matrix betrachtet Aufgaben isoliert. Sie hilft dabei, einzelne To-dos zu priorisieren. Was sie jedoch systematisch ausblendet, ist die kumulative Wirkung vieler paralleler, offener Themen auf eine Organisation.

In der Praxis ist es oft nicht das einzelne wichtige oder dringende Thema, das überlastet – sondern die schiere Anzahl an offenen Baustellen. Aus einer Lean-Perspektive ist es deshalb sinnvoll, die Anzahl gleichzeitig offener Themen möglichst gering zu halten. Nicht nur, um schneller zu werden, sondern um arbeitsfähig zu bleiben.

Genau hier beginnt ein Aspekt, den Eisenhower nur unzureichend adressiert: Offene Themen sind nicht neutral. Sie sind nicht einfach „noch nicht dran“. Sie erzeugen Kosten – allein durch ihr Liegenlassen.

Cost of Delay: Wenn Liegenlassen teuer wird

Wenn man genau hinschaut, habe ich im obigen Behördenbeispiel bereits ein Konzept verwendet, ohne es zu benennen: Cost of Delay.

Nicht die (gefühlte und meist sehr subjektive) Wichtigkeit einer Aufgabe entscheidet über ihre Priorität, sondern die Kosten, die entstehen, wenn sie nicht umgesetzt wird. Diese Kosten sind oft nicht sichtbar – aber sie sind real.

Ein einfaches Beispiel: Ein kurzes Debriefing zu einem Konferenzbesuch an Kollegen zu schicken, ist selten dringend und meist auch nicht besonders wichtig. Während der Zugfahrt nach Hause ist das in wenigen Minuten erledigt. Zwei Wochen später brauche ich dafür schon deutlich länger. Zwei Monate später muss ich anhand meiner Notizen rekonstruieren, was ich eigentlich mitteilen wollte.

Die Aufgabe ist dieselbe geblieben – der Aufwand nicht. Die Verzögerung hat hier keinen inhaltlichen Mehrwert erzeugt, sondern ausschließlich zusätzliche Arbeit. Genau das beschreibt Cost of Delay.

In Organisationen wirkt dieser Effekt noch stärker. Der eigentliche Cost of Delay entsteht häufig nicht durch fehlende Umsetzung, sondern durch das Wiederanlaufen: sich erneut einlesen, Kontexte rekonstruieren, Entscheidungen erklären, Abhängigkeiten neu klären. Je länger ein Thema liegt, desto höher werden diese Reibungsverluste. Besonders schön wird es dann, wenn Nachfragen nach dem Stand einer Aufgabe und ein oder zwei Feedbackschleifen in Summe bereits mehr Zeit kosten als die eigentliche Erledigung.

Eisenhower hilft dabei zu entscheiden, was wichtig und dringend ist. Cost of Delay macht sichtbar, was es kostet, nichts zu entscheiden – und Themen immer wieder liegen zu lassen.

Mir ist bewusst, dass Cost of Delay ein abstrakter Begriff bleibt. Mir hilft dieser Perspektivwechsel jedoch sehr, meine Arbeitsprioritäten besser zu setzen. Übliche Dimensionen, die meinen höchst persönlichen Cost of Delay ausmachen, sind:

• der erwartete Mehrwert des Arbeitspakets (strategisch, operativ oder risikoseitig)
• Effizienz- und Reibungsverluste über die Zeit (Wiederanlauf, Abstimmung, Kontextverlust)
• die Möglichkeit, Themen sauber abzuschließen und damit kognitive Last zu reduzieren
• Lernen und Wissensgewinn – oder dessen Verzögerung

Ob ich eine Aufgabe selbst erledige oder delegiere, beantwortet Cost of Delay allerdings nicht. Aber dazu kommen wir im kommenden Abschnitt.

Verteilte Verantwortung: Wenn klassische Delegation an Grenzen stößt

Die Eisenhower-Matrix ist in einer Welt klarer Hierarchien entstanden. Aufgaben werden priorisiert, erledigt oder delegiert. Delegation setzt dabei etwas voraus, das lange selbstverständlich war: eine eindeutige hierarchische Ordnung mit klarer Weisungsbefugnis.

In der Sprache von Reinventing Organizations [5] würde man sagen: Eisenhower passt hervorragend zu bernsteinfarbenen, stark hierarchischen Organisationen. Führung bedeutet dort, Entscheidungen zu treffen und Aufgaben weiterzugeben.

Viele Organisationen funktionieren heute jedoch anders. Wir sprechen über flache Hierarchien, selbstorganisierte Teams, laterale Führung und Servant Leadership. Verantwortung liegt nicht mehr ausschließlich bei einzelnen Rollen, sondern verteilt sich auf Teams. Entscheidungen werden gemeinsam getroffen, Aufgaben gemeinsam getragen.

In solchen Strukturen wird Delegation unscharf. An wen delegiere ich, wenn Verantwortung im Team liegt? Was bedeutet „abgeben“, wenn ich fachlich gar nicht weisungsbefugt bin? Und was passiert, wenn Delegation nicht als Entlastung, sondern als Abschieben wahrgenommen wird?

Gleichzeitig verstehen sich viele Organisationen zunehmend als lernende Systeme. Aufgaben sind nicht nur Mittel zur Zielerreichung, sondern auch Gelegenheiten zur Entwicklung. Konzepte wie Management 3.0 [6] betonen genau diesen Aspekt: Arbeit dient nicht nur der Effizienz, sondern auch dem Lernen, der Motivation und dem Kompetenzaufbau von Mitarbeitern.

Damit wird Delegation zu einer Führungsentscheidung mit mehreren Dimensionen. Nicht jede Aufgabe, die delegierbar wäre, sollte delegiert werden. Und nicht jede Aufgabe, die belastet, lässt sich sinnvoll abgeben. Eisenhower gibt darauf keine Antworten – weil er diese Organisationslogik schlicht nicht kennt.

Fazit: Eisenhower reicht nicht mehr – aber er bleibt hilfreich

Die Eisenhower-Matrix ist kein schlechtes Werkzeug. Sie hilft, innezuhalten, Aufgaben bewusst zu betrachten und sich nicht von jeder Dringlichkeit treiben zu lassen. Das allein ist viel wert.

In meinem Arbeitsalltag reicht sie jedoch nicht mehr aus. Kognitive Überlastung, systemische Reibung, Cost of Delay und veränderte Organisationsformen lassen sich nicht sauber in vier Quadranten pressen. Dafür sind moderne Wissensorganisationen zu komplex – und Arbeit zu stark von Kontext, Abhängigkeiten und Lernen geprägt.

Was mir heute hilft, ist kein Ersatz für Eisenhower, sondern eine Ergänzung: der bewusste Blick auf Liegezeiten, auf kognitive Last – und auf die Frage, was es mich und die Organisation kostet, Dinge nicht zu entscheiden.

Eisenhower hilft mir weiterhin bei der Orientierung. Die eigentliche Priorisierung entsteht jedoch erst im Zusammenspiel aus Kontext, Verantwortung und Cost of Delay. Am Ende bleibt die Erkenntnis: Ein Werkzeug ist eben nur ein Werkzeug. Mit einem Hammer lässt sich vieles erledigen – aber nicht alles im modernen Arbeitsalltag ist ein Nagel.

Referenzen

[1] Multitasking: Switching Costs – https://www.apa.org/topics/research/multitasking 
[2] The Illusion of Urgency –  https://pmc.ncbi.nlm.nih.gov/articles/PMC10159458/ 
[3] Mintzberg, H. (1973). The nature of managerial work.
[4] Zeigarnik-Effekt – https://de.wikipedia.org/wiki/Zeigarnik-Effekt 
[5] Reinventing Organisations – https://www.reinventingorganizations.com/ 
[6] Management 3.0 – https://management30.com/ 

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 Webentwicklung verändert sich rasant – aktuell vor allem durch neue Frontend-Paradigmen und den zunehmenden Einsatz von AI-gestütztem Coding. Genau deshalb war die c’t webdev conference Mitte November im KOMED im MediaPark in Köln für mich mehr als nur ein Pflichttermin.

Zwei Tage lang trafen sich dort Frontend-Entwickler:innen, die sich intensiv mit Themen wie UI/UX, modernen JavaScript-Frameworks und neuen Ansätzen wie Vibe Coding und AI Agents beschäftigten. Der klare fachliche Fokus, die Tiefe der Vorträge und der direkte Austausch auf Augenhöhe machten schnell klar: Die Konferenz richtet sich nicht an Neugierige, sondern an echte Praktiker:innen. Die Organisation war top und das Catering im KOMED hervorragend – ideale Voraussetzungen für konzentriertes Networking und Lernen.

Doch was die c’t webdev wirklich auszeichnet, war die spezifische Zielgruppe: Es handelte sich um eine klare Frontend-Konferenz. Das Publikum war tief in den Themen UI/UX, Coding mit AI Agents, Vibe Coding und den aktuellen JavaScript-Frameworks (React, Angular, Vue) verwurzelt. Hier traf man auf gleichgesinnte Frauen und Männer, die nicht nur auf der Suche nach Inspiration waren, sondern auch den tiefen fachlichen Austausch suchten. Der Vibe stimmte sofort, was eine ideale Basis für die kommenden Vorträge legte.

Tag 1: Über AI Autopilots, Architektur und granularem State-Management

Keynote: Von Copilot zu Autopilot

Der Tag begann mit einer fesselnden Keynote von Daniel Sogl, der uns mitnahm auf die Reise „From Copilot to Autopilot – How AI Coding Tools Are Transforming the Developer Role“. Der Vortrag war mehr als eine Bestandsaufnahme; er war eine Aufforderung, die neue Realität kritisch zu hinterfragen.

Sogl präsentierte eindrucksvolle Statistiken zur Adoption von AI-Tools, wobei 84 % der Entwickler sie bereits nutzen oder planen zu nutzen, und 51 % sie täglich verwenden. Diese Tools versprechen echte Produktivitätssteigerungen, wie z. B. eine um 55,8 % schnellere Aufgabenerledigung in kontrollierten Studien und eine Reduzierung der täglichen Arbeitszeit um 56 Minuten.

Der zentrale Weckruf kam mit dem Trust Paradox: Während Syntax-Fehler dank AI um bis zu 76 % reduziert werden, steigt das Risiko für tiefer liegende, architektonische Probleme signifikant an. Berechtigungsprobleme (+322 %) und Architekturmängel (+153 %) sind laut Sogl keine Seltenheit. Diese Zahlen haben mich am meisten überrascht und bestätigen meine Skepsis: AI erzeugt „saubereren“ Code, verleitet aber zur Vernachlässigung der architektonischen Kontrolle.

Die Quintessenz des Vortrags: Die Entwicklerrolle wandelt sich vom reinen Coder zum Orchestrator und Strategen. Die Zukunft liegt in der Spec-Driven Development (SDD), bei der wir die Spezifikationen klar vorgeben, bevor die AI den Code generiert. Genau hier liegt für mich eine der großen Herausforderungen der nächsten Jahre: Wir müssen uns stärker als je zuvor auf die architektonische Planung und saubere Anforderungsanalyse konzentrieren, um die AI als präzises Werkzeug zu führen, statt uns von ihren zufälligen ‚Vibes‘ treiben zu lassen.

​

Das Highlight von Tag 1: Signals in Depth

Nach der strategischen Keynote, die den Rahmen für die Zukunft der Entwicklerrolle setzte, tauchten wir am späten Vormittag tief in die Frontend-Architektur ein. Mein persönliches Highlight von Tag 1 war ein Vortrag, der zeigte, wie die modernen Frameworks das Kernproblem der Webentwicklung – die Reaktivität – endlich effizient lösen: „Signals in Depth – How reactivity works in many frontend frameworks“ von Garrelt Mock.

Mock erklärte anschaulich die Schwächen traditioneller Reaktivitätsansätze: das „Dirty Checking“ (bekannt aus älteren Angular-Versionen mittels Zone.js) und das Virtual DOM (VDOM) Diffing in React. Diese Methoden, obwohl funktional, verursachen oft Performance-Overhead und unnötige Rechenzyklen, da unnötig große Teile der Komponenten neu gerendert werden, selbst wenn sich nur ein kleiner Datenpunkt geändert hat.

Die Lösung liegt in Signals, die auf einem granularen Observer-Pattern basieren: Ein Signal weiß genau, welche UI-Teile oder Effekte von ihm abhängen. Bei einer Änderung wird nur dieser spezifische abhängige Effect aktualisiert, nicht die gesamte Komponente.

Für mich war dieser Vortrag die wichtigste technische Erkenntnis des Tages. Die Eleganz und Effizienz, mit der Signals die Notwendigkeit für komplexe Mechanismen wie Zone.js oder VDOM-Diffing eliminieren und Frameworks wie SolidJS, Preact und das neue Angular schneller und speichereffizienter machen, ist ein klarer Hinweis auf einen Paradigmenwechsel im State-Management. Die Frontend-Architektur wird sich dadurch grundlegend vereinfachen – ein Muss für jede skalierbare Anwendung in den kommenden Jahren.

Der Rest des ersten Tages: Von AI-Agents bis zur Frontend-Architektur

Neben Keynote und Signal-Tiefgang bot der erste Konferenztag eine spannende Bandbreite an Themen, die die aktuellen Herausforderungen und Trends in der Frontend-Welt widerspiegelten.

AI-Driven Development: Sebastian Springer beleuchtete in seiner Session „AI Agents Beyond Simple Chatbots“ die Entwicklung komplexer, autonomer AI-Lösungen und proaktiver Assistentensysteme, die weit über einfache LLM-Chat-Interfaces hinausgehen. Er zeigte Frameworks wie LangChain, mit denen man AI-Agents befähigen kann, reale Probleme zu lösen und mehrstufige Workflows zu automatisieren.

Architektur und Skalierung: Der Vercel-Partner-Talk „From Monolith to Microfrontends: Choosing the Right Architecture…“ von Yi Min Yang lieferte einen praktischen Leitfaden zu modernen Frontend-Architektur-Patterns. Er diskutierte alles von Monorepos (z.B. mit Turborepo) bis Microfrontends und präsentierte ein klares Entscheidungs-Framework, um die passende Architektur für Teamgröße und technische Anforderungen zu finden. Sehr interessant zu sehen, wie man auch step-by-step Architekturen modernisieren kann.

Qualität und Metriken: Richard Gross erklärte unter dem Titel „Making sense of frontend code with forensic techniques“, wie man mithilfe von Tools wie CodeCharta und CodeGraph die Code-Qualität und Architektur in Projekten mit hunderttausenden Zeilen analysiert. Darüber hinaus zeigte Eva Feigl in „Beyond clicks: Measuring UX, outcomes and real product success“ auf, wie man Produkt-Telemetrie und qualitative Nutzerforschung kombiniert, um wirklich verwertbare UX-Metriken zu erhalten und den Produkterfolg zu validieren.

Tag 2: Menschliche Empathie und AI-Strenge 

Keynote: Nobody needs UX – Die Unverzichtbarkeit der Empathie

Der zweite Konferenztag begann mit einer provokanten und nachdenklich stimmenden Keynote von Vicky Pirker mit dem Titel „Nobody needs UX“.

Pirker nutzte diesen vermeintlich paradoxen Titel, um die Essenz von User Experience (UX) in Zeiten der schnellen AI-Entwicklung neu zu definieren: Es braucht nicht den Begriff UX, sondern die menschliche Haltung dahinter. Schlechte UX führt zu Frustration und Ablehnung, wie sie eindrücklich zeigte.

Besonders relevant war die Diskussion im Kontext der AI-Revolution. Ihre klare Schlussfolgerung: User Experience bleibt menschzentriert, und KI dient lediglich als unser Sidekick. Die Aufgabe der Entwickler und Designer ist es, die Vision zu formen und die Nutzer zu begeistern.

Für mich war der Fokus auf die Empathie der wichtigste Takeaway. Während KI gut darin ist, bekannte UX-Schemata und Design-Regeln zu erlernen und perfekt umzusetzen, bleibt die Fähigkeit, sich tief in den User hineinzufühlen – also die Wünsche und emotionalen Reaktionen vorherzusehen – eine zutiefst menschliche Leistung. Dieser Mangel an Empathie kann aber zum Problem werden, wenn KI versucht, UX komplett zu übernehmen. Daher muss die menschliche Perspektive, die qualitative Nutzerforschung und Empathie stets die letzte Kontrollinstanz bleiben.

Das Highlight von Tag 2: EXACT Coding gegen den „Vibe“

Die Keynote von Vicky Pirker stellte klar: Der Mensch muss die ethische und empathische Kontrolle behalten. Der darauf folgende Vortrag „AI-Powered Development Vibe Code Doesn’t Work!“ von Marco Emrich und Ferdinand Ade lieferte die technische Methodik dazu. Sie äußerten eine klare Kritik am unstrukturierten „Vibe Coding“ (generieren, akzeptieren, nicht prüfen) und belegten, dass dieser Ansatz – obwohl schnell – zu unsauberen und unsicheren Codebasen führt.

Ich sehe Vibe Coding als einen effizienten Weg für schnelles Prototyping und Proof-of-Concepts; man erhält in kürzester Zeit gute, lauffähige Ergebnisse. Doch für Production-Ready Code ist dieser Ansatz meiner Meinung nach untauglich.

Die Lösung der Sprecher war EXACT Coding, ein Ansatz, der die besten Seiten der AI mit der Disziplin etablierter Methoden kombiniert. EXACT Coding basiert auf EXample-Guided Ai-CollaboraTive.

Das ist die Essenz für professionelle Softwareentwicklung: Bevor die AI überhaupt mit dem Codieren beginnt, müssen wir als Software Engineers in unseren Teams die Anforderungen und Spezifikationen klar erfassen und visualisieren. Der Mensch (Human-in-the-Loop) definiert das „Was“ durch die Beispiele und Tests; die AI übernimmt die Implementierung.

Der größte Vorteil dieser Methodik ist die Qualitätssicherung der Architektur: Indem wir uns zuerst auf Spezifikationen und die „Red“-Phase des TDD-Zyklus konzentrieren, zwingen wir die KI, in einem engen, validierten Rahmen zu arbeiten. Das beugt nicht nur Syntaxfehlern vor, sondern verhindert auch das Auseinanderdriften von Code und Gesamtarchitektur. Nur so stellen wir sicher, dass wir nicht nur Code schreiben, sondern nachhaltige, wartbare Software entwickeln und dabei niemals das große Ganze aus dem Auge verlieren.

Weitere Highlights an Tag 2: Reaktivität, Testing und Agenten-Interfaces

Auch abseits der Keynote und des AI-Vortrags lieferte Tag 2 wertvolle Inhalte, die sich tief mit den technischen Details der modernen Frontend-Entwicklung beschäftigten:

Standardisierung von AI-Interfaces: Max Marschall stellte in seinem Vortrag „AG-UI & MCP: Standardizing Agentic Web Interfaces“ zwei neue Protokolle vor: AG-UI (Agent-User Interaction Protocol) und MCP (Model Context Protocol). Diese zielen darauf ab, die Interaktion zwischen intelligenten Agents und modernen Web-Frontends zu standardisieren und modularer, testbarer und verständlicher zu gestalten.

Test-Qualität: Marco Emrich leitete die interaktive Session „How valuable are your tests?“. Er präsentierte die „Four Pillars of a Good Test“ von Vladimir Khorikov, um Kriterien für eine objektive Bewertung des Nutzens von Tests zu schaffen und so eine fundierte Diskussion über Teststrategien zu ermöglichen.

Accessibility in Komponenten: Und natürlich das beinahe-Highlight „Accessible Web Components“ von Anna Maier. Sie lieferte einen wichtigen Einblick, wie man technische Fallstricke des Shadow DOM vermeidet, um die Barrierefreiheit von Komponenten von Anfang an zu gewährleisten, und betonte die Notwendigkeit, dies auch im Produktkontext zu testen und zu dokumentieren.

Fazit: Eine lohnende Investition in die Frontend-Zukunft

Die zwei Tage auf der c’t webdev conference im Kölner MediaPark waren für mich eine absolut lohnende Investition. Die Konferenz lieferte nicht nur einen umfassenden Überblick über die aktuellen Tools und Frameworks (von Signals bis React Fullstack), sondern beleuchtete vor allem die strategischen und methodischen Herausforderungen der Branche. Der Fokus lag klar auf der Zukunft der Entwicklerrolle: Wir bewegen uns vom reinen Code-Schreiber hin zum Orchestrator, der AI strukturiert einsetzt und dabei die menschliche Urteilsfähigkeit (Human Judgement) behält.

Die wichtigste Erkenntnis: Der Mensch bleibt die Kontrollinstanz

Die entscheidenden Takeaways liegen für mich in der methodischen Disziplin und Empathie. Wir haben gelernt, dass wir AI nicht blind vertrauen dürfen (Stichwort: Trust Paradox bei Architekturmängeln), sondern dass unser menschliches Urteilsvermögen und die Fähigkeit zur Empathie die unverzichtbaren Kontrollinstanzen bleiben.

Networking und Empfehlung

Abgesehen vom Inhalt war die Atmosphäre auf der Konferenz herausragend. Die Teilnehmer:innen waren sehr freundlich und offen für einen fachlichen Austausch, was das Networking sehr erleichtert hat.

Ich kann die c’t webdev conference definitiv uneingeschränkt weiterempfehlen, da sie wertvolle Beiträge und tiefgreifende Infos aus der Tech-Branche im Bereich Frontend liefert. Die Konferenz richtet sich an diejenigen, die wissen wollen, wie man die Zukunft baut, nicht nur, wie man sie benutzt. Ob ich im nächsten Jahr wieder dabei bin, steht noch offen – schließlich soll man als Entwickler auch mal über den Tellerrand hinausschauen. Aber die Impulse aus Köln sind gesetzt und werden meine Arbeit nachhaltig prägen.

Als technologieagnostische Konferenz bietet das SAG weniger Deep Dives, dafür aber einen breit gefächerten und gut zugänglichen Überblick über den aktuellen „Architektur-Mainstream“ in Deutschland. Man trifft viele bekannte Gesichter und das Programm ist üblicherweise mit namhaften nationalen wie internationalen Sprecherinnen und Sprechern besetzt. In diesem Jahr etwa mit Bernd Ruecker (Co-Founder Camunda, mit – Überraschung – einem halben, aber sehr sympathischen Werbevortrag), Cheryl Hung (ehem. CNCF), Alistair Cockburn (Mitautor des Agilen Manifests) oder Gregor Hohpe (dessen launisch-meinungsstarke Vorträge ich seit jeher mag).

Der Nachteil dieser breiten und bewusst agnostischen Ausrichtung liegt allerdings auf der Hand: Viele Themen bleiben eher an der Oberfläche. Auch in diesem Jahr gab es ausschließlich Talks der Kategorien „Beginner“ und „Intermediate“ – wirklich neue Erkenntnisse sind dementsprechend selten.

Wir waren dennoch vor Ort – und möchten im Folgenden ein paar Eindrücke teilen.

Themenlandschaft: weniger AI-Dominanz als erwartet

Ein Blick auf die Agenda brachte die erste Überraschung. Trotz ordentlicher Präsenz war AI nicht erdrückend dominant – für eine Architekturkonferenz zur aktuellen Zeit fast wohltuend. „Nur“ ungefähr jeder sechste Talk drehte sich explizit um die Themen AI, wobei natürlich sehr viele Sessions das Thema zumindest gestreift haben. Im Sprachgebrauch des Gartner Hype Cycle sind wir nun wohl endgültig über den Peak of Inflated Expectations hinaus und arbeiten uns langsam, aber sicher, hin zu wirklichen und nachhaltigen Use Cases.

Statt GenAI waren sozio-technologische Fragestellungen oder auch der Dauerbrenner DDD in diesem Jahr wieder deutlich präsenter.

Auch Green IT, ein Thema, von dem ich mir vor drei bis vier Jahren eine dauerhafte Etablierung erhofft hatte und das spätestens vom energieverschlingenden GenAI-Hype ein wenig in den Hintergrund gedrängt worden ist, war (für mich) überraschend präsent. Letzteres mag damit zu tun haben, dass das iSAQB seit vergangenen Jahr ein neues Modul „Green IT“ in seiner Advanced-Zertifizierung anbietet [1].

Vibe Coding, Verantwortung und Plattformarchitektur

Unter den Vorträgen ist mir der Talk „Vibe Coding Auth Without Melting Down!“ von Cheryl Hung besonders in Erinnerung geblieben [2]. Er ging der Frage nach, ob sich auch fehlerintolerante Bereiche wie Authentifizierung mittels Vibe Coding lösen lassen. Die Antwort: It depends. In ihrem Beispiel zeigte sie eine mit Claude Code generierte Authentifizierungslösung, die funktional war, aber typische handwerkliche Anfängerfehler enthielt – etwa die Verwendung veralteter Hash-Bibliotheken oder das unbeabsichtigte Leaken von Nutzerinformationen [3]. Das deckt sich sehr mit meinen eigenen Erfahrungen: Vibe Coding liefert einen erstaunlich brauchbaren, aber eben nicht fehlerfreien Ausgangspunkt [4].

Spannend war allerdings weniger der Code selbst, sondern Cheryls Vorgehen: Sie hat die Sicherheitslücken nicht eigenhändig gesucht, sondern Claude Code im einmal generierten Code gezielt nach Schwachstellen analysieren lassen – eine Vorgehensweise, die in der Praxis zunehmend eingesetzt wird [5]. Einerseits nicht unerwartet, andererseits irgendwie faszinierend – das LLM „weiß“ grundsätzlich von diesen Schwachstellen, muss aber erst in die richtige Richtung geleitet werden.

Damit bleibt Vibe Coding für mich auf einem Niveau, das signifikante Geschwindigkeitsvorteile ermöglicht – solange man den Leitsatz beachtet: Never vibe code an app you wouldn’t be able to code yourself. Ob das im Startup-Kontext immer beherzigt wird? We will see…

Als möglichen Lösungsansatz griff Cheryl das Konzept Shift Down Security auf. Während Shift Left als etabliertes Prinzip die frühzeitige Verlagerung von Verantwortung – etwa für Qualität, Tests, Sicherheit oder Architektur – in die Entwicklungsteams und in die frühe Phase des Entwicklungsprozesses beschreibt, setzt Shift Down an einer anderen Stelle an: Statt Verantwortung weiter nach vorne zu schieben, wird sie bewusst nach unten, also auf Plattform- und Infrastruktur-Level, verlagert [6][7].

Dort werden Sicherheitsmechanismen technisch und organisatorisch verankert – etwa durch vordefinierte, abgesicherte Base Images, verpflichtende Policies, vorstrukturierte Toolchains oder Plattform-Guardrails, die bestimmte Fehler (menschliche wie maschinelle) gar nicht erst zulassen. Dieser Gedanke deckt sich stark mit dem Prinzip sogenannter Enabling Constraints: Bedingungen, die nicht einschränken, sondern Qualität und Sicherheit gezielt ermöglichen [8].

Ein Konzept, das sowohl menschlichen als auch KI-basierten Entwicklerwerkzeugen hilft, typische Fehler gar nicht erst entstehen zu lassen. Und noch dazu ein netter Querverweis zum Talk von Michael Mahlberg war, in welchem Enabling Constraints eine wichtige Rolle einnehmen [9].

Der Übergang von Vibe Coding zu Shift Down war für meinen Geschmack etwas abrupt, zumal die gezeigten Authentifizierungsfehler kaum über Plattformmechanismen lösbar gewesen wären. Trotzdem ein sehr gelungener Talk mit einem prägnanten Beispiel sowie einem für mich neuen und interessanten Konzept.

Hexagons, Ports & Adapter

Auch der Vortrag von Alistair Cockburn zur hexagonalen Architektur [10] – laut ihm selbst eine der drei schlimmsten Benennungen von Architekturkonzepten überhaupt – war eine der Sessions, die gleichzeitig unterhaltsam, temporeich und technisch fundiert waren. Zum einen ist es schlicht faszinierend, den Urheber eines Architekturstils über Historie, Motivation und ursprüngliches Designziel sprechen zu hören. Zum anderen hat Alistair den Vortrag sehr geschickt mit konkreten Implementationsbeispielen aus unterschiedlichen Sprachen kombiniert.

Allein das Tempo machte den Talk für mich zum anspruchsvollsten Vortrag, den ich die Tage gehört habe – und damit zur willkommenen Abwechslung zu den insgesamt sehr gut gemachten, aber oft sehr einsteigerorientierten Sessions. Ein einzelnes fachliches Learning würde ich rückblickend gar nicht herausgreifen. Stattdessen hat sich mein Eindruck bestätigt, dass Port-&-Adapter-Architekturen zu den Stilformen gehören, mit denen sich jede Entwicklerin und jeder Architekt ernsthaft beschäftigt haben sollte (und spätestens dann versteht, wie ich von Hexagons zu Ports & Adaptern komme).

Fazit: Vor allem eine gute Orientierung

Was bleibt für mich am Ende vom SAG? Am Ende war es inhaltlich zumeist nicht revolutionär, aber durchaus wertvoll. AI war präsent, DDD sowieso – und manche Konzepte wirken erstaunlich robust gegenüber Hype-Zyklen. Vielleicht ist genau das der eigentliche Reiz des SAG: Man nimmt selten ein einzelnes atemberaubendes Konzept mit nach Hause, aber jedes Jahr ein etwas klareres Verständnis davon, warum sich bestimmte Ideen in der Architektur so hartnäckig halten. Und vielleicht reicht das völlig.

Referenzen

1. iSAQB Advanced Level Module – Green IT
   https://isaqb.org/certifications/advanced-level/green-it/ 
2. Keynote: Vibe Coding Auth Without Melting Down!
   https://conferences.isaqb.org/software-architecture-gathering/session/keynote-vibe-coding-auth-without-melting-down/ 
3. Cheryl Hung – Vibe Coding Auth Without Melting Down (Slides)
   https://www.slideshare.net/slideshow/cheryl-hung-vibe-coding-auth-without-melting-down-isaqb-software-architecture-gathering-2025-pdf/284317660 
4. Ein halber Tag im Leben eines Vibecoders
   https://dev.atra.consulting/engineering/ein-halber-tag-im-leben-eines-vibecoders 
5. Passing the Security Vibe Check: The Dangers of Vibe Coding
   https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding 
6. Shift-Down Security (SIG-Security Working Paper)
   https://raw.githubusercontent.com/kubernetes/sig-security/main/sig-security-docs/papers/shift-down/shift-down-security.md 
7. What is Shift-Down Security?
   https://nirmata.com/2024/09/13/what-is-shift-down-security/ 
8. The Magic Power of Enabling Constraints
   https://www.scrum.org/resources/blog/magic-power-enabling-constraints
9. Now We’ve Given Them Every Freedom – and They Still Don’t Do What We Want
   https://conferences.isaqb.org/software-architecture-gathering/session/now-weve-given-them-every-freedom-and-they-still-dont-do-what-we-want/ 
10. The Hexagonal or Ports & Adapters Architecture
    https://conferences.isaqb.org/software-architecture-gathering/session/the-hexagonal-or-ports-adapters-architecture/
    

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

Warum Barrierefreiheit mehr ist als nur eine gesetzliche Vorgabe

Viele Unternehmen betrachten digitale Barrierefreiheit lediglich als eine gesetzliche Pflicht, die es zu erfüllen gilt. Doch wer sich nur auf die Mindestanforderungen konzentriert, verpasst enormes Potenzial.

Barrierefreiheit ist nicht nur ein Zeichen für soziale Verantwortung – sie bietet handfeste wirtschaftliche Vorteile:

In diesem Artikel zeigen wir Ihnen, wie Unternehmen langfristig von Barrierefreiheit profitieren und wie sie A11Y erfolgreich in ihre digitale Strategie integrieren können.

1. Wirtschaftliche Vorteile: Warum Barrierefreiheit ein Wettbewerbsvorteil ist

1.1 Größere Reichweite & neue Zielgruppen erschließen

15 % der Weltbevölkerung leben mit einer Behinderung – das sind über 1 Milliarde Menschen mit einer kollektiven Kaufkraft von über 8 Billionen US-Dollar (Quelle: The Return on Disability Report).

Wer eine barrierefreie Website anbietet, öffnet seine Angebote für:

• Menschen mit Seh-, Hör- oder Mobilitätseinschränkungen.
• Ältere Nutzer, die auf größere Schrift oder einfache Bedienung angewiesen sind.
• Kunden mit temporären Einschränkungen (z. B. gebrochener Arm, schlechte Lichtverhältnisse).
  

Fallbeispiel: Ein Online-Shop, der seine Navigation und Checkout-Prozesse barrierefrei optimiert hat, konnte seine Conversion-Rate um 20 % steigern, da mehr Kunden ihren Kauf erfolgreich abschließen konnten.

1.2 Verbesserte Nutzererfahrung & höhere Conversion-Rate

Eine barrierefreie Website ist für alle Nutzer einfacher zu bedienen. Durch klare Navigation, optimierte Formulare und eine bessere Struktur wird die User Experience erheblich verbessert.

Höhere Verweildauer: Nutzer bleiben länger auf einer Website, die gut lesbar und leicht verständlich ist.
Geringere Absprungraten: Komplexe oder schlecht bedienbare Websites führen zu Frustration – und Nutzer springen ab.
Mehr abgeschlossene Transaktionen: Besonders im E-Commerce ist eine barrierefreie Kaufabwicklung ein entscheidender Faktor.

Fallbeispiel: Ein Finanzdienstleister reduzierte seine Support-Anfragen um 35 %, nachdem er seine Online-Formulare für Screenreader-Nutzer optimiert hatte.

1.3 Barrierefreiheit als SEO-Booster für mehr organischen Traffic

Suchmaschinen wie Google bevorzugen barrierefreie Websites. Warum?
Semantischer HTML-Code mit klaren Strukturen wird von Google besser verstanden.
Alternativtexte für Bilder helfen nicht nur Screenreadern, sondern auch der Bildersuche.
Schnellere Ladezeiten durch optimierte Inhalte verbessern das Google-Ranking.

Google’s Algorithmus ist darauf ausgelegt, barrierefreie Inhalte besser zu bewerten. Unternehmen, die A11Y umsetzen, profitieren also ganz automatisch von einer besseren Auffindbarkeit in den Suchergebnissen.

Fallbeispiel: Eine Nachrichten-Website implementierte barrierefreie Maßnahmen und steigerte ihre Sichtbarkeit in der Google-Suche um 27 %.

2. Erfolgreiche Unternehmen setzen auf Barrierefreiheit – Praxisbeispiele

2.1 Apple – Vorreiter in Sachen digitale Inklusion

Apple setzt seit Jahren auf eingebaute Barrierefreiheitsfunktionen, darunter:

• VoiceOver (Screenreader für blinde Nutzer).
• Hohe Kontraste & Farbfilter für Menschen mit Sehschwäche.
• AssistiveTouch für motorisch eingeschränkte Nutzer.

Erfolg: Apple hat eine treue Nutzerbasis in der inklusiven Tech-Community aufgebaut, die ihre Produkte bevorzugt.

2.2 LinkedIn – Mehr Reichweite durch inklusive Inhalte

LinkedIn hat eine Funktion eingeführt, mit der Nutzer Alt-Texte für Bilder hinzufügen können. Dadurch sind Beiträge für blinde und sehbehinderte Menschen verständlicher.

Erfolg: Die Engagement-Rate auf barrierefreien Posts stieg messbar an.

3. Strategische Maßnahmen für Unternehmen – So gelingt langfristige Barrierefreiheit

Barrierefreiheit ist kein einmaliges Projekt – sie muss langfristig in digitale Strategien integriert werden.

Schritt 1: A11Y als festen Bestandteil der Unternehmenskultur etablieren

• Barrierefreiheit von Anfang an in neue Web-Projekte integrieren.
• Mitarbeiterschulungen durchführen, um A11Y-Kompetenzen zu stärken.
• Externe Experten einbinden, falls internes Know-how fehlt.

Schritt 2: Regelmäßige Audits & Optimierungen durchführen

• Website & digitale Plattformen jährlich auf Barrierefreiheit prüfen.
• Nutzerfeedback einholen und Probleme kontinuierlich beheben.
• Technische Standards (WCAG 2.1) regelmäßig updaten.

Schritt 3: Barrierefreie Inhalte & Kommunikation sicherstellen

• Marketingmaterialien inklusiv gestalten (z. B. Untertitel in Videos, barrierefreie PDFs).
• Alternativtexte für alle Grafiken in Blogartikeln & Social Media nutzen.
• Klare, verständliche Sprache in Kundenkommunikation & Websites verwenden.

Fazit

Barrierefreiheit ist kein Kostenfaktor, sondern eine Investition in nachhaltigen Erfolg. Unternehmen, die sie konsequent umsetzen, profitieren von:

Lassen Sie uns gemeinsam eine digitale Welt für alle schaffen! Kontaktieren Sie uns für eine unverbindliche Erstberatung und starten Sie Ihre A11Y-Optimierung noch heute.

Unsere Expertise

Mit unserer erfahrungsreichen Expertise unterstützen wir Unternehmen bei der barrierefreien Gestaltung ihrer digitalen Angebote. Unsere Dienstleistungen umfassen:

• Technische Umsetzung: Von der Optimierung bestehender Seiten bis hin zur Erstellung neuer, barrierefreier Lösungen.
• Barrierefreiheits-Audits: Wir prüfen Ihre Website auf Konformität mit den WCAG-Standards.
• Strategieberatung: Wir helfen Ihnen, Barrierefreiheit strategisch in Ihre digitalen Prozesse zu integrieren.
  

Besuchen Sie auch gerne für mehr Informationen unsere Website speziell zu diesem Thema!

atra.consulting/barrierefreiheit

Barrierefreiheit

Machen Sie Ihre Website barrierefrei – für mehr Reichweite und rechtliche Sicherheit! Wir helfen Unternehmen, digitale Angebote inklusiver, zugänglicher und gesetzeskonform zu gestalten.

Lassen Sie uns gemeinsam die digitale Welt inklusiver gestalten!

In einem kostenlosen Erstgespräch analysieren wir den aktuellen Stand Ihrer Website und zeigen Ihnen konkrete Maßnahmen auf, wie Sie sie für eine breitere Zielgruppe zugänglich machen können. So verbessern Sie nicht nur die User Experience, sondern stärken auch Ihre Marke und steigern Ihre Reichweite.

Kontaktieren Sie uns jetzt und machen Sie den ersten Schritt zu einer digitalen Zukunft, die niemanden ausschließt!

Ihr Ansprechpartner

Timo Kaiser

Senior Software Engineer Consultant
Web-Entwickler / A11Y-Spezialist

t.kaiser@atra.consulting
+49 1520 2380444

Timo kontaktieren

Barrierefreiheit als Erfolgsfaktor

Digitale Barrierefreiheit sorgt nicht nur für eine bessere Nutzererfahrung, sondern wird für viele Unternehmen ab 2025 zur Pflicht. Doch wie setzt man eine barrierefreie Website oder einen Online-Shop konkret um?

Dieser Artikel zeigt Ihnen die wichtigsten Maßnahmen, um Ihre Website zugänglich, nutzerfreundlich und gesetzeskonform zu gestalten. Dabei orientieren wir uns an den Web Content Accessibility Guidelines (WCAG) – dem internationalen Standard für digitale Barrierefreiheit.

1. Die drei Stufen der WCAG – Welche Anforderungen gelten?

Die Web Content Accessibility Guidelines (WCAG) definieren drei Stufen der Barrierefreiheit:

A (Basisanforderungen):

• Alternative Texte für Bilder, damit Screenreader sie erfassen können.
• Inhalte müssen per Tastatur bedienbar sein (z. B. keine Mauspflicht).
• Kein automatisches Abspielen von Videos oder Audiodateien.

AA (Empfohlen für Unternehmen – Standard für gesetzliche Vorgaben):

• Hohe Farbkontraste zwischen Text und Hintergrund.
• Untertitel für Videos & Alternativen für Audio-Inhalte.
• Klare Navigationsstruktur & konsistentes Design.

AAA (Höchster Standard):

• Gebärdensprachvideos für hörgeschädigte Nutzer.
• Einfache Sprache für kognitive Barrierefreiheit.
• Keine Zeitlimits für Eingaben (z. B. Formulare).

Empfehlung: Unternehmen sollten mindestens Stufe AA umsetzen, da dies gesetzliche Anforderungen (BFSG ab 2025) erfüllt und die beste Balance zwischen Aufwand und Nutzen bietet.

2. Technische & gestalterische Maßnahmen für eine barrierefreie Website

2.1 Barrierefreie Texte & Inhalte

• Kurze, verständliche Sätze & klare Struktur (Überschriften, Absätze, Listen).
• Alternativtexte für Bilder & Icons, damit Screenreader sie interpretieren können.
• Einfache Sprache verwenden, falls komplexe Themen erläutert werden.
• Keine alleinige Nutzung von Farben zur Informationsvermittlung (z. B. Fehlermeldungen müssen mehr als nur eine Farbänderung haben).

2.2 Design & Usability optimieren

• Hoher Farbkontrast (mind. 4,5:1 zwischen Text & Hintergrund gemäß WCAG 2.1 AA).
• Skalierbare Schriftgrößen & flexible Layouts, um Lesbarkeit zu gewährleisten.
• Keine flackernden Animationen oder schnell blinkenden Inhalte, um epileptische Anfälle zu vermeiden.
• Konsistente & logische Navigation, damit Nutzer sich leicht orientieren können.

2.3 Technische Umsetzung & Entwicklung

• Semantisches HTML (richtige Nutzung von <h1>–<h6>, <nav>, <main>, <article> für eine logische Seitenstruktur).
• ARIA-Attribute nutzen, um Screenreader zu unterstützen.
• Tastaturfreundliche Bedienung – Alle interaktiven Elemente müssen ohne Maus nutzbar sein.
• Formulare mit eindeutigen Labels & Fehlermeldungen, damit Nutzer verstehen, was von ihnen verlangt wird.

3. Praktische Tools zur Überprüfung der Barrierefreiheit

Um zu testen, ob Ihre Website barrierefrei ist, gibt es zahlreiche kostenlose Tools:

Automatisierte Test-Tools für Unternehmen & Entwickler

Google Lighthouse → Testet Barrierefreiheit & SEO in Chrome DevTools.
WAVE (WebAIM Accessibility Tool) → Analysiert Farbkontraste, Alternativtexte & Struktur.
axe DevTools → Browser-Erweiterung für Entwickler zur WCAG-Prüfung.

Manuelle Tests & Screenreader-Simulationen

NVDA (NonVisual Desktop Access) → Kostenloser Screenreader für Windows zur Live-Prüfung.
VoiceOver (Mac/iOS) → Eingebauter Screenreader für Apple-Geräte.
Keyboard-Only-Testing → Alle Funktionen einer Website ohne Maus navigieren und testen.

4. Roadmap zur Umsetzung – So machen Unternehmen ihre Website barrierefrei

Schritt 1: IST-Analyse & Bewertung

• Testen Sie Ihre Website mit Analyse-Tools, wie Lighthouse, WAVE oder axe DevTools.
• Notieren Sie alle Probleme, die in der Analyse auftreten.
• Nutzen Sie einen Screenreader & testen Sie die Navigation per Tastatur.

Schritt 2: Priorisierung & Strategie definieren

• Fokus auf Stufe AA der WCAG, um gesetzliche Anforderungen zu erfüllen.
• Wichtige Seiten & Funktionen zuerst optimieren (Startseite, Checkout-Prozesse).
• Falls nötig: Externe Experten für Barrierefreiheit hinzuziehen.

Schritt 3: Umsetzung & Testing

• Technische Anpassungen im Frontend & CMS umsetzen.
• Nach jeder Änderung erneut mit Test-Tools prüfen.
• Live-Tests mit echten Nutzern durchführen, z. B. mit Personen aus der Zielgruppe.

Schritt 4: Kontinuierliche Optimierung

• Regelmäßige Audits durchführen & Barrierefreiheit langfristig in den Entwicklungsprozess integrieren.
• Team-Schulungen zu A11Y-Standards durchführen.
• Feedback von Nutzern sammeln & Optimierungen umsetzen.

Ein Beispiel aus der Praxis

Wie ein mittelständischer Online-Shop Barrierefreiheit erfolgreich umgesetzt hat

Ausgangssituation:
Ein mittelständischer Anbieter für Bürobedarf betrieb seit Jahren einen gut laufenden Online-Shop. Die Website war funktional, aber nicht barrierefrei. Erste Nutzerhinweise und eine Lighthouse-Analyse zeigten: schlechte Farbkontraste, unbeschriftete Buttons und eine fehlende Tastaturnavigation erschwerten vielen Kundengruppen die Nutzung.

Umsetzung:
Das Unternehmen beauftragte eine Agentur mit einem WCAG-Audit. Die Optimierungen erfolgten in vier Phasen:

1. Analyse & Priorisierung: Fokus auf Stufe AA der WCAG.
2. Technische Umsetzung: Navigation per Tastatur, kontrastoptimiertes Design, saubere HTML-Struktur, Alt-Texte.
3. Testing: Kombination aus Lighthouse, WAVE und Tests mit NVDA und VoiceOver.
4. Launch & Monitoring: Veröffentlichung der optimierten Version, begleitet von einem barrierefreien Newsletter.

Ergebnis:
✅ Die Absprungrate sank um 18 %
✅ Die Conversion-Rate stieg in mobilen Ansichten um 24 %
✅ Es kamen gezielte Anfragen von Großkunden, die auf Barrierefreiheit achten
✅ Das Unternehmen wurde als vorbildlich im Branchennewsletter erwähnt

Fazit & Ausblick auf den nächsten Artikel

Barrierefreiheit ist kein einmaliges Projekt – sondern ein Bekenntnis zu Nutzerfreundlichkeit und digitaler Qualität. Es ist ein kontinuierlicher Prozess, der sowohl technische als auch gestalterische Maßnahmen erfordert. Doch der Aufwand lohnt sich: Eine barrierefreie Website verbessert die Usability, sorgt für eine größere Reichweite und erfüllt gesetzliche Vorgaben. Unternehmen, die hier investieren, profitieren auf allen Ebenen.

Lesen Sie im dritten Teil der Serie, wie Unternehmen langfristig von Barrierefreiheit profitieren – mit echten Erfolgsbeispielen und strategischen Tipps!

Unsere Expertise

Mit unserer erfahrungsreichen Expertise unterstützen wir Unternehmen bei der barrierefreien Gestaltung ihrer digitalen Angebote. Unsere Dienstleistungen umfassen:

• Technische Umsetzung: Von der Optimierung bestehender Seiten bis hin zur Erstellung neuer, barrierefreier Lösungen.
• Barrierefreiheits-Audits: Wir prüfen Ihre Website auf Konformität mit den WCAG-Standards.
• Strategieberatung: Wir helfen Ihnen, Barrierefreiheit strategisch in Ihre digitalen Prozesse zu integrieren.
  

Besuchen Sie auch gerne für mehr Informationen unsere Website speziell zu diesem Thema!

atra.consulting/barrierefreiheit

Barrierefreiheit

Machen Sie Ihre Website barrierefrei – für mehr Reichweite und rechtliche Sicherheit! Wir helfen Unternehmen, digitale Angebote inklusiver, zugänglicher und gesetzeskonform zu gestalten.

Lassen Sie uns gemeinsam die digitale Welt inklusiver gestalten!

In einem kostenlosen Erstgespräch analysieren wir den aktuellen Stand Ihrer Website und zeigen Ihnen konkrete Maßnahmen auf, wie Sie sie für eine breitere Zielgruppe zugänglich machen können. So verbessern Sie nicht nur die User Experience, sondern stärken auch Ihre Marke und steigern Ihre Reichweite.

Kontaktieren Sie uns jetzt und machen Sie den ersten Schritt zu einer digitalen Zukunft, die niemanden ausschließt!

Ihr Ansprechpartner

Timo Kaiser

Senior Software Engineer Consultant
Web-Entwickler / A11Y-Spezialist

t.kaiser@atra.consulting
+49 1520 2380444

Timo kontaktieren

Digitale Inklusion als Wettbewerbsvorteil

In einer zunehmend digitalisierten Welt ist Barrierefreiheit kein nettes Extra mehr – sie ist eine Notwendigkeit. Unternehmen, die ihre Websites und Online-Shops nicht für alle Nutzergruppen zugänglich machen, schließen Millionen potenzieller Kunden aus, riskieren rechtliche Konsequenzen und verschenken wirtschaftliches Potenzial.

Dabei bietet eine barrierefreie Website nicht nur einen gesellschaftlichen Mehrwert, sondern sorgt auch für mehr Reichweite, eine bessere Nutzererfahrung und langfristige Wettbewerbsfähigkeit. Doch was bedeutet digitale Barrierefreiheit konkret, welche gesetzlichen Anforderungen müssen Unternehmen erfüllen und warum sollten sie sich aktiv darum kümmern?

Dieser Artikel gibt Ihnen einen umfassenden Überblick darüber, warum Web Accessibility (A11Y) ein entscheidender Erfolgsfaktor für Unternehmen ist.

Was bedeutet digitale Barrierefreiheit?

Barrierefreiheit im Web bedeutet, dass digitale Inhalte von allen Menschen uneingeschränkt genutzt werden können – unabhängig von körperlichen oder kognitiven Einschränkungen.

Betroffene Nutzergruppen:

• Menschen mit kognitiven Einschränkungen → Profitieren von klar strukturierten, leicht verständlichen Texten.
• Sehbehinderte und blinde Menschen → Nutzen Screenreader, Braille-Displays oder benötigen hohe Kontraste.
• Menschen mit motorischen Einschränkungen → Navigieren per Tastatursteuerung oder Spracherkennung.
• Hörgeschädigte Nutzer → Sind auf Untertitel und Transkriptionen für audiovisuelle Inhalte angewiesen.
  

Eine barrierefreie Website berücksichtigt all diese Aspekte und stellt sicher, dass jeder Besucher die Inhalte gleichermaßen erfassen und bedienen kann.

Wirtschaftlicher Nutzen von Barrierefreiheit

Oft wird Barrierefreiheit als zusätzliche Belastung betrachtet. Tatsächlich bringt sie jedoch messbare Vorteile mit sich:

Größere Zielgruppe & höhere Reichweite

• Über 15% der Weltbevölkerung leben mit einer Behinderung – das sind Millionen potenzieller Kunden, die durch Barrierefreiheit besser erreicht werden können.
• Ältere Menschen profitieren ebenfalls von besserer Lesbarkeit und einfacherer Navigation.
• Unternehmen, die Barrierefreiheit ignorieren, verlieren diese potenziellen Kunden an die Konkurrenz.
  

Höhere Usability für alle Nutzer

• Strukturierte Inhalte, gute Lesbarkeit und intuitive Navigation kommen allen Kunden zugute.
• Barrierefreiheit verbessert die User Experience (UX) und erhöht die Verweildauer auf der Website.
  

SEO & Google-Ranking verbessern

• Google bevorzugt barrierefreie Websites – ein besseres Ranking sorgt für mehr Sichtbarkeit.
• Klare Seitenstrukturen, alternative Bildbeschreibungen und schnelle Ladezeiten steigern die Auffindbarkeit.
  

Mehr Conversions & Umsatz

• Untersuchungen zeigen, dass gut nutzbare Websites eine höhere Conversion-Rate erzielen.
• Durch optimierte Bestellprozesse in Online-Shops können mehr Kunden den Kauf abschließen..

Rechtliche Anforderungen: Was Unternehmen wissen müssen

EU-Richtlinie & BFSG: Ab 2025 gilt eine gesetzliche Pflicht

Das Barrierefreiheitsstärkungsgesetz (BFSG) setzt die EU-Richtlinie 2019/882 in deutsches Recht um. Ab Juni 2025 müssen viele private Unternehmen digitale Barrierefreiheit gewährleisten, darunter:

• Online-Shops
• Banken und Versicherungen
• Telekommunikationsanbieter
• E-Book- und Streaming-Dienste
• Software- und Ticketing-Plattformen
  

Verstöße können zu Abmahnungen, Geldbußen und Reputationsschäden führen. Unternehmen sollten daher jetzt handeln, um ihre digitalen Angebote rechtzeitig anzupassen.

Fazit

Digitale Barrierefreiheit ist kein freiwilliges Extra – sie wird zur Pflicht. Doch abgesehen von der gesetzlichen Notwendigkeit bietet sie signifikante wirtschaftliche Vorteile, von mehr Reichweite bis hin zu besseren Conversion-Raten. Wer frühzeitig investiert, sichert sich einen Wettbewerbsvorteil und vermeidet rechtliche Risiken.

Lesen Sie im zweiten Teil der Serie, welche praktischen Maßnahmen Sie ergreifen können, um Ihre Website barrierefrei zu machen.

Unsere Expertise

Mit unserer erfahrungsreichen Expertise unterstützen wir Unternehmen bei der barrierefreien Gestaltung ihrer digitalen Angebote. Unsere Dienstleistungen umfassen:

• Barrierefreiheits-Audits: Wir prüfen Ihre Website auf Konformität mit den WCAG-Standards.
• Strategieberatung: Wir helfen Ihnen, Barrierefreiheit strategisch in Ihre digitalen Prozesse zu integrieren.
• Technische Umsetzung: Von der Optimierung bestehender Seiten bis hin zur Erstellung neuer, barrierefreier Lösungen.
  

Besuchen Sie auch gerne für mehr Informationen unsere Website speziell zu diesem Thema!

atra.consulting/barrierefreiheit

Barrierefreiheit

Machen Sie Ihre Website barrierefrei – für mehr Reichweite und rechtliche Sicherheit! Wir helfen Unternehmen, digitale Angebote inklusiver, zugänglicher und gesetzeskonform zu gestalten.

Lassen Sie uns gemeinsam die digitale Welt inklusiver gestalten!

In einem kostenlosen Erstgespräch analysieren wir den aktuellen Stand Ihrer Website und zeigen Ihnen konkrete Maßnahmen auf, wie Sie sie für eine breitere Zielgruppe zugänglich machen können. So verbessern Sie nicht nur die User Experience, sondern stärken auch Ihre Marke und steigern Ihre Reichweite.

Kontaktieren Sie uns jetzt und machen Sie den ersten Schritt zu einer digitalen Zukunft, die niemanden ausschließt!

Ihr Ansprechpartner

Timo Kaiser

Senior Software Engineer Consultant
Web-Entwickler / A11Y-Spezialist

t.kaiser@atra.consulting
+49 1520 2380444

Timo kontaktieren

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://dev.atra.consulting/blog/die-vielen-gesichter-von-softwarearchitekten/ (abgerufen: 13. Jan. 2025).

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.

Während Agilität mit dem de-facto Standard Scrum auf Teamebene oftmals relativ leicht umzusetzen ist, stellt Skalierung der agilen Vorgehensweisen Organisationen regelmäßig vor größere Herausforderungen. Viele Frameworks wie etwa SAFe oder LeSS liefern interessante und gute Ansätze hierfür. Jedoch scheitern Organisationen regelmäßig bei der Einführung dieser, aufgrund heterogener Teams, Anforderungen und Produktlandschaften. So ist beispielsweise ein Team, welches den Checkout-Prozess eines Onlineshops verantwortet, ganz anders zu betrachten als das Team, welches die interne Cloudplattform oder einen Data Lake entwickelt. Jedes dieser Teams hat unterschiedliche Anforderungen an eine teamübergreifende Planung und Zusammenarbeit. Aufgrund der abweichenden Herausforderungen benötigt es ein anpassbares Vorgehensmodell. 

Die Strukturierung und Interaktion von Teams ist eine der größten Herausforderungen in agilen Organisationen. Besonders in der IT müssen Teams häufig komplexe Aufgaben bewältigen und dabei flexibel bleiben. Matthew Skelton und Manuel Pais bieten mit ihrem Buch „Team Topologies“ eine klare Methode, wie Teams organisiert und ihre Schnittstellen gestaltet werden können, um Effizienz, Zusammenarbeit und Anpassungsfähigkeit zu maximieren.

Die Grundidee hinter Team Topologies

• Klare Verantwortlichkeiten: Jede Teamkategorie hat definierte Ziele und Aufgaben, was den Fokus und die Effizienz erhöht. 
• Verbesserte Zusammenarbeit: Gut durchdachte Kommunikationswege und Schnittstellen reduzieren Missverständnisse. 
• Schnelle Anpassung: Enabling-Teams helfen anderen Teams, neue Technologien oder Methoden schneller einzuführen. 
• Optimierte Ressourcennutzung: Plattform-Teams schaffen gemeinsame Infrastruktur, damit sich andere Teams auf ihre Kernaufgaben konzentrieren können.

Auf diese Weise soll der Ansatz der Teamkategorien eine praxisnahe und flexible Methode bieten, um skaliertes Agilitätsmanagement in komplexen Organisationsstrukturen zu implementieren und nachhaltig zu verankern.

In kurzen Worten: Team Topologies soll die Entwicklung von Organisationen im Laufe der Zeit unterstützen, wann immer sich die Bedingungen ändern. 
Moderne Organisationsprinzipien werden gefördert und Softwareanpassungen können schneller umgesetzt werden. In der Realität bleibt es bei der immer gleichen Herausforderung, den Teams dafür entsprechend Zeit zum Testen & Lernen einzuräumen.

Schauen wir uns das Konzept in der notwendigen Tiefe an, um zu erfahren, wie diese Konzepte auch in den eigenen Teams angewendet werden könnten: 

Inhalt:

1. Conway’s Law
2. Team First
3. Vier grundlegende Topologien
4. Team-Interaktionsmodi
5. Organisatorisches Gespür
6. Topologieentwicklung
7. Team-API

1. Conway’s Law

Conway’s Law besagt:

»Jede Organisation, die ein System entwirft, wird zwangsläufig einen Entwurf erstellen, der eine Kopie ihrer Kommunikationsstruktur ist.« 

Anders formuliert: Die Organisationsstruktur und die Kommunikationswege zwischen den Teams spiegeln sich direkt in der Systemarchitektur wider. Ein einfaches Beispiel dazu zeigt die folgende Grafik.

Während Conway’s Law oft als reine Beobachtung beschrieben wird, geht der Ansatz von Team Topologies einen Schritt weiter: Es wird als aktives Gestaltungsprinzip verstanden. Anstatt zu akzeptieren, dass die Architektur die bestehenden Teamstrukturen widerspiegelt, lassen sich Teams gezielt so gestalten, dass sie eine gewünschte Architektur aktiv fördern.

Möchte man beispielsweise eine modulare, lose gekoppelte Architektur, sollten die Teams entsprechend strukturiert werden. Dies gelingt durch den Aufbau autonomer, funktionsübergreifender Teams sowie durch die Etablierung klarer Schnittstellen und definierter Verantwortlichkeiten. Dieses Prinzip wird als Inverses Conway’s Law bezeichnet. In unserem Projektalltag begegnen wir diesem Phänomen immer wieder.

Ein Beispiel aus der Praxis: Selbst sehr erfahrene Entwickler entwerfen zum Teil monolithische, fehleranfällige Strukturen – nicht aufgrund mangelnden Könnens, sondern weil:

• Architekturbausteine mit zu viel Funktionalität überladen werden, da Entwickler in diesen Bereichen besonders vertraut sind.
• Hoher Lieferdruck führt dazu, dass eigentlich isolierte Funktionalitäten schnell in bestehende Strukturen integriert werden, statt sauber gekapselt zu werden.

Ob traditionelles oder inverses Conway’s Law: Das „Störgefühl“, wenn die Softwarearchitektur nicht mehr zur Teamstruktur passt, kennt fast jeder. Sich dieses Zusammenhangs bewusst zu sein, ist der erste Schritt, um sowohl die Architektur als auch die Organisation gezielt weiterzuentwickeln.

(Mehr dazu hier: Conway´s Law – EN  / Conway´s Law DE)

2. Team First

Bei Team Topologies wird ein Team als eine stabile Gruppe von Menschen betrachtet, die am gleichen Ziel arbeiten. Verantwortlichkeiten werden keinen Einzelpersonen zugewiesen, sondern Teams.

Die Anzahl der Teammitglieder ist entscheidend, um Vertrauen zu bilden. Ein effektives Team umfasst laut Team Topologies 7 bis 9 Personen. 

Bis eine einigermaßen geschlossene Einheit entsteht, dauert es bis zu drei Monate. Es ist kaum sinnvoll, Teams nach Abschluss eines Projekts, an dem sie ein halbes Jahr gearbeitet haben, neu zu strukturieren. Die emotionale Anpassung an die Arbeitsgewohnheiten und Sichtweisen neuer Kollegen hat einen gravierenden Einfluss auf die Leistung. Nur wenn das Vertrauen in eine Organisation hoch ist, ist ein Teamwechsel einmal im Jahr ohne negative Auswirkungen möglich.

Die Autoren betonen, dass es wichtig ist, die kognitiven Fähigkeiten des Teams zu maximieren, durch die Verbesserung der Arbeitsumgebung, des Führungsstils und die Minimierung von Ablenkungen.

Diese Ansicht wird bereits in vielen bekannten Team-Konstellationen angewandt, wie beispielsweise in Projektteams, Enabling oder Transformationsteams. Die Vorteile von Teams mit klarem Fokus ohne Ablenkungen von “außen” sind nicht von der Hand zu weisen. 

John Sweller bezeichnet Kognitive Belastung mit: „Die Gesamtmenge an geistiger Anstrengung, die im Arbeitsgedächtnis aufgewendet wird.“

Drei Arten der kognitiven Belastung werden benannt:

• Intrinsische kognitive Belastung – bezieht sich auf die Faktoren, die für die Lösung der Aufgabe bedeutend sind. Beispiel: Wie kreieren wir eine neue Methode?
• Externe kognitive Belastung – bezieht sich auf die Voraussetzungen, in der die Aufgabe ausgeführt wird. Beispiel: Wie konfigurieren wir diesen Service?
• Lernbezogene kognitive Belastung – bezieht sich auf Inhalte, die erlernt werden müssen, um die Aufgabe zu lösen. Beispiel: Wie funktionieren Bank Transfers?

Mehr dazu hier: Cognitive Load Theory – DE.

Team Topologies spricht davon, die Verantwortlichkeit des Teams so zu beschränken, dass es die maximale kognitive Belastung des Teams nicht überschreitet.

Aus unserer Sicht wird es entscheidend sein, wie viel Zeit den Teams eingeräumt wird, um zu lernen, wie alltägliche Herausforderungen gemeistert werden, ohne die maximale kognitive Belastung zu überschreiten. Der Lieferdruck auf Teams und das Problem, dauerhaft an zu vielen Aufgaben parallel zu arbeiten, macht evident, wie wichtig es ist, in den Teams zu lernen, die Verantwortlichkeiten klar zu definieren und zu beschränken.

 Das Lernen im Tagesgeschäft  “nein” zu sagen, erweist sich unter hohem Lieferdruck, meist als nicht überwindbares Unterfangen und wird selten vom Management in Drucksituationen akzeptiert. Die Akzeptanz auf Managementebenen ist aber maßgeblich, um die Theorie auch in der Praxis umsetzen zu können. Hier zeigt sich für uns klar, dass die gesamte Organisation “lernen” muss.   

Eine Möglichkeit könnte der Team-First-Ansatz sein. Durch den Team-First-Ansatz soll Mitarbeitern die Möglichkeit gegeben werden, in einer Organisation erfolgreich zu sein. Anstatt ein dickes Fell oder Belastbarkeit zu benötigen, um in einer Organisation zu überleben, haben Mitarbeiter in einer Team-First-Organisation den Raum und die Unterstützung, ihre Fähigkeiten und Praktiken zu entwickeln.

3. Die vier grundlegenden Teamtopologien

Es gibt sehr viele Teamtypen in Organisationen. Der Einfachheit wegen werden diese auf vier Haupttypen reduziert. Diese betrachten das Verhalten und die Fähigkeiten der Teams und lauten wie folgt:

Stream-aligned Team: Das Team, das auf die Geschäftsveränderung ausgerichtet ist, mit einem funktionsübergreifenden Kompetenzmix und der Fähigkeit, signifikante Inkremente zu liefern, ohne auf ein anderes Team warten zu müssen.

Enabling-Team: Das Team, das andere Teams bei der Einführung und Änderung von Software im Rahmen einer Übergangs- oder Lernphase unterstützt.

Complicated-subsystem Team: Das Team mit einer besonderen Aufgabe für ein Subsystem, das zu kompliziert ist, als dass es von einem normalen Stream-ausgerichteten Team oder Plattformteam bearbeitet werden könnte. Optional und nur dann verwendet, wenn es wirklich notwendig ist.

Plattform Team: Das Team, das an der zugrunde liegenden Plattform arbeitet und Stream-ausgerichtete Teams bei der Bereitstellung unterstützt. Die Plattform vereinfacht komplexe Technologie und reduziert die kognitive Belastung für Teams.

Nehmen wir hier nochmal als Beispiel ein klassisches Unternehmen aus dem e-Commerce Bereich:

• Ein Stream-aligned Team könnte den gesamten Checkout-Prozess des Onlineshops verantworten, einschließlich der Integration neuer Payment-Dienstleister und der UX-Optimierung.
• Das Unternehmen möchte verstärkt die Vorteile der Cloud-native Entwicklung nutzen. Ein Enabling Team könnte hierbei bei der Einführung der Technologie und notwendigen Architekturmuster helfen, beispielsweise durch Schulungen, Bereitstellung von Prototypen oder Definition von Architekturpattern.

• Als complicated-subsystem-Team entwickelt eine Gruppe von Spezialisten einen hochspezialisierten Empfehlungsalgorithmus, welcher Kundinnen und Kunden passgenaue Produktempfehlungen zur Verfügung stellt.
• Unser fiktives Unternehmen hat direkt zwei Plattform-Teams, welche zum einen die interne Developer-Cloudplattform und zum anderen einen Unternehmensweiten Data-Lake zur Verfügung stellen.

4. Team-Interaktionsmodi 

Ineffektivität wird in vielen Organisationen durch schlecht definierte Interaktionen verursacht. Laut TeamTopologies läuft die Beziehung zwischen den Teams auf zwei Dinge hinaus: Wird durch die Zusammenarbeit mit einem anderen Team ein Ziel erreicht oder bietet es dem Team einen Service an. Auf diese Weise werde drei Möglichkeiten festgelegt, wie Teams interagieren können:

Zusammenarbeit enge Zusammenarbeit mit anderen Teams. Dies ist besonders nützlich, wenn Teams neue Technologien oder Techniken erforschen. Die Zusammenarbeit ermöglicht die schnelle Entdeckung neuer Dinge, da kostspielige Übergaben vermieden werden. Am besten verwendet, wenn ein hohes Maß an Anpassungsfähigkeit zwischen zwei Teams erforderlich ist.

X-as-a-Service etwas mit minimaler Zusammenarbeit nutzen oder bereitstellen.
Dieser Interaktionsmodus kann die Liefergeschwindigkeit erhöhen. Team A braucht etwas, um seinen Wert zu liefern, Team B hat eine Dienstleistung ohne großen Aufwand bereitgestellt. Es sind keine langwierigen Gespräche, Besprechungen oder Vorbereitungen erforderlich.

Unterstützen: Einem anderen Team helfen und umgekehrt, Hindernisse zu beseitigen. Der unterstützende Interaktionsmodus eignet sich am besten in Situationen, in denen ein Team die Hilfe eines anderen benötigt. Das Enabling Team versetzt zum Beispiel ein anderes Team in die Lage, effektiver zu sein, schneller zu lernen, eine neue Technologie besser zu verstehen oder Hindernisse zu entdecken und zu beseitigen.  Domain-Driven Design kann hier ein gutes Hilfsmittel sein.

5. Organisatorisches Gespür

Mit “Organisatorisches Gespür” ist gemeint: die Situation zu erkennen und anzupassen. Unternehmen müssen flexibel sein, um sich an Veränderungen anzupassen. Dazu gehört die Anpassung der Struktur und Abläufe. Eine Organisation sollte in der Lage sein, die richtigen Teamstrukturen und Interaktionsmodi anzuwenden.

Woran erkennt man also, dass eine Organisation sich weiterentwickeln muss?

1. Die Software wird für ein Team zu komplex. Während am Anfang jeder ein umfassendes Verständnis davon hat, was vor sich geht, wird das immer schwieriger. Dadurch verlagert sich der Fokus von echten Prioritäten auf den Versuch, Leute zu finden, die kompetent genug sind, um ein bestimmtes Problem zu lösen.
2. Die Lieferfrequenz verlangsamt sich. Die Teammitglieder sehen, dass eine Lieferung mehr Zeit und mehr Schritte erfordert. Um dies zu vermeiden, müssen Teams autonom sein und dürfen nicht darauf warten, dass andere Teams eine neue Infrastruktur erstellen.
3. Mehrere Geschäftsdienste basieren auf einer großen Anzahl zugrunde liegender Dienste. In einigen Sektoren wie Finanzen, Versicherungen, Regierung usw. können hochrangige Dienste auf Dienste auf niedrigerem Niveau angewiesen sein. Die Lösung könnte darin bestehen, die Dienste auf niedrigerer Ebene zu “plattformisieren” und für jeden Dienst auf hoher Ebene Stream-ausgerichtete Teams einzusetzen.

Hier spricht man von der Kompetenz der OrganisationswahrnehmungDies ist die Fähigkeit, die Organisationsituation so zu erfassen oder zu spüren, dass das Überleben der Organisation sichergestellt wird. Einige der Dinge, die eine Organisation „spüren“ muss, sind:

• Müssen die Teaminteraktionsmodi geändert werden?
• Was behindert den Arbeitsfluss für ein bestimmtes Team?
• Sollen wir ein bestimmtes Tool bauen oder können wir es von einem Anbieter bekommen?

Es gibt nicht wenige Systeme, die über viele Jahre hinweg entstanden sind. Diese Systeme haben Abhängigkeiten, die nicht außer Acht gelassen werden können. Die Teaminteraktionsmodi passen sich an das System an und nicht umgekehrt. Die Frage, die sich stellt, ist: Was kann oder muss ich tun, um die Komplexität des Systems zu verringern, damit die Vorteile der Teaminteraktionsmodi zum Tragen kommen, und ist dies aufgrund der Größe des Systems überhaupt möglich?

6. Topologieentwicklung

Sobald eine Organisation auf neue Herausforderungen reagiert, ist davon auszugehen, dass Teams untereinander anders als zuvor interagieren werden.

Dies kann bedeuten, dass Teams neu strukturiert oder neu zusammengesetzt werden, um spezifische Probleme anzugehen oder neue Technologien zu implementieren. Gleichzeitig können sich die Arbeitsabläufe und Prozesse ändern, um die Zusammenarbeit zwischen den Teams zu verbessern. Das übergeordnete Ziel besteht darin, sicherzustellen, dass die Teams flexibel genug sind, um sich an veränderte Anforderungen anzupassen, und dass ihre Interaktionen effektiv sind, um die Ziele der Organisation zu erreichen. Dies erfordert eine kontinuierliche Bewertung und Anpassung der Teamstrukturen und -interaktionen im Einklang mit den sich ändernden Anforderungen und Zielen der Organisation.

7. Team-API 

Eine Beschreibung der Interaktionen mit dem jeweiligen Team: Code, Versionierung, Wiki und Dokumentation, Praktiken und Prinzipien, Kommunikation, Arbeitsinformationen und einiges mehr. Ziel ist es, anderen Teams transparent und in einem einfachen Überblick zu zeigen, an was, wie, mit wem, das Team arbeitet. Ein gutes Beispiel für eine Team API hat Team Topologies selbst auf Github.com veröffentlicht.

Zusammenfassung

Die sieben Grundideen von Team Topologies bieten Vorteile, die die Effektivität der Teamarbeit in Unternehmen steigern können. 

Die Fähigkeit zur Flexibilität und Anpassungsfähigkeit, denn durch die Strukturierung von Teams können Unternehmen schnell auf Veränderungen reagieren und neue Anforderungen integrieren. 

Das Übertragen von Verantwortlichkeiten an eigenständige Teams fördert die Autonomie und Eigenverantwortung, beschleunigt die Entscheidungsfindung und fördert agile Reaktionen auf Herausforderungen (siehe 3. Grundidee), wenn das Management mit einbezogen wird und Verantwortung an die Teams weitergibt.
Ferner ermöglicht Team Topologies die Bildung hochspezialisierter Teams, die sich auf bestimmte Aufgaben oder Technologien konzentrieren können, die Entwicklung von Expertise fördert und die Effizienz steigert. 

Teams dieser Art gibt es bereits zuhauf in Organisationen. Die große Herausforderung sind die Abhängigkeiten der Teams, des Produkts und nicht zuletzt, wie viel Zeit den Teams eingeräumt wird, um zu wachsen und die Fähigkeiten zu entwickeln, die es benötigt. 

Wenn spezialisierte Teams in ihren eigenen Bereichen isoliert arbeiten und den Informationsaustausch behindern, können Kommunikationsbarrieren entstehen. Das Entstehen von Silos innerhalb des Unternehmens, wenn einzelne Teams isoliert arbeiten und der Gesamtüberblick über Projekte verloren geht, steigt.
Dies kann die Synergien zwischen den Teams behindern und die Effizienz beeinträchtigen. Zudem kommt die zunehmende Komplexität und der Koordinationsaufwand, wenn eine Vielzahl spezialisierter Teams gleichzeitig agiert. Eine klare Fokussierung auf gemeinsame Ziele kann dieses Problem mindern. Hierbei könnten sich die Vorgehensweisen von Team Topologies als klarer Vorteil erweisen. Zwar sind nicht alle Ideen von Team Topologies neu, jedoch ermöglicht die globale Sicht auf die Teams eine einheitliche strategische Ausrichtung und ein gemeinsames Vokabular für IT-Projekte. 

Zusammenfassend hier eine Kurzübersichtskarte: QRC Team Topologies

Herausforderungen bei der Umsetzung

Die Theorie von Team Topologies ist vielversprechend, aber wie bei jedem Ansatz gibt es auch Herausforderungen:

• Management-Unterstützung: Ohne ein Management, das die Prinzipien von Autonomie und psychologischer Sicherheit versteht und fördert, wird es schwer, die Teams nachhaltig zu etablieren. Ein Führungsstil der Haltung “Servant Leadership” ist eine Grundvorraussetzung für den Erfolg und die Produktivität der Teams.
• Silos und Abhängigkeiten: Oft arbeiten Teams isoliert voneinander. Hier braucht es gezielte Interaktionsmodi, um Synergien zu fördern.
• Zeit und Ressourcen: Teams benötigen Raum und Zeit, um ihre Arbeitsweisen zu entwickeln und zu verbessern. Teams müssen mit entsprechenden Personen besetzt und “ausgebildet” werden. Dies wird häufig unterschätzt.

Schlussfolgerung und Einladung zur Diskussion zur Verbesserung ihrer Teams Team Topologies bietet eine mächtige Grundlage, um Teams effektiver, autonomer und besser miteinander vernetzt zu gestalten. Die Implementierung erfordert jedoch eine bewusste Anpassung an die jeweilige Organisation und ein Management, das diese Ansätze aktiv unterstützt.  

Diskussionsfragen an den Leser: 

• Wie sieht es bei Euch im Unternehmen aus? Welche Erfahrungen haben Sie mit der Strukturierung von Teams gemacht, und welche Ansätze haben bei Ihnen besonders gut funktioniert?
• Wie können Organisationen sicherstellen, dass ihre Teamstrukturen nicht nur effizient, sondern auch anpassungsfähig sind?
• Welche Herausforderungen sehen Sie bei der Implementierung der vier Teamarten in Ihrem eigenen Umfeld?

Kaschef Yawar

Geschäftsbereichsleitung »Handel« Prokurist

Kaschef Yawar ist ein erfahrener agiler Coach und Berater mit über 15 Jahren Erfahrung in der IT-Branche. In seinen Rollen als Scrum Master, Agiler Coach und Trainer hat er erfolgreich agile Methoden in verschiedenen Unternehmen und auf unterschiedlichen Ebenen eingeführt und begleitet. Sein Fokus liegt dabei hauptsächlich auf Scrum und Kanban, sowie der Arbeit in skalierbaren Frameworks wie SAFe, LeSS und Nexus. Besonders wichtig ist ihm die wertgetriebene Entwicklung, bei der er stets darauf achtet, dass die entwickelten Produkte und Dienstleistungen einen echten Mehrwert für die Kunden schaffen.

k.yawar@atra.consulting    

• LinkedIn

Auch wir spenden im geschäftlichen Umfeld zu Weihnachten, anstatt zu schenken. Sinnvoll sollte die Spende aber sein, also einem guten Zweck dienen. Hier wird es dann spannend, denn die Auswahl an möglichen Spendenorganisationen und -empfängern ist riesig. Eine entsprechende Google-Suche zum Stichwort »Weihnachtsspende« brachte alleine 135.000 Ergebnisse hervor.

Hierunter finden sich großartige caritative Einrichtungen, aber eben auch so viele, dass eine Auswahl eigentlich nur dem Zufallsprinzip folgen kann, was für uns aber kein gutes Geschäftsprinzipo ist. Als IT-Beratungsgruppe sollte unsere Spende auch »irgendwie technologisch« sein und vielleicht auch mal den Fokus auf andere problematische oder übersehene Bereiche, für die eine finanzielle Zuwendung sinnvoll ist, lenken.

Da wir Open-Source-Software (»OSS«) nicht nur selbst einsetzen, sondern auch in unseren Projekten propagieren, wissen wir, dass sie einerseits die Grundlage des Internets und unserer heutigen, von Software dominierten Welt ist und es andererseits in diesem Umfeld durchaus problematische und übersehene Bereiche gibt.

Die 2,5 Milliarden aktiven Android-Geräte in 2018 bedeuten beispielsweise entsprechend viele Installationen des Linux-Kernels, denn das Android-Betriebssystem basiert auf eben dieser Open-Source-Software. Doch das ist nur die Spitze des berühmten Eisbergs. Mittlerweile haben viele Nutzer bereits mehrere unterschiedliche Browser auf ihren verschiedenen Computern und Handys parallel installiert, die alle OSS-Komponenten einsetzen, wie die Datenbank SQLite zum Beispiel. Diese kommt dadurch auf unglaubliche 1 Billion aktive Nutzungen.

Open-Source-Software ist also das Rückgrat unserer softwarebasierten Infrastruktur, ähnlich den Brücken und Straßen in unserem Land, wie eine entsprechende Untersuchung der Ford Foundation schon 2016 sehr treffend formulierte.

Anders als diese physikalische Infrastruktur entsteht das Open-Source Rückgrat unserer digitalen Welt allerdings häufig im privaten Kontext von Freiwilligen, welche aus Leidenschaft und ohne wirtschaftliche Motivation ihre Entwicklungen der Allgemeinheit zur Verfügung stellen. Davon aber eben auch nicht leben können und so kritische Infrastruktur von Einzelkämpfern in Nacht- oder Wochenendschichten – neben anderen Jobs – bereitgestellt wird. Wie die OpenSSL-Programmbibliothek beispielsweise, welche geschätzte ⅔ des gesamten Internetverkehrs verschlüsselt. Ein lange unentdeckter Fehler in dieser OSS-Komponente führte zum berühmten Heartbleed-Bug, welcher sogar eine eigene Wikipedia-Seite hat, da durch ihn weite Teile der Verschlüsselung privater Daten im Internet anfällig für Angriffe war. Nicht, dass dies nicht auch bei kommerzieller Software passieren würde; es spricht eher für den Entwickler, der OpenSSL lange Zeit weitestgehend alleine gepflegt hat, dass der Fehler so lange unentdeckt blieb. Die Frage ist aber doch, ob wir die Verschlüsselung eines Großteils unserer Daten im Internet vom Einsatz eines einzelnen und dafür auch noch unbezahlten Menschen abhängig machen wollen?

Da Open-Source-Software Entwickler in der Regel mit großer Leidenschaft an ihre entsprechenden Projekte gehen, gleichzeitig ihre Arbeit naturgemäß sehr transparent, eben offen ist und zum Teil auch viel davon abhängt, ist der Druck in diesem Bereich häufig groß. So groß, dass auch das Thema Burnout hier immer offener diskutiert wird, also offensichtlich immer weiter um sich greift.

Dazu kommt, dass auch im Umfeld von OSS, wie leider mittlerweile üblich im Internet, Hatespeech und Flamewars an der Tagesordnung sind. Ein Großteil der Open-Source-Software-Entwicklung erfolgt über Github. Änderungsanforderungen erfolgen dort unter anderem über sogenannte Pullrequests. In deren Kommentarbereichen geht es wiederum häufig nicht anders zu, als in denselben eines beliebigen Influencers auf Instagram. Das geht sogar bis zu Morddrohungen an Daniel Stenberg, dem Entwickler von »libcurl«, einer Open-Source-Software-Komponente, welche zur Datenübertragung in Netzwerken genutzt wird und als eine der meist verwendeten Software-Bibliotheken gilt. Auch diese Software wurde übrigens lange Zeit von ihm alleine gepflegt.

Ein weiteres Risiko in diesem Umfeld ist die sogenannte »Dependency Hell«, welche dadurch entsteht, dass die Software, die man einsetzt, in der Regel auch wieder auf anderen OSS-Komponenten basiert, welche wiederum andere Open-Source-Software einbindet … Wie der Fall eines bis dahin unbekannten Open-Source-Software Entwicklers 2016 zeigte, der aufgrund von rechtlichen Auseinandersetzungen seine nur 11 Codezeilen umfassende Open-Source-Software-Komponente »left-pad« zurückzog und damit fast “das Internet kaputt gemacht hat”.

Zusammengefasst und überspitzt formuliert muss man sich das, um den Titel der oben genannten Studie aufzugreifen, vorstellen, als ob alle Brücken der Welt ein kleines, tragendes Bauteil enthielten, welches von einem einzigen, vielleicht auch noch überarbeiteten Menschen, der dem Burnout nahe ist und gerade auch noch mit Morddrohungen zu kämpfen hat, freiwillig und kostenlos bereitgestellt würde. Klingt nicht sehr stabil, ist im Internet und da, wo Software zum Einsatz kommt, aber ein Teil der Realität.

Wer also beispielsweise mit dem Handy telefoniert, E-Mails oder WhatsApp-Nachrichten verschickt, im Internet surft oder Videos streamt, wird mit Open-Source-Software in Berührung kommen, die eventuell von so einem Programmierer irgendwo auf der Welt am Laufen gehalten wird. Wir finden, Weihnachten ist eine gute Gelegenheit, auch mal diesen etwas anderen, »stillen Helden« für ihren Einsatz zu danken.

Die atra.consulting-Gruppe spendet diese Weihnachten per Gitub Donors an RubyGems, dem Paketsystem für die Verwaltung und Verteilung von Programmbibliotheken der Programmiersprache Ruby. Die Paketverwaltung stellt für jede Programmiersprache eine besonders kritische Infrastrukturkomponente in der sogenannten Software Supply Chain dar. RubyGems ist dadurch regelmäßig das Ziel von Hacker-Attacken, wie beispielsweise gerade auch wieder npm, das populäre Pendant der JavaScript-Welt. Da die größeren und bekannteren OSS-Komponenten in der Regel mittlerweile auch schon mehr Unterstützung erfahren, haben wir uns bewusst dazu entschieden, dieses Jahr diese vielleicht etwas unbekanntere Open-Source-Software-Komponente zu unterstützen.