Ich verwende immer wieder verschiedene Architekturbegriffe wie IT Architektur, Lösungsarchitektur oder Enterprise Architektur. Diese Begriffe bedeuten jeweils etwas anderes und andere Architekten mögen unter den gleichen Worten auch andere Dinge verstehen. Grundsätzlich gilt: Architektur ist immer eine Abstraktion einer Realität mit der Absicht, sich in der Darstellung auf die wesentlichen Punkte zu beschränken und das - für den gegebenen Zweck - unwesentliche wegzulassen. Architektur ist in diesem Kontext ein Bindestrichwort, das bedeutet, es benötigt einen Bezugspunkt und kann nicht alleine stehen. Software Architektur beschreibt die abstrakten Konzepte einer Software, Cloud Architektur die Konzepte einer Cloud, usw.

Hier meine - nicht in jedem Fall vollständig trennscharfe - Definition verschiedener Architekturdisziplinen:

Einordnung verschiedener Architekturen

IT Architektur

IT Architektur ist für mich der Überbegriff für alles was Planungen für Informationstechnologie angeht (also irgendwas mit Computern zu tun hat). Die nachfolgenden Begriffe sind weitgehend in diesem Begriff hier enthalten.

Systemarchitektur

System ist genau wie Architektur ein Bindestrichwort und kann eigentlich nicht alleine stehen. In diesem Kontext bedeutet es jedoch meistens eine IT Architektur auf einer sehr hardwarenahen Schicht und gehört zur Technologieebene. Planungen von Rechenzentren, Serverstrukturen oder Netzwerken können in diesen Bereich fallen. Infrastrukturarchitektur ist weitgehend synonym zur Systemarchitektur. Bedingt kann hier die Modellierungssprache SysML eingesetzt werden. Oft kommen aber auch formfreie Diagramme zum Einsatz. Bei Model Based Systems Engineering findet sich eine schöne Notationsübersicht für die SysML.

Cloud Architektur

Cloud Architektur ist ein Spezialfall einer Systemarchitektur und ist ebenfalls der Technologieebene zugeordnet. Während das Wort Systemarchitektur grundsätzlich offen lässt, welches System gebaut wird (physikalische Hardware, virtuelle Hardware, etc.), schränkt die Cloud Architektur das System auf die bezeichnende Cloud ein. Eine Cloud Architektur ist also eine Systemarchitektur bei der das zu beschreibende System eine Cloud ist. Zur Modellierung werden hier gerne die Bibliotheken und Symbole eingesetzt, die die großen Cloud Anbieter direkt zur Verfügung stellen:

Software Architektur

Konzeptionell ebenfalls auf der Technologieebene liegt die Software Architektur. Sie beschreibt alle Software Komponenten, deren abstrakte Bestandteile (Module, Klassen, Objekte, Funktionen, etc.) und ihr Zusammenspiel mit Hilfe verschiedener Diagramme. Die dedizierte Sprache zur Dokumentation einer Software Architektur ist die Unified Modelling Language ( UML). Der Schulungsanbieter ( oose) bietet eine erstklassige Notationsübersicht für die UML an. Aus der gleichen Ecke stammt auch ein empfehlenswertes Buch zu dem Thema: Analyse und Design mit der UML von Bernd Oesterreich.

Anwendungsarchitektur

Eine Anwendung ist eine Gruppe von Komponenten, die zusammen einem geschäftlichen Zweck dienen. Die Anwendungsarchitektur ist also die Summe der darunter liegenden Architekturen auf der Technologieebene (System, Cloud, Software Architektur). Die Anwendungsarchitektur selbst findet auf der Anwendungsebene statt. Die Anwendungsarchitektur ergänzt zu ihren Teilarchitekturen noch Dinge wie den Lebenszyklus einer Anwendung, Ihre Nutzer sowie die Verantwortlichen für die Anwendung und ihre Bestandteile.

Datenarchitektur

Nicht für alle Anwendungen sind die zu verarbeitenden Daten von überragender Bedeutung. Es gibt jedoch Anwendungen, bei denen die größte Komplexität innerhalb der verarbeiteten Daten liegt. Für solche Anwendungen ist eine separate Datenarchitektur sinnvoll. Auch um den Fluss von Daten über verschiedene Anwendungen hinweg zu visualisieren ist eine Datenarchitektur auf der Datenebene notwendig. Als Mittel der Darstellung bieten sich Datenflussdiagramme, ER-Diagramme oder moderner auch UML-Klassendiagramme an.

Abgrenzung zu dem Begriff Informationsarchitektur: Dieser Begriff wird häufig im Kontext der Darstellung und Aufbereitung von Daten und Informationen verwendet. Während die Datenarchitektur lediglich die technischen Strukturen von Daten betrachtet.

Geschäftsprozessarchitektur

Ganz klar auf der Business Ebene befindet sich die Geschäftsprozessarchitektur. Hier dreht sich alles um geschäftliche Abläufe, ihre einzelnen Schritte sowie deren Zusammenhänge. Für diesen Zweck wurde die BPMN (Business Process Model and Notation) entworfen. Sie enthält alle Symbole und Diagrammbestandteile, die man für eine gute Beschreibung von Geschäftsprozessen benötigt. Eine tolle Notationsübersicht bietet die BPMN Initiative Berlin zum Download.

Eine gute Übersicht zu dem Thema liefert das Praxishandbuch BPMN von Jakob Freud und Bernd Rücker.

Lösungsarchitektur

Eine Lösungsarchitektur (engl. Solution Architecture) ist eine Sammlung von Architekturen der bisher genannten Typen: System, Cloud, Software, Anwendungs- Daten- oder Geschäftsprozessarchitektur die zusammen eine Lösung für eine Aufgabe bilden. Lösungsarchitekten müssen alle der genannten Architekturen beherrschen. Die gestellte Aufgabe kann beispielsweise ein Projekt sein, dann ist die Lösungsarchitektur eine Projektarchitektur.

Eine gute Vorlage für eine Lösungsarchitektur ist das arc42 Template. Auch wenn nicht für jede Lösungsarchitektur jeder Baustein des Templates benötigt wird, kann man sich sehr gut an der Vorlage orientieren.

Geht es bei der Lösungsarchitektur um eine einzelne Anwendung, ist der wichtigste Baustein die Kontextsicht (auch Kontextabgrenzung). Sie stellt auf einen Blick dar, was die Anwendung macht und mit wem oder was sie interagiert. Sie erweist sich in den meisten Gesprächen über ein Projekt als überaus wertvoll. Für eine Kontextsicht verwende ich gerne die Syntax eines UML Komponentendiagramms, ergänze aber auch Bestandteile, die nicht explizit zu diesem Diagrammtyp gehören, sofern sie sich für das gegebene Projekt als nützlich erweisen. Als Einstieg in dieses Thema kann ich das Buch Effektive Softwarearchitekturen von Gernot Starke empfehlen.

Ist das Projekt größer und umfasst mehrere Anwendungen, eventuell auch über Unternehmensgrenzen hinaus, dann ist ein Big Picture der richtige Start in eine Lösungsarchitektur. Hier wird vor allem der Umfang einer Lösung beschrieben und gezeigt, wozu die Anwendungen eines Projekts dienen. Die Syntax eines Big Picture folgt dem Metamodell, das das Unternehmen vorgibt.

Enterprise Architektur

Eine Enterprise Architektur (dt. Unternehmensarchitektur) ist eine Architektur für ein gesamtes Unternehmen und beschreibt im Wesentlichen das Zusammenspiel von Prozessen und IT im Unternehmen. Sie ist nicht Teil des Begriffs Lösungsarchitektur. Früher meinte man oft IT Enterprise Architektur, wenn man Enterprise Architektur sagte und beschränkte damit die Enterprise Architektur auf die IT eines Unternehmens. Die Prozessperspektive kann in einem modernen, digitalen Unternehmen jedoch nicht vernachlässigt werden und so macht eine Einschränkung auf IT Enterprise Architektur heute keinen Sinn mehr.

Die Enterprise Architektur spielt eine wesentliche Rolle als Vermittler zwischen der Geschäftswelt und der IT-Welt und ist dabei entweder durch das Business getrieben (Business Driven) oder - im Zeitalter der Digitalisierung - selbst der Business Treiber (Business Driver).

Bezogen auf die oben genannten Architekturen, betrachtet die Enterprise Architektur aus einer hohen Flugebene die großen Bausteine - also zum Beispiel:

  • Anwendungen und Projekte als Ganzes für eine Bebauungsplanung
  • Wesentliche Daten- und Informationsobjekte für die Pflege eines Unternehmensdatenmodell (engl. Enterprise Data Model).
  • Wichtige Geschäftsprozesse für eine Prozesslandkarte
  • Metamodelle, die die oben genannten Modelle in Beziehung zueinander setzen.

Mit Hilfe der hohen Flugebene verbindet die Enterprise Architektur verschiedene Projekte, Anwendungen und Lösungen eines Unternehmens und hilft dabei, sie an Hand der strategischen Unternehmensziele auszurichten.

Unabhängig von den genannten Modellen kommen bei der Enterprise Architektur noch welche dazu, die nicht direkt in IT Systemen abgebildet sind, wie:

  • Eine Business Capability Map, die die Fähigkeiten eines Unternehmens zeigt und welche Anwendungen und Prozesse hierfür benötigt werden. Sie dient der strategischen Planung eines Unternehmens.
  • Das Technologieradar, das aufzeigt welche neuen Technologien lang- und mittelfristig auf das Unternehmen zukommen und so eine strategische Projekt- und Personalplanung ermöglicht.
  • Eine Produkt Portfolio Landkarte, die zeigt welche Produkte ein Unternehmen anbietet und Planungen für zukünftige Produkte ermöglicht.

Diese Liste ist nicht vollständig - ganz im Sinne einer agilen Enterprise Architektur muss man sich darauf einstellen, dass hier immer wieder neue Modelle auftauchen, die für die strategische Planung hilfreich sind.

Viele Diagramme innerhalb einer Enterprise Architektur folgen nicht einer festgelegten Symbolik. Für bestimmte Aspekte lassen sich Archimate Diagramme erstellen. Wobei dieses eine Sprache von Enterprise Architekten für Enterprise Architekten ist und somit nur ein begrenztes Einsatzgebiet hat (siehe auch: Metamodelle).

Ecosystem Architektur

Eine Ecosystem Architektur bedient sich bei den Werkzeugen der Enterprise Architektur. Sie beschränkt sich jedoch nicht auf nur ein Unternehmen, sondern modelliert vor allem das Zusammenspiel mehrerer Unternehmen. Das kann im Rahmen von einzelnen Projekten, aber auch für langfristige Kooperationen stattfinden.