Softwarearchitekten kennen mehrere Definitionen von Softwarearchitektur (u. a. ISO 42010/IEEE 1471, SEI, Booch etc.) und können deren Gemeinsamkeiten benennen:

• Komponenten/Bausteine mit Schnittstellen und Beziehungen
• Bausteine als allgemeiner Begriff, Komponenten als eine spezielle Ausprägung davon
• Strukturen, Querschnittskonzepte, Prinzipien
• Architekturentscheidungen mit systemweiten oder den gesamten Lebenszyklus betreffenden Konsequenzen

Wesentliche Ziele von Softwarearchitektur sind:

• Qualitätsanforderungen wie Zuverlässigkeit, Wartbarkeit, Änderbarkeit, Sicherheit sowie funktionale Anforderungen zu erreichen
• Erstellung und Wartung von Software, insbesondere die Implementierung zu unterstützen
• Verständnis für Strukturen und Konzepte des Systems zu vermitteln, bezogen auf sämtliche relevanten Stakeholder.

Softwarearchitekten können Ihre Aufgaben und Ergebnisse in den gesamten Lebenszyklus von ITSystemen einordnen. Sie können:

• Konsequenzen von Änderungen bei funktionalen Anforderungen, Qualitätsanforderungen, Technologien oder der Systemumgebung im Bezug auf die Softwarearchitektur erkennen
• inhaltliche Zusammenhänge zwischen IT-Systemen und den unterstützten Geschäfts- und Betriebsprozessen aufzeigen.

Softwarearchitekten tragen die Verantwortung für die Erreichung der geforderten oder notwendigen Qualität und die Erstellung des Architekturentwurfs der Lösung. Sie müssen diese Verantwortung, abhängig vom jeweiligen Prozess- oder Vorgehensmodell, mit der Gesamtverantwortung der Projektleitung oder anderen Rollen koordinieren. Aufgaben und Verantwortung von Softwarearchitekten:

• Anforderungen und Randbedingungen klären, hinterfragen und bei Bedarf verfeinern. Hierzu zählen neben den funktionalen Anforderungen (Required Features) insbesondere die geforderten Qualitätsmerkmale (Required Constraints)
• Strukturentscheidungen hinsichtlich Systemzerlegung und Bausteinstruktur treffen, dabei Abhängigkeiten und Schnittstellen zwischen den Bausteinen festlegen
• Querschnittskonzepte entscheiden (beispielsweise Persistenz, Kommunikation, GUI) und bei Bedarf umsetzen
• Softwarearchitektur auf Basis von Sichten, Architekturmustern sowie technischen und Querschnittskonzepten kommunizieren und dokumentieren
• Umsetzung und Implementierung der Architektur begleiten, Rückmeldungen der beteiligten Stakeholder bei Bedarf in die Architektur einarbeiten, Konsistenz von Quellcode und Softwarearchitektur prüfen und sicherstellen
• Softwarearchitektur analysieren und bewerten, insbesondere hinsichtlich Risiken bezüglich der geforderten Qualitätsmerkmale
• Die Konsequenzen von Architekturentscheidungen erkennen, aufzeigen und gegenüber anderen Stakeholdern argumentieren

Sie sollen selbständig die Notwendigkeit von Iterationen bei allen Aufgaben erkennen und Möglichkeiten für entsprechende Rückmeldung aufzeigen

Softwarearchitekten können ihre Rolle erklären und ihren Beitrag zur Systementwicklung in Verbindung mit anderen Stakeholdern kontextspezifisch ausgestalten, insbesondere zu:

• Anforderungsanalyse (Systemanalyse, Anforderungsmanagement, Fachbereich)
• Implementierung
• Projektleitung und -management
• Produktmanagement, Product-Owner
• Qualitätssicherung
• IT-Betrieb (Produktion, Rechenzentren), zutreffend primär für Informationssysteme
• Hardwareentwicklung
• Unternehmensarchitektur, Architekturboard.

• Softwarearchitekten können den Einfluss von iterativem Vorgehen auf Architekturentscheidungen erläutern (hinsichtlich Risiken und Prognostizierbarkeit).
• Sie müssen aufgrund inhärenter Unsicherheit oftmals iterativ arbeiten und entscheiden. Dabei müssen sie bei anderen Stakeholdern systematisch Rückmeldung einholen.

Softwarearchitekten können:

• langfristige Qualitätsanforderungen sowie deren Abgrenzung gegen (kurzfristige) Projektziele erklären
• Potentielle Zielkonflikte zwischen kurz- und langfristigen Zielen erklären, um eine für alle Beteiligten tragfähige Lösung zu erarbeiten
• Qualitätsanforderungen identifizieren und präzisieren.

Softwarearchitekten:

• können Annahmen oder Voraussetzungen explizit darstellen und vermeiden implizite Annahmen
• wissen, dass implizite Annahmen potentielle Missverständnisse zwischen beteiligten Stakeholdern bewirken.

Der Fokus des iSAQB CPSA-Foundation Level liegt auf Strukturen und Konzepten einzelner Softwaresysteme. Darüber hinaus kennen Softwarearchitekten weitere Architekturdomänen, beispielsweise:

• Unternehmens-IT-Architektur (Enterprise IT Architecture): Struktur von Anwendungslandschaften
• Geschäfts- bzw. Prozessarchitektur (Business and Process Architecture): Struktur von u.a. Geschäftsprozessen
• Informationsarchitektur: systemübergreifende Struktur und Nutzung von Information und Daten
• Infrastruktur- bzw. Technologiearchitektur: Struktur der technischen Infrastruktur, Hardware, Netze etc.
• Hardware- oder Prozessorarchitektur (für hardwarenahe Systeme).

Diese Architekturdomänen sind nicht inhaltlicher Fokus vom CPSA-F.

Softwarearchitekten kennen unterschiedliche Typen von IT-Systemen, beispielsweise:

• Informationssysteme
• Decision-Support, Data-Warehouse oder Business-Intelligence Systeme
• Mobile Systeme
• Batchprozesse oder -systeme
• hardwarenahe Systeme; hier verstehen sie die Notwendigkeit des Hardware-/Software-Codesigns (zeitliche und inhaltliche Abhängigkeiten von Hard- und Softwareentwurf).

Auch als operationale Systeme bezeichnet, arbeiten diese Systeme als Teil der normalen Geschäftsprozesse in Unternehmen. In den meisten Fällen enthalten sie Operationen auf Daten (Transaktionen, Einfüge-, Änderungs- und Löschoperationen), die vom Ablauf her in die Benutzeroberfläche eingebettet sind. Die Art der Transaktionen ist festgelegt. Die Systeme operieren auf möglichst aktuellen Datenbeständen. Sie erfordern ein hohes Maß an Systemverfügbarkeit und Performance.

Quelle: Effektive Softwarearchitekturen. 8. Auflage Kapitel: 3.2.2

Kopien der aktuellen Unternehmensdaten (data warehouse) und enthalten hauptsächlich lesende Datenzugriffe. Die Art der Anfragen an die Daten ist flexibel. Benutzer können neue Anfragen (queries) formulieren. Daher ist die Laufzeit von Anfragen im Vorfeld kaum abschätzbar. Solche Systeme tolerieren höhere Ausfallzeiten und geringere Performance.

Quelle: Effektive Softwarearchitekturen. 8. Auflage Kapitel: 3.2.2

Eine (moderne) Variante von Online-Systemen – durch die starke Verbreitung von Smartphones und Tablet-Computern sehr wichtig geworden. Starker Fokus auf Benutzeroberfläche und Benutzbarkeit, oftmals per Internet an Backend-Systeme angebunden.

Quelle: Effektive Softwarearchitekturen. 8. Auflage Kapitel: 3.2.2

dienen hauptsächlich der Datenmanipulation, oftmals zur Vor- oder Nachverarbeitung vorhandener Datenbestände; werden zur Interaktion mit anderen Systemen eingesetzt.

Quelle: Effektive Softwarearchitekturen. 8. Auflage Kapitel: 3.2.2

arbeiten eng verzahnt mit spezieller Hardware. Ein Beispiel für eingebettete Systeme sind Mobiltelefone (viele haben auch Echtzeitanforderungen).

Quelle: Effektive Softwarearchitekturen. 8. Auflage Kapitel: 3.2.2

Operationen werden innerhalb garantierter Zeiten fertiggestellt. Beispiel: Produktionssteuerung (Fließbänder mit festen Taktzeiten), Herzschrittmacher.

Quelle: Effektive Softwarearchitekturen. 8. Auflage Kapitel: 3.2.2