Ich habe mit klugen Menschen gearbeitet, in Organisationen mit guten Absichten und modernen Praktiken. Und dennoch sah ich immer wieder dieselben Dinge schiefgehen. An denselben Stellen. Das gab mir zu denken.
Entwickler empfanden Sicherheit als einschränkend. Sicherheitsteams hielten Entwickler für leichtsinnig. Der Betrieb wollte Stabilität, während das Management Geschwindigkeit und Innovation wollte.
Die übliche Diagnose lautet: ein Kommunikationsproblem. Teams müssen mehr zusammenarbeiten. Sich häufiger treffen. Mehr Verständnis füreinander aufbringen. Also: mehr Meetings, mehr Alignment-Sitzungen, mehr gemeinsame Retrospektiven.
Ich habe diesen Rat viele Male gehört. Und ich habe gesehen, wie wenig er strukturell gelöst hat. Denn ein Jahr später hatte dieselbe Organisation dieselben Spannungen — nur jetzt mit einem volleren Kalender.
Mehr Abstimmung löst nichts, wenn Menschen aus fundamental verschiedenen Logiken heraus handeln. Sie reden nicht aneinander vorbei, weil sie sich nicht kennen — sondern weil sie sich gut genug verstehen und trotzdem anderer Meinung sind, was wichtig ist.
Ich betrachte das wahrscheinlich aufgrund meines Hintergrundes anders. Neben meiner Arbeit in der IT habe ich öffentliche Verwaltung studiert. Während dieses Studiums las ich Jane Jacobs und ihr Buch Systems of Survival. Jacobs beschreibt, wie Gesellschaften aus zwei grundlegend verschiedenen moralischen Systemen heraus funktionieren. Einige Systeme sind auf Schutz, Stabilität und Kontrolle ausgerichtet. Andere auf Handel, Innovation und Bewegung. Beide sind notwendig, aber sie betrachten Risiko, Verantwortung und Wandel fundamental unterschiedlich.
Jahre später begann ich dieselben Muster zu erkennen — zunächst in IT-Organisationen, dann auch in industriellen Umgebungen.
Cybersicherheit, Betrieb und IT-Management funktionieren weitgehend aus einer Schutzlogik heraus. Kontinuität sicherstellen. Verantwortlich für Störungen, Vorfälle und Verfügbarkeit. Aus dieser Perspektive ist Vorsicht rational. Kontrolle ist rational. Standardisierung ist rational.
Entwicklungsteams und Innovationsabteilungen funktionieren oft aus der entgegengesetzten Logik heraus. Wandel ermöglichen. Belohnt für Geschwindigkeit, neue Funktionalität und Wachstum. Aus dieser Perspektive fühlt sich Governance wie Verzögerung an. Zusätzliche Kontrollen fühlen sich wie Reibung an.
Und plötzlich begann mir viel Verhalten Sinn zu machen.
Der Entwickler, der sich über Änderungsverfahren ärgert, ist nicht zwangsläufig unreif. Der Sicherheitsingenieur, der zusätzliche Kontrollen fordert, ist auch nicht automatisch bürokratisch. Diese Teams stoßen nicht zusammen, weil Menschen schwierig sind, sondern weil sie verschiedenen moralischen Logiken dienen.
In industriellen Umgebungen wird diese Spannung noch schärfer
Ein IT-Entwickler, der etwas deployen möchte, kann es im schlimmsten Fall zurückrollen. Ein Prozessoperator in einer Produktionshalle arbeitet mit physischen Anlagen, Sicherheitssystemen und Prozessen, die nicht einfach neu gestartet werden können. Ein Firmware-Update auf einer SPS ist keine Sprint-Aufgabe — es ist eine Änderung mit potenziell physischen Konsequenzen, bei der die Menschen in der Nähe der Anlage ein Interesse daran haben, dass man sorgfältig vorgeht.
Ich habe in solchen Umgebungen gearbeitet. Und was mich immer traf: Die Spannung lag selten in der Technologie selbst. Die Technologie war lösbar. Die Spannung lag in den Nähten — den Schnittstellen zwischen Systemen, zwischen Teams, zwischen Verantwortlichkeiten.
Aber ich sah dieselbe Dynamik auch außerhalb technischer Umgebungen. Als ich an einer groß angelegten Bildungsreform beteiligt war — neue pädagogische Modelle, programmatische Bewertung, andere Organisation — erkannte ich genau dasselbe Muster. Lehrer, die die Qualität und Kontinuität des Unterrichts sicherstellen. Innovatoren, die Geschwindigkeit wollen, weil die Welt sich verändert und Bildung Schritt halten muss. Zwei Gruppen mit guten Absichten, aber mit fundamental verschiedenen Definitionen von Erfolg. Und die Spannung lag auch dort nicht in den Menschen, sondern in den Nähten — den Stellen, wo Stundenpläne, Bewertungssysteme und Arbeitsmethoden nicht zusammenpassten, weil sie aus verschiedenen Logiken heraus entworfen worden waren.
Das war der Moment, in dem ich erkannte: Dieses Muster ist nicht branchenspezifisch. Es existiert in jeder Organisation, die gleichzeitig etwas schützen und etwas verändern muss.
Diese Erkenntnis veränderte auch meine Sichtweise auf Architektur.
Viele Organisationen betrachten Architektur immer noch als technische Disziplin: Systeme entwerfen, Standards etablieren, Infrastruktur modellieren. Aber die schwierigsten Fragen sind selten rein technisch.
Wie gibt man der Entwicklung ausreichend Geschwindigkeit, ohne die Kontrolle vollständig aufzugeben? Wie verhindert man, dass Sicherheit zur Bremse für Innovation wird? Wie schützt man Stabilität, ohne jeden Versuch unmöglich zu machen?
Das sind letztendlich keine rein technischen Fragen. Es sind Governance-Fragen. Und genau diese Kombination — technisch und Governance — finde ich in meiner Arbeit am wertvollsten.
Vielleicht erklärt das auch, warum sich viele DevOps- und DevSecOps-Transformationen schwieriger als erwartet erweisen. Organisationen versuchen, zwei verschiedene Logiken einander näher zu bringen, behandeln die Spannung aber so, als ob sie vollständig auflösbar wäre. Ich halte das für einen Irrtum.
Eine gesunde Organisation braucht tatsächlich beide Systeme. Ohne Schutzlogik entstehen Chaos und Zerbrechlichkeit. Ohne Innovationslogik entstehen Stagnation und Verlust an Anpassungsfähigkeit.
Aber was dann?
Wenn mehr Abstimmung nicht die Lösung ist und die Spannung der Arbeitsweise von Organisationen inhärent ist — was macht man damit?
Meine Antwort lautet: Behandle es als Architekturfrage, nicht als Prozessfrage.
Die meisten Organisationen versuchen, die Spannung mit besserer Governance zu managen. Klarere Verfahren, schnellere Change Boards, mehr Disziplinen am Tisch. Das hilft marginal. Das grundlegende Problem bleibt: Kontrolle sitzt als Gate nach dem Entwicklungsprozess, also fĂĽhlt sie sich strukturell wie eine Bremse an.
Was hilft, sind drei Prinzipien, die ich in der Praxis immer wieder wirken sehe.
Entwirf die Grenze, nicht das Verhalten. Hör auf zu versuchen, zu kontrollieren, was innerhalb eines Teams oder Systems passiert. Kontrolliere stattdessen die Schnittstellen — die Stellen, wo Systeme und Teams miteinander in Berührung kommen. Innerhalb dieser Grenze: Freiheit. Über diese Grenze hinweg: Governance. In industriellen Umgebungen ist das seit Jahren Praxis — Zonen und Conduits, ISA-95, das Purdue-Modell. Die IT-Welt kann davon mehr lernen, als sie oft erkennt.
Mache den sicheren Weg auch zum schnellen Weg. Wenn die sichere Option mehr Aufwand kostet als die unsichere, werden Menschen strukturell die unsichere wählen. Nicht aus Unwilligkeit, sondern aus Zeitdruck. Die Lösung ist nicht strengere Durchsetzung — es ist das Senken der Schwelle für die richtige Wahl. Vorgenehmigte Infrastruktur, automatisierte Prüfungen, Standardlösungen, die Entwickler einfach aufgreifen können. Die Freiheit bleibt, aber die Reibung sitzt auf der richtigen Seite.
Differenziere nach Risiko. Nicht jede Änderung ist gleich. Eine UI-Anpassung ist fundamental anders als eine Änderung in der Authentifizierungslogik oder ein Update auf einer SPS, die einen physischen Prozess steuert. Organisationen, die einen einzigen Änderungsprozess für alles haben, erzeugen die Frustration selbst. Diejenigen, die Risiko ernst nehmen, machen Unterscheidungen — und geben risikoarmen Änderungen den Raum, sich schnell zu bewegen.
Das übergreifende Prinzip hinter alledem: Man löst die Spannung zwischen Schutz und Innovation nicht auf, indem man Menschen näher zusammenbringt. Man löst sie auf, indem man die Architektur so gestaltet, dass Geschwindigkeit und Sicherheit keine Gegensätze mehr sind.
Das ist letztendlich die Aufgabe eines Architekten. Nicht zwischen den beiden Logiken zu wählen — sondern die Umgebung zu bauen, in der beide existieren können.