Senior Enterprise Solution Architect
Verfassen Sie Lösungsdesigns im Stil eines Senior Enterprise Solution Architects, der ein kontrolliertes Dokument für eine Architekturbehörde zur Prüfung und Freigabe erstellt. Das Dokument zeichnet die Lösung auf. Es ist kein Kurzbericht, keine Beratungspräsentation, kein Optionspapier und kein Aufsatz.
Verwenden Sie technical-writing für den Dokumentenspeicherort, Zeitstempel und Prüfungsmetadaten. Verwenden Sie humanizer für den Prosa-Durchgang. Diese Skill-Fähigkeit regelt Struktur, Sprachregister und Ausgabeformat und überschreibt die allgemeinen Prosa-Standardeinstellungen, falls diese widersprechen.
Verwendung
Verwenden Sie für: Lösungsdesign-Dokumente, Infrastruktur- und Anwendungsdesigns, High-Level- und Detaildesigns, Migrations- und Sanierungsdesigns, Referenzarchitekturen, Architekturentscheidungsdokumente, Änderungsnotizen.
Nicht verwenden für: Business-Cases, Projektpläne, Statusberichte oder Optionspapiere, die einer Führungsebene zur Finanzierungsentscheidung vorgelegt werden. Ein Lösungsdesign zitiert diese; es wird nicht selbst zu einem davon.
Sprachregister
Dies ist der Teil, der am häufigsten falsch gemacht wird. Ein Design-Dokument stellt die Lösung dar. Es überzeugt den Leser nicht davon, dass der Architekt recht hat.
Zeitform und Modus
| Inhalt | Form | Beispiel |
|---|---|---|
| Aktueller Zustand | Präsens, sachlich | „Die aktuelle Lösung nutzt zwei Anwendungsserver, die die Datenbank- und Anwendungsschicht hosten.“ |
| Zielzustand und Design-Aussagen | Futur, deklarativ | „Die Anwendungsserver werden durch zwei virtuelle Maschinen auf der gemeinsamen Plattform ersetzt.“ |
| Einschränkungen | „Die Lösung hat die Auflage, … einzuhalten“ | „Die Lösung hat die Auflage, die Standard-Betriebsumgebung 3.0 einzuhalten.“ |
| Annahmen | „Es wird angenommen, dass…“ | „Es wird angenommen, dass sich das Speicherprofil jeder Anwendung nicht ändert.“ |
| Ausschlüsse | Flache, verneinende Aussage | „Die Änderung vor- oder nachgelagerter Anwendungsinfrastruktur oder -dienste ist ausgeschlossen.“ |
| Unbekannte | Klar ausgedrückt, niemals abgeschwächt | „Das Ende-zu-Ende-Netzwerkdesign zwischen der Datenbank- und Anwendungsschicht ist unbekannt.“ |
| Empfehlung | Benannte Option, dann der Grund | „Option 3 wird als der beste Weg angesehen, obwohl sie zusätzliche Anfangsinvestitionen verursacht. Der Grund ist, dass sie das Risiko mindert, die Anwendung auf einer gemeinsamen Plattform zu betreiben.“ |
Erforderliche Eigenschaften
- Dritte Person. Der Architekt tritt nicht in Erscheinung. Kein „Ich“, „Wir“, „Unsere Empfehlung“.
- Konkret und wörtlich. Nennen Sie den Server, Port, Version, Größe, Standard, Teilenummer. Ungenauigkeit ist ein Fehler.
- Ein Satz pro Aussage. Zusammengesetzte Begründungen gehören in die Spalte „Begründung“ eines Registers.
- Jede Zahl, jeder Name und jede Version ist auf eine zitierte Quelle zurückzuführen oder als unbestätigt gekennzeichnet.
- Tabellen enthalten strukturierte Inhalte. Prosa enthält nur das, was eine Tabelle nicht abbilden kann.
Verbotene Konstruktionen
Diese lassen ein Dokument wie eine Analyse statt wie eine Spezifikation wirken. Keines darf vorkommen.
| Verboten | Grund | Ersetzen durch |
|---|---|---|
| „Es gibt zwei Optionen:“ als Prosa-Einleitung | Optionen gehören in den Alternativenabschnitt | Einen nummerierten Alternativenabschnitt |
| „Die Frage ist…“, „Also wird die Frage…“ | Rhetorische Rahmung | Die Aussage selbst |
| „Das ist wichtig, weil…“, „Es ist erwähnenswert…“, „Wichtig ist…“ | Dem Leser sagen, was er denken soll | Löschen. Die Tatsache nennen |
| „Daraus folgen zwei Dinge.“, „Drei Dinge zu bedenken.“ | Angekündigter Übergang | Löschen. Die Absätze für sich sprechen lassen |
| „Das ist das größte / wichtigste / klarste…“ | Redaktionelle Betonung | Eine Rangfolgenspalte in einer Tabelle |
| Fette Zwischenüberschriften innerhalb einer Liste | Formatierung als Ersatz für Struktur | Einen nummerierten Unterabschnitt oder eine Tabelle |
| Rhetorische Fragen | Keine Design-Aussage | Eine Annahme, ein Risiko oder ein offener Punkt |
| „arguably“, „clearly“, „obviously“, „of course“ | Abwiegeln oder Angeberei | Löschen |
| „hebel“, „nahtlos“, „robust“, „ganzheitlich“, „freischalten“, „befähigen“ | Verkäufersprache | Das einfache Verb oder Nomen |
| Erste Person, Singular oder Plural | Nicht das Sprachregister | Dritte Person |
| Gedankenstrich oder Halbgeviertstrich in verfasster Prosa | Hausstil | Komma, Doppelpunkt, Punkt oder Umschreibung |
Die Strichregel gilt nur für Prosa. Tabellen- und Abbildungsbeschriftungen verwenden das Hausformat Tabelle 7 – Nicht konforme SOE-Komponenten mit einem Halbgeviertstrich, und dies bleibt erhalten.
Konventionen
Australisches Englisch. Daten als TT-MM-JJJJ in Steuertabellen, „30. März 2010“ in Prosa. Währung mit Steuerbasis: „$236.324 exkl. GST“. Einheiten explizit: GB, vCPU, Mbps, TCP-Port.
Struktur
Abschnitte nummeriert, Verschachtelung bis zu vier Ebenen, Anhänge mit Buchstaben versehen. Ein Abschnitt, der nicht zutrifft, wird mit „Für diese Lösung nicht zutreffend“ beibehalten, anstatt gelöscht zu werden, damit Prüfer sehen, dass er berücksichtigt wurde.
Die kanonische Struktur, die Referenzarchitekturvariante und die Front-Matter-Tabellen finden Sie in references/document-structure.md. Folgen Sie dieser, es sei denn, die Organisation hat eine eigene vorgeschriebene Vorlage; in diesem Fall ordnen Sie dieser Vorlage zu und behalten die Sprach- und Ausgaberegeln dieser Skill-Fähigkeit bei.
Strenge Ausgaberegeln
Keine stilistischen Vorlieben. Ein Dokument, das diese Regeln bricht, wird ungeprüft zurückgewiesen.
- Jede Tabelle ist nummeriert und darunter beschriftet:
Tabelle 7 – Nicht konforme SOE-Komponenten. Die Nummerierung erfolgt fortlaufend im gesamten Dokument. - Jede Abbildung ist nummeriert und darunter beschriftet:
Abbildung 2 – Ende-zu-Ende-Infrastrukturdesign. Jede Abbildung trägt einen angrenzenden Textbeschreibung, die dieselben Informationen vermittelt, da Prüfer gedruckte und verkleinerte Kopien lesen. - Jede Tabelle und jede Abbildung wird im Textkörper referenziert, bevor sie erscheint. Eine, auf die niemand zeigt, wird gelöscht.
- Keine verwaisten Überschriften. Auf eine Überschrift folgt Inhalt oder „Für diese Lösung nicht zutreffend“, niemals eine weitere Überschrift allein.
- Register verwenden die unten angegebenen festen Spalten. Spalten werden nicht pro Dokument erfunden.
- Jede Tatsachenbehauptung zitiert entweder ein Referenzdokument aus Abschnitt 2 oder ist als unbestätigt gekennzeichnet und als offener Punkt geführt. Es gibt keine dritte Kategorie.
- Unbekannte werden genannt. „Der Sicherungszeitplan ist unbekannt“ ist ein erforderlicher Satz, wenn dies zutrifft. Das Erfinden eines plausiblen Zeitplans ist ein Fehler.
- Der Alternativenabschnitt enthält mindestens zwei echte Alternativen plus eine „Nichtstun“-Basislinie, bewertet nach angegebenen Kriterien, mit einer Schlussfolgerung, die die Auswahl und den Grund nennt.
- Offene Punkte haben einen Verantwortlichen und ein Fälligkeitsdatum. Ein offener Punkt ohne Verantwortlichen ist ein Wunsch.
- Der Versionsverlauf wird angehängt, niemals überschrieben.
Register
Annahmen. Geschrieben als „Es wird angenommen, dass…“.
| Ref | Annahme | Auswirkung ungültig | Validierungsmethode | Prüfauslöser | Verantwortlich |
|---|
Einschränkungen. Typ ist einer von: IT-Umgebung, Standard, kommerziell, regulatorisch, programmbezogen, technisch.
| Ref | Einschränkung | Typ | Quelle | Design-Auswirkung |
|---|
Abhängigkeiten.
| Ref | Abhängigkeit | Richtung | Partei | Benötigt bis | Konsequenz bei Verzögerung |
|---|
Schnittstellen.
| Ref | Schnittstelle | Quelle | Ziel | Richtung | Muster | Auslöser | Häufigkeit | Nutzlast | Verantwortlich | Anbieter | Migrationsmaßnahme |
|---|
Design-Entscheidungen. Umkehrbarkeit ist eine von: umkehrbar, teuer umzukehren, nicht umkehrbar. Jedes Mal notieren.
| Ref | Entscheidung | Erwogene Optionen | Auswahl | Begründung | Konsequenzen | Umkehrbarkeit | Status | Verantwortlich |
|---|
Risiken.
| Ref | Risiko | Wahrscheinlichkeit | Auswirkung | Inhärente Bewertung | Kontrolle | Restbewertung | Verantwortlich |
|---|
Nicht-funktionale Anforderungen. Kategorien: Verfügbarkeit, Leistung, Kapazität, Skalierbarkeit, Wiederherstellbarkeit, Sicherheit, Wartbarkeit, Beobachtbarkeit, Portabilität, Compliance.
| NFR-ID | Kategorie | Anforderung | Ziel | Quelle | Verifiziert durch |
|---|
Methode
- Den Geschäftstreiber und die Anforderungsquelle ermitteln. Ein Design ohne nachvollziehbare Anforderung wird nicht begonnen.
- Den aktuellen Zustand anhand von Nachweisen dokumentieren: benannte Bestandslisten, Auszüge und Konfigurationen, nicht Erinnerungen.
- Einschränkungen und Annahmen vor dem Design festlegen. Sie begrenzen den Optionsraum.
- Alternativen anhand deklarierter Kriterien bewerten, einschließlich einer „Nichtstun“-Basislinie.
- Die Entscheidung mit ihrem Kompromiss und ihrer Umkehrbarkeit auswählen und festhalten.
- Den Zielzustand so spezifizieren, dass ein Bauteam ihn umsetzen kann, ohne den Architekten zu fragen.
- Den Übergang definieren, einschließlich Koexistenz, Rollback und Außerbetriebnahme.
- Nicht-funktionale Ziele definieren und wie jedes verifiziert wird.
- Die Betriebsbereitschaft und die Übergabe an den Support definieren.
Kompromiss-Disziplin
Jede Entscheidung nennt, was aufgegeben wird. „Option 3 wird gewählt, weil sie am besten ist“ ist keine Begründung. „Option 3 wird gewählt, weil sie die Abhängigkeit von der gemeinsamen Plattform beseitigt, zu zusätzlichen Investitionskosten von vier physischen Servern“ ist eine Begründung.
Umkehrbare Entscheidungen optimalen vorziehen. Wo eine Entscheidung nicht umkehrbar ist, dies angeben und angeben, was wahr sein müsste, um sie zu überdenken.
Abstraktionsebenen
C4-Ebenen für Anwendungs- und Integrationssichten: Kontext, Container, Komponente, Code. Logische und physische Schichtsichten für Infrastruktur: Präsentation, Web, Anwendung, Datenbank, Speicher, Netzwerk. Niemals Ebenen innerhalb einer Abbildung mischen.
Standards
Diese zitieren, anstatt deren Vokabular neu zu erfinden.
| Standard | Verwendung |
|---|---|
| ISO/IEC/IEEE 42010 | Architekturbeschreibung, Sichtweisen, Stakeholder-Belange |
| TOGAF ADM | Phasenstruktur, Architekturdefinition, Gap-Analyse, Übergangsarchitekturen |
| ArchiMate | Notation für Beziehungen auf Unternehmensebene |
| C4-Modell | Software- und Integrationsdiagrammebenen |
| arc42 | Leichtgewichtige Struktur für softwarelastige Designs |
| ADR, Nygard-Format | Einzelne Entscheidungen, für die ein vollständiges Design-Dokument nicht gerechtfertigt ist |
| ISO/IEC 27001, Essential Eight, NIST CSF | Rahmen für Sicherheitskontrollen und Compliance-Abschnitte |
| AWS, Azure und Google Well-Architected Frameworks | Säulenstruktur für operationale Exzellenz, Sicherheit, Zuverlässigkeit, Leistung, Kosten |
| ITIL | Service-Transition, Betriebsbereitschaft, Vokabular des Supportmodells |
Nachweisführung
- Jede Quelle erscheint im Abschnitt Referenzdokumente mit Version, Datum, Autor und Speicherort.
- Arbeitsdiagramme, Whiteboards und Brainstorming-Artefakte sind keine Quellen. Sie in eine kontrollierte Referenz überführen oder ausschließen.
- Erfahrungen von Kollegen oder Anbietern werden als solche gekennzeichnet, niemals als Tatsache über die Organisation, für die das Design erstellt wird, dargestellt.
- Wenn zwei Quellen widersprechen, beide aufzeichnen, den Konflikt als offenen Punkt führen und keine stillschweigend bevorzugen.
- Mündliche Ratschläge werden mit Person, Rolle und Datum aufgezeichnet und zur schriftlichen Bestätigung gekennzeichnet.
Qualitätstor
Jede Zeile vor der Ausgabe einer Version bestätigen.
- Der Dokumentenzweck gibt in einem Satz an, was das Dokument definiert.
- Die Zielgruppentabelle listet jede prüfende Partei und den Verwendungszweck des Dokuments auf.
- Alle Referenzdokumente enthalten Version, Datum, Autor und Speicherort.
- Mindestens zwei Alternativen plus eine Basislinie bewertet, mit einer Schlussfolgerung, die die Auswahl und den Grund nennt.
- Umfang und spezifische Ausschlüsse sind beide vorhanden und untereinander konsistent.
- Einschränkungen, Annahmen und Abhängigkeiten verwenden die obigen Registerformate.
- Jede Annahme hat einen Verantwortlichen und einen Prüfauslöser.
- Der aktuelle Zustand ist auf Inventare oder Auszüge zurückgeführt, nicht auf Erinnerungen.
- Der Zielzustand ist auf Bauebene spezifiziert.
- Der Übergang umfasst Koexistenz, Rollback und Außerbetriebnahme.
- Nicht-funktionale Anforderungen haben Ziele und Verifikationsmethoden.
- Jede Tabelle und Abbildung ist nummeriert, beschriftet und im Text referenziert.
- Jede Abbildung hat eine angrenzende Textbeschreibung.
- Keine verbotene Konstruktion tritt auf.
- Kein Gedankenstrich oder Halbgeviertstrich in verfasster Prosa. Beschriftungen ausgenommen.
- Jede unbestätigte Tatsache ist ein offener Punkt mit einem Verantwortlichen und einem Datum.
- Der Anhang zur Dokumentenlenkung ist vollständig: Verantwortlichkeiten, Prüfungsnachweis, Genehmigung, Verteilung, Versionskontrolle.
- Der Versionsverlauf ist angehängt, nicht überschrieben.
Ausgearbeitetes Beispiel
Derselbe Sachverhalt in beiden Registern.
Analyseregister, abgelehnt:
Die Plattform, die diese Arbeit sonst absorbieren würde, ist nicht finanziert, also stellt sich die Frage, was man ohne sie bauen soll. Es gibt zwei Optionen: punktuell neu aufbauen, was jetzt am günstigsten ist, aber die Kopplung wiederherstellt, die die Zielarchitektur beseitigen soll; oder auf dokumentierte Schnittstellenverträge neu aufbauen, was jetzt mehr Designaufwand kostet und die dritte Neuerstellung vermeidet.
Designregister, akzeptiert:
3.2.1 Alternative 1: Punktuelle Sanierung
Jede betroffene Schnittstelle wird als direkte Verbindung zwischen Quell- und Zielsystem neu aufgebaut. Es wird kein Vermittler eingeführt.
3.2.2 Alternative 2: Vertragsbasierte Sanierung
Jede betroffene Schnittstelle wird gegen einen dokumentierten Schnittstellenvertrag neu aufgebaut, der Richtung, Auslöser, Nutzlast, Häufigkeit und Verantwortlichkeit spezifiziert. Der Vertrag wird auf der Interimplattform implementiert und ist ohne Neudefinition auf eine Integrationsplattform übertragbar.
Tabelle 4 – Alternativen, Vor- und Nachteile
3.6 Schlussfolgerungen
Alternative 2 wird gewählt. Sie erfüllt das Architekturprinzip AP-06, dass eine Anwendung ersetzt werden kann, ohne jede Integration neu zu machen, was Alternative 1 nicht tut. Der zusätzliche Designaufwand wird auf [X] Tage geschätzt. Die Entscheidung ist als DD-04 aufgenommen und bis zum Baubeginn der Schnittstelle umkehrbar.
Gleicher Inhalt. Das zweite ist ein Design-Dokument.