Prinzipien für die IT-Architektur müssen Entscheidungen verändern

„Cloud first“, „API first“, „Standard vor Individualisierung“: Solche Sätze klingen nach technischer Richtung. In konkreten Entscheidungen bleiben sie häufig folgenlos. Ein Projekt wählt eine Anwendung ohne belastbare Schnittstelle, ein anderes erklärt dieselbe Abweichung für unzulässig. Beide berufen sich auf dasselbe Prinzip.

Das Problem liegt nicht zwingend im Inhalt. Es liegt in der fehlenden Übersetzung von Absicht in Entscheidung. Wenn niemand sagen kann, wo ein Prinzip gilt, welche Konsequenz es auslöst und wer eine Ausnahme genehmigt, ist es keine wirksame Leitplanke.

Die Kernaussage lautet deshalb: Ein Architekturprinzip muss eine wiederkehrende Entscheidung erkennbar verändern. Andernfalls ist es Dekoration.

Prinzip, Policy, Standard und Entscheidung sind nicht dasselbe

Eine klare Begriffstrennung verhindert, dass ein kurzer Leitsatz mit einer vollständigen technischen Regel verwechselt wird:

Element	Zweck	Beispiel
Architekturprinzip	gibt eine langfristige Präferenz und Abwägungsrichtung vor	Standardfunktionen werden gegenüber eigener Erweiterung bevorzugt
Policy oder Richtlinie	setzt eine verbindliche organisatorische Regel	privilegierte Zugriffe müssen personengebunden und genehmigt sein
Standard	legt eine konkrete zulässige Ausprägung fest	unterstützte Identitätsprotokolle oder Protokollierungsfelder
Pattern oder Referenz	zeigt einen bewährten Lösungsweg	Standardmuster für die Anbindung an den Identitätsdienst
Architekturentscheidung	dokumentiert die konkrete Wahl im Einzelfall	System X wird über Variante Y integriert, weil Bedingungen A und B gelten

Ein Prinzip ersetzt diese nachgelagerten Artefakte nicht. Es sorgt dafür, dass ähnliche Entscheidungen mit derselben Grundhaltung getroffen werden. Ein Standard kann sich ändern, während das zugrunde liegende Prinzip bestehen bleibt. Eine konkrete Entscheidung kann begründet vom Prinzip abweichen, ohne es abzuschaffen.

Ein Slogan enthält noch keine Abwägung

„Cloud first“ lässt offen, ob damit jede SaaS-Lösung bevorzugt werden soll, nur neue Standardanwendungen betroffen sind oder auch besonders schutzbedürftige Daten ohne weitere Prüfung in eine öffentliche Cloud gehören. „API first“ erklärt nicht, welche fachlichen Fähigkeiten eine Schnittstelle abdecken muss oder ob ein dokumentierter Dateiaustausch für einen seltenen, unkritischen Vorgang genügt.

Ein entscheidungsfähiges Prinzip braucht deshalb mehr als eine Aussage. Die von The Open Group dargestellte Struktur aus Statement, Rationale und Implications ist eine hilfreiche Grundlage. Für den mittelständischen Betrieb sollte sie um Geltungsbereich, Nachweis, Verantwortung, Ausnahme und Review ergänzt werden.

Der Prinzipien-Steckbrief

Der folgende Steckbrief ist eine KinOps-Empfehlung. Er ist kein vorgeschriebenes TOGAF- oder ISO-Formular.

Feld	Leitfrage
Aussage	Welche beständige Präferenz soll Entscheidungen leiten?
Geltungsbereich	Für welche Systeme, Daten, Vorhaben und Entscheidungstypen gilt sie?
Begründung	Welches geschäftliche oder technische Problem adressiert sie?
Konsequenzen	Was müssen Projekte konkret tun, vermeiden oder finanziell berücksichtigen?
Abwägung	Welche Nachteile und Zielkonflikte werden bewusst akzeptiert?
Nachweis	Welche Unterlage oder Prüfung zeigt die Anwendung des Prinzips?
Owner	Wer pflegt die Bedeutung und entscheidet über Auslegungsfragen?
Ausnahmeweg	Wer darf mit welcher Begründung, Befristung und Kompensation abweichen?
Review	Welcher Anlass führt zur Prüfung, Änderung oder Aufhebung?

Besonders wichtig sind die Konsequenzen. „Wir bevorzugen Standardfunktionen“ wird erst handlungsfähig, wenn ein Projekt beispielsweise jede gewünschte Abweichung mit Geschäftswirkung, Alternativen, Lebenszykluskosten und Upgradefolgen begründen muss. Das Prinzip trifft die konkrete Entscheidung nicht vorweg. Es verschiebt aber die Beweislast.

Ein konstruiertes Beispiel: API first ohne Mindestnachweis

Das folgende Beispiel ist konstruiert.

Ein Unternehmen hat „API first“ als Architekturprinzip beschlossen. Bei einer Softwareauswahl bietet der fachlich bevorzugte Kandidat keine geeignete Programmierschnittstelle, sondern nur einen periodischen CSV-Export. Das Auswahlteam hält den Export für ausreichend. Die interne Architekturrolle lehnt die Lösung mit Verweis auf das Prinzip ab.

Beide Seiten können ihre Position vertreten, weil das Prinzip nicht definiert:

• für welche Integrationsarten es gilt,
• welche Fähigkeiten eine API mindestens bieten muss,
• welches zukünftige Änderungs- oder Automatisierungsziel geschützt werden soll,
• wie Aktualität, Fehlerbehandlung und Identität bewertet werden,
• und wer eine begründete Abweichung genehmigen darf.

Ein entscheidungsfähiger Steckbrief könnte festlegen, dass neue geschäftskritische Systeme ihre relevanten Daten und Funktionen über dokumentierte, unterstützte Schnittstellen bereitstellen sollen. Im Auswahlverfahren wäre nachzuweisen, welche Integrationsbedarfe über den Lebenszyklus bestehen. Ein Dateiaustausch bliebe möglich, wenn Aktualität und Fehlerfolgen dies zulassen, der Mehraufwand transparent ist und die zuständige Rolle die Ausnahme befristet akzeptiert.

Das Beispiel ist kein tatsächlicher Projektbericht. Es zeigt, dass ein scharf klingendes Prinzip ohne Geltungsbereich und Abwägung lediglich einen Konflikt benennt.

Begründung muss zum Geschäft führen

Ein Prinzip wird leichter akzeptiert, wenn seine Begründung nicht bei technischer Eleganz endet. Die Organisation sollte verstehen, welches wiederkehrende Problem vermieden oder welches Ziel geschützt werden soll.

Mögliche Begründungsrichtungen sind:

• geringere Abhängigkeit von einzelnen Personen oder Herstellern,
• sichere und nachvollziehbare Zugriffe,
• beherrschbare Änderungen und Wiederherstellung,
• konsistente Daten und Schnittstellen,
• schnellere Einführung standardisierter Fähigkeiten,
• oder transparente Lebenszykluskosten.

Das sind keine automatisch richtigen Prinzipien. Sie sind mögliche Anliegen, die aus Geschäftsstrategie, Risiken und Betriebsrealität abgeleitet werden müssen. ISO/IEC/IEEE 42010:2022 strukturiert Architekturbeschreibungen unter anderem über Stakeholder, ihre Anliegen, Sichten und Modelle. Die Norm legt keine konkrete Architekturstrategie für ein Unternehmen fest. Sie stützt aber den Grundgedanken, technische Beschreibungen und Entscheidungen auf relevante Anliegen und nachvollziehbare Begründungen zu beziehen.

Prinzipien brauchen sichtbare Konsequenzen im Arbeitsablauf

Ein PDF im Intranet verändert keine Beschaffung. Prinzipien müssen an die Stellen gelangen, an denen Entscheidungen vorbereitet und freigegeben werden.

Je nach Organisation betrifft das:

• Anforderung und Markterkundung,
• Ausschreibung und Softwareauswahl,
• Architektur- oder Sicherheitsprüfung,
• Make-or-Buy-Entscheidung,
• Budget- und Roadmap-Priorisierung,
• Change-Freigabe,
• sowie Ausmusterung und Ersatzplanung.

Für jedes relevante Prinzip sollte klar sein, welches Arbeitsmittel seinen Nachweis trägt. Bei „Standard vor Individualisierung“ kann das der Abweichungs-Steckbrief aus dem Beitrag „Nicht jeder Sonderprozess verdient ERP-Customizing“ sein. Bei einer Präferenz für austauschbare Services kann die Make-or-Buy-Entscheidung Übergabe, Datenexport und Exit prüfen.

Die Konsequenz muss proportional bleiben. Ein risikoarmer Pilot benötigt nicht dieselbe Nachweistiefe wie ein langfristig gebundenes Kernsystem. Das Prinzip bleibt dasselbe; der Umfang der Evidenz richtet sich nach Wirkung und Rückholbarkeit.

Ausnahmen sind ein notwendiger Teil der Governance

Ein Prinzip ohne Ausnahmeweg wird entweder dogmatisch oder heimlich umgangen. Beide Varianten schaden der Architektursteuerung.

Ein belastbarer Ausnahmeentscheid enthält:

• betroffenes Prinzip und konkreten Geltungsfall,
• begründeten Zielkonflikt,
• geprüfte Alternativen,
• erwartete Folgen und zusätzliche Risiken,
• kompensierende Maßnahmen,
• verantwortliche Entscheidung,
• Gültigkeitsdauer oder Überprüfungsanlass,
• und gegebenenfalls einen geplanten Rückweg.

Nicht jede Ausnahme braucht ein Gremium. Die Entscheidungsbefugnis sollte zur Wirkung passen. Eine begrenzte, reversible Abweichung kann innerhalb eines Projekts entschieden werden. Eine dauerhafte Ausnahme für ein geschäftskritisches Kernsystem kann IT-Leitung, Informationssicherheit, Fachverantwortung oder Geschäftsführung betreffen.

Das GOV.UK Service Manual betont evidenzbasierte Entscheidungen auf der richtigen Ebene sowie klare Befugnisse und Grenzen. Die konkrete Governance eines Mittelständlers muss kleiner ausfallen können. Das Prinzip bleibt: Entscheidungen sollen dort getroffen werden, wo ausreichende Verantwortung und Information zusammenkommen.

Das Ausnahmeprotokoll prüft zugleich das Prinzip

Ausnahmen sind nicht nur Abweichungen, die kontrolliert werden müssen. Sie liefern Evidenz über die Qualität des Prinzips.

Wiederholen sich ähnliche Ausnahmen, sind mehrere Ursachen möglich:

• Der Geltungsbereich ist zu weit oder missverständlich.
• Die geforderte technische Fähigkeit ist am Markt nicht realistisch verfügbar.
• Ein Standard oder Referenzmuster fehlt, das die Umsetzung erleichtert.
• Projekte umgehen kurzfristig notwendige Investitionen.
• Das Prinzip schützt kein aktuelles Unternehmensziel mehr.

Die richtige Reaktion ist nicht automatisch, das Prinzip zu lockern. Ebenso wenig sollte jede Ausnahme als mangelnde Disziplin behandelt werden. Ein Review muss unterscheiden, ob die Organisation an einem sinnvollen Ziel scheitert oder ob die Leitplanke selbst falsch zugeschnitten ist.

Wenige klare Prinzipien schlagen eine vollständige Sammlung

Eine lange Liste erhöht die Wahrscheinlichkeit von Widersprüchen. „Cloud first“, „Daten bleiben unter eigener Kontrolle“, „Best-of-Breed“ und „Komplexität reduzieren“ können jeweils sinnvoll klingen und in derselben Entscheidung gegeneinanderstehen.

Deshalb sollte die Organisation mit den wiederkehrenden Entscheidungen beginnen, bei denen heute die größten Kosten, Risiken oder Verzögerungen entstehen. Für jedes Prinzip ist zu prüfen:

• Welches konkrete Entscheidungsmuster soll sich ändern?
• Welche andere Leitlinie kann damit kollidieren?
• Welche Rolle löst den Zielkonflikt auf?
• Welche Evidenz zeigt, dass das Prinzip geholfen hat?

Es gibt keine allgemeingültige richtige Anzahl. Die Sammlung ist ausreichend, wenn sie die wesentlichen wiederkehrenden Architekturentscheidungen konsistent unterstützt und von den betroffenen Teams verstanden wird. Ein Prinzip ohne erkennbaren Anwendungsfall sollte nicht aus Vollständigkeitsgründen fortgeschrieben werden.

Architekturprinzipien ersetzen keine Strategie und keine Roadmap

Ein Prinzip gibt eine Abwägungsrichtung vor. Es sagt nicht automatisch, welches Vorhaben zuerst finanziert wird, welche Abhängigkeit Kapazität bindet oder wann eine Plattform ersetzt werden muss.

Die IT-Roadmap verbindet Initiativen mit Geschäftswirkung, Voraussetzungen, Kapazität und Entscheidungspunkten. Architekturprinzipien liefern dafür Leitplanken. Umgekehrt kann die Roadmap notwendige Enabler sichtbar machen: Wenn „zentrale Identität“ ein Prinzip stützt, aber die aktuelle Plattform die geforderte Integration nicht ermöglicht, muss aus der Leitlinie ein priorisierbares Vorhaben werden.

Auch eine CMDB erfüllt einen anderen Zweck. Sie kann zeigen, welche Services und Systeme von einer Architekturentscheidung betroffen sind. Der Beitrag „Eine CMDB beginnt nicht mit Daten, sondern mit Entscheidungen“ erklärt, wie Beziehungen aus konkreten Entscheidungszwecken abgeleitet werden.

Woran ein wirksames Prinzip erkennbar wird

Die Zahl veröffentlichter Prinzipien oder bestätigter Kenntnisnahmen ist kein Nutzenbeweis. Aussagekräftiger sind Beobachtungen aus Entscheidungen:

• Auswahlteams kennen die Leitplanken vor der Produktauswahl.
• Wiederkehrende Grundsatzdiskussionen benötigen weniger Zeit.
• Entscheidungen enthalten vergleichbare Nachweise und Begründungen.
• Ausnahmen sind sichtbar, befristet und einer befugten Rolle zugeordnet.
• Häufige Ausnahmen führen zu einem Review von Prinzip, Standard oder Umsetzungshilfe.
• Technische Entscheidungen lassen sich mit geschäftlichen Anliegen verbinden.

Eine vollständig ausnahmelose Anwendung ist kein sinnvolles Qualitätsziel. Sie kann ebenso bedeuten, dass Ausnahmen nicht dokumentiert werden. Entscheidend ist die Qualität und Konsistenz der getroffenen Abwägungen.

Das Digital Handbook des UK Cabinet Office ordnet Prinzipien, Standards und Governance-Artefakte als Leitplanken im jeweiligen Geltungsbereich ein. Die dortige Verwaltungsstruktur ist nicht eins zu eins auf den Mittelstand übertragbar. Nützlich bleibt die Trennung: Ein Prinzip formuliert die Richtung; Standards, Kontrollen und Entscheidungen machen sie operativ.

Der nächste Schritt beginnt mit einer strittigen Entscheidung

Starten Sie nicht mit einer Sammlung guter Leitsätze. Nehmen Sie eine wiederkehrende Entscheidung, bei der Projekte heute unterschiedlich handeln – etwa Integration, Identität, Standardsoftware, Datenhaltung oder Betriebsmodell.

Formulieren Sie für diese Entscheidung ein Prinzip und füllen Sie den gesamten Steckbrief aus. Lassen Sie anschließend zwei Personen unabhängig erklären, welche Konsequenz es für einen konkreten Fall hat und wann eine Ausnahme zulässig wäre. Kommen sie zu völlig verschiedenen Regeln, ist das Prinzip noch nicht entscheidungsfähig.

Architekturprinzipien sollen Denken nicht ersetzen. Sie sollen wiederkehrende Abwägungen nachvollziehbarer, schneller und konsistenter machen. Erst wenn sie das im Projektalltag leisten, sind sie mehr als Dekoration.