Die Dokumentationsfamilie für Univention-Produkte ist um ein neues Mitglied gewachsen, die Univention Corporate Server Architecture. Sie finden das Dokument online und zum Download als PDF. Es ist die erste Iteration eines viel größeren Dokumentationsprojekts, das die technische Architektur hinter Univention Corporate Server (UCS) auf verschiedenen Detailebenen für unterschiedliche Zielgruppen abdeckt.
Inhaltsverzeichnis
Für wen eignet sich die Dokumentation?
Die erste Iteration richtet sich an Consultants, Administrierende, Lösungsarchitekt*innen, Softwareentwickler*innen und Systemingenieure, die sich einen Überblick über die Positionierung von UCS in der IT-Welt und die verschiedenen Konzepte hinter UCS wie z.B. Domäne, Rollen und Berechtigungen verschaffen wollen.
Ziel ist es, ein umfassendes Verständnis für die technische Architektur von UCS zu vermitteln, so dass dieser Personenkreis IT-Anwendungsfälle besser abdecken und IT-Umgebung mit UCS planen und betreiben können. Das Dokument soll auch Softwareentwickler*innen und Systemingenieuren ermöglichen, schneller in die Softwareentwicklung für UCS einzusteigen.
Der Inhalt umfasst die folgenden Aspekte:
- Ursprung und Geschichte von UCS als eine von Debian GNU/Linux abgeleitete Linux-Distribution. UCS verwendet denselben Paketmanager und dasselbe Paketformat wie Debian, um Softwarepakete und Aktualisierungen auf UCS zu verteilen.
- Das Identitätsmanagement ist die wichtigste funktionale Säule von UCS. Administrierende erledigen ihre täglichen Aufgaben rund um die Verwaltung von Benutzeridentitäten mit Hilfe von UCS effizienter.
- Verbindung zur Außenwelt, denn Administrierende und Nutzer*innen interagieren mit UCS über das Web mit der Univention Management Console (UMC) und Services über verschiedene Protokolle wie HTTP, LDAP, DHCP, DNS, SMTP und IMAP.
- Die Leser*innen lernen die grundlegenden Konzepte kennen, die UCS charakterisieren, wie Domänen, Replikation von Benutzeridentitäten, Computersystemrollen, Benutzerrechte und Sicherheitszertifikate.
Veröffentlichen, wenn fertig: Unser Experiment des iterativen Schreibprozesses
Wir haben uns aus mehreren Gründen für einen iterativen Schreibprozess entschieden:
- Wir veröffentlichen Inhalte, sobald sie verfügbar sind, um die Einarbeitung neuer Teammitglieder bei Univention und neuer Vertriebspartner zu unterstützen. Wenn Sie an einer neuen Herausforderung interessiert sind, sehen Sie sich sehr gerne unsere offenen Stellen an.
- Wir teilen die anfallende Arbeit in kleinere Häppchen auf und veröffentlichen diese, anstatt uns von der Fertigstellung eines Projekts abhängig zu machen. Wir halten uns an ein wichtiges Prinzip von Open Source Software: Release early, release often, wie es Eric S. Raymond 1997 in seinem Essay The Cathedral and the Bazaar populär gemacht hat.
- Wir können Rückmeldungen zu den veröffentlichten Inhalten in die nächsten Iterationen einfließen lassen.
Die übliche Vorgehensweise beim Schreiben von Dokumenten wie der Architektur für UCS gliedert sich in mehrere Prozessschritte wie Planen, Schreiben, Überprüfen und Veröffentlichen. Leider braucht der daraus resultierende Inhalt eine gewisse Zeit bis zur Veröffentlichung, wenn das Dokument alle Schritte als Ganzes durchläuft. Potenzielle Leser*innen können erst dann von den Inhalten profitieren, wenn das Projekt abgeschlossen ist. Dieser Ansatz ähnelt dem Wasserfallmodell in der Softwareentwicklung.
Für die agile Softwareentwicklung verwenden wir bei Univention das Kanban-Framework, um in selbstorganisierenden und funktionsübergreifenden Teams zu arbeiten, und um adaptive Planung und kontinuierliche Verbesserung zu nutzen. Warum nicht dieselben Prinzipien aus der Softwareentwicklung auch für die Erstellung von Produktdokumentationen anwenden?
Mit der UCS-Architekturdokumentation experimentieren wir mit einem anderen Ansatz und liefern gleichzeitig frühzeitig geprüfte Inhalte. Bereits vor Projektbeginn haben wir den Veröffentlichungsschritt automatisiert, da er auch für andere Univention-Dokumentationen gilt. Zu Beginn des Projekts haben wir die Struktur des gesamten Dokuments geplant. Mit der Automatisierung können wir den Veröffentlichungsschritt so oft wie nötig wiederholen, ohne dass zusätzlicher Arbeitsaufwand anfällt.
Die Schritte Schreiben und Überprüfen beinhalten die Arbeit an den Inhalten, die dem Leser Nutzen bringen. Sie gehören zusammen. Aber wie können wir den Nutzen für den Leser und die Leserin früher erreichen? Wir haben uns die Zielgruppen und den geplanten Inhalt angesehen. Wir beschlossen, den Inhalt in Abschnitte aufzuteilen, die den verschiedenen Zielgruppen entsprechen, so dass jede Iteration einer anderen Zielgruppe des Dokuments einen Nutzen bringt.
Nächste Iteration: Beschreibung der UCS-Produktkomponenten und -Dienste für Administrierende und Lösungsarchitekt*innen
Wir haben zwei zusätzliche Detailebenen für das Dokument geplant. Die zweite Detailebene richtet sich an Administrierende und Lösungsarchitekt*innen. Sie behandelt die UCS-Produktkomponenten und die zahlreichen Services, die UCS für IT-Infrastrukturen bietet. Die dritte Detailebene richtet sich an Softwareentwickler und Systemingenieure und behandelt die Softwarebibliotheken, die internen Systeme und den Storage.
Mit zunehmender Detailtiefe wird sich auch das benötigte Wissen der Leser*innen von der Informationstechnologie im Allgemeinen, den Bausteinen für Rechnernetze und Software über Linux-Betriebssysteme und deren Administration bis hin zu Kenntnissen über Softwarearchitektur und Software-Engineering erweitern.
Sobald wir weitere Inhalte veröffentlichen, finden Sie die Ankündigung in diesem Blog und auf unseren Kommunikationskanälen. Sie dürfen gespannt sein, was noch alles auf Sie zukommt.
Ihr Feedback zur UCS-Architekturdokumentation ist willkommen und wird sehr geschätzt. Wenn Sie Kommentare, Anregungen oder Kritik haben, senden Sie uns bitte Ihr Feedback, damit wir das Dokument in einer der nächsten Iterationen verbessern können. Vielen Dank.
