Auf einen Blick
- Architektur wird aus Anforderungen abgeleitet – nicht andersherum. Erst die funktionalen und nicht-funktionalen Anforderungen und Randbedingungen, dann die Architektur.
- ISO 42010:2011 definiert Architektur über elements, relationships, principles sowie design (was) und evolution (wie).
- Zwei oberste Kriterien guter Architektur: Angemessenheit und Umsetzbarkeit.
- Nicht-funktionale Anforderungen gehören dem Architekten – wenn möglich mit Zahlen (know your numbers).
- Architektursichten: Jede Sicht beschreibt einen Aspekt; alle zusammen ergeben ein vollständiges Bild (Geschäfts-, Kontext-, Logische, Entwicklungs-, Daten-, Verteilungs-/Laufzeitsicht).
- Validierung vs. Verifikation: Baue ich das Richtige? (Validierung) vs. Baue ich es richtig? (Verifikation).
Kernkonzepte
1. Was ist Software-Architektur? (ISO 42010:2011)
Die ISO-Definition lautet: Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.
Die Bestandteile dieser Definition:
- concepts – was geplant ist (Zukunft) · properties – bestehende Bestandteile (Gegenwart)
- elements – die einzelnen Bausteine · relationships – die Beziehungen zwischen den Bausteinen · principles – Grundsätze und Regeln
- design – was entwickelt wird · evolution – wie entwickelt wird
2. Vereinfachte Definitionen
Drei einprägsame Kurzformen, die alle einen wahren Kern treffen:
- Software-Architektur ist alles, was bei der Entwicklung von Software wirklich wichtig ist.
- Software-Architektur ist das gemeinsame Verständnis der Entwickler über den Aufbau des Systems.
- Software-Architektur ist alles, was schwer zu ändern ist.
Analogie Bauwesen: Der Bauplan im Großen, aufgeteilt in Aspekte (Erscheinungsbild, Geometrie, Statik, Technik, Vorschriften, Brandschutz). Die Rolle des Architekten: Abstimmung, Planung, Begleiten der Ausführung, Entscheidungen, Qualitätssicherung.
3. Wann braucht man Architektur – und wann nicht?
Architektur ist kein anti-agiles Planen. Agil heißt nicht keine Dokumente – Agil nimmt Dokumente nur nicht als Maß des Fortschritts.
Architektur brauchen wir bei:
- Großem Team / großem Projekt
- IT-Sicherheit (z. B. Anwendung im Internet)
- Hohen nicht-funktionalen Anforderungen
- Anforderungen des Kunden, von Standards oder Gesetzen
Keine (zusätzliche) Architektur nötig bei: keinen technischen Risiken, oder wenn die Architektur dem Team klar ist (Standardarchitektur vorhanden, Erfahrung aus vorherigen Projekten).
4. Oberste Kriterien guter Architektur
- Angemessenheit – die funktionalen und nicht-funktionalen Anforderungen werden erfüllt, aber auch nicht mehr (kein Over-Engineering).
- Umsetzbarkeit – unter den gegebenen Randbedingungen (Team, Wissen, Zeit, Budget).
Beispiel Kinoticket-Anwendung: Brauche ich wirklich native Apps für iOS und Android und ein Browser-UI? Sind 8 Microservices angemessen – haben wir das Wissen (auch für den Betrieb)? Ist ein Desaster-Recovery mit max. 10 Min Ausfallzeit gerechtfertigt? Und: Security ist auch bei billigen Tickets wichtig (Passwörter, Ransomware).
5. Vorgehen: Architektur aus Anforderungen ableiten
Der zentrale Merksatz des Kapitels. Die Architektur ergibt sich aus drei Eingangsgrößen:
- Funktionale Anforderungen – Zweck der Software; was muss sie können?
- Nicht-funktionale Anforderungen – Datenvolumen/Last, Sicherheit, Arbeitslast … quantitativ: know your numbers!
- Randbedingungen – Kunde/Anwender, Organisation, Team, Kenntnisse, Standorte.
6. Nicht-funktionale Anforderungen gehören dem Architekten
Der Architekt verantwortet insbesondere die NFAs. Wichtige Kategorien:
- Performanz & Skalierbarkeit – Datenvolumen, Datendurchsatz, Requests pro Zeiteinheit, Antwortzeiten (mit Zahlen!).
- Sicherheit (VIV) – Vertraulichkeit, Integrität, Verfügbarkeit.
- Authentifizierung (wer bist du?) und Autorisierung (was darfst du? – verwalten, provisionieren, prüfen).
- Auditierbarkeit (Nachvollziehen von Datenänderungen) und Protokollierung/Logging (Nachvollziehen der Verarbeitung).
- Monitoring & Alerts, Gebrauchstauglichkeit (Usability).
- Internationalisierung (I18N) – UI-Labels, mehrsprachige Datenwerte, Formatierung von Datum/Zeit/Zahlen/Geldbeträgen.
- Datenlebenszyklus – Sperren und Löschen (GDPR/DSGVO), Archivierung (aufheben, aber nicht im Online-System).
- Verfügbarkeit – Wartungsfenster (wann, wie lange, wie oft), maximale ungeplante Nichtverfügbarkeit.
- Vorgaben – durch Auftraggeber, Standards, Gesetze.
7. Rolle des IT-Architekten
- Analyse – funktionale Anforderungen abstimmen, nicht-funktionale ableiten.
- Architektur erstellen – Baupläne, Entwicklungsvorgaben, Auswahl von Tools/Technologien, Entscheidungen treffen.
- Fachliche Führung des Entwicklungsteams – Aufgaben planen und verteilen, Arbeitsabläufe gestalten.
- Fortschritt bewerten & Qualität prüfen.
- Kommunikation – nah am Auftraggeber und am Entwickler, übersetzen zwischen Fachbereich und IT, die Lösung verkaufen und verteidigen.
8. Konzept der Architektursichten
Jede Sicht beschreibt einen Aspekt; alle Sichten zusammen ergeben ein vollständiges Bild.
| Sicht | Inhalt |
|---|---|
| Geschäftssicht | Geschäftsprozesse, Geschäftsobjekte, Akteure, Organisation, fachliche Modelle und Regeln |
| Kontextsicht | Umfeld der Anwendung: Akteure, andere Systeme, Datenflüsse |
| Logische Sicht | Kernanwendungsfälle, Modellierung, Aufteilung in Module, Modulabhängigkeiten |
| Entwicklungssicht | Werkzeuge, Entwicklungsrichtlinien, Verwaltung des Codes, Konfiguration, Bau der Anwendung |
| Datensicht | Technisches Datenmodell, Datenaustausch / Integration |
| Verteilungs- & Laufzeitsicht | Verteilung auf Infrastruktur, Ausführung, Performanz & Skalierung, Betrieb |
Diese Vorlesung vertieft vor allem die Entwicklungssicht, die Ausführungs-/Verteilungssicht und die Logische Sicht (per Domain Driven Design / hexagonalem Modell: Domäne, Applikation, Infrastruktur).
9. Validierung vs. Verifikation
Zwei Begriffe, die in der Klausur gern verwechselt werden:
- Validierung – Baue ich das Richtige? (Stimmt es mit den Bedürfnissen/Anforderungen überein?)
- Verifikation – Baue ich es richtig? (Ist es korrekt gegen die Spezifikation umgesetzt?)
Merksätze
Ableitungsrichtung
Architektur wird aus Anforderungen abgeleitet – nicht andersherum. Funktionale Anforderungen, nicht-funktionale Anforderungen, Randbedingungen zuerst.
Zwei oberste Kriterien
Angemessenheit (Anforderungen erfüllt, aber nicht mehr) und Umsetzbarkeit (unter den gegebenen Randbedingungen).
NFAs gehören dem Architekten
Nicht-funktionale Anforderungen sind Architektensache – und wenn möglich mit Zahlen zu hinterlegen: know your numbers.
Sicherheit = VIV
Vertraulichkeit, Integrität, Verfügbarkeit. Authentifizierung (wer?) ist von Autorisierung (was darf?) zu trennen.
Sichten ergänzen sich
Jede Architektursicht beschreibt nur einen Aspekt. Erst alle Sichten zusammen ergeben ein vollständiges Bild des Systems.
Validierung ≠ Verifikation
Validierung: baue ich das Richtige? Verifikation: baue ich es richtig?
Übungsfragen
F1 Wie definiert die ISO 42010:2011 Software-Architektur?
Als die fundamentalen Konzepte oder Eigenschaften eines Systems in seiner Umgebung, verkörpert in seinen Elementen, deren Beziehungen und in den Prinzipien seines Designs und seiner Evolution. Kurz: elements (Bausteine), relationships (Beziehungen), principles (Regeln) sowie design (was entwickelt wird) und evolution (wie entwickelt wird).
F2 Nenne die zwei obersten Kriterien für eine gute Software-Architektur.
Angemessenheit und Umsetzbarkeit. Angemessenheit heißt, dass alle funktionalen und nicht-funktionalen Anforderungen erfüllt werden – aber auch nicht mehr (kein Over-Engineering). Umsetzbarkeit heißt, dass die Architektur unter den gegebenen Randbedingungen (Team, Wissen, Zeit) realisierbar ist.
F3 In welche Richtung leitet man Architektur ab?
Aus den Anforderungen zur Architektur – nicht andersherum. Zuerst stehen funktionale Anforderungen (was muss die Software können), nicht-funktionale Anforderungen (Last, Sicherheit, Antwortzeiten …) und Randbedingungen (Kunde, Team, Standorte) fest; daraus wird die Architektur entwickelt.
F4 Was bedeutet VIV bei der Sicherheit?
Vertraulichkeit, Integrität und Verfügbarkeit – die drei Schutzziele der IT-Sicherheit. Ergänzend gehören Authentifizierung (Nachweis der Identität) und Autorisierung (Rechteprüfung: verwalten, provisionieren, prüfen) sowie Auditierbarkeit und Protokollierung zur Sicherheitsbetrachtung des Architekten.
F5 Warum sind nicht-funktionale Anforderungen Sache des Architekten?
Weil sie den grundlegenden, schwer änderbaren Aufbau des Systems bestimmen (Performanz, Skalierung, Sicherheit, Verfügbarkeit, I18N, Datenlebenszyklus). Sie sind oft nicht offensichtlich aus dem fachlichen Wunsch ableitbar und müssen aktiv erhoben und – wenn möglich – mit konkreten Zahlen hinterlegt werden (know your numbers).
F6 Ist Architektur ein Widerspruch zu agilem Vorgehen?
Nein. Agil heißt nicht keine Dokumente – Agil nimmt Dokumente nur nicht als Maß des Fortschritts. Architektur ist besonders dann sinnvoll, wenn es technische Risiken, hohe nicht-funktionale Anforderungen, große Teams oder gesetzliche/kundenseitige Vorgaben gibt. Bei geringen Risiken und einer dem Team bereits klaren Standardarchitektur braucht es keine gesonderte Architekturarbeit.
F7 Welche Architektursichten gibt es und wozu dienen sie?
Geschäftssicht (Prozesse, Geschäftsobjekte, Akteure, Regeln), Kontextsicht (Umfeld: Akteure, andere Systeme, Datenflüsse), Logische Sicht (Kernanwendungsfälle, Module und Abhängigkeiten), Entwicklungssicht (Werkzeuge, Richtlinien, Code-Verwaltung, Bau), Datensicht (technisches Datenmodell, Integration) und Verteilungs-/Laufzeitsicht (Infrastruktur, Ausführung, Performanz, Betrieb). Jede Sicht beleuchtet einen Aspekt; erst alle zusammen ergeben ein vollständiges Bild.
F8 Was unterscheidet Validierung von Verifikation?
Validierung beantwortet die Frage Baue ich das Richtige? – also ob das System die tatsächlichen Bedürfnisse und Anforderungen trifft. Verifikation beantwortet Baue ich es richtig? – also ob das System korrekt gegen seine Spezifikation umgesetzt ist.
F9 Welche Aufgaben umfasst die Rolle des IT-Architekten?
Analyse (funktionale Anforderungen abstimmen, nicht-funktionale ableiten), Architektur erstellen (Baupläne, Vorgaben, Technologiewahl, Entscheidungen), fachliche Führung des Teams (Aufgaben planen und verteilen), Fortschritts- und Qualitätsbewertung sowie Kommunikation (Übersetzen zwischen Auftraggeber und IT, die Lösung verkaufen und verteidigen).