Blog

Lean-Architektur-Prinzip #11: Freiheit, wo möglich, Standardisierung, wo nötig

Denis Koelewijn

Aktualisiert Oktober 22, 2025

4 Minuten

Dies ist der elfte und letzte Beitrag in einer Reihe von Blogbeiträgen über die Prinzipien der Lean Architecture. Jeder Beitrag befasst sich mit einem Prinzip. Die Anwendung dieser Prinzipien führt zu einer Architektur (Prozess), die besser mit dem Geschäft verbunden ist, besser mit Veränderungen umgehen kann und kohärenter ist. Das elfte Prinzip, das wir besprechen, heißt"Freiheit, wo möglich, Standardisierung, wo nötig". Aus Angst, die Kontrolle über Projekte zu verlieren und in dem Versuch, den Zusammenhalt von IT-Systemen zu wahren, werden IT-Projekten oft strenge Kontrollen und damit strenge Einschränkungen auferlegt. Diese Beschränkungen oder Standards und Vorschriften, wie sie auch genannt werden, haben sich historisch in Organisationen entwickelt. Im Idealfall resultieren diese Standards aus bewährten Praktiken und Erfahrungen während der Projekte, aber oft beruhen sie auf persönlichen Vorlieben, dem Wunsch, Erfahrungen zu sammeln oder anderen nicht rationalen Gründen. Die Aktualisierung dieser Standards wird häufig vernachlässigt, was zu veralteten Standards führt, die in der Folge Projekte daran hindern, die Lösungen zu entwickeln, die das Unternehmen benötigt. Standards sollten nur darauf ausgerichtet sein, die Komplexität zu reduzieren. Nehmen wir an, Ihr Team ist im Bereich der Integration von Unternehmensanwendungen tätig und Ihr Unternehmen hat Dutzende von Systemen für verschiedene Abteilungen, die integriert werden müssen. Ihr Leitbild könnte lauten, dass dieses Team alle Integrationsprobleme zwischen all diesen Systemen lösen muss und dass Sie daher kein noch so schwieriges und kompliziertes Integrationsproblem scheuen. Aus einer engen Perspektive wäre dies richtig, aber aus der Perspektive des großen Ganzen ist es nicht wünschenswert, dass Sie jedes mögliche Integrationsproblem auf Ihrem Weg lösen. Dies würde zu Dutzenden von speziellen Lösungen führen, die einen Alptraum in Bezug auf Verwaltung und Wartung darstellen. In diesem Fall ist also eindeutig eine Standardisierung sowohl der Prozesse als auch der Techniken erforderlich. Beispiele für relevante Standards in dieser Umgebung sind:

Verwenden Sie JMS für asynchrone Kommunikation.
Verwenden Sie SAML2, OpenId oder einen anderen offenen Standard für die unternehmensweite Authentifizierung.
Verwenden Sie ein zentrales Verzeichnis für die Speicherung von Authentifizierungsinformationen.
Und so weiter...

Angenommen, die Standards und Vorschriften in Ihrem Unternehmen schreiben die Verwendung von Webservices vor, die das WS- Stapel. Es wurde schon viel über die Vor- und Nachteile des WS- geschrieben. Stack im Vergleich zu REST zum Beispiel, also ist dies eindeutig ein Fall eines umstrittenen Standards. Nehmen wir nun an, Sie müssen ein Integrationsproblem mit Publish & Subscribe lösen. In diesem Fall verwenden Sie JMS anstelle von WS- oder REST ist eine praktikable und viel sauberere und einfachere Lösung, die implementiert werden kann. Die Beschränkung auf die WS- Stapel liegt in diesem Fall eindeutig nicht im Interesse des Unternehmens, das am Ende der wichtigste Faktor sein sollte. Was sind also die Voraussetzungen für gute Standards?

Für jeden Standard sollte es eine klare Verbindung zu den Unternehmenszielen geben. Wenn ein Standard nicht vom Unternehmen unterstützt wird, dann hilft er dem Unternehmen wahrscheinlich nicht, seine Ziele zu erreichen.
Standards sollten Raum für innovative Ideen lassen. Sehr strenge Standards töten kreative neue Ideen, an die zum Zeitpunkt der Ausarbeitung der Standards noch nicht gedacht wurde.
Um Unterstützung und Befürwortung für die Standards zu erhalten, sollten diese Standards von der Argumentation hinter dem Standard begleitet werden. Das macht die Argumentation für die Befolgung von Standards in Projekten viel einfacher.
Die Standards sollten ständig aktualisiert werden, um den aktuellen Best Practices in diesem Bereich zu entsprechen.

Die Kohäsion der 3 K's der Architektur wird durch dieses Prinzip unterstützt, da Standards dort vorgeschrieben werden, wo sie benötigt werden, und so die Kohäsion zwischen IT-Lösungen, wo dies möglich ist, und die Komplexität begrenzen. Der Zusammenhalt wird dadurch erreicht, dass die Lösungen, die das Unternehmen wirklich braucht, innerhalb der Belastung durch zu strenge Standards erstellt werden können. Dies war der elfte und letzte in einer Reihe von Blogbeiträgen über die Prinzipien der Lean Architecture. Nächste Woche werden wir eine kurze Zusammenfassung der besprochenen Lean-Architektur-Prinzipien geben.

Mehr aus dieser Serie.