Alles beginnt damit, dass eine Vielzahl an Definitionen des Begriffs Softwarearchitektur (siehe z. B. [SoD]) nebeneinander existieren. Viele davon teilen einen ge- meinsamen Kern, aber nicht alle teilen den Kern, den die Autoren für relevant halten. Wir können heute nicht davon ausgehen, dass jeder „Softwarearchitekt“ die Gemeinsamkeiten und Unterschiede einiger Definitionen kennt oder diskutieren kann. So werden Missverständnisse aus unterschiedlichen Auffassungen des Verantwortungsbereichs eines Softwarearchitekten möglich, z. B. durch Unkenntnis auf Sei- ten eines Softwarearchitekten und fälschlicher Annahme eines Konsenses auf Seiten des Auftraggebers.
Alles beginnt damit, dass eine Vielzahl an Definitionen des Begriffs Softwarearchitektur (siehe z. B. [1]) nebeneinander existieren. Viele davon teilen einen gemeinsamen Kern, aber nicht alle teilen den Kern, den die Autoren für relevant halten. Wir können heute nicht davon ausgehen, dass jeder „Softwarearchitekt“ die Gemeinsamkeiten und Unterschiede einiger Definitionen kennt oder diskutieren kann. So werden Missverständnisse aus unterschiedlichen Auffassungen des Verantwortungsbereichs eines Softwarearchitekten möglich, z. B. durch Unkenntnis auf Seiten eines Softwarearchitekten und fälschlicher Annahme eines Konsenses auf Seiten des Auftraggebers.
Würden alle Betroffenen eine gemeinsame Vorstellung des Berufsbildes Softwarearchitekt teilen, könnten sowohl Softwarearchitekten als auch Auftraggeber davon in verschiedener Hinsicht profitieren. Gemäß IEEE-Std 1471:2000 ist Softwarearchitektur eine intrinsische Eigenschaft eines Softwaresystems. Jede Software verfügt über eine Architektur, gleichgültig, ob letztere explizit entwickelt wurde oder nicht. Ein Softwarearchitekt hat dafür zu sorgen, dass neben den funktionalen Anforderungen auch nicht funktionale Anforderungen – sogenannte Qualitätsmerkmale – erfüllt werden, die nicht immer zwingend im Fokus des Projektleiters oder Auftraggebers liegen. Er plant bei der Erstellung (bzw. Anpassung) des Systems die Struktur der Software so, dass die Qualitätsmerkmale – im Rahmen der Möglichkeiten des Projekts – bestmöglich erfüllt werden. Während der Erfolg eines Projektleiters auch von Laien gemessen werden kann, wenn er mit den definierten Ressourcen im vereinbarten Zeitraum gewünschte Ergebnisse liefert, zeigt sich die gute Arbeit eines Softwarearchitekten erst nach der Systemeinführung.
Der Nutzen für den Softwarearchitekten
Aufgrund des bekannten Rollenmodells findet der Softwarearchitekt Hilfe zur eigenen Positionierung und Abstimmung mit beteiligten Ansprechpartnern. Der Kompetenzrahmen und Handlungsspielraum für Architekturthemen wird häufig durch die Organisation vorgegeben und muss projektspezifisch ausgehandelt werden. Eine Auseinandersetzung mit einem gemeinsamen Berufsbild schafft den Spielraum, um Verantwortung zu delegieren oder gar einzufordern. Der Softwarearchitekt kann dadurch seine Aufgabenbereiche leichter abstecken, benötigte (aber nicht zwingend offensichtliche) Interessenvertreter leichter ausfindig machen und erforderliche Mitwirkungen seiner Ansprechpartner leichter einfordern. Nicht nur ihm ist die Abhängigkeit seiner Rolle zu anderen Interessenvertretern bewusst. Eine klare Vorstellung von der Rolle des Softwarearchitekten verdeutlicht den Ausbildungspfad – insbesondere für das Selbststudium in Themen der Softwaretechnik und Softwarearchitektur und dient dem kontinuierlichen Lernen als roter Faden. Hierdurch wird eine Distanzierung von Teilen des allgemein Anerkannten ermöglicht, die – aufgrund des gemeinsamen Verständnisses – leichter benannt werden kann. Darüber hinaus erlaubt ein gemeinsames Verständnis vom Berufsbild des Softwarearchitekten das effektive Weiterentwickeln der Disziplin Softwarearchitektur. Durch eine vereinheitlichte Nomenklatur können Softwarearchitekten sich direkter und effektiver über Erfahrungen, Gesetzmäßigkeiten und Best Practices austauschen.
Der Nutzen für den Auftraggeber
Angenommen, alle Beteiligten haben ein gemeinsames Verständnis von dem Berufsbild und den Aufgaben eines Softwarearchitekten. Dann könnte der Auftraggeber aufgrund vergleichbarer Maßstäbe feststellen (lassen), ob der Softwarearchitekt seinen Verantwortungsbereich nach bestem Stand der Technik ausfüllt, oder nicht. Auftraggeber können – bildlich gesprochen – schnell die Spreu vom Weizen trennen, indem sie prüfen, inwieweit die Fähigkeiten und Kenntnisse eines Mitarbeiters dem Berufsbild entsprechen. Unternehmen sind auf die Kompetenz ihrer Mitarbeiter angewiesen. Sie bewerten kontinuierlich die Qualifikation der Mitarbeiter so objektiv wie möglich. Ein standardisiertes Berufsbild schafft hier einen unternehmensübergreifenden Bezugsrahmen, in dem erforderliche Fähigkeiten vergleichbar gemacht werden. Im Idealfall profitiert der Auftraggeber indirekt von einer Verbesserung der Disziplin Softwarearchitektur und direkt von der besseren Ausbildung der Softwarearchitekten im Allgemeinen. Das gemeinsame Verständnis aller Beteiligten vom Berufsbild des Softwarearchitekten hilft, die Projektorganisation zu vereinfachen: Die Aufgabenzuordnung ist bereits projektunabhängig bekannt, sodass nur noch über projektspezifische Abweichungen von der Standardzuordnung der Aufgaben diskutiert werden muss. Dies hilft auch agilen Projektteams, die die Verantwortung für die Lieferung eines lauffähigen Softwaresystems kollektiv übernehmen, die aus der Architekturverantwortung resultierenden Aufgaben in ihre Planungen mit einzubeziehen.
Softwarearchitekt als standardisierte Berufsbezeichnung
Der praktizierende Softwarearchitekt profitiert von einer Standardisierung des Begriffs Softwarearchitekt, da er seine Ausbildung und Spezialisierung nach bekannten Spielregeln verfolgen kann. Existiert ein allgemeines Verständnis über die Aufgaben, Verantwortungen und Kompetenzen eines Softwarearchitekten, wird die Teambildung und die Projektarbeit potenziell signifikant vereinfacht. Für den ausgebildeten Softwarearchitekten sind die Wege zu erweiterten Interessenvertretern (Stakeholdern) leichter auffindbar oder kürzer, da ihm die Bedeutung der Interessenvertreter für seinen Projekterfolg bewusster ist.
Organisationen, d. h. die Arbeitgeber der Softwarearchitekten, können auf ein etabliertes Rollenmodell zurückgreifen und dadurch einfacher feststellen, in welchen Bereichen ein Softwarearchitekt noch Verbesserungspotenzial hat und in welchen Bereichen er seine Stärken ausspielen kann. Eine Standardisierung des Begriffs Softwarearchitekt hilft dem Auftraggeber dabei, Projektteams aus kompetenten Partnern zusammenzustellen, die sich auf Basis bekannter Spielregeln selbst organisieren.
Erwartung an ein Zertifikat für Softwarearchitekten
Zertifikate haben das Ziel, anzuzeigen, ob der Zertifizierte über die Fähigkeiten und das Verständnis verfügt, welches das Zertifikat repräsentiert. Einige Zertifikate erfordern Schulungen und/oder das Ablegen einer Prüfung. Manche können auch direkt durch die Teilnahme an einer Prüfung erworben werden. Ein Zertifikat etabliert zu einem wesentlichen Teil durch das Prüfungsverfahren ein Leistungsversprechen. Dies entscheidet darüber, ob es ein anspruchsvolles, aussagekräftiges Zertifikat ist, das zuverlässig korrekte Rückschlüsse auf die Mindestqualifikation des Zertifizierten erlaubt. Für Softwarearchitekten sind zwei Arten von Zertifikaten sinnvoll: Zertifikate bzgl. allgemeiner, technologie-neutraler Themen oder aber Zertifikate zu technologiespezifischen Themen. Während Erstere tendenziell zeitlos sind, ist die Lebensdauer Letzterer häufig begrenzt. Renommierte Zertifikate bilden für die einheitliche Beurteilung eine gute Grundlage. Ein Indikator für die Qualität und Beständigkeit eines Zertifikats ist die Aufteilung der Verantwortung für die Definition des Inhalts, für die Durchführung der Ausbildung und für die Zertifizierungsprüfung auf verschiedene unabhängige Organisationen. Selbst wenn man die Aussagekraft eines Zertifikats in Zweifel ziehen wollte, bleibt der Nachweis, dass ein zertifizierter Mitarbeiter Zeit über die normale Arbeit hinaus in das Thema investiert hat, das mit dem Zertifikat verbunden ist. Zwei anerkannte Beispiele aus anderen Bereichen – die unter anderem bei der Auswahl von Bewerbern häufig Berücksichtigung finden – sind Certified Scrum Master oder der ISTQB Certified Tester.
###Sinnvolle Investition in die Zertifizierung
Wer erst noch Softwarearchitekt werden möchte, profitiert von dem Besuch eines Trainings für Softwarearchitekturen, um das Themengebiet strukturiert zu erschließen und sich auf angehende Aufgaben eines Softwarearchitekten vorzubereiten. Die anschließende Zertifizierungsprüfung stellt den Lernerfolg fest. Unternehmen können mit solchen Maßnahmen gezielt Mitarbeiter aufbauen und sie auf neue Aufgaben vorbereiten. Unternehmen können erfahrene Mitarbeiter zu Schulungen entsenden, um die Eignung für die Ausbildung jüngerer Kollegen in Bezug auf Unternehmenskontext und -ziele zu prüfen. Erfahrene Softwarearchitekten profitieren von einer Teilnahme an Trainings mit entsprechender Zertifizierung, um eigene Gedankenmodelle zu überprüfen, neue Standpunkte kennenzulernen oder Altbekanntes aufzufrischen und sich implizites Wissen bewusst zu machen.
Nicht sinnvolle Zertifizierungen
Unternehmen tun sich und unserer Zunft keinen Gefallen, wenn sie Mitarbeiter Zertifikate horten lassen, die keinen Bezug zu aktuellen oder geplanten Aufgabengebieten haben. Dies gilt insbesondere auch für Zertifikate als Abschiedsgeschenke für ausscheidende Mitarbeiter, wenn diese das mit einem Zertifikat verbundene Wissen nicht praktisch einsetzen konnten. Mittel- bis langfristig wird dadurch die Aussagekraft des Zertifikats geschmälert.
Welches Zertifikat?
In diesem Artikel können wir keinen seriösen Vergleich über die existierenden Zertifikate für Softwarearchitekten präsentieren. Dennoch wollen wir hier eine Reihe von Zertifikaten vorstellen. Auf eine Betrachtung von Zertifikaten, die an eine Technologie gebunden sind oder sich auf andere Architekturebenen wie zum Beispiel Unternehmensarchitektur konzentrieren, verzichten wir an dieser Stelle. Für Unternehmensarchitektur sei hier auf Zachman Framework oder TOGAF verwiesen.
IASA CITA-P
Die [2] ist in verschiedene Landesverbände unterteilt. Derzeit gibt es keinen Landesverband in Deutschland. IASA definiert die Laufbahn des Softwarearchitekten über einen Zeitraum von etwa 10 Jahren. Das Zertifikat (CITA-P: Certified IT Architect Professional) erfordert mehrere Jahre IT-Erfahrung in verschiedenen Phasen des Softwareentwicklungs-Lebenszyklusses sowie eine Reihe von Trainings, eine Darstellung der bisherigen Leistungen und eine Prüfung. CITA- P ist die 3. Ausbildungsstufe in der Architektenausbildung nach IASA. Der Lehrplan orientiert sich am ITA- BoK – dem IT Architecture Body of Knowledge. Die erste Stufen der Softwarearchitekten-Ausbildung genügt für eine Teilnahme an Trainings und das Bestehen der zugehörigen Zertifizierungsprüfung. Die Prüfung zum CITA-P erfolgt auf Basis eingereichter Unterlagen und mündlicher Prüfung durch mehrere Prüfer.
SEI Software Architecture Professional
Das [3], das Software Engineering Institute der Carnegie Mellon University, bietet Dienstleistungen, Beratung und Trainings rund um das Thema Softwaretechnik und auch Softwarearchitektur an. Das Zertifikat zum SEI Software Architecture Professional erhält man nach der Absolvierung der entsprechenden Kurse zu Grundprinzipien, Dokumentation und Entwurf, Analyse von Softwarearchitekturen sowie zu Softwareproduktlinien und einer zugehörigen Prüfung – einem Multiple-Choice-Test. Inhaltlich hat der Lehrplan für das Zertifikat recht große Überschneidungen mit dem zum CPSA der iSAQB. Das SEI bietet darüber hinaus noch ein Zertifikat SEI ATAM Evaluator Professional an sowie auf den Professional Zertifikaten aufbauende Instruktor-Zertifikate.
CPSA
Die Lehrinhalte für das Zertifikat CPSA (Certified Professional for Software Architecture) werden von iSAQB – dem International Software Architecture Qualification Board e.V. – definiert. Der Verein ist von Softwarearchitekturspezialisten – Praktikern, Fachbuchautoren, Hochschulprofessoren und Trainingsanbietern – mit dem Ziel gegründet worden, die Qualität der Ausbildung im Bereich Softwarearchitektur zu verbessern und ein gemeinsames Verständnis des Berufsbildes Softwarearchitekt international zu etablieren. Das Zertifikat gibt es in 3 Stufen: CPSA-F, CPSA-A und CPSA-E (für Foundation-, Advanced- und Expert-Level). Aktuell verabschiedet ist bislang nur der Lehrplan für CPSA-F. CPSA-A ist in der Entwicklung und CPSA-E in Planung. Schulungen gemäß dem iSAQB-Lehrplan für den Foundation-Level kann man bereits bei verschiedenen lizensierten Trainingsanbietern buchen. Für die Zertifizierung ist eine Prüfung (Multiple-Choice-Test) bei einem von derzeit zwei unabhängigen Prüfungsunternehmen notwendig, die häufig direkt im Anschluss an die Trainings stattfinden. Der iSAQB-Lehrplan formuliert für die Zertifizierung zum CPSA notwendige fachliche, organisatorische und soziale Kenntnisse und Fähigkeiten (siehe [4]). Eine Übersicht bietet Abbildung 1. Der Lehrplan steht unter [5] zum Herunter- laden zur Verfügung.
CPSA-F und die Hochschulen
Der Lehrplan für den CPSA-F definiert die notwendigen Vorkenntnisse, um an einer Schulung zum CPSA-F und der anschließenden Prüfung teilnehmen zu können. Diese sind unter anderen: Objektorientierung, Programmierkenntnisse, UML sowie praktische Projekterfahrung in Entwicklungsteams mit mehreren Personen. Es gibt Hochschulen, die ihren Studenten bereits während des Studiums diese Vorkenntnisse vermitteln und ihnen dadurch eine Zertifizierung zum CPSA-F ermöglichen können. Dafür steht Hochschulen eine einfache Form der Lizenzierung zur Verfügung.
Die Bedeutung des CPSA-F
Der CPSA-F zeigt die Ausrichtung auf das Thema Softwarearchitektur und dass sich der Zertifizierte der prüfungsrelevanten Aufgabenstellungen bewusst ist. Der Erwerb des Zertifikats CPSA-F allein macht noch keinen Softwarearchitekten. Er signalisiert potenziellen Arbeitgebern das Interesse für diese Berufsausrichtung. Auch Hochschulabsolventen können so die Gelegenheit bekommen, sich zunächst in größeren Projekten zu bewähren, um nach einigen Jahren das CPSA-A (Advanced-Level) und später dann das CPSA-E (ExpertLevel) Zertifikat zu erwerben. Das CPSA-F Zertifikat ist ein wichtiger Grundbaustein für eine Karriere als Softwarearchitekt. Auftraggeber können nicht aus dem Besitz des Zertifikats ableiten, wie qualifiziert der Inhaber des CPSA-F ist. CPSA-F besagt, dass der Zertifizierte die Aufgaben des Softwarearchitekten kennt und Grundkenntnisse in der Dokumentation, dem Entwurf und der Bewertung von Softwarearchitekturen besitzt.