KI und Ethik: Was sind unsere Leitplanken für den Einsatz von KI? Part (3/3)

KI und Ethik: Was sind unsere Leitplanken für den Einsatz von KI? Part (3/3)

KI und Ethik

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

„Künstliche Intelligenz ist wahrscheinlich das Beste oder das Schlimmste, was der Menschheit passieren kann.“

(Stephen Hawking, Physiker)

„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

KI und Ethik: Was sind unsere Leitplanken für den Einsatz von KI? Part (3/3)

Softwarearchitekten und KI-Systeme: Herausforderungen und Möglichkeiten Part 2/3

Softwarearchitekten und KI-Systeme:

Herausforderungen und Möglichkeiten

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

(frei nach Jochen Mader (codepitbull)

Seit 2023 gibt es einen regelrechten Hype um Large Language Models (LLMs) und KI-Chatbots, wie z. B. ChatGPT. Mit solchen Tools können Anwender aus einem Textprompt nicht nur hochwertige Texte, Zusammenfassungen, fotorealistische Bilder oder Musik erzeugen. Auch das Erzeugen von Quellcode und Dokumentationen ist möglich. Dies wird unserer Ansicht nach große Auswirkungen auf die Softwareentwicklung haben und die IT nachhaltig beeinflussen. In diesem Artikel untersuchen wir, wie ein KI-Tool die Arbeit eines Softwarearchitekten unterstützen kann und ob Künstliche Intelligenz ein Silver Bullet sein könnte.

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.

Das International Software Architecture Qualification Board (iSAQB) hat sich zum Ziel gesetzt, die Ausbildung von Softwarearchitekten im europäischen Raum zu standardisieren. Das iSAQB betreut und entwickelt als Non-Profit-Organisation die Zertifizierungsschemata für die iSAQB-Foundation/Advanced/Expert-Level.
Das iSAQB definiert sechs Kernaktivitäten für Softwarearchitekten:

1. Klärung von Anforderungen und Randbedingungen (Constraints)
2. Entwurf von Strukturen
3. Entwurf querschnittlicher Konzepte
4. Bewertung von Architekturen
5. Kommunikation von Architekturen
6. Begleitung der Umsetzung

Diese Kernaktivitäten stehen nicht einzeln für sich, sondern sind eng miteinander verbunden. Im Rahmen der Digitalisierung und der Einführung der KI in den Entwicklungsprozess zeichnen sich verschiedene Möglichkeiten der Toolunterstützung der Architekten durch KI ab. Die KI-Tools müssen allerdings eine Reihe von gesetzlichen Vorgaben erfüllen.

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

 

KI und Ethik: Was sind unsere Leitplanken für den Einsatz von KI? Part (3/3)

Die schöne neue Welt von KI und IT: Herausforderungen und Möglichkeiten Part 1/3

Die schöne neue Welt von KI und IT:

Herausforderungen und Möglichkeiten

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

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

Willkommen in der Zukunft

Wir schreiben das Jahr 2033. Vor zehn Jahren startete der Hype um LLMs und ChatGPT und hatte inzwischen auch große Auswirkungen auf die Softwareentwicklung. Der Einfluss geschah nicht mit einem großen Knall, sondern lief eher schleichend in mehreren Phasen ab. Alles begann im Jahr 2024 mit dem Einsatz von Künstlicher Intelligenz in Form von Coding Assistenten.

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 2 (2026): Einsatz von spezialisierten Assistenten für UX, DevOps, Softwaretest und Softwarearchitektur

Die Entwicklungsteams waren auf den Geschmack gekommen und nutzten auch fleißig weitere spezialisierte KI-Assistenten. Dies waren oftmals Assistenten für Querschnittsthemen, wie z. B. für den Entwurf grafischer Benutzeroberflächen (UX), DevOps, IT-Security, Softwaretest und Softwarearchitektur. Durch den direkten Einsatz der KI-Assistenten fielen viele Wartezeiten für die Entwickler weg, da die Querschnittsthemen jetzt direkt durch das Team selbst erledigt werden konnten. Diese Tools übernahmen dann auch praktischerweise gleich die Dokumentation. Durch den großen Erfolg der ersten beiden Phasen wurde das Management mutig und wollte die Produktivität der Teams weiter steigern, indem man der Künstlichen Intelligenz mehr Verantwortung für den Projekterfolg geben wollte. An Phase 2 schloss sich schließlich Phase 3 mit KI-Teammitgliedern an.

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.

Phase 6 (2033): KI generiert direkt Maschinencode

Durch den Wegfall der menschlichen Komponente in den Entwicklerteams war es nun nicht mehr notwendig, all die vielen Zwischenschritte von der Planung bis zur Realisierung und Produktivsetzung zu unternehmen, die die menschlichen Kollegen brauchten, um das Problem und die Software verstehen zu können. In Phase 6 wurde der direkte Weg von der Kundenanforderung zur Umsetzung in Maschinencode realisiert. Ein Quantensprung in der Softwareentwicklung.

Heute ist die gesamte Softwareentwicklung maximal automatisiert und wurde um den Faktor 10-100 beschleunigt. Heute sprechen wir von One-Day-Sprints. Die Stakeholder sprechen heute direkt mit spezialisierten Chatbots und diskutieren mit ihnen neue Anforderungen und deren Umsetzung noch am gleichen Tag. Damit erfüllt sich endlich der langehegte Wunsch der Auftraggeber, ihre Wünsche und Anforderungen, ohne die störende IT umzusetzen.

Möglich wurde diese Entwicklung durch den konsequenten Ausbau der Künstlichen Intelligenz, das bereitwillige Lernen der KI-Assistenzsysteme und die Anpassung des Agilen Manifests an die „neue Zeit“: durch das AI-Agile Manifest.

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

AGILA – Agile Softwarearchitektur | Part 3/3

AGILA – Agile Softwarearchitektur | Part 3/3

AGILA – Agile Softwarearchitektur

Teil 3

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

 

AGILA – Agile Softwarearchitektur | Part 2/3

AGILA – Agile Softwarearchitektur | Part 2/3

AGILA – Agile Softwarearchitektur

Teil 2

Willkommen zum nächsten Teil der Blogserie

Nachdem wir uns im letzten Beitrag mit den Grundlagen der Softwarearchitektur und agiler Entwicklung im Allgemeinen beschäftigt haben, betrachten wir in diesem Beitrag, wie sich beides zusammenführen lässt.

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.

AGILA – Agile Softwarearchitektur | Part 1/3

AGILA – Agile Softwarearchitektur | Part 1/3

AGILA – Agile Softwarearchitektur

Teil 1

 Was ist das eigentlich?

Im Februar 2001 trafen sich 17 Softwareentwickler:innen. Aus ihrer Sicht fehlte es den vorherrschenden Arbeiten an Flexibilität und Kundennähe. Das agile Manifest entstand und krempelte die Arbeitsweisen in der Softwarentwicklung ähnlich um wie heute ChatGPT. Das Herzstück agiler Methoden sind dabei Kundennähe, schnelle Feedbackschleifen und damit einhergehend kontinuierliche Veränderungen auf Basis des erhaltenen Feedbacks. Agile Vorgehensweisen setzen die Menschen in das Zentrum des Arbeitens. Nicht nur auf Kundenseite auch im Team.

 

Mythbusting: Im Bezug auf Dokumentation wird das agile Manifest oft missverstanden. Agiles Arbeiten verzichtet nicht auf Dokumentation, sondern setzt diese anders ein. So wird z.B. auf Lastenhefte verzichet und in kleine Arbeitspakete geschnürrt.

Wie funktioniert das?

Die agile Softwarearchitektur priorisiert funktionierende Software über umfassende Dokumentation und betont die enge Zusammenarbeit zwischen Architekten, Entwicklern und Kunden. Die Architekten arbeiten eng mit den Stakeholdern zusammen, um Anforderungen zu verstehen und kontinuierliches Feedback zu erhalten. Die Architektur wird inkrementell entwickelt und angepasst, um auf sich ändernde Anforderungen und Erkenntnisse zu reagieren.

Wozu das alles?

Dieses Vorgehen spiegelt die Werte des agilen Manifests wider, wobei Individuen und Interaktionen, funktionierende Software, Zusammenarbeit mit Kunden und die Bereitschaft zur Anpassung an Veränderung im Mittelpunkt stehen. Agile Softwarearchitektur fördert die Schaffung einer evolutionären Architektur, die auf klare Kommunikation, schnelles Feedback und ständige Anpassung setzt. Dies ermöglicht es den Entwicklungsteams, flexibel auf Herausforderungen zu reagieren und hochwertige Softwarelösungen zu liefern, die den Kundenanforderungen gerecht werden.

Wir freuen uns, Ihnen eine spannende Blogserie in drei Teilen anzubieten, die sich mit den Grundlagen und den Herausforderungen der Softwarearchitektur im agilen Umfeld beschäftigt.

Teil 1: Grundlagen der Softwarearchitektur und Agilität

Starten Sie mit uns in die Grundlagen, um die essenziellen Konzepte der Softwarearchitektur und agilen Methoden zu verstehen.

 Teil 2: Agiles Architekturvorgehen

Im zweiten Teil tauchen wir tiefer ein und zeigen Ihnen, wie Sie agile Prinzipien erfolgreich in Ihre Architekturansätze integrieren können.

 Teil 3: Architekturanforderungen in agilen Projekten

Abschließend beleuchten wir die spezifischen Anforderungen, die in agilen Projekten an die Architektur gestellt werden, und wie Sie diesen gerecht werden können.

 Seien Sie dabei und erweitern Sie Ihr Wissen über die Schnittstelle von Softwarearchitektur und Agilität.

Teil 1)

Grundlagen der Softwarearchitektur

Softwarearchitektur bezieht sich auf die organisierte Struktur und das Designen von Software-Systemen, die aus verschiedenen Komponenten, Modulen und Interaktionen bestehen. Sie legt die grundlegenden Entscheidungen und Prinzipien fest, die die gesamte Software-Entwicklung beeinflussen, um sicherzustellen, dass Systeme die gewünschten Anforderungen erfüllen, skalierbar, wartbar und erweiterbar sind.

Die Softwarearchitektur beschäftigt sich mit folgenden Themen und Fragestellungen:

  • Komponenten und Module: Wie ist die Software in Komponenten und Module unterteilt? Welche Funktionen haben diese Einheiten und wie interagieren sie miteinander?
  • Kommunikation und Schnittstellen: Wie kommunizieren die verschiedenen Komponenten miteinander? Welche Schnittstellen definieren ihre Interaktion?
  • Datenfluss und -speicherung: Wie werden Daten innerhalb des Systems verarbeitet, gespeichert und übertragen?
  • Skalierbarkeit: Wie kann die Softwarearchitektur erweitert werden, um steigenden Anforderungen gerecht zu werden?
  • Wartbarkeit: Wie einfach ist es, Fehler zu finden und zu beheben sowie neue Funktionen hinzuzufügen, ohne das gesamte System zu beeinträchtigen?
  • Sicherheit: Wie werden Sicherheitsaspekte im System berücksichtigt, um Daten und Funktionen vor unberechtigtem Zugriff zu schützen?
  • Performance: Wie wird sichergestellt, dass die Software unter den erwarteten Belastungen effizient arbeitet?
  • Technologieauswahl: Welche Technologien, Programmiersprachen, Frameworks oder Plattformen werden verwendet, um die gewünschte Architektur umzusetzen?
  • Muster und Stile: Welche bewährten Muster und Architekturstile (z.B. Schichtenarchitektur, Microservices, monolithisch, …) werden angewendet, um die Ziele des Systems zu erreichen?
  • Dokumentation: Wie wird die Architektur dokumentiert, um sicherzustellen, dass Entwickler das System verstehen und um daran arbeiten zu können?

 Die Wahl einer angemessenen Softwarearchitektur ist entscheidend für den Erfolg eines Softwareprojekts, da sie die Grundlage für die gesamte Entwicklung legt. Eine gut durchdachte Architektur ermöglicht eine effiziente Entwicklung, eine bessere Zusammenarbeit im Team und erleichtert zukünftige Anpassungen und Erweiterungen.

Grundlagen der Agilität

Agile Prinzipien sind eine Reihe von Leitlinien und Werten, die angewendet werden, um eine flexible, kundenorientierte und effiziente Arbeitsweise zu fördern. Das „Agile Manifesto“ betont die Wichtigkeit von Individuen und Interaktionen, funktionierender Software, Zusammenarbeit von Kunden und die Bereitschaft zur Anpassung an Veränderungen.

Die agilen Prinzipien sind:

  • Individuen und Interaktionen über Prozesse und Werkzeuge

Die Zusammenarbeit zwischen den Teammitgliedern und die klare Kommunikation stehen im Vordergrund. Effektive Zusammenarbeit führt zu besserem Verständnis und letztendlich zu einer erfolgreichen Umsetzung.

 

  • Funktionierende Software über umfassende Dokumentation

Die Priorität liegt darauf, funktionierende Software zu entwickeln, die den Nutzerbedürfnissen entspricht. Dokumentation ist wichtig, aber sie sollte nicht den Fokus von der tatsächlichen Entwicklung ablenken.

 

  • Zusammenarbeit mit Kunden über Vertragsverhandlung

Die enge Zusammenarbeit mit dem Nutzer ermöglicht es dem Team, ihre Anforderungen und Bedürfnisse besser zu verstehen. Feedback der Nutzer ist von großer Bedeutung, um die Software kontinuierlich zu verbessern.

 

  • Reagieren auf Veränderung über das Befolgen eines Plans

Anstatt strikt einem starren Plan zu folgen, sollten agile Teams bereit sein, auf Änderungen und neue Erkenntnisse flexibel zu reagieren. Veränderungen werden als eine Möglichkeit zur Anpassung und Verbesserung begriffen.

Aufbauend auf den 4 Werten leitet das agile Manifest zwölf Prinzipien für die Zusammenarbeit zwischen Entwicklungsteam und Kunden ab:

  1. Höchste Priorität ist frühe und kontinuierliche Auslieferung zu gewährleisten. Dieses Vorgehen soll sicherstellen nicht an Bedürfnissen der Nutzer vorbei zu entwickeln.
  2. Änderungen sind erwünscht. Durch kontinuierliches Feedback kann dieses Vorgehen zum Wettbewerbsvorteil werden.
  3. Funktionsfähige Software, die in kurzen Zeitspannen ausgeliefert werden können.
  4. Arbeite eng mit Kunden und Nutzern zusammen, um Anforderungen zu definieren und laufend Feedback zu erhalten.
  5. Bilde motivierte Individuen aus und gebe ihnen die Umgebung und Unterstützung, die sie benötigen. Vertraue darauf, dass sie die Arbeit erledigen.
  6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht.
  7. Funktionierende Software ist das primäre Maß für Fortschritt.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Entwickler, Sponsoren und Anwender sollten ein konstantes Tempo auf unbestimmte Zeit aufrechterhalten können.
  9. Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design verbessert die Agilität.
  10. Einfachheit – die Kunst die Menge nicht erledigter Arbeit zu maximieren – ist essenziell.
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen in selbstorganisierten Teams.
  12. In regelmäßigen Abständen reflektieren das Team und seine Mitglieder darüber, wie sie effektiver werden können, und passen ihr Verhalten entsprechend an.

 Diese agilen Prinzipien dienen als Grundlage für agile Entwicklungsmethoden wie Scrum, Kanban, Extreme Programming und andere, um Teams bei der Entwicklung hochwertiger Software mit hoher Flexibilität und Nutzerzufriedenheit zu unterstützen.

In agilen Softwareentwicklungsprojekten wird zunehmend auf evolutionäre Softwarearchitektur und emergentes Design im Gegensatz zu vorher festgelegter Architektur (engl.: „Big Design Up Front“) gesetzt. Dabei soll durch Techniken wie Behavior Driven Development, testgetriebene Entwicklung und vor allem Refactoring sichergestellt werden, dass das technische Design und die Architektur im Laufe eines Softwareentwicklungsprojektes ständig an die Anforderungen angepasst werden.

 Wie sich agiles Arbeiten in der Gestaltung von Softwarearchitektur umsetzen lässt, werden wir im zweiten Teil unserer Blogserie „Agile Softwarearchitektur“ mit dem Thema „Agiles Architekturvorgehen“ betrachten.