Der Weg zur nachhaltigen Architektur
Sie sollen ein komplexes System erweitern und müssen verstehen, wie dessen Komponenten zusammenarbeiten? Sie sollen es auf eine neue Technologie migrieren und müssen nun das alte System verstehen – und das neue entwerfen? Die Basis für eine hohe Qualität ist immer eine gute Architektur. Und die Basis hierfür legt der iSAQB Certified Professional for Software Architecture® – Foundation Level.
Was ist Architektur?
Es gibt viele Definitionen von Architektur. Beispielsweise wird Architektur in der ISO/IEC 42010 definiert als die fundamentalen Konzepte oder Eigenschaften eines Systems in seiner Umgebung, verkörpert durch Bauelemente, Beziehungen, und die Prinzipien, die für sein Design und seine Evolution angewendet werden. Architektur macht also deutlich mehr aus als das bekannte UML-Diagramm, das die Komponenten einer Software und deren Beziehungen untereinander modelliert.
Der Grund hierfür ist, dass Architektur eines (Software-)Systems nicht nur die Basis dafür definiert, dass das System seine funktionalen Anforderungen erfüllen kann. Die ISO 25010 definiert eine Reihe weiterer Qualitätsmerkmale, oft als „nichtfunktionale Merkmale“ subsumiert. Diese decken zum einen die Fragestellung ab, wie gut das System seine Funktionalität zur Laufzeit umsetzt. Die Eigenschaften Performanz, Kompatibilität, Benutzbarkeit, Zuverlässigkeit und Sicherheit (im Sinne von Security) umfassen diese Kriterien. Zum anderen decken sie die Fragestellung ab, wie gut ein System gewartet und evolviert werden kann. Diese Kriterien werden durch die Qualitätseigenschaften Wartbarkeit und Portabilität abgedeckt.
Die Architektur eines (Software-)Systems bildet die Basis für alle genannten acht Qualitätskriterien. Und das ist die Herausforderung dabei: All diese Kriterien müssen bei der Modellierung des Systems beachtet und gemeinsam mit den Stakeholdern gegeneinander abgewogen werden. Denn beispielsweise ein System, dessen Zuverlässigkeit durch geolokale Redundanz maximiert wird, kann gleichzeitig große Schwächen in der Performanz aufweisen, falls große Datenmengen zwischen den verschiedenen Standorten abgeglichen werden müssen. Und auch hochperformante Systeme bestechen oft genug nicht durch ihre Wart- und Portierbarkeit, wie bestehende assemblerbasierte Mainframe-Programme stets aufs Neue beweisen. Diese unterschiedlichen Kriterien optimal auszutarieren, ist das Ergebnis einer gelungenen Architektur. Diese ist daher auch ihrerseits bereits frühzeitig im Entwicklungsprozess einer Analyse zu unterziehen, um die Qualität des Entwurfs als solchem und seine Orientierung an den Business-Anforderungen zu gewährleisten. Letzteres geschieht bspw. mithilfe der Architecture Tradeoff Analysis Method (ATAM). Über die gesamte Entwicklung und Wartung eines Systems hinweg sollte dann die Entwurfsqualität regelmäßig wieder unter die Lupe genommen werden, um einer schleichenden Regression vorzubeugen.
Wie begegnet man dieser Herausforderung am besten?
Eine Reihe von Hilfestellungen unterstützt Architekt:innen dabei, sich dieser Herausforderung zu stellen. Zum einen sind dies strukturierte Vorgehensweisen, zum anderen Lösungsbausteine, aus denen Architekturen zusammengestellt werden können.
Es hat sich bewährt, bei der Modellierung eines Systems explizit verschiedene Sichten einzunehmen, auf deren Basis die Diskussion mit den Stakeholdern zur Ermittlung des Lösungsraums geführt wird. Hierbei handelt es sich um folgende Sichten:
- Die Kontextsicht, die das „Drumherum“ um ein System unter die Lupe nimmt.
- Die Bausteinsicht, die die Einzelteile des Systems betrachtet.
- Die Laufzeitsicht, die das Zusammenspiel der Systembausteine zur Laufzeit betrachtet.
- Die Verteilungssicht, die die Verteilung der Bausteine u.a. auf Hardware und deren Lokationen betrachtet.
Durch die Einteilung des Designprozesses in diese Sichten gewinnt der gesamte Prozess an sich Struktur und man läuft weniger Gefahr, bei der Ermittlung von Anforderungen und Randbedingungen im Austausch mit den verschiedenen Stakeholdern wesentliche Aspekte zu vergessen.Wochen angeboten:
Das ist aber noch nicht alles. Kenne ich meinen Lösungsraum, muss ich mich ja nach wie vor um die konkrete Lösung kümmern. Diese sollte dabei zum einen qualitativ hochwertig und zum anderen gut dokumentiert sein. Glücklicherweise gibt es auch hierfür Hilfestellungen, nämlich in Form von
- Generellen Architekturprinzipien,
- Architekturpattern als Blaupausen für das Design im Großen und
- Designpattern als Blaupausen für das Design im Kleinen.
Durch das Befolgen von Prinzipien und die Nutzung von Pattern erreiche ich beides: Ich wende erprobte und für gut befundene Lösungsmuster an, die zudem bereits für sich genommen gut dokumentiert sind. Das wiederum senkt sowohl das Innovationsrisiko meines Produkts, als auch den Dokumentationsaufwand signifikant.
Die Schulung zum Certified Professional for Software Architecture
Vom iSAQB, dem International Software Architecture Qualification Board, gibt es mit den Zertifizierungen zum Certified Professional for Software Architecture® (CPSA) ein Curriculum, das die für die Entwicklung nachhaltiger (Software-)Architekturen notwendigen Qualifikationen auf- und ausbaut. Der Einstieg ist hierbei der iSAQB Certified Professional for Software Architecture® – Foundation Level (CPSA-F).
Teilnehmer einer Schulung zum CPSA-F lernen die Art und Weise, wie Architekturen konstruiert werden und kennen nach erfolgreicher Schulungsdurchführung
- Die grundlegenden Begrifflichkeiten rund um (Software-)Architektur,
- Die Rolle des Softwarearchitekten und seine Aufgaben und Verantwortlichkeiten im Softwareentwicklungsprozess,
- Die beteiligten Stakeholder bei der Abstimmung der Ausgestaltung einer Architektur für ein konkretes Softwareprodukt,
- Die wesentlichen Schritte zur Definition einer Architektur und die Sichten, die hierbei eingenommen und modelliert werden und
Die Methoden und Praktiken, die bei der Modellierung zum Einsatz kommen – namentlich Architekturmuster und Designpattern.
Entwickeln Sie IT-Lösungen, sei es als Entwickler, Tester oder bereits als Architekt? Oder möchten Sie einfach die Strukturen Ihres Systems mit Ihren Entwicklern auf Augenhöhe kommunizieren? Dann sind Sie in dieser Schulung richtig! Idealerweise bringen Sie schon praktische Programmiererfahrungen in einer objektorientierten Programmiersprache und grundlegende Kenntnisse in UML mit.
