Die Bedrohungslandschaft rund um Webanwendungen und IT-Systeme wird immer raffinierter. Während traditionelle Angriffe wie SQL-Injections, Cross-Site-Scripting und Session Hijacking auch 2025 nach wie vor aktiv sind, konnten sie durch moderne Web-Frameworks, Web-Application-Firewalls (WAF) und die Einhaltung von Best Practices deutlich eingedämmt werden.

Doch haben Sie schon einmal von Angriffen gehört, bei denen es nicht darum geht, vertrauliche Daten zu stehlen oder zu manipulieren? Es gibt auch Attacken, die einzig und allein darauf abzielen, IT-Systeme so lange wie möglich außer Betrieb zu setzen und den Schaden bei den Betroffenen zu maximieren.

In diesem Artikel betrachten wir eine solche böswillige Angriffsmethode, die im Jahr 2013 mit den Lastspitzen auf spamhaus.org eine neue Dimension erreichte. 5 Jahre später erlebte GitHub einen DDoS-Angriff mit einer schier unglaublichen Datenrate von 1,35 Tbit/s. Solche Angriffe sind keine Einzelfälle – jedes Unternehmen oder jede Organisation könnte schon morgen betroffen sein.

Was sind DDoS-Angriffe?

DDoS steht für Distributed Denial of Service und beschreibt eine Angriffstechnik, bei der eine enorme Anzahl an Paketen oder Anfragen gleichzeitig auf ein Zielsystem gesendet wird, um dessen Verfügbarkeit stark zu beeinträchtigen oder das System zum Absturz zu bringen. Im Gegensatz zum klassischen DoS (Denial of Service) verwendet DDoS eine Gruppe von kompromittierten Computern, statt nur eines einzelnen Rechners.

DDoS-Angriffe können auf unterschiedlichen Ebenen des weit verbreiteten OSI-Modells erfolgen, was zu einer Vielzahl an Angriffsmöglichkeiten führt. Diese können grob in zwei Kategorien unterteilt werden: stumpfe Angriffe und intelligente Angriffe, je nachdem, welche Ebene des OSI-Modells das Ziel darstellt.

Angriffsmethoden: Von einfach bis raffiniert

1) SYN-Flood-Angriff

Ein häufig eingesetzter Angriff ist die SYN-Flood-Attacke, die auf der Transportebene (Layer 4) durchgeführt wird. Dabei missbraucht der Angreifer den TCP-Drei-Wege-Handshake, der beim Verbindungsaufbau zwischen zwei Rechnern verwendet wird. Der Angreifer sendet zahlreiche SYN-Pakete mit gefälschten Quell-IP-Adressen an den Server, der diese mit SYN-ACK-Paketen beantwortet. Da der letzte Schritt des Handshakes (ACK vom Client) ausbleibt, bleiben die Verbindungen offen und überlasten das System. Solche Angriffe sind relativ einfach durchzuführen und können durch Techniken wie SYN-Cookies abgewehrt werden.

2) DNS-Verstärkung (DNS Reflection / Amplification)

Eine weitaus raffiniertere und schwerer zu entdeckende Angriffsmethode ist die DNS-Verstärkung. Bei dieser Methode wird das Zielsystem mit DNS-Antworten von seriösen DNS-Servern überflutet, die es jedoch nie angefragt hat. Kompromittierte Computer in einem Botnetz nutzen öffentlich zugängliche DNS-Server, um Anfragen zu stellen, deren Antworten dann über gefälschte Quell-IP-Adressen an das Ziel weitergeleitet werden. Das resultierende Datenvolumen ist häufig extrem hoch und kann das Zielsystem schnell überlasten. Im Fall des Angriffs auf spamhaus.org führte dies zu erheblichen Störungen im weltweiten Netzwerkverkehr.

Der Schaden durch DDoS-Angriffe

Ob einfache Flutattacken oder raffinierte DNS-Verstärkungsangriffe – der Schaden durch DDoS-Attacken kann enorm sein. Neben unmittelbaren Umsatzverlusten und Wiederherstellungskosten können auch Reputationsschäden und Rechtskosten erhebliche finanzielle Folgen haben.

Schutzmaßnahmen gegen DDoS-Angriffe

Um sich gegen DDoS-Angriffe zu schützen, ist es wichtig, proaktive Schutzstrategien zu entwickeln. Hier sind einige wesentliche Maßnahmen:

1) Priorisieren Sie kritische Dienste

Bestimmen Sie, welche Dienste für Ihr Unternehmen unverzichtbar sind, wie Webanwendungen, E-Mail-Server oder Datenbanken, und stellen Sie sicher, dass diese priorisiert geschützt werden.

2) Nutzen Sie spezialisierte DDoS-Schutzdienste

Setzen Sie auf Dienste wie Cloudflare oder Akamai, die Ihre Infrastruktur vor Angriffen schützen und den Traffic filtern können.

3) Implementieren Sie Intrusion Detection Systeme (IDS)

Verwenden Sie IDS und zentralisierte Logauswertung, um Anomalien frühzeitig zu erkennen und auf DDoS-Angriffe reagieren zu können.

4) Erstellen Sie eine DDoS-Reaktionsstrategie

Entwickeln Sie eine DDoS-Reaktionsstrategie und schulen Sie Ihr Team, damit alle wissen, wie im Fall eines Angriffs zu handeln ist. Regelmäßige Tests stellen sicher, dass der Plan funktioniert.

5) Betreiben Sie kritische Systeme an einem separaten Internet-Uplink

Betriebssysteme, die kritisch sind, sollten an einem anderen Internet-Uplink betrieben werden, um sie gezielt unter DDoS-Schutzmaßnahmen zu stellen, ohne die gesamte Infrastruktur zu beeinträchtigen.

6) Geografische Traffic-Filterung

Konfigurieren Sie Ihre Firewall so, dass Traffic aus nicht relevanten geografischen Regionen blockiert oder priorisiert wird, um den Druck auf Ihre Systeme zu verringern.

Weiterführende Schutzstrategien: Schulungen und Best Practices

DDoS-Angriffe sind nur ein Teil der weiten Bedrohungslandschaft, die Webanwendungen betrifft. Um nachhaltiges Wissen über Sicherheitsmaßnahmen aufzubauen und sich gegen moderne Bedrohungen zu wappnen, empfehlen wir praxisorientierte Intensivtrainings. Diese Trainings decken ein breites Spektrum an Angriffstechniken und Abwehrmechanismen ab und bieten Ihnen die Möglichkeit, gezielt gegen Cyberangriffe vorzugehen.

Fazit: Schutz vor DDoS-Angriffen

DDoS-Angriffe sind eine ernsthafte Bedrohung für Unternehmen und Organisationen weltweit. Mit den richtigen Schutzmaßnahmen und einer durchdachten Reaktionsstrategie können Sie jedoch sicherstellen, dass Ihre Systeme auch bei einem Angriff funktionsfähig bleiben und der Schaden minimiert wird.

Für eine noch tiefere Expertise empfehlen wir ein iSAQB-zertifiziertes Training zur Web-Sicherheit, das Sie mit den notwendigen Fähigkeiten ausstattet, um Ihre Web-Anwendungen effektiv zu schützen.

Quellen

1. Spamhaus History (abgerufen am 14.09.2024)
2. GitHub DDoS Incident Report (abgerufen am 03.09.2024)

„Die Macht der künstlichen Intelligenz ist so unglaublich, dass sie die Gesellschaft auf tiefgehende Weise verändern wird.“

(Bill Gates, Gründer Microsoft)

Was sind unsere Leitplanken für den Einsatz von KI?

Wir schreiben das Jahr 2024. Vor einem Jahr startete der Hype um LLMs und ChatGPT und hat inzwischen auch erste Auswirkungen auf die Softwareentwicklung. KI- Chatbots können nicht nur Texte erzeugen, fotorealistische Bilder zeichnen, Musik erzeugen oder Fragen beantworten – sie können inzwischen auch funktionierende Programme in einer Programmiersprache erzeugen, die sogar funktionieren. Und durch das immerwährende Lernen werden sie immer besser in dem, was sie tun. Das ist eine mächtige Technologie und bisher gibt es kaum Regelungen oder gesetzliche Leitplanken für den Einsatz dieser Tools. Es wird also Zeit, einmal über Leitplanken für die Erstellung und den Einsatz dieser äußerst mächtigen Technologie nachzudenken. Denn eins ist klar: KI wird in Zukunft in alle möglichen Produkte integriert werden und somit unser aller Leben stark beeinflussen.
Um wirklich das Ausmaß zu zeigen, das mit dem Anbruch des KI-Zeitalters auf uns zukommen wird, möchte ich hier aus einer TED-Rede von Mustafa Suleyman zitieren:
„In diesem Sinne biete ich heute die folgende Metapher an, die uns helfen soll, uns mit dem auseinanderzusetzen, was dieser Moment [die breite Einführung von KI] wirklich ist. Ich denke, dass KI am besten als so etwas wie eine neue digitale Spezies verstanden werden sollte. Nehmen Sie das bitte nicht zu wörtlich, aber ich prophezeie, dass wir sie als digitale Begleiter sehen werden, als neue Partner auf unseren Lebenswegen. Unabhängig davon, ob Sie glauben, dass wir uns auf einem 10-, 20- oder 30-jährigen Weg befinden, ist dies meiner Meinung nach die genaueste und grundsätzlich ehrlichste Art und Weise, um zu beschreiben, was tatsächlich auf uns zukommt.“
Und eine wichtige Erkenntnis von ihm ist: „We can only control what we can understand“.

Was müssen wir also tun, um dies zu verstehen?

KI und Ethik: Worauf müssen wir achten?

Im Kern geht es also um Folgendes: Wenn Künstliche Intelligenz wirklich so eine mächtige Sache ist, die uns alle beeinflussen wird, wie kann gewährleistet werden, dass das System nicht missbraucht wird oder die Technik „eigensinnig“ entscheidet?
Um dies zu klären, hat sich die Europäische Union (EU) zu einer Reihe wichtiger Werte verpflichtet, den sogenannten ethischen Mindestanforderungen. Zu den ethischen Mindestanforderungen, die in der KI implementiert sein müssen, gehören insbesondere:
1. Schutz der Privatheit
2. Klärung der Verantwortungsbeziehungen. D.h. konkret: Wer ist verantwortlich, wenn etwas schiefläuft?
3. Fairness
4. Transparenz. D. h. konkret: Kann man durchschauen, was in der KI intern passiert? Ist das Verhalten nachvollziehbar?
5. Sicherheit
Aus diesen Mindestanforderungen wurden 2021 von der Bundesregierung sieben ethische Indikatoren für KI aufgestellt:
1. Vorrang menschlichen Handelns und menschlicher Aufsicht (Mensch vor Maschine)
2. Technische Robustheit und Sicherheit
3. Schutz der Privatsphäre und Datenqualitätsmanagement
4. Transparenz und Erklärbarkeit (Daten und Prozesse von KI müssen rückverfolgbar und erklärbar sein)
5. Vielfalt, Nichtdiskriminierung und Fairness (Der Zugang zur Nutzung der Dienste muss gleichberechtigt und diskriminierungsfrei sein)
6. Gesellschaftliches und ökologisches Wohlergehen (Auswirkung KI-Systeme auf Gesellschaft und Umwelt müssen vorab geprüft werden)
7. Rechenschaftspflicht (es muss geklärt sein, wer für KI-Systeme und deren Ergebnisse verantwortlich ist und rechtlich zur Rechenschaft gezogen werden kann)

Digitale Ethik

Bei der breiten Einführung der Digitalisierung kommen die Gebote der digitalen Ethik zum Einsatz.

Fazit

Es ist also wichtig für uns, am Rande des Zeitalters der Künstlichen Intelligenz genau zu reglementieren, was die neue Technologie darf und was nicht. Denn durch diese Leitplanken wird festgelegt, was passieren darf und was nicht. Andernfalls könnte der Menschheit dasselbe widerfahren wie bei früheren technologischen Revolutionen: die Menschen werden von der neuen Technologie überrollt und sind ihr hilflos ausgeliefert.

Quellen

Youtube: What Is an AI Anyway? | Mustafa Suleyman | TED              https://www.youtube.com/watch?v=KKNCiRWd_j0 

https://www.bmwk.de/Redaktion/DE/Schlaglichter-der-Wirtschaftspolitik/2021/09/11-ethische-leitlinien-fur-kunstliche-intelligenz.html 

https://www.youtube.com/watch?v=gOtxR2cER3g                    Der EU AI Act einfach erklärt

https://www.youtube.com/watch?v=g_RDoKAPZ9A                  Das wichtigste Gesetz aller Zeiten? (AI-Act)

https://www.youtube.com/watch?v=Pzx2wkba6tc                    Wie ethisch ist KI? – Thilo Hagendorff – Science Slam

https://webcare.plus/digitale-ethik/ 

https://www.hdm-stuttgart.de/digitale-ethik/lehre/10_gebote 

https://www.youtube.com/watch?v=G97ZJU44vTY     Künstliche Intelligenz: Unsere neue Superkraft? | Idee 3D | ARTE

https://www.youtube.com/watch?v=oNk6ESLpxKI      Von Chatbots bis zu Waffensystemen – Fluch und Segen der Künstlichen Intelligenz | SWR Doku 

https://www.youtube.com/watch?v=eLaqIGCfCwY     AI Act: EU-Verordnung zu künstlicher Intelligenz (KI) in 3 Minuten erklärt

„A good software architect is like a werewolf: Afraid of silver bullets.“

(frei nach Jochen Mader (codepitbull)

1. Was macht eigentlich ein Softwarearchitekt?

Ein Softwarearchitekt ist eine Rolle in enger Zusammenarbeit mit dem Softwareentwicklungsteam und den Stakeholdern. Ein Softwarearchitekt entwirft den Aufbau von Softwaresystemen und trifft grundlegende Entscheidungen über das Zusammenspiel der Komponenten. Er ist für die konzeptionelle Entwicklung von Softwareanwendungen zuständig. Seine Aufgaben beginnen beim Entwurf und reichen über die Umsetzung der Systeme bis hin zum Deployment. Er ist dabei insbesondere für die technologische Umsetzung, die Priorisierung und Einhaltung der Qualitätskriterien (z. B. nach ISO25010) und Randbedingungen (Constraints) verantwortlich. Er ist somit das „technische“ Gegenstück zum Product Owner (PO), der die fachlichen Anforderungen verantwortet.

2. KI in Aktion: Anwendungsmöglichkeiten von KI für Softwarearchitekten

KI-Systeme wie ChatGPT können heute erstaunliche Dinge vollbringen. Zum Beispiel können sie lauffähigen Code erzeugen, den Sie im Dialog mit ChatGPT an Ihre Bedürfnisse anpassen können. Das ist eine große Entwicklung, aber sollte nicht einfach kritiklos von Ihnen akzeptiert werden. Machen Sie es so, wie Sie es von Ihrem Kollegen gewohnt sind, der Ihnen einen Pull-Request schickt: machen sie ein kritisches Code Review.

Mit den KI-Tools bekommen Sie einen Kollegen an die Seite gestellt, der sie gerne bei Ihrer Architekturarbeit unterstützt. Er kann Ihnen zum Beispiel beim Erstellen eines Proof-of-Concepts (POC) oder einer Dokumentation in plantUML helfen. Sie können mit ihm aber auch auf die Suche nach architekturrelevanten Anforderungen in Anforderungsdokumenten gehen oder bei einer lästigen Nachdokumentation bei einer Klasse mit 200 Zeilen einfach mal fragen, was der Code eigentlich macht. Das kann Ihnen gut weiterhelfen.

Werfen wir einen Blick auf sechs Standardaktivitäten der Softwarearchitekten, dann können wir eine Einschätzung für jede Kategorie abgeben:

1. Klärung von Anforderungen und Randbedingungen (Constraints): Hier kann der KI-Assistent bei der Sichtung der Anforderungsdokumente unterstützen und Randbedingungen identifizieren. Daneben wäre auch eine Suche nach architekturrelevanten Anforderungen möglich.
2. Entwurf von Strukturen: Hier kann der KI-Assistent bei der Initiierung und Durchführung von POCs, wie auch für die endgültigen Strukturen, unterstützen und Quelltext und Dokumentationen erzeugen.
3. Entwurf querschnittlicher Konzepte: Hier kann der KI-Assistent bei der Erstellung von Konzepten und Dokumentationen (einschließlich Diagrammerstellung) unterstützen.
4. Bewertung von Architekturen: Hier kann der KI-Assistent bei der Erstellung von Checklisten und anderen Dokumenten unterstützen.
5. Kommunikation von Architekturen: Hier könnte der KI-Assistent beispielsweise in eine allgegenwärtige Sprache übersetzten (Ubiquitous Language).
6. Begleitung der Umsetzung: Hier sehe ich aktuell die Möglichkeit zur Generierung von Quellcode und die Generierung von Schnittstellenverträgen mittels Open-API durch den KI-Assistenten.

Die Analysefähigkeiten und Kommunikationsmöglichkeiten der KI-Systeme sind aktuell noch begrenzt. Daher wird sich der Fokus des Softwarearchitekten zwar ändern, aber der Beruf wird erhalten bleiben. Softwarearchitekt und Künstliche Intelligenz können aber voneinander lernen und gegenseitig profitieren.

Insgesamt kann der KI-Assistent aktuell also bei fünf von sechs Kernaktivitäten eines Softwarearchitekten unterstützen. Es geht dabei aber rein um Unterstützungsmöglichkeiten – eine KI nimmt einem Architekten nicht das kritische Denken und das Überprüfen der Ergebnisse ab. Wir dürfen nämlich eine Sache nicht vergessen: Eine KI arbeitet mit statistischen Wahrscheinlichkeiten und hat kein tieferes Verständnis von dem, was sie tut. Das ist zumindest heute noch so, könnte sich aber in der Zukunft gegebenenfalls noch ändern. Eine KI ist also heute so etwas wie ein Lehrling, der vor dem Einsatz aktiv trainiert werden muss.

Wie können wir unseren KI-Assistenten aktuell am besten zur Unterstützung unserer Architekturarbeit einsetzen? Die Koexistenz von Menschen und KI wird oft als „Human in the loop“ (HITL) bezeichnet. Dabei soll der Mensch dafür sorgen, dass die KI nur hochwertige Daten und Zwischenergebnisse zum Aufbau des KI-Modells nutzt. Eine besondere Form dieser Zusammenarbeit ist der Sokratische Dialog, eine philosophische Diskursmethode, die zur Reflexion, Selbstbesinnung und Überprüfung eigener Normen und Vorurteile anleiten soll und eigenverantwortliches Denken fördern will. Ähnlich wie der Philosoph Sokrates um 450 vor Christus durch gezieltes Fragen Erkenntnisse gewann, stellt auch ein Softwarearchitekt Fragen an die KI und beurteilt sowie verifiziert die Antworten des KI-Systems.  Wie in einem Sokratischen Dialog wird die Anfrage immer weiter verfeinert, bis der Architekt mit den Ergebnissen zufrieden ist oder abbricht. Die nachfolgend betrachteten Formen der Zusammenarbeit orientieren sich oft an dieser Form von Dialog.

Bei der Arbeit mit KI-Assistenten haben sich bisher folgende Praktiken bewährt:

• KI als Sparringspartner bei der Architekturarbeitum große Probleme in kleinere, handhabbare Probleme zu zerlegen und dann aufzulösen.
• KI als Unterstützung bei der Sichtung, Erstellung und Vollständigkeitsprüfung der Softwarearchitekturdokumentation.
• KI als Unterstützung beim Erfassen und Zusammenfassen von Dokumenten.
• KI als Unterstützung bei der Vorbereitung und Nachbearbeitung von Architekturreviews.
• KI als Unterstützung bei der Nachdokumentation von bestehenden Systemen.
• KI als Unterstützung bei der Klassifizierung von Anforderungen und als Spürhund für architekturrelevante Anforderungen.
• KI als Unterstützung bei der Ableitung von Modellen aus Anforderungen (z. B. MDA/ MDSE).
• KI als Unterstützung bei der Identifikation schwacher Anforderungen (d. h. unvollständige, interpretierbare oder widersprüchliche AFOs).
• KI als Unterstützung bei der Überprüfung, ob Patterns korrekt umgesetzt oder DDD-Anforderungen korrekt eingehalten werden (z. B. die korrekte Ubiquitous Language im Bounded Context).
• KI als Unterstützung für Vorschlägewelche der betrachteten Optionen für einen POC verwendet werden könnten.

Fazit

Künstliche Intelligenz ist ein ganzes Bündel an wertvollen Werkzeugen, die uns als Architekten den Arbeitsalltag vereinfach können. Es gibt viele Möglichkeiten, es gibt aber auch gute Gründe, kritisch zu sein. Wir müssen neu abwägen, womit wir unsere Zeit verbringen. Was bedeutet es, ein Softwarearchitekt, ein Entwickler, ein Scrum Master, ein Product Owner, ein Tester oder ein Requirements-Engineer zu sein? Das beginnt mit der Selbstreflexion. Womit verbringen wir unsere Zeit? Was sind unsere Rituale, Rollen, Artefakte? Was muss in Frage gestellt, verändert oder neu bewertet werden, wenn wir in das Zeitalter der KI eintreten?

Bleiben wir also vorsichtig und sehen Künstliche Intelligenz (KI) als das, was sie ist: ein gutes Hilfsmittel, das einem eine Menge Arbeit abnehmen kann, was aber das kritische Denken nicht ersetzt und auch kein Silver Bullet ist. Im nächsten Beitrag unserer Serie geht es dann um ein weiteres KI-Thema: Künstliche Intelligenz und Ethik – digitale Ethik.

Quellen

Der perfekte Leitfaden für KI Chatbots in Unternehmen

https://www.youtube.com/watch?v=SjoXy9RDyiw

Generative AI in a Nutshell – how to survive and thrive in the age of AI (Henrik Kniberg)

https://www.youtube.com/watch?v=2IK3DFHRFfw

What Is an AI Anyway? | Mustafa Suleyman | TED

https://www.youtube.com/watch?v=KKNCiRWd_j0

„Nichts ist so beständig wie der Wandel.“

(Heraklit von Ephesus, 535-475 v. Chr.)

Phase 1 (2024): Einsatz von Coding Assistent

So fing es also an: Jeder Entwickler im Team konnte, wenn er es wollte, einen KI-Coding-Assistenten nutzen. Da die Entwickler sehr technologieaffin waren, nahmen sie das Angebot gerne an. Der Einsatz bewährte sich gut. Die Entwickler freundeten sich bald mit „ihrem“ neuen Assistenten an und diese wurden durch das ständige Lernen immer besser. Rückblickend lief dies ähnlich zur Einführung der Navigationscomputer im Straßenverkehr in den 2000er Jahren und der Einführung der Smartphones in den 2010er Jahren. Die Entwicklung wurde durch die KI-Unterstützung deutlich beschleunigt und das Management freute sich. Doch gab es schnell den Wunsch, weitere Bereiche in der Entwicklung mit spezialisierten KI-Assistenten unterstützen zu lassen. Daher ging man in der IT nach zwei Jahren in Phase 2 über.

Phase 3 (2027): KI-Assistenten werden zu vollständigen Mitgliedern im Entwicklungsteam (20 % KI)

KI-Assistenten wurden nun zu vollständigen Mitgliedern (KI-Entwicklern) im Entwicklungsteam. Neben menschlichen Entwicklern mit KI-Assistenz gab es nun also einzelne KI-Entwickler. Diese bekamen zunächst einmal die lästigen Arbeiten zugewiesen, auf die die menschlichen Kollegen nur wenig Lust hatten. Nach und nach erkannten die Teams aber, dass Tandems aus menschlichen und KI-Entwicklern besonders produktiv bei der Lösung der kniffligen Herausforderungen sein können. Und so wurde die Zusammenarbeit zwischen menschlichen und KI-Kollegen weiter gefördert. In dieser Phase traten aber auch neue Herausforderungen zutage, insbesondere, wenn es darum ging, wer das Sagen haben sollte: Mensch oder Künstliche Intelligenz? Und auch zwischen den KI-Assistenzsystemen selbst kam es zu Zielkonflikten, die in Phase 3 aber noch durch die Menschen im Team aufgelöst wurden. Doch es war klar, dass auch das Agile Manifest, das ja ursprünglich für menschliche Teams erstellt wurde, angepasst werden musste. Das Ergebnis der Transformation war das AI-Agile Manifest, auf das wir weiter unten eingehen.

Phase 4 (2028): KI-/ Entwickler-Tandems bilden das ganze Entwicklerteam

Nachdem sich die KI-Kollegen in der Lösung kniffliger Probleme und der Umsetzung von unbeliebten Aufgaben bewährt hatten, war im Jahr 2028 das Vertrauen in die Entwickler-KI so gewachsen, dass man die Struktur der Entwicklungsteams grundsätzlich änderte: nun wurden Tandems aus humanoiden und KI-Entwicklern gebildet, sodass der KI-Anteil der Teams auf 50 % anwuchs. In dieser Phase kam es zu einer starken Erhöhung der Leistung der Teams, da die KI-Entwickler ja rund um die Uhr arbeiten konnten, wodurch die 14-Tagessprints auf 5-Tagessprints verkürzt werden konnten. Reviews und Tests sind weitgehend nicht mehr notwendig. Die menschlichen Entwickler hatten dabei vor allem die Aufgabe, zu koordinieren, die Ergebnisse zu überwachen und Zielkonflikte aufzulösen. Doch die KI-Kollegen lernten fleißig mit und das Management und die Auftraggeber waren begeistert von der hohen Produktivität und so kam es folgerichtig zur Phase 5, der vollständigen Übernahme aller Entwicklungsaktivitäten durch KI-Kollegen.

Phase 5 (2030): KI ersetzt das gesamte Entwicklerteam vollständig (100 % KI)

Im Jahr 2030 wurde Phase 5 aktiviert. Dadurch kam es zur vollständigen Übernahme aller Entwicklungsaktivitäten durch KI-Entwickler. Dazu gehörten sowohl die Entwicklung, das Testen, der Entwurf grafischer Benutzeroberflächen, DevOps-Tätigkeiten, First- und Second-Level-Support, IT-Sicherheit und die Entwicklung und Pflege der Softwarearchitektur. Durch das Ersetzen der menschlichen Kollegen war es möglich, den Output weiter zu steigern, sodass Sprints jetzt nicht mehr eine bis drei Wochen, sondern nur noch einen Tag dauerten. Und es war sogar noch eine weitere Evolutionsstufe zum Greifen nahe: das direkte Erstellen von Maschinencodes durch KI-Entwickler.

Das AI-Agile Manifest – Künstliche Intelligenz

1. Sie müssen wissen, was Sie mit KI erreichen wollen. Es besteht eine Abwägung zwischen Machbarkeit und geschäftlichen Auswirkungen.
2. Die Organisation muss sich für das KI-Projekt engagieren.
3. Der Leiter des KI-Teams muss ein effektiver Manager und eine Führungspersönlichkeit sein, die eine klare Vision von KI hat.
4. Design Thinking und Agile sind wertvolle Werkzeuge. Konzentrieren Sie sich auf die To-Do-Liste, um den Umfang, die Kosten und den Zeitplan des KI-Projekts zu kontrollieren.
5. Sie müssen alle Faktoren kennen, die das KI-Projekt beeinflussen können.
6. Das KI-Projekt muss alle Prozessressourcen der Organisation nutzen und mit ihnen in Einklang stehen.
7. Ein KI-Projekt braucht hervorragende Mitarbeiter, Modelle und Daten.
8. Bei der KI-Qualität geht es nicht nur um die Qualität von Modellen und Software, sondern auch um Menschen und Daten.
9. Das KI-Risikomanagement erfordert eine ständige Risikobewertung, eine Risikostrategie und Human-in-the-Loop.
10. Sie müssen alle Beteiligten einbeziehen und einen klaren Kommunikationsplan haben, insbesondere wenn etwas schiefläuft.
11. Sie müssen die durch KI verursachten ethischen Bedenken erkennen, verstehen und gezielt angehen.
12. Agiles Vorgehen für KI erfordert einen spezifischen Ansatz mit längeren Zyklen und mehr Exploration.

Fazit

Ich hoffe, Ihnen hat dieser Ausblick auf die nächsten 10 Jahre Softwareentwicklung unter Berücksichtigung des Einsatzes von Künstlicher Intelligenz (KI) ohne Scheuklappen und Denkverbote gezeigt, dass wir heute tatsächlich an der Schwelle zu einer anderen Zukunft stehen. Einer Zukunft, die so ganz anders ist, als wir es uns bisher vielleicht vorgestellt haben – aber einer Zukunft, der wir nicht willenlos ausgeliefert sind, sondern auf die wir jetzt noch aktiv Einfluss nehmen können. Im nächsten Blogartikel geht es um das Thema Einsatz von KI in der Softwarearchitekturarbeit. Schauen Sie doch einmal rein!

Quellen

• https://hups.com/blog/are-developers-needed-in-the-age-of-ai
• https://hups.com/blog/agile-in-the-age-of-ai
• The AI Project Handbook: How to manage a successful artificial intelligence project (The Artificial Intelligence Handbook Series) von Minh Trinh PhD (Author)
• https://www.wbscodingschool.com/blog/is-web-development-dead-in-the-age-of-ai/

Willkommen zum letzten Teil der Blogserie
Nachdem wir uns in den letzten Beiträgen mit den Grundlagen der Softwarearchitektur, agiler Entwicklung im Allgemeinen und agilem Architekturvorgehen beschäftigt haben, betrachten wir im letzten Beitrag der Serie, welche Anforderungen an Architekturen agile Projekte mit sich bringen.

Architekturanforderungen in agilen Projekten

Architekturanforderungen in agilen Projekten sind spezifische Anforderungen oder Kriterien, die bei der Entwicklung der Softwarearchitektur berücksichtigt werden müssen. Durch sie soll sichergestellt werden, dass resultierende Systeme die gewünschten Qualitätsmerkmale, Funktionalitäten und Leistungseigenschaften erfüllt. Diese Anforderungen dienen als Leitlinien für die Gestaltung der Architektur und beeinflussen die technischen Entscheidungen im Entwicklungsprozess. In agilen Projekten sollten Architekturanforderungen agil und anpassbar sein, um auf sich ändernde Anforderungen reagieren zu können.

Architekturanforderungen können verschiedene Aspekte umfassen:

– Leistungsmerkmale umfassen Anforderungen an die Performance, Skalierbarkeit und Reaktionsfähigkeit des Systems unter bestimmten Belastungsbedingungen.
– Sicherheit meint Anforderungen an den Datenschutz, die Sicherheit der Datenübertragung, den Zugriffsschutz und die allgemeine Sicherheit des Systems.
– Skalierbarkeit bezieht sich auf die Fähigkeit des Systems, sich an steigende Anforderungen anzupassen. Sei es in Bezug auf Nutzerzahl, Datenmenge oder Transaktionsvolumen .
– Wartbarkeit sind Anforderungen, die festlegen , wie leicht das System gewartet, aktualisiert und erweitert werden kann, ohne negative Auswirkungen auf die Funktionalität zu haben.
– Erweiterbarkeit meint, wie einfach und nahtlos das System um neue Funktionen oder Module erweitert werden kann, ohne bestehende Codes zu beeinträchtigen.
– Interoperabilität betrifft die Fähigkeit des Systems, nahtlos mit anderen Systemen oder Diensten zu kommunizieren und zu interagieren.
– Architekturmuster und -stile können als Anforderungen festgelegt werden, um sicherzustellen, dass die Architektur den gewünschten Designprinzipien folgt.
– Technologische Anforderungen umfassen spezifische Technologien, Frameworks oder Plattformen, die im Projekt verwendet werden.
– Nicht-funktionale Anforderungen: Dies können nicht-funktionale Anforderungen wie Benutzerfreundlichkeit, Zugänglichkeit, Barrierefreiheit und mehr umfassen.

In agilen Projekten werden Architekturanforderungen oft in enger Zusammenarbeit mit den Stakeholdern erarbeitet und können sich im Laufe des Projektes ändern. Sie dienen als Leitfaden für die kontinuierliche Anpassung und Entwicklung der Architektur, um sicherzustellen, dass das Endprodukt den Anforderungen entspricht und die Erwartungen erfüllt.

Agile Konzepte für Architekturanforderungen

Agile Konzepte für Architekturanforderungen betonen die Flexibilität, Zusammenarbeit und kontinuierliche Anpassung von Anforderungen. Diese Konzepte sollen sicherstellen, dass Architekturanforderungen agil sind und sich in einer sich ständig ändernden Umgebung weiterentwickeln können.

Es folgen einige Beispiele:

– User Stories für Architektur: Ähnlich wie bei funktionalen Anforderungen können Architekturanforderungen als User Stories formuliert werden. Diese User Stories beschreiben die Anforderungen aus Sicht eines Benutzers oder einer Stakeholder-Rolle. Sie fokussieren sich auf den Wert, den die Architektur für diese Benutzer bietet.
– Agile Architekturdokumentation: Agile Konzepte bevorzugen eine leichtgewichtige Dokumentation, die sich schnell anpassen lässt. Diagramme, Skizzen, Whiteboard-Skizzen und kurze Beschreibungen können verwendet werden, um Architekturprinzipien und entscheidungen zu dokumentieren.
– Emergente Architektur: Agile Architekten bevorzugen die Entwicklung einer emergenten Architektur, die sich schrittweise aus den Anforderungen und der Funktionalität entwickelt. Dies ermöglicht es, auf veränderte Anforderungen und Gegebenheiten flexibel zu reagieren, ohne in umfangreiche Vorausplanung zu verfallen.
– Risikoorientierte Architekturanforderungen: Agile Architekten identifizieren und priorisieren Risiken, die mit der Architektur verbunden sind. Anforderungen werden basierend auf diesen
Risiken festgelegt und entsprechende Strategien entwickelt, um sie zu mindern.
– Kontinuierliche Anpassung: Architekturanforderungen werden kontinuierlich überprüft und
angepasst, um sicherzustellen, dass sie aktuell und relevant bleiben. Dies geschieht in enger Zusammenarbeit mit den Stakeholdern, um sicherzustellen, dass die Architektur den aktuellen Bedürfnissen entspricht.
– Just-in-Time-Entscheidungen: Agile Teams treffen Entscheidungen „just-in-time“, wenn die Anforderungen und das Verständnis des Systems wachsen. Dadurch können sie sich auf aktuelle Informationen stützen.
– Kollaboratives Arbeiten: Architekturanforderungen werden durch kollaboratives Arbeiten mit dem Entwicklungsteam, den Produktverantwortlichen und anderen Stakeholdern entwickelt.
Dies fördert das gemeinsame Verständnis und sorgt für eine bessere Umsetzung der Anforderungen.

Diese agilen Konzepte für Architekturanforderungen tragen dazu bei, dass die Architektur flexibel, anpassungsfähig und auf die aktuellen Bedürfnisse ausgerichtet bleibt, während gleichzeitig eine hohe Qualität und Kundenzufriedenheit gewährleistet werden.

Dringlichkeit als Treiber für agile Architekturarbeit

Dringlichkeit als Treiber für agile Architekturarbeit bezieht sich auf die Notwendigkeit, sich auf spezifische Aspekte der Softwarearchitektur zu konzentrieren, die aufgrund ihrer kritischen Bedeutung oder ihrer potenziellen Auswirkungen auf das Projekt priorisiert werden müsse.

Dieser Ansatz basiert auf der Idee, dass nicht alle Teile der Architektur gleich wichtig sind und dass es sinnvoll ist, sich zuerst auf diejenigen Aspekte zu konzentrieren, die einen unmittelbaren und signifikanten Einfluss haben.

Die Dringlichkeit kann verschiedene Gründe haben:

Risikominderung: Wenn bestimmte Architekturaspekte ein hohes Risiko für das Projekt darstellen, sollten sie frühzeitig angegangen werden, um potenzielle Probleme zu minimieren.
Kritische Funktionalitäten: Falls die Architektur direkt mit kritischen Funktionen des Systems verbunden ist, ist es dringend erforderlich, diese Bereiche zu priorisieren, um die Leistung und Zuverlässigkeit sicherzustellen.
Performance und Skalierbarkeit: Wenn das System unter erwarteter Last gut funktionieren muss, ist es wichtig, Architekturentscheidungen zu treffen, die die Performance und Skalierbarkeit optimieren.
Integration: Wenn das System mit anderen externen Systemen oder Diensten interagiert, ist es dringend erforderlich, die Integrationsarchitektur sorgfältig zu planen und umzusetzen.
Änderungen in den Anforderungen: Wenn sich die Anforderungen ändern, kann es notwendig sein, die Architektur schnell anzupassen, um sicherzustellen, dass das System den aktuellen Bedürfnissen entspricht.

Die agile Architekturarbeit unter Berücksichtigung der Dringlichkeit ermöglicht es, schnell auf die wichtigsten Anliegen zu reagieren. So kann sichergestellt werden, dass das Projekt auf einem soliden Fundament aufbaut. Dabei ist jedoch eine Balance erforderlich, um die Dringlichkeit mit den langfristigen Zielen der Architektur und der technischen Integrität in Einklang zu bringen.

Quellen

• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://de.wikipedia.org/wiki/Softwarearchitektur
• https://www.agile-academy.com/
• Mike Cohn: Agile Design: Intentional Yet Emergent.
• Stefan Toth: „Vorgehensmuster für Softwarearchitektur: Kombinierbare Praktiken in Zeiten von Agile und Lean”, 2. Auflage, Hanser Verlag 2015

Agiles Architekturvorgehen

Dieser Ansatz verfolgt die Integration agiler Prinzipien und Methoden in den Prozess der Gestaltung und Entwicklung von Softwarearchitekturen. Er zielt darauf ab, die traditionell starren und vorausplanenden Ansätze zur Architekturdefinition zu überwinden und stattdessen eine flexible, anpassungsfähige und inkrementelle Herangehensweise zu fördern.
Im Rahmen des agilen Architekturvorgehens werden Architekten und Entwickler ermutigt, zusammenzuarbeiten, kontinuierlich zu lernen und sich ändernden Anforderungen anzupassen.

Einige Merkmale des agilen Architekturvorgehens sind:

– Kontinuierliche Anpassung: Anstatt eine vollständige Architektur im Voraus zu entwerfen, entwickeln agile Teams eine initiale Architekturrichtung und passen sie im Laufe der Zeit an, während sie mehr über das Projekt und die Anforderungen erfahren.

– Inkrementelle Entwicklung: Die Architektur wird schrittweise entwickelt, wobei es sich mit jeder Iteration weiterentwickelt und den sich ändernden Bedürfnissen des Projekts angepasst wird.

– Enge Zusammenarbeit: Architekten arbeiten eng mit dem Entwicklungsteam zusammen, um sicherzustellen, dass die Architekturprinzipien in den laufenden Entwicklungsprozess integriert werden. Architektur wird in vielen agilen Ansätzen von Anfang mitgedacht. So kann der Architekt einem Team zugeordnet sein und seine Tätigkeiten innerhalb des Teams
ausüben. So wird sichergestellt, dass Architekturprinzipien in den Entwicklungsprozess von Stunde null mitgedacht werden.

– Einfache Kommunikation: Anstatt umfangreicher Dokumentation bevorzugt das agile Architekturvorgehen eine klare und verständliche Kommunikation, um die Architekturentscheidungen im Team zu teilen.

– Schnelles Feedback: Durch häufige Auslieferungen von funktionierender Software und Prototypen erhalten Architekten kontinuierliches Feedback durch die Stakeholder, Nutzer und ggf. Kunden im Review. Während des Sprints können je nach Wunsch Personen eingeladen werden. Der PO achtet darauf, dass er oder sie Feedback gibt.

– Evolutionäre Architektur: Die Architektur entwickelt sich ständig weiter, um den sich ändernden Anforderungen gerecht zu werden. Dies ermöglicht einen Fokus auf das Wesentliche und trägt dazu bei, unnötige Komplexität zu vermeiden.

– Risikoreduktion: Durch das frühe Erkennen von potenziellen Architekturproblemen und die Möglichkeit, Gegenmaßnahmen zu ergreifen, werden Risiken minimiert.

Architekturarbeit iterativ und agil gestalten – Risikogetriebene Architekturarbeit

Risikogetriebene Architekturarbeit bezieht sich auf den Ansatz, bei dem die Identifikation, Bewertung und Behandlung von Risiken eine zentrale Rolle bei der Entwicklung und Gestaltung der Softwarearchitektur spielt. Anstatt sich ausschließlich auf technische oder funktionale Aspekte zu konzentrieren, legt dieser Ansatz den Schwerpunkt auf die Einschätzung und Minderung von Risiken, die sich auf den Erfolg des Projekts auswirken könnten.

Die Grundidee hinter der risikogesteuerten Architekturarbeit besteht darin, die kritischen Risiken zuerst anzugehen, um frühzeitig sicherzustellen, dass das Projekt auf einem stabilen Fundament aufgebaut wird. Dies beinhaltet:

–  Identifikation von Risiken: Die Architekten analysieren und identifizieren potenzielle Risiken in Zusammenhang mit den Anforderungen, der Technologie, der Skalierbarkeit, der Performance, der Sicherheit und anderen relevanten Faktoren.

– Bewertung von Risiken: Die identifizierten Risiken werden bewertet, um festzustellen, welche davon die größte Bedrohung für den Erfolg des Projekts darstellen.

– Priorisierung von Risiken: Basierend auf der Bewertung werden die Risiken nach ihrer Dringlichkeit und Auswirkung priorisiert. Diejenigen mit höherer Priorität werden zuerst angegangen.

– Entwicklung von Risikominderungsstrategien: Für die identifizierten und priorisierten Risiken werden Strategien entwickelt, um sie zu mindern oder zu verhindern. Dies kann durch technische Lösungen, Architekturanpassungen oder alternative Herangehensweisen erfolgen.

– Prototyping und Validierung: In einigen Fällen kann es erforderlich sein, Prototypen oder Proof of Concepts zu erstellen, um die Wirksamkeit der gewählten Risikominderungsstrategien zu überprüfen.

– Iterative Anpassung: Während des Entwicklungsprozesses wird die Risikobewertung laufend überprüft und aktualisiert, um sicherzustellen, dass neue Risiken erkannt und behoben werden.

Indem die Architekten die Risiken von Anfang an berücksichtigen und angehen, können potenzielle Probleme frühzeitig erkannt und gemindert werden. Die Wahrscheinlichkeit von Fehlern und Verzögerungen wird dadurch verringert. Dieses Vorgehen trägt dazu bei, dass die Softwarearchitektur solide, stabil und den Anforderungen des Projekts gerecht wird.

Rollenmodelle für Architekten in agilen Projekten

In agilen Projekten können verschiedene Rollenmodelle für Architekten existieren, je nach Größe des Teams, der Art des Projekts und den spezifischen Anforderungen.

Hier sind einige gängige Rollenmodelle für Architekten in agilen Projekten:

– Agiler Architekt: Diese Rolle ist für die Gestaltung der Softwarearchitektur verantwortlich, wobei der Schwerpunkt auf Flexibilität, Zusammenarbeit und Anpassungsfähigkeit liegt. Der agile Architekt arbeitet eng mit den Entwicklungsteams und den Produktverantwortlichen zusammen, um sicherzustellen, dass die Architektur die agilen Werte und Prinzipien widerspiegelt.

– Architekt als Teil des Entwicklungsteams: In kleinen agilen Teams kann der Architekt Teil des Entwicklungsteams sein und aktiv am Coden und an der Umsetzung von Features teilnehmen.
Dies ermöglicht eine enge Zusammenarbeit und eine kontinuierliche Ausrichtung der Architektur auf die Entwicklungsarbeiten.

– Technologieberater: Ein Architekt kann als Technologieberater dienen, der das Team bei der Auswahl geeigneter Technologien, Frameworks und Tools unterstützt. Sie helfen dabei, sicherzustellen, dass die gewählten Technologien die Anforderungen des Projekts erfüllen und gut in die Architektur passen.

– Architekturcoach: Diese Rolle befasst sich damit, das Team in Bezug auf bewährte Methoden, Architekturmuster und Prinzipien zu schulen. Der Architekturcoach fördert das Verständnis für Architekturpraktiken und hilft dem Team, bessere technische Entscheidungen zu treffen.

– Evangelist für Qualität und Wartbarkeit: Architekten können die Verantwortung übernehmen, sicherzustellen, dass die entwickelte Software qualitativ hochwertig, wartbar und skalierbar ist. Sie setzen Standards für Codequalität und arbeiten mit dem Team zusammen, um sicherzustellen, dass diese Standards eingehalten werden.

– Architekturstratege: Diese Rolle übernimmt die langfristige Sicht auf die Architektur und hilft, eine Vision für die technische Entwicklung des Produkts zu definieren. Sie berücksichtigen technologische Trends, organisatorische Ziele und zukünftige Anforderungen, um sicherzustellen, dass die Architektur langfristig erfolgreich bleibt.

Es ist wichtig zu beachten, dass die Rollenmodelle für Architekten in agilen Projekten variieren können. In jedem Fall ist die Zusammenarbeit zwischen den Architekten, dem Entwicklungsteam, den Produktverantwortlichen und anderen relevanten Stakeholdern entscheidend. So kann sichergestellt werden, dass die Architektur den Bedürfnissen der Kunden, Nutzer und Stakeholder gerecht wird und agil umgesetzt wird.

Möglichkeiten, Stakeholder in die agile Architekturarbeit zu involvieren

Die Einbeziehung von Stakeholdern in die agile Architekturarbeit ist entscheidend, um sicherzustellen, dass die entwickelte Software den Anforderungen und Erwartungen aller relevanten Parteien entspricht. Wir möchten drei Möglichkeiten betrachten, wie Stakeholder in die agile Architekturarbeit eingebunden werden können:

– Regelmäßiges Feedback und Reviews: Durch das Abhalten regelmäßiger Meetings oder Reviews, erhalten Stakeholder die Gelegenheit, die Ergebnisse des Sprints zu betrachten und Feedback zu geben. Dies geschieht in Form von Demos, Präsentationen oder Diskussionen. Das Team kann gemeinsam mit den Stakeholdern experimentieren, wie das Review gestaltet werden soll. Stakeholder können ihre Anforderungen, Erwartungen und Bedenken kommunizieren, was zu einer kontinuierlichen Anpassung und Verbesserung der Architektur führt.

– Involvieren in Planung und Priorisierung: Durch die Einladung von Stakeholdern zur Teilnahme an Planungssitzungen, in denen kommende Aufgaben und Prioritäten besprochen werden, erhalten diese die Möglichkeit, ihre Perspektiven mit einzubringen und sicherzustellen, dass die Architekturarbeit die für sie wichtigen Aspekte berücksichtigt. In aller Regel sollte bei einem Scrum Vorgehen nicht die gesamte Stakeholderschaft im Planning
vertreten sein. Der PO ist die Stimme des Kunden und des Nutzers, er oder sie muss priorisieren welche Backlog Stories eingeplant werden gemeinsam mit den Devs.

– User Stories und Anforderungen: Arbeiten Sie mit den Stakeholdern zusammen, um User Stories und Anforderungen zu erstellen oder zu überarbeiten, die in die Entwicklung der Architektur einfließen. Diese User Stories können als Grundlage für die Architekturarbeit dienen und sicherstellen, dass die entwickelte Architektur die gewünschten Funktionen und Eigenschaften erfüllt.

Die Schlüsselkomponente in allen diesen Ansätzen ist die offene Kommunikation und enge Zusammenarbeit mit den Stakeholdern. Dies ermöglicht es, Missverständnisse zu vermeiden, frühzeitig auf Feedback zu reagieren und sicherzustellen, dass die Architektur die Bedürfnisse und Erwartungen aller Beteiligten erfüllt.

Quellen

• https://www.scrum.org/
• http://agilemanifesto.org/
• https://www.isaqb.org/
• https://de.wikipedia.org/wiki/Softwarearchitektur
• https://www.agile-academy.com/
• Mike Cohn: Agile Design: Intentional Yet Emergent.