Was ist eine Referenzarchitektur?
Was ist eine Referenzarchitektur?
- Erwartete Teile einer Referenzarchitektur
- Grundlagen einer Referenzarchitektur
- Betrachtung der Struktur eines Systems
- Erwarteter Blick auf die Funktion eines Systems
Warum eine Referenzarchitektur verwenden?
- Prüfung auf Vollständigkeit der Architektur
- Vereinfachung kaskadierender Anweisungen und Einschränkungen für die Governance
- Wichtige Fragen konsequent beantworten
- Verwenden einer Referenzarchitektur mit Standard-EA-Anwendungsfällen
- Welche Branchen verwenden Referenzarchitekturen?
Was ist eine Referenzarchitektur?
Eine Referenzarchitektur ist eine generische Architektur, die die normalen Umrisse eines Systems identifiziert. Sie stellt die Komponenten, Beziehungen, Prinzipien und Architekturrichtlinien bereit.
Technisch gesehen wird die Referenzarchitektur als Teil von Unternehmensarchitektur. Im Hinblick auf die TOGAF Im Unternehmenskontinuum finden Sie grundlegende, allgemeine oder branchenspezifische Beispiele.
Die besten Referenzarchitekturen geben die Gewissheit, dass das Problem und jeder wichtige Teil offengelegt werden.
Bei Referenzarchitekturen unterscheiden wir häufig zwischen zwei Typen: solchen, die die Struktur eines Systems offenlegen, und solchen, die zeigen, wie ein System funktioniert. Bitte bedenken Sie, dass das Wort „System“ keine IT-Konnotationen hat. Man kann die Kernfusion der Sonne, einen Markt und eine Produktveröffentlichung als System beschreiben.
Erwartete Teile einer Referenzarchitektur
Vollständige Referenzarchitekturen umfassen mehr als nur ein Modell. Mögliche Teile sind:
- Umfang des interessierenden Systems
Begrenzung des Systems und Erklärung des Problems. Kann Ziele, besondere Zwecke und Herausforderungen umfassen, die gelöst werden müssen - Modell(e) des Systems
- Komponenten eines Systems
- Beziehungen zwischen Komponenten
- Attribute, die angegeben werden sollten
Navigieren umfasst Architekturattribute für verschiedene Komponenten. Diese können von einem bevorzugten Betriebsmodell einer Geschäftsfähigkeit zur erwarteten Lebensdauer einer Schnittstelle - Vokabular
Ein spezielles Glossar mit Definitionen und Ausdrücken zum jeweiligen System
- Architekturmuster des Systems
- Grundsätze der Architektur des Systems
- Viewpoint-Bibliothek
- Best Practice im System
Die Grundlagen der Referenzarchitektur
Eine Referenzarchitektur muss die Komponenten und Beziehungen innerhalb des Systems umfassen. Sie kann die Identifizierung von Komponenten umfassen, die über den Rahmen der Referenzarchitektur hinausgehen, um zu erklären, wie die Referenz in ein größeres Ganzes passt.
Referenzarchitekturen können auf verschiedenen Abstraktionsebenen entwickelt werden. Eine eher abstrakte Architektur kann die Bausteine einer Lieferkette (SCOR) oder die für die Verwaltung digitaler Produkte (IT4IT) erforderlichen Informationen darstellen.
Ein gängiger Ansatz für eine Referenzarchitektur ist die Verallgemeinerung mehrerer Lösungen. Die Supply-Chain-Referenz von SCOR ist ein Beispiel dafür – sie zeigt die gemeinsamen Aktivitäten für verschiedene Supply-Chain-Ansätze. Die SCOR-Referenz zeigt, wie diese Komponenten zu einer Lösung zusammengefügt werden.
Betrachtung der Struktur eines Systems
Referenzmodelle, die das Verständnis der Systemstruktur unterstützen, liefern die Grundlagen eines Systems. Sie existieren in unterschiedlichen Detaillierungsstufen und identifizieren die Kernelemente eines Systems. Strukturreferenzmodelle sind typischerweise statische Modelle und werden in einfacher grafischer oder tabellarischer Form dargestellt.
Fast die gesamte Unternehmensarchitektur verwendet statische Modelle.
Beispiele für Strukturreferenzmodelle sind:
- Kanadas GSRM (Government Service Reference Model)
- Technisches Referenzmodell der US Federal Enterprise Architecture
- Referenzarchitektur für Unternehmensarchitekturfähigkeiten
Wir verwenden System Structure, um auf Vollständigkeit zu prüfen und die Entwicklung einer einzigartigen Architektur zu beschleunigen.
Betrachtung der Funktion eines Systems
Referenzmodelle, die das Verständnis der Systemfunktion unterstützen, beschreiben die Funktionsweise eines Systems. Sie beschreiben die Interaktion der Komponenten in einem System. Funktionsreferenzmodelle werden häufig in einem Diagramm dargestellt. In der Regel gibt es eine unterstützende Dokumentation und ein dynamisches Modell. Ausgeprägte Funktionsmodelle können angewendet werden.
Wir verwenden Systemdynamik um starke Funktionsmodelle zu erforschen. Das Verständnis der Funktionsweise eines Systems ist entscheidend, um die effektiven Hebel und Barrieren für Veränderungen zu verstehen. Das obige Beispiel ist die Einführung neuer Produkte – denken Sie an eines, das die Entwicklung von Unternehmensagilität oder die Beseitigung technischer Schulden.
Warum ein Referenzmodell verwenden?
Wir vereinfachen den Nutzen der Verwendung von Referenzarchitekturen zur Verkürzung der Lieferzeit und Verbesserung der Qualität.
Mit einem Referenzmodell haben Sie:
- Vertrauen, dass alle Schlüsselkomponenten, Beziehungen und Attribute berücksichtigt werden
- Fähigkeit, die Ursache von Mängeln und deren Lösung zu identifizieren
Ohne Referenzarchitektur müssen Sie das System verstehen. Anschließend testen Sie Ihr Modell auf Vollständigkeit und Genauigkeit. Die ganze Zeit wird für den Beginn der Analyse benötigt.
Referenzarchitekturen erleichtern die Zusammenarbeit und Kommunikation. Sie helfen Teams, Fehler und Verzögerungen zu vermeiden. Sie bilden die Grundlage für Governance.
Es gibt noch weitere leistungsstarke Einsatzmöglichkeiten, darunter die folgenden.
- Prüfung auf Vollständigkeit der Architektur
- Vereinfachung kaskadierender Anweisungen und Einschränkungen für die Governance
- Wichtige Fragen konsequent beantworten
Testen der Vollständigkeit der Architektur
Eine Referenzarchitektur stellt stets die Komponenten eines Systems und die Beziehungen zwischen den Komponenten dar. Das bedeutet, dass wir mithilfe einer Referenzarchitektur sicherstellen können, dass jede Architekturanalyse oder jeder Entwurf das gesamte System berücksichtigt.
Wenn in der Referenz Komponenten fehlen, können Sie feststellen, ob eine Lücke im System vorliegt oder ob die Komponente irrelevant ist. Fehlende Komponenten sind Lücken im System.
Entscheidung zur kaskadierenden, überlegenen Architektur
Die Grundlage der Architektur-Governance und Implementierungs-Governance ist die Fähigkeit, eine Architekturentscheidung von der Vision und Strategie bis zur Implementierung zu kaskadieren.
Wo immer sinnvoll, wenden wir Architekturentscheidungen auf Referenzarchitekturkomponenten an. Bei detaillierteren Architektur- oder Designarbeiten können wir die Konformität mit einer Referenz testen. Anwendbarkeit und Aufwand müssen ausgewogen sein. Je besser die Referenzarchitektur auf einen Problembereich anwendbar ist, desto einfacher ist die Kaskadierung anwendbarer Entscheidungen. Der Aufwand für die lückenlose Dokumentation der Entscheidungen steigt jedoch.
Governance bei der Lösungsbereitstellung und -implementierung
Wir wissen, dass das wichtigste Ergebnis des Anwendungsfalls „Solution Delivery“ die Ermöglichung Umsetzungs-Governance.
Die Tiefe der Implementierungs-Governance hängt davon ab, wie detailliert der zukünftige Zustand und die Roadmap sind. Das folgende Diagramm veranschaulicht die zunehmende Tiefe und Detailliertheit der Implementierungs-Governance anhand von drei Lösungsquellen.
Eine Bottom-up-Lösung wird von den direkt Betroffenen identifiziert. Sie schließt keine identifizierten Lücken automatisch. Die verfügbare Orientierung dient als allgemeine Zielarchitektur.
Eine Lösung zur Lückenfüllung wird entweder von den direkt Betroffenen oder als Teil eines Implementierungsplans identifiziert. Diese Art von Lösungen liefert Orientierung anhand der Lücke zwischen aktuellem und zukünftigem Zustand. Diese Orientierung konzentriert sich darauf, was sich voraussichtlich ändern wird (Lücke) und was voraussichtlich gleich bleiben wird (alles andere). Dies gibt der Lösung eine Grenze, wo sie die Organisation verbessern soll und wo sie das Vorhandene nutzen soll.
Roadmap-Lösungen werden von oben nach unten entwickelt. Das Arbeitspaket zur Schließung einer Lücke ist auf einer Roadmap abgebildet. Die Arbeit wird von einem Sponsor betreut. Das Portfolio enthält konkrete Leistungserwartungen und eine Umsetzungsstrategie. Die zu schließende Lücke kann zudem durch jeden Übergangszustand, auf den die Roadmap hinarbeitet, verfeinert werden.
Verwenden einer Referenzarchitektur mit Standard-EA-Anwendungsfällen
Es gibt vier Standardanwendungsfälle für Unternehmensarchitektur. Jeder Anwendungsfall zielt darauf ab, einem anderen Publikum dabei zu helfen, wirksame Veränderungen voranzutreiben.
Unterstützender Portfolio-Anwendungsfall
Die Architekturarbeit konzentriert sich auf die Unterstützung des Portfolioinhabers. Das Portfolio existiert. Es hat klare Ergebnisse und Einschränkungen.
Portfoliobesitzer sind zukunftsorientiert. Sie wollen Veränderungen vorantreiben und im Rahmen ihrer Möglichkeiten die erwarteten Vorteile erzielen.
Die zukunftsorientierte Handlungsorientierung eines Portfolioinhabers erfordert eine Architekturarbeit, die sich auf die Ermöglichung von Veränderungen konzentriert. Der Portfolioinhaber muss im Voraus Entscheidungen treffen, um Aktivitäten voranzutreiben, die zu den Ergebnissen führen, für die er verantwortlich ist. Der Praktiker benötigt:
- Eine End-to-End-Architektur, die Kontext, Anleitung und Einschränkungen für das Portfolio bereitstellt
- Eine oder mehrere fokussierte Architekturbeschreibungen, die auf das Ergebnis und die Hauptkomponenten des Portfolios abgestimmt sind
Portfoliobesitzer streben den optimalen Ansatz zwischen Top-down- und Bottom-up-Planung an. Top-down stellt sicher, dass Leistungserwartungen, Einschränkungen und Abhängigkeiten berücksichtigt werden. Bottom-up berücksichtigt lokales Wissen und Kreativität.
Die Portfoliobesitzer und andere Stakeholder nutzen die Architektur-Roadmap Verbesserungsprojekte zu leiten. Sie verstehen Abhängigkeiten und Synergien. Vor allem wissen sie, wo sie anhalten, Werte schöpfen und die Richtung ändern können. Inkrementelle Übergangspunkte unterstützen die Unternehmensagilität direkt durch die Wertschöpfung.
Bei der Portfolioarbeit konzentrieren sich Architekturspezifikationen auf Arbeitspakete sowie Architekturprinzipien und -muster.
Anwendungsfall zur Unterstützung der Lösungsbereitstellung
Die Solution Delivery Architecture geht von einer zentralen Annahme aus: Das Gesamtziel und die zu seiner Verwirklichung erforderlichen Änderungen sind bekannt. Eine Lösung schließt bekannte Lücken innerhalb bekannter Einschränkungen, die die Kreativität und Freiheit der Implementierer einschränken.
Die aktuelle Handlungsorientierung eines Implementierers erfordert, dass sich die Architektur auf die Übermittlung von Leistungserwartungen und externen Einschränkungen konzentriert. Der Implementierer konzentriert sich auf die Leistungserwartungen und Einschränkungen seiner verschiedenen Projekte. Seine Aufgabe ist es, die Ressourcen zu bündeln und umzusetzen. Der Implementierer muss wissen, was von ihm erwartet wird und welche Grenzen seiner Kreativität gesetzt sind. Der Standardanwendungsfall identifiziert Architekturarbeit als:
- Definiert, wie Änderungen vorgenommen werden, welche Einschränkungen gelten und welche Leistungserwartungen bestehen.
- Direkte Unterstützung der Implementierungs-Governance
- Die Umsetzung effektiv begleiten
Es ist wichtig zu beachten, dass die Architektur für die Lösungsbereitstellung in erster Linie der Implementierungssteuerung dient, um die Ergebnisverantwortlichen zu unterstützen.
Die wichtigsten Elemente einer Lösungsarchitektur sind:
- Die Lücken werden gefüllt
- Die Komponenten in der Lösung und ihre Beziehung
- Leistungserwartungen und -einschränkungen, die sich aus der überlegenen Architektur ergeben
- Leistungserwartungen und Einschränkungen, die auf die Implementierung angewendet werden
Das entscheidende Ergebnis ist eine Lösungsarchitektur, die angibt, welche Lücke die Lösung im zukünftigen Zustand schließen wird, sowie alle geltenden Einschränkungen und Leistungserwartungen. Wenn eine Roadmap die Implementierungsstrategie vorgibt, muss der Lösungsansatz in die Lösungsarchitektur integriert werden.
Eine Lösungsarchitektur zeichnet sich durch ihre Abgrenzung aus. Sie adressiert einen spezifischen Problemraum. Formal gesehen handelt es sich um ein spezifisches System von Interesse, das in andere Systeme passt und mit ihnen interagiert. Wir binden das Konzept nicht an einen bestimmten Detaillierungsgrad. Es genügt zu sagen, dass eine Lösungsarchitektur detaillierter ist als die umgebende Architektur.
Welche Branchen verwenden Referenzarchitektur?
Referenzarchitekturen werden branchenübergreifend eingesetzt.
Es gibt branchenspezifische Referenzarchitekturen sowie engere Schwerpunkte wie Lieferkette, KI, IT-Infrastruktur, öffentliche Cloud oder Container.
Das obige Bild zeigt eine Reihe von Referenzmodellen für den Menschen – Atmungsmodell, Skelettmodell, Kreislaufmodell, Verdauungsmodell und Nervensystemmodell.
Wie verwenden Sie eine Referenzarchitektur?
Es gibt drei Möglichkeiten, eine gute Referenzarchitektur zu verwenden.
Zunächst sollte es einen Ausgangspunkt für die Grundlagen bieten. SCOR beschreibt Lieferkettenprozesse und drei Fertigungsmodelle. Anstatt mit einem leeren Blatt Papier zu beginnen, stehen Ihnen die wesentlichen Kerninformationen bereits zur Verfügung. Auf diese Weise verschwenden Sie keine Zeit damit, das Rad neu zu erfinden, wenn es nicht nötig ist. Stattdessen können Sie an den einzigartigen Aspekten des Rades im jeweiligen Anwendungsfall arbeiten. Flugzeugräder müssen blitzschnell von 0 auf 225 km/h beschleunigen. Die Räder des Mondrovers mussten sehr leicht sein und durften keinen Staub aufwirbeln. Beide sind rund, abnehmbar und dienen zum Lenken. Es kommt alles auf den Anwendungsfall an.
Zweitens sollte es ein Verständnis für die Funktionsweise eines Systems vermitteln. Sie müssen nicht die Teile eines Systems und deren Interaktion verstehen. Stattdessen sollten Sie untersuchen, wie die Architektur die Teile und Interaktionen für den jeweiligen Anwendungsfall optimiert. Sieben Hebel der digitalen Transformation ist ein hervorragendes Beispiel.
Drittens sollte man Referenzen verwenden können Architektur in der Architektur-Governance. Die Referenzarchitektur dient der Bewertung eines Entwurfs, um sicherzustellen, dass dieser alle erwarteten Anforderungen eines Systems berücksichtigt. Beispielsweise benötigen im GSRM alle widerruflichen Genehmigungen ein Verfahren zur Beurteilung, ob der Genehmigungsinhaber die Genehmigung behalten darf, sowie ein Einspruchsverfahren. Dabei spielt es keine Rolle, ob es sich um einen Führerschein, eine ärztliche Zulassung oder eine Genehmigung zum Transport von Atommüll handelt – alle Prozesse müssen vorhanden sein.
Um weiter zu gehen, schauen Sie sich Referenzarchitekturen für die digitale Transformation nutzen.
Beispiele für Referenzarchitekturen
Es gibt viele Beispiele für Referenzarchitekturen:
- Sieben Hebel der digitalen Transformation bietet eine Referenzarchitektur für die Transformation eines Unternehmens
- IT4IT ist eine Informationsreferenzarchitektur für Informationstechnologiefunktionen.
- BIAN ist eine Referenzarchitektur für die Bankenbranche.
- SCOR ist eine Referenzarchitektur für die Lieferkette.
- APQC bietet branchenübergreifende oder branchenspezifische Referenzarchitekturen für Geschäftsprozesse. APQC wird häufig als Grundlage für Geschäftsprozessmodelle oder Fähigkeitsmodelle.
- Eulynx kann für Verkehrssignalsysteme verwendet werden.
- GSRM (Canada's Government Services Reference Model) bietet eine Referenzarchitektur für staatliche Dienste.
- EA-Fähigkeitsreferenzarchitektur wird verwendet, um die Entwicklung eines EA-Teams zu beschleunigen.
- AUTOSAR ist eine Art komponentenorientierte Referenzarchitektur für Fahrzeugsoftware.
- AWS verfügt über zahlreiche Referenzarchitekturen für Systemstrukturen, darunter eine Architektur der Sicherheitsdienste.
- Das US-Verteidigungsministerium stellt Zero-Trust-Referenzarchitektur.
TOGAF-Standardreferenzarchitekturen
Die TOGAF-Standard umfasst zwei Referenzarchitekturen: die Technische Referenzarchitektur und das Integrierte Informationsinfrastruktur-Referenzmodell. Ein gemeinsames Verständnis kann mithilfe einer standardisierten Terminologie erreicht werden. Beispielsweise können Referenzarchitekturstandards eine gemeinsame Sprache bereitstellen.
Referenzarchitektur vs. Referenzmodell
Die meisten Menschen verwenden Referenzarchitektur und Referenzmodell als Synonyme. Technisch gesehen sind sie zwar unterschiedlich, für die meisten Unternehmensarchitekten ist dieser Unterschied jedoch irrelevant.
Aus puristischer Sicht erklärt ein Referenzmodell einen Teil eines Systems, während eine Referenzarchitektur das gesamte System erklärt. Die Unterscheidung hängt mit dem Umfang des Systems zusammen. Allerdings werden die Begriffe fast überall synonym verwendet. Es wäre sinnvoller, eine nützliche Architektur zu entwickeln, die den Wandel vorantreibt, als Zeit mit semantischen Diskussionen zu verbringen.
Die Architektur eines Systems wird durch einen Architekturrahmen dargestellt, der eine Zusammenfassung eines minimalen Satzes von Praktiken und Kriterien darstellt. Die TOGAF-Rahmenwerk bietet Methoden zur Beschreibung und Identifizierung von Architektureingaben.
Referenzarchitekturen gehen noch einen Schritt weiter: Sie beschleunigen den Prozess für einen bestimmten Architekturtyp, helfen bei der Bestimmung, welche Architekturansätze bestimmte Anforderungen erfüllen, und bestimmen den minimal notwendigen Satz an Architekturartefakten, der zur Erfüllung der Best Practices-Anforderungen für eine bestimmte Architektur erforderlich ist. Referenzarchitekturen legen großen Wert auf den "Vorlagen"-Anteil des Konzepts.
Tests für eine gute Referenzarchitektur
Die besten Referenzarchitekturen basieren auf allgemein anerkannten Best Practices der Branche und empfehlen häufig die optimale Bereitstellungsstrategie. Eine leicht verständliche Referenzarchitektur verbessert die Qualität und Geschwindigkeit der Architekturentwicklung und -implementierung.
Standardüberlegungen für ein gutes Referenzmodell:
- Konsortien mit Beteiligung mehrerer Interessengruppen aufgebaut
- umrahmt den Problemraum
- identifiziert Schlüsselelemente
- identifiziert Schlüsselbeziehungen
- erklärt Ihnen, wie Sie das System bewerten.
Referenzarchitektur für Unternehmensarchitekturfähigkeiten
Laden Sie die Referenzarchitektur für Unternehmensarchitekturfähigkeiten. Es ist die Grundlage für den Aufbau eines soliden Enterprise-Architecture-Teams.
Ihr Enterprise Architecture Capability-Modell ist zentral für eine optimiertes Rahmenwerk für Unternehmensarchitekturfähigkeiten.
