Architecture Decision Records für Client-Plattformen

Ein Architecture Decision Record ist eine Seite. Sie hält fest, in welchem Kontext eine Entscheidung getroffen wurde, welche Optionen zur Wahl standen, wofür man sich entschieden hat und was der Preis dafür ist. Dazu ein Status: vorgeschlagen, angenommen, abgelöst. Damit ist das Format vollständig.

Der entscheidende Punkt ist die Abgrenzung zur Dokumentation. Dokumentation beschreibt, was gilt. Ein ADR beschreibt, warum es gilt, welche Alternative verworfen wurde und was man dafür in Kauf genommen hat. Das Erste kann eine Konsole exportieren. Das Zweite existiert nur, wenn es jemand aufschreibt.

Warum ausgerechnet die Endgeräteplattform

Konfiguration am Endpunkt entsteht selten in einem Zug. Sie wächst über Jahre, entlang von Migrationen, Zukäufen, Vorfällen und Anforderungen einzelner Fachbereiche. Jede einzelne Einstellung war irgendwann eine Entscheidung. Nach zwei Jahren ist sie eine Gegebenheit, und niemand weiß mehr, ob sie eine Sicherheitsanforderung abbildet oder einen Workaround von damals.

Drei Situationen machen das teuer. Ein Sicherheitsvorfall, bei dem geklärt werden muss, ob eine Konfiguration Ursache oder Zufall war. Ein Audit, bei dem die Frage nicht lautet, ob eine Einstellung gesetzt ist, sondern auf welcher Grundlage. Und ein Personalwechsel, nach dem die neue Verantwortung eine Umgebung erbt, die sie nicht erklären kann und deshalb nicht anzufassen wagt.

Das Ergebnis ist in allen drei Fällen dasselbe: Die Plattform wird nicht mehr geführt, sie wird konserviert.

Was zehn ADRs für eine Apple-Plattform abdecken

Ein Architekturvorhaben für eine Apple-Flotte kommt erfahrungsgemäß mit rund zehn Entscheidungen aus, die diesen Aufwand rechtfertigen. Alles darunter ist Konfiguration und gehört in die Betriebsdoku.

• Identitätsbindung: Platform SSO gegenüber dem Kerberos-Erbe, mit den Folgen für Anmeldung und Passwortsynchronisation.
• Gerätevertrauen: zertifikatsbasiert gegenüber Passwortrotation, inklusive Ausstellung und Rückruf.
• Verwaltungsmodell: deklarative Zielzustände gegenüber befehlsbasierten Profilen.
• Apple-Konten: Managed Apple IDs, Föderation mit dem Unternehmens-IdP, Umgang mit privaten Konten.
• Enrollment-Pfad: automatisiert über Apple Business Manager gegenüber manuellen Wegen, samt Ausnahmeregel für Altbestand.
• Updatesteuerung: Fristen, Fenster, Aufschub, und wer den Aufschub genehmigt.
• Herkunft der Baseline: BSI IT-Grundschutz oder CIS, und wie mit Abweichungen umgegangen wird.
• Rollen in der Verwaltungsebene: wer darf konfigurieren, wer freigeben, wer nur lesen.
• Ausnahmen: wer sie beantragt, wer sie genehmigt, wie lange sie gelten, wo sie sichtbar sind.
• Wiederherstellung: Verschlüsselungsschlüssel, Notfallzugang, Verlust und Stilllegung.

Die Liste ist als Prüfraster gedacht, nicht als Inhaltsverzeichnis. Fehlt zu einem Punkt eine bewusste Antwort, existiert die Entscheidung dennoch: Sie ist dann übernommen worden statt getroffen.

Wie eine solche Seite aussieht

Kontext: Die Anmeldung am Mac läuft heute gegen Active Directory, das Passwort wird lokal zwischengespeichert, mobile Nutzung erzeugt Abweichungen zwischen lokalem und zentralem Passwort.

Optionen: das bestehende Verfahren beibehalten, ein Drittprodukt zur Passwortsynchronisation einführen, oder Platform SSO gegen den vorhandenen Identity Provider.

Entscheidung: Platform SSO, weil die Anmeldung damit ohne Zwischenprodukt gegen die zentrale Identität läuft und der Gerätezustand in dieselbe Vertrauenskette gehört.

Konsequenz: Der Identity Provider wird für die Anmeldung am Gerät kritisch, es braucht einen dokumentierten Weg für den Ausfall, und Altgeräte unterhalb einer Betriebssystemversion fallen aus dem Verfahren heraus. Status: angenommen, gültig ab Rollout-Welle zwei.

Vier Absätze dieser Art halten fest, was zwei Jahre später sonst nicht mehr rekonstruierbar ist.

Wiederkehrende Fehler in der Praxis

ADRs im Nachhinein. Nach der Umsetzung aufgeschrieben, dokumentiert ein ADR eine Rechtfertigung. Der Wert entsteht davor, weil das Aufschreiben die Optionen sichtbar macht, die man sonst überspringt.

Kein Status. Ein ADR ohne Status ist eine Meinung mit Datum. Erst die Kette aus angenommen und abgelöst erklärt, warum die Plattform heute anders aussieht als vor drei Jahren.

Keine Konsequenzen. Der Abschnitt, der den Preis benennt, ist der einzige, dem später jemand glaubt. Ohne ihn liest sich jedes ADR wie eine Werbebroschüre für die getroffene Wahl.

Ablage im Ticketsystem. Entscheidungen gehören dorthin, wo auch die Konfiguration liegt, versioniert und mit Änderungsverlauf. Ein Ticket ist geschlossen, ein ADR gilt.

Was das mit Nachweisführung zu tun hat

Prüfer fragen nach dem Warum. Regulierung fragt nach nachvollziehbaren Entscheidungen, nicht nach vollständigen Einstellungslisten. Ein gepflegter Satz ADRs beantwortet beides, ohne dass jemand eine Woche vor dem Termin rekonstruiert, was gemeint war.

Der zweite Effekt wiegt im Alltag schwerer. Eine Plattform, deren Entscheidungen geschrieben sind, kann übergeben werden. Eine, deren Entscheidungen in Köpfen liegen, kann nur weitergereicht werden. Zwischen beidem liegt der Unterschied, ob eine Organisation ihre Endgeräte führt oder verwaltet.

Wie sich Konfiguration versioniert führen lässt, steht in Config as Code am Endpunkt.