Diejenigen von uns, die mit der Arbeit an übergeordneten Themen wie Unternehmensarchitektur und -strategie beauftragt sind, fürchten sich vor der einfachen Frage: „Was machen Sie?“ Wenn die Ergebnisse nicht greifbar und klar sind, lassen die Antworten auf diese Frage den Fragesteller benommen zurück und bedauern den Befragten fast. Ein gebräuchlicher Begriff, der als Platzhalter für Unsicherheit und Unvollständigkeit in die Antwort geworfen wird, ist Referenzarchitektur.
Dieser Begriff kann für verschiedene Menschen viele Dinge oder irgendetwas bedeuten. Wenn es undefiniert bleibt, entsteht der Eindruck von Flaumigkeit und Unschärfe, die Frustration und Verschwendung hervorruft. Diejenigen, die mit der Implementierung beauftragt sind, stellen möglicherweise Ihre Fähigkeit in Frage, Konzepte und Denken in Realität und Konkretheit zu verankern. Daher sind Definitionen nützlich. Hier ist meine Definition einer Referenzarchitektur:
Die Artikulation von Überlegungen, Optionen und bekannten Standards zur Gestaltung eines Produkts, einer Lösung oder eines Systems, basierend auf Beobachtungen aus Umfragen, Erfahrungen und Experimenten, in einer Sprache und einem visuellen Format, die der Zielgruppe vertraut sind.
Die Wahrheit ist, sobald die Absicht, der Wert und der Kontext der Nutzung für ein bestimmtes Publikum klar gemacht sind, spielt eine formale Definition keine Rolle.
Die eigentliche Frage ist —
“ was wollen wir tun?“
Zweitens—
“ was wollen wir Menschen (wer auch immer sie sind) tun?“
Klare Antworten auf diese Fragen sind der Anfang, um die Bedeutung und Bereitstellung von Referenzarchitektur zu entwirren. Die Absicht, der Inhalt, das Publikum und der Wert müssen klar sein. Das Wort „Referenz“ legt nahe, dass die Ausgabe Anleitungen und Standards aus Beobachtung, Erfahrung und Experimentieren enthält, im Gegensatz zu einer Definition dessen, was gebaut werden soll. Eine „Architektur“ legt nahe, dass sie strukturiert, kohärent und überprüfbar ist.
Es gibt verschiedene Definitionen von Referenzarchitektur im Internet, aber die obige Regel der Klarheit (Absicht, Inhalt, Publikum, Wert) kann in jedem gefunden werden. Betrachten Sie eine alternative Definition zu meiner, die in einer Google-Suche als Top-Ergebnis angezeigt wird:
(1) Klären Sie das Medium und das Format dessen, was geliefert werden soll, z. B. „ein Dokument“. Dies informiert über die erforderlichen Werkzeuge, die Art der auszuführenden Arbeit und die Fähigkeiten der Mitwirkenden. Alternative Möglichkeiten der Bereitstellung könnten eine Präsentation oder abfragefähige Wissensdatenbank sein.
(2) Vereinbaren Sie die Struktur und den Umfang dessen, was geliefert werden soll, z. B. „eine Reihe von Dokumenten“. Ein Deliverable ist möglicherweise nicht ausreichend, aber der Umfang der betreffenden Systemdomäne erfordert möglicherweise, dass das Deliverable in mehrere Dokumente zerlegt wird.
(3) Identifizieren Sie die primäre Zielgruppe und Stakeholder, z. B. „Projektmanager“. Haben Sie ein Verständnis für die Art und das Format der Informationen, die sie regelmäßig konsumieren. Auch der Status quo könnte hier eine Rolle spielen. In einigen Fällen wird die Referenzarchitektur die Berichtszeilen als Richtlinie „weitergegeben“, während sie in anderen Fällen als „Nice to have“ behandelt wird, mit der Erwartung, dass sie den besten Weg und die zu berücksichtigenden Alternativen beschreibt.
(4) Identifizieren Sie andere interessierte Parteien, die möglicherweise die Referenzarchitektur verwenden müssen. Ist es notwendig, verschiedene Ansichten oder Ebenen zu erstellen? Gibt es Bedarf und Raum für die Schulung anderer in der Interpretation und Anwendung der Referenzarchitektur?
(5) Machen Sie deutlich, was das Publikum / der Leser mit dem Dokument machen soll, z. „siehe Best Practices.“ Die Ausgaben sollten liefern, was sie auf dem Cover sagen, einschließlich der Beweise und Links zu Quellen zur Validierung. Eine Referenzarchitektur könnte auch „Lernen“ aus Experimenten in einer kohärenten, umsetzbaren Weise liefern.
(6) Machen Sie den relevanten Bereich klar. Eine Referenzarchitektur ohne spezifische Domäne ist eher eine Philosophie höherer Leitprinzipien als eine Architektur. Eine Architektur, auch eine Referenzarchitektur, muss domänengebunden sein. Je kleiner diese Domäne ist, desto relevanter und umsetzbarer ist die Referenzarchitektur.
(7) Der beabsichtigte Wert der Referenzarchitektur sollte kommuniziert werden, da dies dem Publikum hilft, seinen Zweck und seine Einschränkungen zu beurteilen, z. B. „Wählen Sie die beste Bereitstellungsmethode.“ Implementierungsteams wissen dann, wohin sie gehen müssen, wenn diese Entscheidung getroffen werden muss.
(8) Beispiele aus der Domäne und die Angabe der relevanten Technologien helfen, den Kontext der Referenzarchitektur zu verdeutlichen.
(9) Alternativen und Quellen von Komponenten und Fähigkeiten, die bei der Implementierung zu berücksichtigen sind, sollten gut dokumentiert und miteinander verknüpft sein.
Eine Referenzarchitektur ist nicht unbedingt ein Blocker, bevor ein Technologieprojekt gestartet wird. Es kann parallel oder nach der Lieferung entwickelt werden und dient als Dokumentation einer Obduktion und der gewonnenen Erkenntnisse. Wenn es vor Beginn eines Projekts erstellt wird, sind Erhebungen, Versuche und Experimente erforderlich, um über bewährte Verfahren zu informieren. Nachfolgend finden Sie eine vorgeschlagene Taxonomie möglicher Klassen von Referenzarchitekturen, abhängig von der Zielgruppe, der Lösung und der aktuellen Wissenslücke innerhalb einer Organisation oder eines Projektteams.
Das Akronym für die fünf verschiedenen Aspekte einer Referenzarchitektur ist MUSIK, die sich in Gesprächen auf jeder Organisationsebene oder in jedem Verständnisbereich als einprägsam erwiesen hat:
- embership: Die Auflistung und Kategorisierung von Architekturelementen, die für die Domäne relevant sind.
- salbei: user Stories, Business Cases, Prozesse, Workflows und Mittel zur Erläuterung von Aktivitäten in der Domäne.
- struktur: Wie die verschiedenen Elemente in einer Domäne miteinander verbunden sind, um die Verwendung zu unterstützen.
- nteraction (oder Integration): Die Schnittstellen und Nachrichten, die während der Verwendung zwischen Architekturelementen ausgetauscht werden.
- ontrols: Die Einschränkungen und Richtlinien, die zum Steuern von Interaktionen verwendet werden.
Dies bedeutet nicht, dass alle Referenzarchitekturen 25 Dokumente oder Unterabschnitte liefern müssen, die jeden der identifizierten Bereiche abdecken. Dies zeigt, dass es wahrscheinlich 25 verschiedene Bereiche gibt, in denen Überlegungen, Optionen und Verantwortlichkeiten in einer Organisation oder einem Projekt artikuliert werden müssen. Dies wird sich je nach Publikum ändern. Es gibt keine Unschärfe oder Flaumigkeit in Referenzarchitekturen. Sie sind das Ergebnis von Erkundungsbemühungen und die greifbaren Ergebnisse kurzfristiger angewandter Forschung.