+49 621 595702 0 info@itech-progress.com
Softwarearchitekten und KI-Systeme: Herausforderungen und Möglichkeiten Part 2/3

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

Jan. 29, 2025 | AI, Leseempfehlungen, Softwarearchitektur

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

 

Besuchen Sie uns auf der OOP 2025 in München

Besuchen Sie uns auf der OOP 2025 in München

Jan. 15, 2025 | Aktionen & Gewinnspiele, Messen & Konferenzen, Softwareentwicklung

Besuchen Sie uns auf der OOP 2025 in München!

Messestand Nr. 16

Wir von ITech Progress freuen uns, Sie auch 2025 wieder auf der OOP in München willkommen zu heißen! Vom 4. bis 6. Februar 2025 laden wir Sie herzlich an unseren Stand Nr. 16 im ICM München ein.

Großer_Preis_des_Mittelstandes_Urkunde_Jurystufe_Logo_2022

Tag(e)

:

Stunde(n)

:

Minute(n)

:

Sekunde(n)

Als Spezialist:innen für Softwarearchitektur und -entwicklung begleiten wir seit über zwei Jahrzehnten Unternehmen auf ihrem Weg zu zukunftssicheren, innovativen und nachhaltigen Softwarelösungen. Lassen Sie uns gemeinsam die Themen von morgen erkunden – auf einer der führenden Konferenzen für Softwarearchitekt:innen, Entwickler:innen und IT-Entscheider:innen! Das erwartet Sie auf der OOP 2025

Die OOP 2025 bietet ein vielfältiges Programm mit inspirierenden Top-Speaker:innen, interaktiven Workshops und praxisnahen Vorträgen zu den neuesten Entwicklungen in der Softwarewelt. Freuen Sie sich auf Themen wie:

  • Künstliche Intelligenz und maschinelles Lernen – die Gamechanger der Zukunft
  • Cloud-Technologien – Strategien für eine nahtlose Integration
  • Softwarearchitektur – Best Practices und innovative Ansätze
  • Agilität und Skalierung – moderne Prozesse auf den Punkt gebracht
  • Security und Datenschutz – essenziell für zukunftsfähige Software

Lassen Sie sich inspirieren und nehmen Sie frische Impulse für Ihre Projekte mit! Unsere Highlights am Messestand Nr. 16

Gewinnspiel für Architektur-Begeisterte

    • 1x CPSA-Schulung – Der nächste Schritt für Ihre Karriere
    • 3x Fachbuch „Basiswissen für Softwarearchitekt*innen“ – Must-have für Architektur-Profis

Exklusive Barista Bar

  • Genießen Sie bei uns erstklassigen Kaffee: Ob Espresso, Flat White oder Cappuccino – unsere Barista Bar lädt zum Verweilen und Netzwerken ein. Nutzen Sie die Gelegenheit, mit unseren Expert:innen bei einer Tasse Kaffee Ihre Herausforderungen und Ziele zu besprechen.

Warum ITech Progress?

ITech Progress steht für:

  • Architekturberatung – maßgeschneidert und zukunftssicher
  • Trainings & Schulungen – u. a. CPSA-Zertifizierungen und individuelle Workshops
  • Projektsupport – von der Idee bis zur erfolgreichen Umsetzung

Lernen Sie uns persönlich kennen und entdecken Sie, wie wir Ihre Vision in die Realität umsetzen können.

Save the Date! 4.–6. Februar 2025, ICM München, Messestand Nr. 16.
Lassen Sie sich inspirieren, gewinnen Sie tolle Preise und genießen Sie eine Tasse Kaffee mit uns. Wir freuen uns auf Sie!

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

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

Jan. 13, 2025 | AI, Leseempfehlungen, Softwareentwicklung, Technisch

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

Dez. 10, 2024 | Leseempfehlungen, Softwarearchitektur, Softwareentwicklung

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

Dez. 3, 2024 | Leseempfehlungen, Softwarearchitektur, Softwareentwicklung

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.

Quellen