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.

Des Weiteren kommt häufig die Frage, ob sich denn der Wechsel auf eine aktuellere Version lohnen würde? Viele Kunden von Microsoft haben einen SQL Server 2008 im Einsatz und noch mehr einen SQL Server 2005. Und natürlich gibt es noch durchaus Anwender des SQL Server 7 & 2000, aber da stellt sich aus Supportsicht die Frage eigentlich nicht.

Oft kommt auch noch die Frage, ob sich denn das Warten auf die nächste Version lohnen würde. Zurzeit warten wir ja alle ganz gespannt auf SQL Server 2011 aka Denali.

Und natürlich ist der Fragesteller dann immer schnell bei der Hand die guten alten "Best Practices" zu bemühen. Also da muss es doch auch so eine richtig vs. falsch Regel für geben. Wieder mal gibt es diese nicht, denn die Antwort auf so eine Frage kann natürlich nur das wiederum gute alte "Kommt ganz drauf an." sein.

Ach ja, das Thema Lizenzierung lassen wir mal für den Moment ganz außen vor, ist aber nicht weniger spannend! Glaubt mir!

Ich will hier nun keinen detaillierten Vergleich der Editionen durchführen. Dafür hat Microsoft selbst gute Seiten. Siehe unten.

Fangen wir mit der häufigsten Frage an. Welche Edition für das Projekt?

Immer wieder habe ich in Workshops und Proof-of-Concepts die Diskussion, dass Kunden & Partner erwarten die gerade für sie "selbstverständlichen" Features in der Standard Edition vorzufinden. Mein Einwand ist dann meist, dass es sich da um ein semantisches Missverständnis handelt. Nicht nur, dass der SQL Server mit seinem Namen eh schon ein Problem hat, da die wenigsten BDM bei etwas mit diesem Namen eine komplette "Data Plattform inkl. BI" vermuten, sondern auch "Standard" in Abgrenzung zu "Enterprise" ist verwirrend in der Kommunikation.

Daher beantworte ich diese Frage meist damit, dass in meinem Verständnis die "Enterprise" Edition die eigentliche "Standard" Edition ist. Schon verwirrend, was für Labels der Hersteller da auf seine Boxen klebt. :-)

Die eigentliche "Enterprise" Edition, also das was viele damit verbinden (GROSSE Umgebungen.), ist für mich die "Data Center" Edition. In der "Data Center" Edition liegt zum Beispiel die Premium Edition von StreamInsight bei. Die wird benötigt für Umgebungen mit mehr als 5000 Events pro Sekunde und einer Latenz unter 5 Sek. Das ist sehr wahrscheinlich gar nicht so selten. Wesentlich bekannter ist die Eigenschaft, dass sie tatsächlich alle verfügbaren CPUs des Betriebssystems unterstützt. Und wem das nicht genug ist, kann ja gerne mal auf die "Fast Track" Konfiguration und "Parallel Data Warehouse" Edition hinweisen!

Nur was sind denn jetzt die wesentlichen Unterschiede in den Editionen (Standard vs. Enterprise) bezogen auf Business Intelligence Projekte?

Unterscheiden wir mal die einzelnen Dienste des SQL Server 2008 R2:

In der Datenbank Engine sind die wesentlichen Unterschiede in der "Enterprise" Edition:

• wichtig für Data Warehouse Umgebungen
  • Partitionierung in der relationalen Datenbank
  • Parallele Indexvorgänge
  • volle Unterstützung von Indizierte Sichten
  • Datenkomprimierung
  • Optimierung von Sternjoinabfragen
  • SQL Server Audit
  • Transparente Datenbankverschlüsselung
• praktisch für Integrationsprozesse (ETL/ELT) im Quellsystem
  • Datenbank-Momentaufnahmen (Snapshots)
  • Change Data Capture

In den SQL Server Integration Services (SSIS) kommt folgendes hinzu:

• High-Performance-Oracle-Ziel
• High-Performance-Teradata-Ziel
• SAP BW-Quelle und -Ziel (ja, ja. so etwas gibst!)
• Zieladapter des Data Mining-Modelltrainings
• Zieladapter für Dimensionsverarbeitung
• Zieladapter für Partitionsverarbeitung
• Persistente Suchen
• Fuzzygruppierung und -suche
• Ausdrucksextrahierung und -suche

Bei den Analysis Services (SSAS) würde uns ohne "Enterprise" Edition folgendes fehlen:

• Partitionierte Cubes
• Finanzaggregationen & Kontointelligenz
• Semiadditive Measures

Vorsicht, das liest sich hier für die SSAS jetzt von der Menge her nicht sehr tragisch, kann einen Architekten bzw. Berater aber empfindlich eingrenzen und leicht zum Misserfolg eines Projektes führen!

Und bei den Reporting Services fehlt uns eigentlich "nur" das Feature "Datengesteuerte Berichtsabonnements", aber auch das kann fehlen. Und immer daran denken, dass nachmachen nicht gilt! :-)

Master Data Services und PowerPivot für SharePoint haben wir nur ab der "Enterprise Edition"!

Wie kann nun im Rahmen eines Proof-of-Concepts entschieden oder in den ersten Projekt Phasen eine belastbare Entscheidung herbeigeführt werden für die Auswahl einer Edition? Wie oben bereits gesehen, hängt die Auswahl der Edition stark von den Anforderungen ab! Daher ist es sehr wichtig den Anforderungskatalog für das geplante Projekt durchzugehen und zu klären, ob echte Showstopper dabei sind. Sofern sich die Projektbeteiligten nicht einig sind, ob die Features wirklich benötigt werden, empfehle ich einen Piloten auf Basis der kostenlosen "Evaluierung" Edition aufzusetzen. Diese Edition hat den Umfang der "Enterprise" Edition.

Nun zur Wahl der Version. Wichtig der Hinweis, dass diese Entscheidung, wenn sie denn tatsächlich ansteht, vor der Wahl einer Edition erfolgen sollte.

Hier ist der Rat sehr einfach. Eigentlich sollte immer auf die aktuell verfügbare Version zurückgegriffen werden. Wenn bereits eine Version vorhanden ist und keine Möglichkeiten bestehen im Rahmen des Lizenzvertrages mit Microsoft auf die aktuelle Version zu wechseln, also eine nicht kostenneutrale Entscheidung ansteht, dann empfehle ich wieder auf Basis des Anforderungskatalogs zu klären, welche neuen Features benötigt werden.

Ein häufiger Grund für den Wechsel von 2008 auf 2008 R2 waren in der Vergangenheit u. a. die zahlreichen Erweiterungen der Reporting Services.

Ein Hinweis noch zur sogenannten "Developer Edition", da diese relativ unbekannt ist. Mit dieser dürfen Entwickler bzw. BI Berater auf Entwicklungssystemen bzw. lokalen Rechner isoliert von den produktiven Systemen an der Lösung arbeiten. Solche extra Server sind bei anderen Herstellern immer recht kostenintensiv, bei Microsoft hat sich über Jahre ein Preis von unter 100? pro Lizenz gehalten. Das ist äußerst günstig und sollte in Projekten auf jeden Fall genutzt werden, da es zumindest keinen lizenztechnischen Grund gibt direkt auf dem produktiven Systemen die Lösung weiterzuentwickeln.

Bei allen Angaben in diesem Post beziehe ich mich als Quelle auf diese Seite von Microsoft: http://technet.microsoft.com/de-de/library/cc645993.aspx

Wir sprachen über die Einführung eines Data Warehouses, ETL etc. pp. und dann kam da einer mit einer ganz tollen Frage: Was ist denn mit ELT und wo sei der Unterschied? Und ob das denn die Integration Services auch könnten? Ist doch die Zukunft des Integrationsprozesses, sagt doch der andere Hersteller. Also wäre ja zu erwarten, dass Microsoft solche Innovationen unterstützt. Der klassische ETL Prozess wäre ja quasi von gestern und mit ELT dann ja auch dazu noch überflüssig geworden.

Erwartungsvolle Gesichter in der Runde. Was ist denn nun ELT und kann das der SQL Server? Ich liebe meinen Job.

Also, klassisches ETL (Extract, Transform, Load) meint, stark vereinfacht ausgedrückt, dass Daten aus verschiedenen Vorsystemen extrahiert werden. Diese werden in der Regel in Form von "Datenpaketen" in einer sogenannten Landing Zone gesammelt. Von dort aus werden die Pakete i. d. Regel mehrstufig weiterverarbeitet, sprich transformiert. Der letzte Schritt ist das Laden der Daten in das relationale Data Warehouse, wobei dann noch die Historisierung von Daten durchgeführt werden kann. 

Was kann nun eine ELT Lösung dazu Innovatives beitragen? Das Offensichtliche zuerst. ELT steht für Extract, Load & Transform. Ok, ist halt vertauscht. Und? :-)

Die Idee dabei ist, dass Daten wiederum zuerst aus Vorsystemen extrahiert werden. Die Methoden, Konzepte, Ideen und auch Herausforderungen sind 100% identisch zur ETL Welt. Auch können diese Daten in Form von Datenpaketen organisiert werden. Nur dann kommt der wesentliche Unterschied! Die Daten werden beim ELT Ansatz gleich wieder in ein relationales Datenbanken System geladen. Häufig ist es das System, welches auch das eigentliche Data Warehouse hält. Und auf diesem System werden die Daten mittels SQL Statements transformiert. Das ist schon alles.

Ok, ok. wozu jetzt die ganze Aufregung? Dazu müssen wir noch ein wenig mehr ins Detail gehen beim ETL Prozess. Beim ETL findet häufig eine Verarbeitung der Daten außerhalb einer relationalen Datenbank statt. In der Regel werden die Daten zeilenweise verarbeitet. In den Integration Services wird das durch den konsequenten Einsatz der Datenflusskomponente und des RAW-Dateiformates erreicht. Ab einer sehr großen Datenmenge ist dieses Vorgehen deutlich schneller als die relationale Engine zu bemühen.

Bei ELT gibt es aber keine extra Verarbeitungsengine, sondern "alles" findet innerhalb einer relationalen Datenbank statt. Es wird damit eine Technologie "gespart". Das ist der häufig ins Feld geführte Vorteil einer ELT Architektur. In der Praxis heißt das auch oft, dass ein extra System gespart wird.

Meine 2 Cent dazu sind:
ELT klingt gut, kann es sogar sein, ja wenn. die Rahmenbedingungen stimmen! Wenn ich keine wirklich komplexe und unübersichtliche Umgebung habe. Des Weiteren sollte die Anzahl der Vorsysteme überschaubar sein. Und, steht ja schon oben, die Datenmenge sollte auch gewisse Grenzen haben (und nein, da gibt es keine one-size-fits-all Antwort drauf!).

Die Wahrheit ist, dass es da draußen eine Unmenge an ETL Prozessen gibt, welche sehr wahrscheinlich ELT Prozesse sind. Und bisher hat es keinen gestört! :-)

Ach ja, und natürlich lassen sich auch ELT Integrationsprozesse mit dem Microsoft SQL Server abbilden. Alles eine Frage der Architektur!

"Der Stern, die Schneeflocke oder die Galaxie ist nicht gleichzusetzen mit dem daraus entstehenden multidimensionalem Raum!"

Kurzfassung:

Der Stern ist nicht der Würfel!

Viele Anwender der Analysis Services arbeiten aber gerne mit der Vorstellung, dass das Starschema nicht nur die Quelle darstellt, sondern auch, dass im Cube die Trennung zwischen Dimensionen und Fakten existiert. Dimensions- und Faktentabellen sind aber "nur" relationale Strukturen, welche als Datenquellen für den Würfel dienen. Viele Frontends, wie auch Excel, unterscheiden aber sehr deutlich in der Darstellung zwischen Attributen (Dimensionen) und Measures. Der eigentliche Cube bzw. der, wie ich finde korrektere Ausdruck, multidimensionale Raum haben aber ihre ganz eigene "Logik".

Wie kommen wir da jetzt raus?

Muss nun jeder Endanwender eine hochesoterische MDX Schulung erhalten? Bitte nicht! Das führt nicht gerade zur Akzeptanz einer Lösung!

Aber jeder, der sich für das Erstellen von OLAP Cubes mit den SQL Server Analysis Services interessiert, sollte frühzeitig in den "echten" multidimensionalen Raum einsteigen. Selbst wenn nie geplant ist mit MDX Berechnungen etc. pp. einzubauen, so ist das bloße Beschäftigen damit und Hinterfragen schon sehr nützlich, um auch die "einfachen" Funktionen von SSAS noch besser zu nutzen. Ehrlich!

Viele Fragestellungen bzw. Herausforderungen, welche ich im Rahmen von Coachings gestellt bekommen habe bzw. wir als Team in Projekten angetroffen haben, lassen sich auf einige grundlegende Missverständnisse und inkonsequente Entscheidungen zurückführen. Dabei geht es nicht um technische Details.

Ist tatsachlich die Entscheidung für eine echte ETL Lösung getroffen worden?

ETL heißt nicht, dass ein bestimmtes Tool verwendet wird! Also, wir verwenden die Integration Services heißt nicht automatisch, dass man da von ETL sprechen kann oder sollte. ETL ist für mich die konsequente Verfolgung eines Konzeptes. Und es heißt viel mehr als nur in Extract, Transform und Load zu denken, denn das trifft auch auf die meisten üblichen Schnittstellen zu.

ETL heißt u. a., dass alle Beteiligen sehr wahrscheinlich in Zukunft in Datenpaketen denken müssen. Und damit ist nicht gemeint, dass SSIS Task in Paketen organisiert werden, sondern "wieder" klassische Batchverarbeitung von Datensätzen angesagt ist. Aber nur mit diesen einfachen aber effektiven Methoden können Datenmengen in Enterprise Umgebungen auch nachhaltig bewältigt werden.

Ist jemand im Team, der schon mal ein echtes Data Warehouse gesehen hat?

Ok, provokant, aber leider eine berechtigte Frage! Denn mit Integration Services zu arbeiten heißt nicht, dass man später nur noch mit bunten Pfeilen Kästchen verbinden darf und alles andere ist dann von ganz allein im Lot. Viel zu häufig erlebe ich, dass die SSIS unterschätzt werden. Das grundlegende Konzept ist ja auch sehr einfach. Da kommt dann gerne mal im Workshop oder Proof-of-Concept viel zu schnell ein "Schnittstelle, verstanden, lassen Sie uns jetzt bitte mit diesen Würfeln weitermachen.". Daher, da muss jemand ins Team, der das Ziel kennt.

Ist eine Entscheidung für den Einsatz des Datenflusstasks getroffen worden?

Was soll das denn jetzt? Der Datenflusstask ist doch das Herz der Integration Services! Korrekt, aber ich kenne einige sehr erfolgreiche und durchaus komplexe BI Projekte, welche komplett auf den Datenfluss Task verzichtet haben. Warum? Ja, weil einfach die Anforderung für den Einsatz fehlte. Zwar wurde der Bewirtschaftungsprozess komplett in SSIS gekapselt, aber es wurden konsequent SQL Statements für die Verarbeitung der Daten eingesetzt.

Den Datenflusstask einzusetzen heißt, dass sich das Team bewusst dazu entscheidet ab sofort neben einem "Thinking in Sets" (ja, ich meine damit auch das Buch von Joe Celko) mit der Prämisse "Thinking in Rows" zu leben. Den Datenflusstask einzusetzen heißt auch eine nicht unerhebliche Lernkurve mitzumachen.  Dann hat das Team eine äußerst leistungsfähige Technologie zur Hand, um wirkliche Massendaten bei jedem Lauf des Prozesses zu bewegen. Wenn es aber wie so häufig um wenige 100.000 Sätze pro Tag geht, dann sollte vorher entschieden werden, ob sich der Aufwand beim Einsatz lohnt. Wichtig ist mir hier der Hinweis, dass es da kein Richtig oder Falsch gibt! Es gilt immer die Fallentscheidung.

Sind die politischen Aspekte eines solchen Projektes klar?

Natürlich ist jedes Projekt irgendwie politisch. Wer kennt das Spiel um die Förmchen und Schäufelchen nicht aus eigener Erfahrung. ETL Projekte, also wenn wir von einem echten sprechen (s.o.), sind anders, denn hier nehmen wir allen den Sand aus dem Sandkasten weg, um ihn erst mal richtig gut durchzuwaschen, zu sieben und dann färben wir den Sand auch der Größe der Körner nach ein. Und dann wird auch noch entschieden wer ab sofort mit dem blauen, roten und grünen Sand spielen darf. Vielleicht werden im Zuge des Projektes auch noch die liebgewonnen Eimer und Siebe standardisiert. Mit diesem Bild vor Augen sollte jedem die Situation und Herausforderung klar sein, in die er sich da begibt. Mein Ratschlag: Nehmen wir viele Lollies mit, welche dann vom Business Intelligence Competence Center verteilt werden sollten. Nicht ohne Grund ist die Gründung eines BICC häufig ein Teil eines ETL/DWH Projektes, um den Anwendern das Ganze schmackhaft zu machen.