Sascha Lorenz

Auch dieses Jahr findet wieder der SQLU Summit statt - die SQL Server Konferenz in Mitteleuropa (und da gehören wir hier dazu.). 2012 ist Bratislava, die slowakische Hauptstadt, Gastgeber dieses Stelldicheins einiger prominenter Mitglieder der internationalen SQL Community.

Wie schon im Vorjahr gibt es ein spezielles Angebot für Mitglieder von PASS Deutschland. Diese erhalten auf den jeweils gerade gültigen Preis noch einmal einen Rabatt von 10%. Bis 30.06.2012 ist der Very Early Bird: 690,00 Euro(exkl. MwSt.) gültig. Der Preis für PASS Deutschland Mitglieder beträgt also nur 621,00 Euro (exkl. MwSt.) für drei Tage volles Programm.

Heute mal was ganz anderes. Liegt mir gerade auf dem Herzen.

Lasst uns über Dokumentation in Projekten und beim späteren Betrieb der Lösung sprechen. Hey, jetzt nicht gleich umschalten. :-)

Über Dokumentation spricht keiner gerne. Sie hat den Ruf, dass das Erstellen meist im Weg steht und als lästige Pflicht gesehen wird. Klar wird jeder sofort den Nutzen einer Dokumentation nicht in Frage stellen wollen, dennoch ist sie das Stiefkind vieler Projekte.

Woran liegt das?

Meine These dazu ist, dass das Dokumentieren von Lösungen als so unangenehm wahrgenommen wird, weil vielen einfach nicht immer wirklich klar ist, was denn nun wie dokumentiert werden muss. Vorlagen existieren meist nur bei großen Organisationsstrukturen wie Konzernen und Behörden oder zertifizierten Spezialisten und oft sind diese Vorlagen dann doch nicht mit der Praxis wirklich kompatibel und führen zu mehr Verwirrung als, dass sie helfen. Es kommt Ende meist wieder auf die Kreativität des Einzelnen an.

Natürlich gibt es noch das Versprechen der Dokumentationsgeneratoren. Auch ich verwende gern solche automatisierten Tools, um eine Microsoft Business Intelligence Lösung zu "dokumentieren". Meist auf Basis der Analysis Management Objects entwickle ich kleine Helfer, welche dann entsprechende Repositories verwalten. Nur, ist das wirklich Dokumentation? Die gleiche Frage stellt sich mir bei vielen IT-Infrastruktur Visualisierungstools. Schicke Poster. Wo ist der konkrete Nutzen?

Stellen wir uns mal die total esoterische Frage: Was ist überhaupt der ganz konkrete Nutzen von Dokumentation ?

Hey, wer hat da gelacht?

Ich glaube, dass gerade diese Frage bzw. die Tatsache, dass sie häufig nicht spontan und konkret beantwortet werden kann, das primäre Problem bei der Erstellung einer (nützlichen) Dokumentation ist. Weil wenn immer klar wäre, was denn nun in einer Dokumentation erwartet werden würde, dann würde vielen armen Seelen die Erstellung einer solchen wesentlich leichter fallen.

Also, was ist der konkrete Nutzen einer Dokumentation? Wozu braucht man so etwas überhaupt?

Nein, so klar ist das nämlich gar nicht! Die Antwort kann nicht lauten: Um zu dokumentieren. :-)

Eine Dokumentation soll ja etwas bewirken können. Eine Wirksamkeit haben. Und zwar, wenn etwas geändert werden muss bzw. wenn etwas schief geht. Natürlich wird das nie im gerade aktuellem Projekt passieren. Also, dass jemand was ändern möchte. Später. oder dass gar etwas schief geht. Versprochen.

Nennen wir diese möglichen Einsatzzwecke einer Dokumentation doch einfach mal Risiken. Für mich sind die Folgen einer Änderung oder der Problemfall zukünftige Risiken, welche wir heute bereits verwalten müssen. Wir müssen Maßnahmen ergreifen, um diese Risiken zu minimieren. Und schwupps sind wir beim Risikomanagement angekommen.

Wie steht es bei Wikipedia so schön: "Risikomanagement umfasst sämtliche Maßnahmen zur systematischen Erkennung, Analyse, Bewertung, Überwachung und Kontrolle von Risiken."

Risikomanagement hat nichts mit Schwarzmalerei zu tun. Ganz im Gegenteil. Es ist für mich eine erstrebenswerte Form von Komfort im Projekt und auch gerade für den späteren Betrieb als auch weitere Anpassungen. Und idealerweise das alles nicht durch mich. Womit wir bei einem weiteren Risiko wären: Der ehemalige Berater ist aus welchen Gründen auch immer nicht verfügbar bzw. kann sich an nichts mehr erinnern. Welche Risiken entstehen dadurch und müssen durch welche Maßnahmen verhindert werden?

Eine verwandte Disziplin zur Dokumentation ist das sogenannte Betriebshandbuch. Hier ist der spätere Nutzen bereits im Namen dokumentiert. (Kleines Wortspiel. öhm. )

Zurück zur Dokumentation. Ich möchte hier jetzt keine x-te Vorlage für eine gute Dokumentation liefern. Vielmehr den Ansatz, dass sich bei der Planung und Erstellung einer Dokumentation erst mal bewusst gemacht werden muss, welche möglichen Risiken damit verringert bzw. verhindert werden sollen.

Beispiel. Klar soll eine Dokumentation eines Stück Codes helfen, dass er einfacher geändert werden kann. Nur das ist NICHT der eigentlich Nutzen. Der Nutzen ist, dass

a.) die Änderung schneller, einfacher und damit günstiger wird. (Risiko der Kosten)

b.) und, dass sie ohne unvorhersehbare Folgen für den Betrieb der gesamten Lösung sein wird. (Risiko der Katastrophe.)

Es ist zu einfach jetzt zu sagen, dass das doch klar ist. Vielmehr ist es so, dass gerade das Spiegeln von möglichen Risiken an den notwendigen Maßnahmen die Erstellung einer wirksamen Dokumentation deutlich vereinfacht. Des Weiteren wird die Pflege einer Dokumentation deutlich vereinfacht, weil "das Thema" klar ist. Wer kennt nicht noch die Aufsätze von früher mit dem Hinweis "Thema verfehlt."?

Jeder Teil einer wie immer gearteten Dokumentation sollte helfen Risiken zu minimieren. Da hat auch das IT-Poster seinen Sinn, da man sich schnell einen Überblick verschaffen kann (Spart Einarbeitungszeit) und das SQL Server BI Tool hilft die Details im Auge zu haben.

Also stellen sich beim Erstellen einer guten Dokumentation die Fragen nach dem WAS? und dem WIE? soll etwas dokumentiert werden, damit möglichst viele Risiken ausgeschlossen werden können.

Hoffe, dass diese paar Zeilen dem einen oder anderem helfen werden, um eine Dokumentation wirksamer und einfacher zu erstellen.

Das Programm der BASTA! 2012 wächst und wächst. Mittlerweile ist auf der Website zu lesen, dass ich auch noch einen zweiten Vortrag halten werde. Neben der Session "Integration der Master Data Services in produktive Umgebungen" werde ich auch noch das Thema MDS und Data Quality Services (DQS) im Kontext BI vorstellen. Session lautet "SQL Server 2012 MDS & DQS im Business-Intelligence-Projekt".

Hier die Beschreibung:
"In dieser Session werden die SQL-Server-Dienste Master Data Services und Data Quality Services im Kontext von Business-Intelligence-Projekten vorgestellt und erläutert. Es wird das Zusammenspiel von MDS und DQS mit den bekannten Diensten SSIS und SSAS anhand von Beispielen demonstriert. Des Weiteren wird der Nutzen für BI-Architekturen aufgezeigt."

Ich freue mich drauf.  

Einer meiner letzten Posts hat wieder mal zu einigen Nachfragen geführt. Ich hatte die Disziplin Datenvirtualisierung kurz vorgestellt und wie diese mit SQL Server Bordmitteln erfolgreich und einfach umgesetzt werden kann. Die Datenvirtualisierung ist Teil einer Referenzarchitektur für Data Warehouses wie ich sie in der Regel für Projekte einsetze.

Eine Frage war, ob bei der Nutzung einer Datenvirtualisierung ein ETL / ELT Prozess damit überflüssig werden würde.

Die Antwort ist definitiv: Nein!
Warum? Eine Datenvirtualisierung ist kein Ersatz für einen ETL/ELT Prozess. Und sie ist nicht zwingend nur für diesen Business Intelligence orientierten Einsatzzwecks zu gebrauchen als Architekturpattern. Eine Datenvirtualisierung hat nur einen Zweck und zwar den Zugriff auf Datenquellen in den nachfolgenden Schichten zu vereinfachen durch das Konzept der Zentralisierung. Dabei wird darauf Wert gelegt, dass die Daten nicht physisch als Kopie vorliegen (wie zum Beispiel in einer Landing Zone) sondern auf diese "verwiesen" wird. Daher auch die Bezeichnung als "virtuell". Auch klassische Integrationslösungen wie BizTalk oder Master Data Services können davon profitieren.

Dann kam die Frage, was denn nun wiederum das Besondere wäre an der Verwendung von Linked Servern und Views. Wozu da ein Repository?

Erst mit der Nutzung eines Repositorys, welches die Meta Daten der Linked Server und Views enthält, wird für mich daraus ein valides Vorgehen. Natürlich können die Linked Server und Views auch manuell hinzugefügt und später auch gepflegt werden. Aber nur durch die Automatisierung, welche auf Basis des Repositorys möglich wird, ist diese Architekturkomponente wirklich wirksam in der Anwendung. Es entsteht ein echter Nutzen für die Gesamtumgebung.

Und dann natürlich noch der Klassiker. Wenn schon Views, warum dann nicht alles als Views implementieren? Also auch den kompletten ETL/ELT Prozess!

Die Antwort ist wieder definitiv: Nein!
Weil dann wäre ich zumindest nicht mehr bereit den Bewirtschaftungsprozess als ETL/ELT Prozess zu benennen. Dann hätten wir eine Art einfache Schnittstelle. Wenn überhaupt. Nicht dass ich jetzt falsch verstanden werde. Ich habe nichts gegen Views. Ganz im Gegenteil. Im richtigen Kontext können diese sehr nützlich sein. Ein valider ETL/ELT Prozess ist mehr als nur die Summe seiner Technologien. Damit er "überlebt" und wirksam bleibt ist auch immer ein Stück Implementierungsphilosophie notwendig.

Heute ist es wieder soweit. Die Hamburger SQL Server Usergroup (PASS Deutschland e.V.) trifft sich um 18 Uhr wieder in der

Microsoft Niederlassung Hamburg
Gasstraße 6a.

Heute gibt es einem sehr interessanten Vortrag vom Thomas Martens:

Dokumentation von SSAS Modellen unter Verwendung von SSAS DMVs und dem OpenSource Tool Graphviz
Entwurf einer Dokumentations-Methode von SSAS Modellen. Als Grundlage für die Dokumentation der SSAS Modelle werden SQL Server StoredProcedures verwendet, die verschiedene DMVs durch Joins miteinander verknüpfen. Einzelne Objekte wie Dimensionen, MeasureGroups, Cubes und Perspektiven werden dabei als Nodes und die Beziehung dieser Objekte untereinander als Edges interpretiert. Für Objekte vom Typ MeasureGroup wird dabei bspw. das Granularitätsattribut der Dimension bzw. die Kardinalität der Beziehung der Dimension zur MeasureGroup angegeben. Die Visualierung von Nodes und Edges erfolgt anschließend in einem pdf-Dokument.

ich bin sehr gespannt, da ich zwar selber sehr gerne und ausgiebig automatisierte Dokumentationen und Repositorys für SQL Server Analysis Services Datenbanken (aka OLAP Cubes) erstelle und nutze, aber mich bisher so gar nicht mit Graphviz beschäftigt habe. Interessanter Ansatz!

Um zahlreiches Erscheinen wird gebeten! Sofern möglich, meldet Euch bitte vorher kurz beim Rolf Keyser unter rky@sqlpass.de an.

Freue mich drauf Euch vor Ort zu treffen!