arc42 gibt praxisorientierte Antwort die folgenden zwei Fragen, und läßt sich einfach an Ihre spezifischen Bedürfnisse anpassen:

  • Was sollen wir über unsere Architektur kommunizieren/dokumentieren?
  • Wie sollen wir kommunizieren/dokumentieren?

Dazu haben wir ein einfaches Template mit 12 Kapiteln entwickelt, in denen Sie alles Wissenswerte über die Architektur unterbringen können.

Den Kern der Architekturdokumentation bilden die Kontexabgrenzung (Kap. 3), die drei Sichten (Bausteinsicht, Laufzeitsicht und Verteilungssicht - Kap. 5 - 7), sowie die querschnittlichen Konzepte (Kap. 8).

Die restlichen Kapitel runden die Dokumentation ab. Sie halten u.a. Ziele, wichtige Entscheidungen und Risiken fest. Ein abeschließendes Glossar stellt sicher, dass alle über das Gleiche sprechen.

Wenn Sie mehr zu den Kapiteln wissen wollen, lesen Sie weiter oder lernen Sie noch mehr Details über die jeweiligen Links.


intro-image

1. Einführung und Ziele

Kurze Beschreibung und Extrakt der requirements, Die Top3 (bis maximal 5) Qualitätsziele für die Architektur, deren Erreichung für die wichtigsten Stakeholder kritisch ist. Eine Übersicht über die wichtigsten Stakeholder mit deren Erwartungen bezüglich der Architektur.

mehr dazu ...

constraints-image

2. Randbedingungen

Alles, was das Team beim Design und der Implementierung der Architektur einschränkt. Diese Einschränkungen sind manchmal auch außerhalb eines Projekts in der gesamten Organisation gültig.

mehr dazu ...

solution strategy overview

3. Kontextabgrenzung

Grenzt das System, an dem Sie arbeiten, von externen Kommunikationspartnern (Nachbarsystemsen und Benutzern) ab. Spezifiziert die externen Schnittstellen aus Sicht des Business (immer) und aus Sicht der Technologie (optional)

mehr dazu ...

solution strategy overview

4. Lösungsstrategie

Zusammenfassung der fundamentalen Entwurfsentscheidungen und Lösungsstrategien für die Gesamtarchitektur. Kann Technologieentscheidungen, Top-Level-Zerlegungsstrategie oder Ansätze zur Erreichung der wesentlichen Qualitätsziele beinhalten, bzw. relevante Organisationsentscheidungen.

mehr dazu ...

building block view

5. Bausteinsicht

Statische Zerlegung des Systems. Die Abstraktion des Sourcecodes, dargestellt als Hierarchie von “White-Boxes” (die wiederum kleinere Black-Boxes beinhalten), bis zu einem angemessenen Detaillierungsgrad.

mehr dazu ...

runtime view

6. Laufzeitsicht

Das Verhalten der Bausteine in Form von dynamischen Szenarien, die die wichtigsten Prozesse oder Features abdecken, Interaktionen an kritischen externen Schnittstellen oder “interessante” interne Abläufe und kritische Ausnahme- oder Fehlerfälle.

mehr dazu ...

deployment view

7. Verteilungssicht

Technische Infrastruktur mit (echten oder virtuellen) Prozessoren, Systemtopologie, und die Abbildung der Software-Bausteine auf diese Infrastruktur.

mehr dazu ...

crosscutting concepts

8. Querschnittliche Konzepte

Übergreifende, generelle Prinzipien und Lösungsansätze, die in vielen Teilen der Architektur einheitlich benutzt werden (→ cross-cutting). Konzepte beziehen sich oft auf mehrere Bausteine. Hier findet man Themen wie Domänenmodelle, Architekturmuster und -stile, Regeln zur Nutzung bestimmter Technologiestacks, etc.

mehr dazu ...

risks and technical decisions

9. Architekturentscheidungen

Wichtige, teure oder kritische oder riskante Architekturentscheidungen, die zentrale Bedeutung für das Gesamtsystem haben, mit Begründungen für diese Entscheidungen.

mehr dazu ...

quality

10. Qualitätsanforderungen

Qualitätanforderungen in Form von Szenarien, mit einem Qualitätsbaum für den Überblick. Die allerwichtigsten Qualitätsziele sollten schon im Kapitel 1.2. (Qualitätsziele) aufgeführt sein. section 1.2. (quality goals).

mehr dazu ...

risk

11. Risiken und technische Schulden

Bekannte Risiken und angehäufte technische Schulden. Welche potentiellen Probleme lauern im und um das System? Über welche Schwächen beklagen sich die Entwicklungsteams?

mehr dazu ...

glossary

12. Glossar

Wichtige Domänenbegriffe und technische Begriffe, die Stakeholder kennen sollten, wenn sie über die Architektur des Systems diskutieren. Manchmal auch Übersetzungstabellen, wenn in einer mehrsprachigen Umgebung gearbeitet wird.

mehr dazu ...


Weitere Informationen

So - jetzt kennen Sie die einzelnen Teile des Templates. Gerne können Sie noch weiterlesen:

Schauen Sie in unsere weiterführende Doku: