Immer wieder begegnen uns in der IT-Welt Referenzarchitekturen und es stellt sich unweigerlich der Eindruck ein, dass damit sehr unterschiedliche Dinge gemeint sind. Während sowieso schon viele Begriffe rund um Softwarearchitektur sehr dehnbar interpretiert werden, ist das bei Referenzarchitekturen noch viel ausgeprägter. Es fällt auf, dass Referenzarchitekturen häufig leider inhaltlich eher dünn sind und nur eingeschränkten Nutzen bieten.

In diesem Artikel möchten wir dabei helfen, die Vielfältigkeit von Referenzarchitekturen besser zu überblicken, häufige Missstände zu (er-)kennen und sowohl beim Lesen als auch beim Gestalten von Referenzarchitekturen gewappnet zu sein.

Was ist eine Referenzarchitektur?

Eine Referenzarchitektur ist in der IT-Welt eine Architektur, die als Vorlage und Orientierung für eine Menge von Systemen und deren Architekturen erstellt wird. Dazu abstrahiert die Referenzarchitektur von den Unterschieden der einzelnen Systeme und konzentriert sich auf deren Gemeinsamkeiten.

Unterschiedlichste Ausprägungen von Referenzarchitekturen

Im Folgenden betrachten wir verschiedene Dimensionen, in denen sich Referenzarchitekturen unterscheiden. Die Dimensionen zeigen zahlreiche Ausprägungen und in der Kombinatorik über die Dimensionen zeigt sich, wie unterschiedlich Referenzarchitekturen sein können.

System-Scope von konkretem Produkt bis Anwendungslandschaft

Referenzarchitekturen können für ein einzelnes klar umrissenes Softwareprodukt gelten, z.B. für die Infotainment-Systeme eines Autoherstellers, die auf einer gemeinsamen Architektur und Plattform basieren sollen.

Referenzarchitekturen können aber auch für komplexe Systems-of-Systems gelten wie das Zusammenspiel von Produktionsmaschinen in ganzen Produktionsanlagen. Dies kann bis zur Gesamtlandschaft von Anwendungen eines Unternehmens reichen, die in Referenzarchitekturen skizziert werden.

Referenzarchitekturen können sich entweder rein auf den Softwareanteil konzentrieren oder auch Hardware-Architekturen umfassen.

Damit beziehen sich Referenzarchitekturen auch auf zahlreiche Architekturbegriffe und Scopes, die wir üblicherweise kennen, wie z.B. Softwarearchitektur, Systemarchitektur, Hardwarearchitektur, Enterprise Architektur etc. Dem Namen „Referenzarchitektur“ und der näheren Beschreibung ist dieser Scope aber meist nicht anzusehen!

Inhaltlicher Fokus: Fachlichkeit vs. Technik

Referenzarchitekturen können von reiner fachlicher Ausrichtung bis zu rein technischer Ausrichtung alle Fokussierungen einnehmen.

Rein fachlich könnten z.B. Bebauungspläne mit fachlichen Komponenten zur Abdeckung von bestimmten standardisierten betrieblichen Prozessen sein.

Rein technisch könnten Blueprints zur Verwendung und Integration von Technologien zur Lösung von bestimmten Problemstellungen sein (z.B. Grundlegende Referenzarchitektur für Azure AI Foundry-Chats).

Dazwischen sind natürlich alle Mischungen und Anteilsverhältnisse von Fachlichkeit und Technik möglich.

Ersteller: Unternehmensintern vs. Öffentlich

Referenzarchitekturen können unterschiedliche Konstellationen von Erstellern und Zielgruppe haben.

Referenzarchitekturen können rein unternehmensintern erstellt und genutzt werden. Z.B. als Basisarchitektur einer Produktlinie von Produkten des Unternehmens mit Gemeinsamkeiten.

Referenzarchitekturen können aber auch als Vorlage oder gar Vorgabe für externe Zielgruppen dienen. So können z.B. Konsortien oder Verbände ihre Ideen formulieren und einer großen Zielgruppe von Unternehmen (z.B. in einer Branche) zur Verfügung stellen. Ein Beispiel wäre RAMI 4.0, eine Referenzarchitektur für Industrie 4.0.

Je größer eine Zielgruppe ist und je diverser damit die Menge an Systemen, die von der Referenzarchitektur abgedeckt werden, desto abstrakter werden Referenzarchitekturen zwangsläufig. So ist RAMI 4.0 auch eher ein Orientierungsrahmen und ein Erklärmodell als eine Architektur.

Grundlage: Extrahierte Best Practices vs. Initialer Vorschlag

Referenzarchitekturen können auf sehr unterschiedlicher Grundlage entstehen. Manchmal werden aus einer sehr großen Zahl erfolgreich realisierter Systeme die Best Practices extrahiert und in abstrahierter Form als Grundlage für weitere zukünftige Systeme beschrieben. So entstandene Referenzarchitekturen können viele spannende und relevante Details enthalten und sehr belastbar sein (z.B. Quasar, die Referenzarchitektur des früheren Beratungshauses sd&m).

Im Kontrast dazu werden häufig auch Referenzarchitekturen erstellt, vor allem auch im Umfeld von Forschung und Vorentwicklung (z.B. die Referenzarchitektur für Data Spaces), für die es noch gar keine Instanziierung oder Realisierung gibt. Diese Referenzarchitekturen sind also eher initiale Vorschläge, Orientierungshilfen und grobe Ideen. Sie sollten nie als solide Grundlage zur Ableitung einer konkreten Architektur für ein System begriffen werden.

Welchen Nutzen können Referenzarchitekturen bieten?

• Orientierungshilfe: Referenzarchitekturen können dabei helfen, gewisse Domänen oder Technologien schneller zu durchdringen auf dem Weg zu einer eigenen Systemarchitektur.
• Wiederverwendung von Best Practices: Je konkreter eine Referenzarchitektur ist, desto eher kann sie als Vorlage und damit zur Übernahme von Best Practices dienen. Vor allem wenn sie auch mögliche Abwägungen in der Instanziierung gut beschreibt und damit bei der Gestaltung der eigenen Architektur schon viele gute Hinweise gibt.
• Vergleichbarkeit: Unternehmen suchen manchmal auf strategischer Ebene nach Vorlagen und Vergleichsobjekten, z.B. für ein Benchmarking von Fähigkeiten oder den Einsatz von IT-Systemen. Dabei können Referenzarchitekturen als Hilfsmittel dienen.
• Interoperabilität: Wenn es um Interoperabilität zwischen Systemen geht, kann das Befolgen einer gemeinsamen Referenzarchitektur helfen. Oft ist das aber nicht das Ziel hinter Referenzarchitekturen und Interoperabilität kann auch auf anderen Wegen erreicht werden.

Was geht dabei häufig schief?

• Unklare Zielsetzung: Referenzarchitekturen scheitern häufig schon daran, exakt zu formulieren, wofür sie eigentlich geschaffen sind. Der Nutzen bleibt schwammig. Oft scheinen die Ziele auch den Erstellern nicht ganz klar gewesen zu sein und so liest sich die Referenzarchitektur wie eine lose Sammlung von Themen.
• Beliebigkeit in der Abstraktion: Je nach Zielsetzung gibt es unterschiedlichste Aspekte, von denen abstrahiert werden kann in einer Referenzarchitektur. Es kommt aber immer wieder vor, dass das Ergebnis eine wilde Mischung ist, die eigentlich nicht zusammenpasst, aber trotzdem irgendwie nach Architektur aussieht.
• Trivialitäten kombiniert mit mangelnder Tiefe: Teilweise sind Referenzarchitekturen eine Ansammlung von Trivialitäten ohne klare Zielsetzung. Da sie aber nicht mehr Tiefe versprechen, scheint es trotzdem in Ordnung zu sein und wird selten hart genug infrage gestellt.
• Pseudo-Ergebnisse als einfacher Ausweg: Wenn ein (Forschungs-)Projekt wenig liefern kann und nicht konkret genug wird, liefert es manchmal eine Referenzarchitektur. Dann ist die Referenzarchitektur eine Art einfacher und auch letzter Ausweg, doch noch etwas zu liefern. Die Nützlichkeit ist oft zweifelhaft. Da aber eine Referenzarchitektur per Definition immer gewisse Aspekte offen lässt und Abstraktion dazugehört, ist das Ergebnis oft wenig angreifbar (im doppelten Sinne … wenig greifbar und wenig attackierbar).
• Für bare Münze nehmen: Es kommt gerne vor, dass Verwender von Referenzarchitekturen drastisch überschätzen, wie viel ihnen die Referenzarchitektur tatsächlich bietet und wie viel Arbeit ihnen damit abgenommen ist auf dem Weg zu ihrer eigenen konkreten Architektur. Da in Referenzarchitekturen häufig schon einiger Umfang zu finden ist, der nicht selten den Umfang von Architekturdokumenten in Unternehmen sogar übersteigt (ein anderes Problem!), fühlt es sich danach an, dass das „schon genug“ ist. Das ist natürlich nie der Fall, weil es völlig an dem vorbei geht, was eine Referenzarchitektur überhaupt leisten soll und kann.
• Verwechselung mit Dokumentationsframeworks: Teilweise werden auch Dokumentationsframeworks (wie z.B. NAF (Nato Architecture Framework) als Referenzarchitekturen bezeichnet. Sie definieren aber nicht die Architektur einer Menge von Systemen sondern Hilfsmittel, um die Architekturen von Systemen zu dokumentieren.

Die Gestaltung und Dokumentation von Architekturen konkreter Systeme fällt häufig schon schwer und die Ergebnisse sind oft problematisch.

Bei Referenzarchitekturen verschärft sich diese Problematik noch mal deutlich: Durch die große Bandbreite von Referenzarchitekturen fehlt es an brauchbaren Guidelines und Methoden. Außerdem öffnet die notwendige Abstraktion Tür und Tor für problematische Entscheidungen und wenig hilfreiche Vereinfachungen. Da immer noch die Ebene der Ausgestaltung konkreter Architekturen dazwischenliegt, scheinen Referenzarchitekturen immer weniger verbindlich und verantwortlich, oft mit einem Hang zur Beliebigkeit.

Tipps zum Verwenden von Referenzarchitekturen

• Klären, ob Zielgruppe und Zielsetzung der Referenzarchitektur klar formuliert sind.
• Einordnen, wie die konkrete Referenzarchitektur die oben beschriebenen Charakteristiken ausprägt (Scope, Inhaltlicher Fokus, Ersteller, Grundlage).
• Prüfen, ob diese Charakteristiken zur eigenen Zielsetzung passen oder zumindest hilfreiche Hinweise liefern können.
• Kritisch hinterfragen, ob die Referenzarchitektur echte Substanz bietet oder vielleicht ein „Pseudo-Ergebnis“ ist.
• Verstehen, wo welche Abstraktionen vorgenommen wurden und wie belastbar die Referenzarchitektur damit ist.
• Prüfen, ob die Referenzarchitektur die Erreichung von Qualitätsanforderungen als Ziel hat, oder ob nur Fachlichkeit oder Technik strukturiert werden.

Tipps zum Gestalten von Referenzarchitekturen

• Klären, ob es wirklich sinnvoll ist, eine Referenzarchitektur zu erstellen und zu veröffentlichen.
• Möglichst nur dann eine Referenzarchitektur veröffentlichen, wenn hinreichend viel Erfahrung und Tiefe einfließen kann (insbesondere indem schon Architekturen für Systeme gestaltet wurden, die als Abstraktionsgrundlage dienen).
• Klar die Zielgruppe und Zielsetzung der Referenzarchitektur herausarbeiten und formulieren.
• Die Einordnung der Referenzarchitektur anhand der beschriebenen Charakteristiken herausarbeiten und als Hilfestellung für die Zielgruppe in der Referenzarchitektur dokumentieren.
• Auf eine ausgewogene Abstraktion achten, die gut zu den verfolgten Zielen passt.
• Echte Tiefe in die Referenzarchitektur bringen, sodass sie den Lesern wirklichen Wert bieten kann.
• Wenn möglich, auch Qualitätseigenschaften berücksichtigen und Lösungsmöglichkeiten diskutieren.
• Konkrete Anleitungen und Hinweise geben, wie die Referenzarchitektur verwendet und gegebenenfalls instanziiert werden kann. Am besten anhand von konkreten Beispielen, wie eine instanziierte Architektur aussehen kann.
• Terminologie und Art der Beschreibung an üblichen Vorgehensweisen in der Domäne orientieren, für die die Referenzarchitektur gedacht ist.
• Best Practices für Architekturdokumentation verwenden und für den konkreten Fall der Abstraktion geeignet anpassen (z.B. Architektursichten, visuelle Klarheit, …).