Den Begriff prägte Edsger W. Dijkstra 1974 in seinem im E.W.-Dijkstra-Archiv der University of Texas at Austin veröffentlichten Aufsatz „On the role of scientific thought“ (EWD447). Darin beschreibt er, dass es die einzig wirksame Methode sei, mit der Komplexität eines Problems umzugehen: sich zu jedem Zeitpunkt nur auf einen Aspekt zu konzentrieren, ohne dabei die anderen Aspekte und ihr Zusammenspiel aus den Augen zu verlieren.

Ein Concern ist dabei eine abgegrenzte Zuständigkeit eines Systems — etwa die Erfassung von Messwerten, ihre Speicherung, ihre Absicherung oder ihre Darstellung. Separation of Concerns verlangt, dass jeder Teil eines Systems genau einen solchen Concern trägt und die übrigen Teile nur über eine definierte Schnittstelle kennt.

Formalisiert wurde die Idee kurz darauf in der Strukturierten Analyse und dem Strukturierten Entwurf: W. P. Stevens, G. J. Myers und L. L. Constantine beschrieben 1974 im IBM Systems Journal die Begriffe Kopplung (Coupling) und Kohäsion (Cohesion) als messbare Größen für gute Trennung.

Ohne Trennung kennt im ungünstigsten Fall jeder Teil eines Systems jeden anderen: Bei sechs Modulen sind das bis zu fünfzehn mögliche Abhängigkeiten, bei zehn bis zu fünfundvierzig — dieselbe Rechnung, mit der sich auch die Kopplung zwischen einzelnen IT-Systemen beschreiben lässt. Jede Änderung an einem Modul kann dann jedes andere berühren, und niemand kann mehr allein absehen, welche Folgen eine kleine Anpassung hat.

Separation of Concerns reduziert diese Abhängigkeiten auf definierte Schnittstellen zwischen wenigen Teilen. Ein Modul für die Datenerfassung kann sich ändern, ohne dass die Auswertung etwas davon merkt, solange die Schnittstelle zwischen beiden gleich bleibt. Die Trennung macht ein System damit nicht kleiner, aber verständlicher — und vor allem: veränderbar, ohne dass jede Änderung zur Untersuchung des gesamten Systems wird.

Die beiden Größen aus der Strukturierten Analyse lassen sich an jedem System ablesen — unabhängig davon, ob es aus Code, aus Anlagen oder aus Organisationseinheiten besteht.

Das Ziel ist nicht, Kopplung vollständig zu vermeiden — kein System kommt ohne Verbindungen zwischen seinen Teilen aus —, sondern sie auf wenige, benannte Schnittstellen zu konzentrieren, statt sie unkontrolliert im gesamten System zu verteilen.

• IT/OT-Trennung. Die Zuständigkeit für die Produktionssteuerung (OT) wird von der Zuständigkeit für Büro-IT getrennt — nicht aus Misstrauen, sondern weil beide unterschiedlichen Anforderungen an Verfügbarkeit, Update-Rhythmus und Ausfallsicherheit folgen.
• Zonen und Conduits nach IEC 62443. Die Norm teilt ein Automatisierungsnetz in Sicherheitszonen mit vergleichbarem Schutzbedarf und erlaubt Kommunikation zwischen ihnen nur über definierte, überwachte Übergänge (Conduits) — Separation of Concerns als Sicherheitsarchitektur.
• Unified Namespace. Ein Namensraum trennt die Zuständigkeit für die Datenhaltung (aktueller Stand jeder Quelle) von der Zuständigkeit jeder einzelnen Anwendung, die diese Daten nutzt — Quelle und Verbraucher kennen einander nicht, nur den Namen der Information.
• Schichtenarchitektur. Die klassische Trennung in Datenerfassung, Datenhaltung, Geschäftslogik und Darstellung ist die älteste und am weitesten verbreitete Anwendung des Prinzips.

• Schnittstellen als Vertrag. Eine Schnittstelle (API) legt fest, was ein Teil von einem anderen erwarten darf — und was nicht. Ändert sich die Innenseite eines Moduls, ohne die Schnittstelle zu berühren, merkt der Rest des Systems nichts davon.
• Kein gemeinsamer Datenzugriff über Zuständigkeiten hinweg. Jedes Modul besitzt seine Daten; andere Module fragen darüber an, statt direkt in einer gemeinsamen Datenbank zu lesen oder zu schreiben — sonst entsteht Kopplung, die keine Schnittstelle mehr sichtbar macht.
• Ereignisgesteuerte Entkopplung. Ein Publish-Subscribe-Muster, wie es auch einem Unified Namespace zugrunde liegt, entkoppelt Quelle und Verbraucher zeitlich und technisch: Beide kennen nur den Namen der Information, nicht einander.
• Versionierung. Schnittstellen ändern sich irgendwann doch — eine Versionsnummer macht sichtbar, welche Seite mit welcher Erwartung spricht, statt stillschweigend zu brechen.

1. Zuständigkeiten benennen

   Welche Concerns gibt es tatsächlich — Datenerfassung, Absicherung, Auswertung, Darstellung? Die Liste entsteht aus der Aufgabe, nicht aus der vorhandenen Technik.

2. Schnittstellen statt Durchgriffe definieren

   Jede Zuständigkeit bekommt eine Schnittstelle, über die andere sie ansprechen — nie einen direkten Zugriff auf ihre internen Daten.

3. Verantwortlichkeiten zuordnen

   Eine Zuständigkeit sollte einem Team oder einer Rolle eindeutig zugeordnet sein — sonst wird auch die technische Trennung nicht durchgehalten.

4. Trennung überprüfen

   Der Schotten-Test: Zieht eine Änderung in einem Teil regelmäßig Änderungen in einem anderen nach sich, der eigentlich nichts damit zu tun haben sollte? Wenn ja, ist die Grenze falsch gezogen.

• Kein Argument für beliebig viele Schichten. Die Anzahl der Teile richtet sich nach der Anzahl der tatsächlich unterschiedlichen Zuständigkeiten — nicht nach einer für richtig gehaltenen Zahl an Ebenen.
• Kein Ersatz für eine Schnittstellendefinition. Zwei Module in getrennte Dateien oder Dienste zu legen, ohne festzulegen, was sie voneinander erwarten dürfen, trennt nichts — es benennt das Problem nur um.
• Kein rein technisches Thema. Wie ein System zerlegt wird, hängt eng damit zusammen, wie die Teams zerlegt sind, die es bauen und betreiben — eine Beobachtung, die in der Softwareentwicklung als Conways Gesetz bekannt ist.
• Kein Selbstzweck. Eine Trennung, die niemand für Änderungen, Tests oder Verantwortlichkeiten nutzt, ist nur zusätzlicher Aufwand ohne Gegenwert.

• Über-Trennung. Für ein kleines, stabiles System kosten sechs säuberlich getrennte Schichten mehr an Schnittstellen-Pflege, als sie an Übersicht einbringen.
• Falsche Schnittgrenzen. Trennung entlang der Technik (etwa nach Datenbank-Tabellen) statt entlang der tatsächlichen Zuständigkeit führt dazu, dass ein fachlicher Vorgang trotzdem mehrere Module gleichzeitig ändert.
• Der verteilte Monolith. Module sind zwar als eigene Dienste ausgerollt, greifen aber weiterhin auf dieselbe Datenbank zu und rufen sich überall synchron gegenseitig auf — das Ergebnis vereint die Komplexität eines Monolithen mit der eines verteilten Systems, ohne die Vorteile von beidem.
• Fehlende Eigentümerschaft. Eine Zuständigkeit ohne klaren Verantwortlichen wird über die Zeit wieder mit anderen vermischt, auch wenn die technische Trennung anfangs sauber war.

pronubes ist die Plattform zwischen Shopfloor und IT — selbst nach dem Prinzip aufgebaut, das sie für ihre Kunden umsetzt.

• pronubes Edge trägt genau eine Zuständigkeit: Rohdaten an der Quelle erfassen und bei Verbindungsverlust puffern.
• pronubes Zones trägt die Zuständigkeit für Struktur und Benennung — unabhängig davon, welche Anwendung die Daten später nutzt.
• pronubes Insights trägt die Zuständigkeit für Auswertung und Sichtbarkeit, ohne selbst Daten zu erfassen oder zu strukturieren.

Jede Komponente kommuniziert über eine definierte Schnittstelle statt über eine gemeinsame Datenbank — damit ein Austausch an einer Stelle nicht zum Umbau der ganzen Landschaft wird. Mehr zur Plattform