Coaches’ Diary: Wie verwende ich SSIS & SSAS in Business Intelligence Projekten mit dem SQL Server denn nun wirklich richtig?

Eine Frage höre ich im Verlauf von Coachings und Workshops immer wieder:

„Wie setzen wir denn nun die Werkzeuge bzw. die Dienste rund um den SQL Server wirklich richtig ein?“

Häufig stehen dabei die Werkzeuge wie das SSMS und das BIDS im Kontext von Business Intelligence Projekten im Vordergrund.

Es geht um die klassische Frage: Was ist richtig, was ist falsch? Und schon wird es alles andere als einfach!

Die Verantwortlichen in den Unternehmen für BI Projekte möchten nach Möglichkeit schnell zum Ziel kommen. Möglichst wenig Schleifen fliegen müssen. Zeit und damit Geld soll möglichst wenig verbrannt werden. Idealerweise soll schon vor dem Start klar sein wo, wann und wie die Ladung stattfindet und was während des Fluges so alles gereicht wird. Alles äußerst löbliche Ziele für ein Projekt! Wenn da das „aber“ nicht wäre.

Genaugenommen ist unser „aber“ hier ein „Randbedingungen“.

Jedes Projekt hat Randbedingungen. Und jeder Kunde definiert diese anders. Dazu kommt, dass diese Definition in den seltensten Fällen ein zu 100% bewusster Prozess ist.

Die Randbedingungen in Projekten bestimmen in der Regel, was sich später als falsch oder richtig herausstellen wird. Genau, das wird auch erst später deutlich! Dabei müssen doch jetzt Entscheidungen getroffen werden. Idealerweise noch vor dem Start eines Projektes! Und schon sind wir in der Schublade mit den Herausforderungen des klassischen Projektmanagements gelandet. Ein wenig muffig hier.

Wie kommen wir hier wieder raus?

Reduzieren wir das Ganze doch erst mal auf den technischen Aspekt. Technik wird sich ja wohl nur richtig oder falsch anwenden lassen, oder? Das trifft auf viele technische Werkzeuge zu. Bestimmt auch auf die eine oder andere Software, vielleicht sogar auf einige BI Lösungen. Nur bestimmt nicht auf den Business Intelligence Stack von Microsoft.

Der Microsoft BI Stack ist ein ehrlicher und gut ausgestatteter Werkzeugkasten, welcher keine falsche Versprechungen macht. Mittlerweile zieht der Vergleich mit dem Werkzeugkasten auch nicht mehr, eigentlich müssten wir hier schon von einem ganzen Schrank sprechen. Nehmen wir zum Beispiel auch noch die SharePoint Welt mit auf, dann sind wir sinnbildlich schon fast bei einer ganzen Garage. Und wurden in diesen nicht die innovativsten Lösungen entwickelt? Aber wir schweifen ab.

Was ist denn nun richtig oder falsch? Hier möchte ich kurz das Bild des Golfers bemühen. Ja, genau diese Gattung Mensch, welche einen kleinen Ball mit einem teilweise wirklich nicht ergonomischen Schläger in einem unübersichtlichem Gelände in ein viel zu kleines Loch befördern möchte. Wenn man es genau bedenkt, dann ist der Vergleich zum BI Projekt gar nicht so weit, oder? Und diese Golfer nehmen Stunden bei Golftrainern. So weit, so gut. Nun ist es aber so, dass es beim Golfen kein falsch oder richtig gibt. Wie kommst? Da steht nun der ehrgeizige Golfer. Möchte seinen Schlag verbessern, was in der Regel bedeutet, weiter und öfter mal dahin wo er ihn hinhaben will. Der Trainer gibt Tipps. Mehr Gewicht nach links, weniger das Handgelenk bewegen usw. Was passiert beim ersten Schlag? Geht völlig quer. Warum? Weil der letzte Trainer, den man hatte, genau das Gegenteil geraten hat. Mehr Gewicht nach rechts, Schwung aus der Schlägerhaltung usw. Wer hat nun Recht? Das fragt sich unser Golfer und zahl ein wenig zerknirscht die Trainerstunde. Beide Trainer schlagen im Übrigen total tolle Bälle und haben ein traumhaftes Handicap. Sie haben jeweils ihren eigenen Stil beim Abschlag und diesem bleiben sie treu. Wir könnten hier auch von einem Plan sprechen. Und wer sich mal mit einem professionellen Golfer unterhalten hat, der bekommt auch eine Impression davon wie komplex dieser Plan sein kann. Und wenn wir nun munter zwischen diesen Stilen bzw. Plänen wechseln, nun ja, klar, dass es uns da den Abschlag verhagelt. Angeblich erkennt man einen guten Golftrainer auch daran, dass er nicht versucht dem Golfer seinen Stil aufzudrücken, sondern bestrebt ist die vorhandene Technik zu verbessern.

Also gibt es kein richtig oder falsch. Nur ein “passt zum Plan” oder “passt nicht zum Plan”! Was ist nun in unserem BI Projekt der Plan? Nennen wir es mal Konzept.

Und was lernen wir da draußen an der Projektfront? Eine deutliche Unterschätzung bzw. Abwertung von klassischen konzeptionellen Phasen. Mitunter kommt sogar das Gefühl auf, dass „das Konzept“ bereits ein Unwort geworden ist. Alles muss mittlerweile pragmatisch und agil sein. Nicht, dass diese Ansätze falsch wären, aber auch hier ist ein mehr oder weniger klar definiertes Ziel von Vorteil.

Aber kommen wir zur Ausgangsfrage zurück: Wie verwende ich SSIS & SSAS denn nun richtig?

Unterscheiden wir mal zwischen allgemeinen Best Practices, welche sich um Performance Fragen drehen, und Architekturen, welche das Gesamtbild der späteren Lösung entscheidend bestimmen.

Best Practices gibt es mittlerweile viele. Und die meisten sind auch in den häufigsten Fällen allgemein genug, um sie fast immer anzuwenden.

Kommen wir zur Architektur. Hier stellt sich die Frage: Wie viel Feenstaub darf es denn sein?

Hier hilft eine klare und möglichst realistische Vorstellung des Ziels deutlich weiter. Klare Antworten auf Fragen wie „Wer arbeitet später mit dem System?“ oder „Wie viele arbeiten später damit?“. Auch immer gern im Vorwege gewusst: „Warum arbeiten die überhaupt damit?“. Viel zu häufig wird davon ausgegangen, dass das doch klar ist. Fragen lohnt sich hier auf jeden Fall. Allein schon der Antworten wegen.

Ok, Versuch es auf den Punkt zu bringen. :^)

Der Microsoft BI Stack ist eine erwachsende Umgebung, welche neben einer gewissen technischen Expertise auch einen belastbaren Plan benötigt, um ans Ziel zu kommen!

Dieser Plan darf durchaus mehrstufig sein. Ich mag ja die Worte Grob- und Feinkonzept kaum schreiben.

Des Weiteren ist es in Projekten gar nicht so unüblich, dass Entscheidungen unterwegs mal zurückgenommen werden. Alles gut, ehrlich. Es muss nur in geordneten Bahnen verlaufen. Viel zu häufig wird Projektmanagement mit dem Abarbeiten eines unveränderlichen Plans verwechselt.

Es gibt eine ganze Reihe von Randbedingungen, welche für die Auswahl der jeweiligen Methode, Vorgehensweise, Vorgangs- und Reifegradmodells berücksichtigt werden müssen.

Hier ein paar Tipps aus der Coaching Praxis:

Stellt Euch die Frage, welche Entscheidungen getroffen werden müssen. Das fängt schon mit der Wahl der SQL Edition an. Entwickelt im Dialog einen Entscheidungsbaum, welcher die jeweiligen Entscheidungen beinhaltet. Dokumentiert damit, welche Auswirkungen auf ein Projekt die jeweilige Entscheidung hat. Visio hilft hier gern.

Spiegelt an diesem Entscheidungsbaum später Eure Anforderungen. Also so etwas wie 24x7 Betrieb oder auch near-real time latency der Daten. Natürlich ist auch das erwartete Datenvolumen wichtig. Sprechen wir über 80 GB oder 8 TB? Der SQL Server kann beides stemmen. Nur der Weg ist halt ein anderer.

Berücksichtigt die Rahmenbedingungen des Projektes. Also zum Beispiel: Wie viele Berater sollen, müssen oder können parallel was zum Erfolg beitragen? Die Antwort ist meist erschreckend.

Bei uns kommt zum Beispiel noch die Frage dazu, ob wir in dem Projekt mit Repositories für SSIS & SSAS arbeiten oder nicht. Das passt auch nicht immer.

Wir sehen, dass der Plan (und ja, ich nenne es Konzept) den Einsatz der Werkzeuge bestimmt und nicht umgekehrt.

„It depends!“

(Alte Beraterweisheit, welche sicherlich schon beim Bau der Pyramiden ein alter Hut war.)