Vorlesung 2: Was ist ein Software-Architekt? Flashcards
Nenne und erkläre die verschiedenen Bereiche die verschiedene Architekten betreffen
Anwendungsarchitekten:
- Beschäftigen sich nur mit dem “Innenleben” einer einzelnen Software
Software / sehr enge Abgrenzung
- Kann auch die Aufgabe eines leitenden Entwicklers sein (oder ähnlich)
Software-Architekten:
- Breiterer Kontext einer Anwendung, inkl. vor- und nachgelagerter
Systeme
- Sie haben die gesamte Geschäftsdomäne im Blick
Lösungsarchitekten:
- Gewährleistet die Integrität des Gesamtsystems (von der Hardware bis zur
Software)
- Übersetzen” der Software-Architektur in den Betrieb
Erkläre die Erwartungen an einen Software-Architekten
Ein Softwarearchitekt sollte…
Architekturentscheidungen treffen:
-Einige Architekturentscheidungen setzen bestimmte Technologien voraus, und Technologieentscheidungen können sich auf die Architektur auswirken!
Die Architektur kontinuierlich analysieren:
- Analysieren Sie die Tragfähigkeit der aktuellen Architektur
- Abgleich der aktuellen Architekturimplementierung mit neuen Anforderungen und verfügbaren Technologien
Mit den aktuellen (Technologie-)Trends Schritt halten:
- Mit den verfügbaren Technologien und Branchentrends Schritt halten
- Wichtig: Architekturentscheidungen sind langlebig und schwer zu ändern
Die Einhaltung von Entscheidungen sicherstellen:
- Überprüfen Sie, ob die Entwickler sich an die Entscheidungen / Muster halten
Über vielfältige Erfahrungen und Kenntnisse verfügen:
- Erfahrung in und Nutzung von verschiedenen Technologien
- Die technologische Breite ist wichtiger als die Tiefe (vielleicht T-förmig, Pi-förmig)
- Notwendig, um gute Entscheidungen zu treffen
Kenntnisse der Geschäftsbereiche haben:
- Die Softwarearchitektur muss die Geschäftsziele unterstützen - die Geschäftsziele/Anforderungen müssen verstanden werden
- Notwendig, um Entscheidungen zu treffen und mit den Beteiligten zu kommunizieren
Über zwischenmenschliche Fähigkeiten verfügen:
- Technische Führung ist immer auch ein “menschliches Problem”
- Architekturen müssen effektiv kommuniziert werden
- Technologische Führung wird erwartet (inkl. Coaching / Mentoring)
Die Politik verstehen und steuern können:
- Architekturentscheidungen werden sich (höchstwahrscheinlich) nicht nur auf die jeweilige Anwendung auswirken!
- Investitionen in die Architektur werden in Frage gestellt werden
- Entwickler werden Entscheidungen in Frage stellen
Welche Technische Fertigkeiten sollte ein Softwarearchitekt haben?
Die Codierungsaktivitäten von Softwarearchitekten hängen ab von…
- der Ebene, auf der sie arbeiten (z. B. Unternehmensarchitektur vs. Anwendungsarchitektur) und
- der Form der Organisation.
▪ Einige sehen “Architects Don’t Code” als ein Gegenmuster:
▪ Codierende Architekten verhindern den Elfenbeinturmeffekt
- Sich von Zeit zu Zeit in die schmutzigen Details einmischen
- Gemeinsames Verständnis schaffen
Welche Arten von Softwarearchitekten gibt es und was ist die ideale Art?
Typ 1: Kontrollfreak-Architekt
- Versucht, jeden einzelnen Aspekt des Softwareentwicklungsprozesses zu kontrollieren
- Trifft Entscheidungen, die typischerweise zu feinkörnig / niedrigschwellig sind
- Schafft enge Grenzen für das Entwicklungsteam (was zu Frustration führt)
▪ Typ 2: Sesselarchitekt
- Hat schon lange nicht mehr programmiert (wenn überhaupt) und kümmert sich nicht um Details (“Kästchen und Pfeile”)
- Schafft lose Grenzen für Entwicklungsteams, die zu lose sind, um hilfreich zu sein
▪ Typ 3: Effektiver Architekt
- Schafft angemessene Beschränkungen und Grenzen für das Team, legt ein gutes Maß an Anleitung fest
- Stellt sicher, dass das Team über geeignete Werkzeuge und Technologien verfügt
- Offensichtlich ist das der richtige Weg - leider ist es eine Kunst
Wie viel Kontrolle über die Architektur für ein Team notwendig ist, hängt von mehreren Faktoren ab, nenne und erkläre diese.
- Vertrautheit des Teams: Je besser sich die Teammitglieder untereinander kennen, desto weniger Kontrolle ist erforderlich.
- Größe des Teams: Je größer das Team ist, desto mehr Kontrolle ist erforderlich
- Gesamterfahrung: Je mehr einschlägige Erfahrung im Team vorhanden ist (Bereich, Technologie usw.), desto weniger Kontrolle ist erforderlich
- Projektkomplexität: Je komplexer ein Projekt ist, desto mehr Kontrolle ist erforderlich
- Projektdauer: Je kürzer die Dauer eines Projekts ist, desto weniger Kontrolle ist erforderlich
