Projektdokumentation
Wer heute Dokumentationen erstellt, muss mehrere Dinge unter einen Hut bringen. Sie sollten verschiedene Phasen eines Projekt begleiten, unterschiedliche Themen mit geeigneter Tiefe beschreiben und modular die Bearbeitung durch mehrere Autoren unterstützen. Dies erreichen Sie natürlich nicht durch ein großes monolithisches Dokument sondern eher durch mehrere Dokumente, die miteinander verbunden sind.
Leser und Autoren
Unterschiedliche Personen erstellen und Pflegen die Dokumentationen. Es ist dabei unerheblich, ob die Person beim Kunde oder Dienstleister arbeitet:
- Projektleitung und Steuerung
Organisiert und kontrolliert den Projektfortschritt und muss nicht technisch orientiert sein. - Infrastruktur Consultant
Diese Personen stellen die maßgeblichen Konzepte, stellen Varianten und Alternativen gegenüber und begleiten den Entscheidungsprozess um danach die festgelegten Konzepte auszuarbeiten. - Technischer Consultant
Diese Personen übernehmen die vorgegebenen Konzepte und arbeiten Sie bezüglich der Umsetzung aus. Dazu gehören Server, Sizing, Placement, Migrationswege, Aufbauplanung Desaster-Dokumente. - Administrator
Die Administratoren dokumentieren die aktuelle Konfiguration und pflegen diese weiter. Sie sind zudem für das „Servertagebuch“ zuständig.
Als Leser sehe ich generell alle Personen an. Es gibt keinen Grund, warum nicht alle Personen im Projekt und sogar der Firma Zugang zu den Ergebnisdokumenten haben sollten. Ausnahmen sind natürlich möglich.
Zeit und Projektphasen
Immer wieder höre ich die Frage, wann denn die Dokumentation fertig sei oder wann sie geschrieben werden sollte. Dazu machen ich gerne auch zwei Aussagen
- Dokumentation beginnt mit dem ersten Tag
Alles was besprochen, entschieden und letztlich auch getan wird, sollte umgehend dokumentiert werden., Es ist eine denkbar schlechte Idee "nachträglich" dokumentieren zu wollen. Zu viele Informationen sind dann schon nicht mehr präsent. Ideal ist es, wenn ein Team zusammen arbeitet und eine Person die Dokumentation macht. Wir bei Net at Work haben zumindest ein größeren Umgebungen immer gute Erfahrungen gemacht, wenn eine Person mit dem Kunden ein Thema erarbeitet und die zweite Person anhand unserer internen Checklisten die Qualität sichert (nichts vergessen !) und schreibt die Ergebnisse mit. Darauf muss sich ein Kunde natürlich einlassen. - Dokumentation ist nie fertig
Jede Infrastruktur unterliegt permanenten Änderungen und entsprechend gilt es auch die Dokumentation kontinuierlich fort zu schreiben. Insofern gibt es maximal ein "Projektende" aus Budget-Sicht bzw. zur Verrechnung. Wenn die Dokumentation kontinuierlich gepflegt wird, kann Sie auch jederzeit "gelesen" werden und das sollte sogar so sein. Wer die Dokumentation erst am Ende schreiben will, verhindert eine frühere Zusammenarbeit und mögliche Korrekturen.
Wenn Sie diese beiden Aussagen verstanden haben, sollten Sie sich noch heute Gedanken über ihre Dokumentation machen, einen Rahmen und eine Plattform schaffen und die Projektbeteiligten bei der Dokumentation unterstützen.
Auch ein Projekt durchläuft in der Regel mehrere Phasen und so wird auch eine Dokumentation sich kontinuierlich weiter entwickeln. Wenn ihr Projekt dazu noch aus aus "Proof of Concept" und"Pilot"-Phasen besteht, wird einige Dokumente erst als "Rohform" und nicht vollständig beschreiben. ähnlich wie bei einem Hausbau werden am Anfang viele Skizzen und Entwürfe erstellt die erst nach und nach
Die Dokumentationen entstehen parallel zu den unterschiedlichen Projektphasen und sind entsprechend erst gegen Projektend "komplett". Es liegt in der Natur der Dinge, dass die erste Versionen eher als "Entwurf" zu sehen und sollte daher niemand zu vorschneller Kritik verleiten. Die Konzepte müssen so vollständig sein, dass Sie zur aktuellen Projektphase passen., Bei einen "Proof of Concept" und auch einen späteren Pilot können noch nicht alle Ergebnisse feststehen sondern werden erst erarbeitet. So enthält ein Namenskonzept nur die Festlegungen der aktuell schon angelegten Objekten (Server, Benutzer, Gruppen).
Diese Diagramm enthält nur einen Teil der verschiedenen Dokumente. Über die Zeitachse sehen Sie die verschiedenen Projektphasen, die natürlich bei ihnen anders aussehen können. Schon bei den ersten Gesprächen mit dem Kunden entstehen grobe Zeitpläne, Besprechungsnotizen und ein guter Consultant hat schon eine erste Planung im Kopf, die er sich aber als Dokumentation merken sollte. Schließlich ist dies der Startpunkt für die weiteren Schritte. Bei größeren Projekte mit vielen Unsicherheiten wird ein Proof of Concept in einer isolierten Umgebung bereit gestellt, in dem die Anforderungen konkretisiert und die Umsetzung im kleinen demonstriert werden kann. Eventuell wird ein Pilot eingeschoben, um in der Produktion die Funktion zu verifizieren um dann die flächendeckende Einführung zu begleiten. Die meisten "Konzepte" werden natürlich vor dem Rollout, also während oder nach einem Pilot ausgearbeitet.
Aber damit sollten wir uns auf die verschiedenen unterschiedlichen Dokumentationen
Klassifizierung
Dokumente unterscheiden sich natürlich nicht nur bezüglich der technischen Tiefe sondern auch für die Zielgruppe und der Qualifikation des Autors. Ich habe hier vier verschiedene Klassifizierungen vorgenommen:
| Klasse | Beschreibung | Autor | Leser |
|---|---|---|---|
| Projektsteuerung | n den Bereich der Projektsteuerung gehören alle unterlagen, die für die Projektdurchführung relevant sind. Das sind z.B. Listen der Ansprechpartner, Termine, Sitzungsprotokolle, Entscheidungen, Offene Posten, Projektpläne, Analysen und Bewertungen etc. |
|
|
| Konzeptdokumente | Diese Dokumente beschreiben die große Funktionsblöcke ohne auf die einzelnen Server einzugehen. Sie sind dazu geeignet, dass sich jemand schnall über den prinzipiellen Aufbau einer Umgebung einen Überblick beschaffen kann. Sie beschreiben u.a. wie welche Aufgaben warum umgesetzt wurden aber ohne auf einzelne Server, IP-Adressen etc. einzugehen. Die beschreiben z.B. auch die Informationen, die für ein Sizing heran gezogen wurden oder Namensauflösung, Netzwerkrouting, Datenhaltung, Intranet, Internetzugriff, Netzwerkzugangsschutz, Backup, Storage-Design, Stromversorgung, Administrationskonzept,etc. |
|
|
| Betriebsdokumente | Diese Dokumente helfen beim Betrieb und Beschreiben die Zusammenhänge unter Nennung der Server und Nachrichtenflüsse. Sie beschränken sich aber auf die durch die Konzeption festgelegten Zusammenhänge und beschreiben keine Alternativen. Hierzu gehören auch Netzwerkpläne, Serverpläne und Funktionsdiagramme. |
|
|
| Konfigurationsdokumente | Die Konfigurationsdokumente werden meist von
den Administratoren selbst erstellt, da sie
näher am Objekte sind und diese Dokumente auch
Teil der Betriebsunterlagen sind. Es ist auch
denkbar, dass ein Großteil dieser Dokumente
skriptgesteuert automatisch erstellt wird. DNS, WINS, NTP, Proxy, SMTP-Relay, Exchange, Lync Einstellungen, etc. |
|
|
Die Klassifizierung ist auf "meinem Mist" gewachsen. Sie können natürlich eigene Überlegungen anstellen, beschreiben und umsetzen.
Konzepte
Wenn Sie keine Idee haben, welche Konzepte alles so erstellt werden können, dann möchte ich ihnen gerne ein paar Ansatzpunkte geben, die sowohl konzeptionell als auch bezüglich der Konfiguration erstellt werden können:
| Bereich | Themen |
|---|---|
Netzwerk |
IP-Adresse, Routing, WLAN, WAN, IPv6, IP-Adressverwaltung, DHCP, VPN |
Infrastruktur |
DNS, WINS, NTP, LDAP, Kerberos, Radius, Active Directory, Authentifizierung, Verzeichnisdienste |
Client |
Installation, Softwaremanagement, Gruppenrichtlinien, Bitlocker, WSUS, Patch-Management, Endpoint Security, Mobile Device Management |
Verschlüsselung und Signatur |
PKI, SMIME, Zertifikate, Smartcard, RMS, Bitlocker, EFS |
Storage |
DAS, NAS, SAN, iSCSI, Replikation, Backup und Restore, Versionierung, HSM |
|
Kommunikation |
Mail, Spamschutz, IM, VoIP, Konferenz, Präsenz, Lync, Exchange, OWA, Mobile Mail, Fax, SMS, De-Mail |
Schutz |
Antivirus, Intrustion Detection, Firewall, 802.x1, Zugang |
Gebäude |
USV, Klimatisierung, Zugangsschutz, |
Webservices |
Webveröffentlichungen, Zertifikate, Reverse Proxy, Proxy, File Exchange, SharePoint |
Monitoring |
Services, Eventlog, Performance Counter, Reporting, Auditing, Logmanagement, Funktionstests |
File/Print |
Dateiservices, NFS, SMB, FTP, Berechtigungen, Versionierung, Archivierung, Druckerfreigaben, Quota |
Provisioning |
Administrationskonzept, Benutzerverwaltung, Exit/Entry-Management, Metadirectory, |
Sicher ist die Liste nicht vollständig und hat noch Luft für ihre eigenen Bausteine. So finden Sie hier z.B.: kein "SQL-Server", da dieser allein keine Funktion hat, sondern nur z.B.: besser in einem ERP-Konzept oder SharePoint-Projekt zu beschreiben ist.
Ob sie solche Dokumentationen nun mit Word, Wordpress, auf einem Wiki, per SharePoint oder partiell per PowerShell erzeugen, überlasse ich ihnen. Letztlich sollte der Zugang "einfach" für jeden möglich sein, der dokumentieren soll, darf oder muss.
