BI-Projekte sind dynamisch. Wenn man jetzt schon wüsste, welche Anforderungen in zwei Jahren kommen, würde man höchstwahrscheinlich anders modellieren als mit dem aktuellen Wissensstand. Wir sind aber alle keine Hellseher und deswegen ist es müßig, im Nachhinein immer sich zu sagen: „Hätte ich damals gewusst…“.
Manchmal ist es dennoch sinnvoll und wichtig, das BI-System einem kleinen Review zu unterziehen, und Optimierungsmöglichkeiten zu erkennen. Sei es, weil die technischen Entwicklung elegantere Lösungen möglich macht oder sich im Laufe der Zeit so viele Änderungen ergeben haben, dass man nicht nur mehr ein weiteres Pflaster aufkleben kann sondern gut daran tut, auch mal beim Fundament etwas zu tun. Vielleicht auch ist das System in die Jahre gekommen, sodass heute andere Standards und Methoden gelten.
Vielleicht – und das ist zugegeben ein sensibles Thema – wurde auch einfach schlecht modelliert? Thomas Ivarsson hat bereits vor längerer Zeit in seinem Blog – etwas ketzerisch – zwanzig Indizien aufgezählt, an denen man erkennt, ob man einen schlechten BI-Berater (konkret geht es hier um SSAS, also Microsoft) angeheuert hat:
Es handelt sich dort aber um eine rein technische Sicht, deshalb wollen wir diese Punkte nicht nur übersetzen – sondern um unsere Sichtweise ergänzen und in einen Beratungskontext setzen.
Wie schon erwähnt weiß man ja nachher immer alles besser – und auch Themen wie Zeitnot und Budget spielen eine große Rolle. Auch haben sich theoretisch großartige Vorgehensweisen in der Praxis nicht immer so gut bewährt, sodass man ruhig mal ein paar Regeln brechen kann.
Dennoch kann man immer wieder gewisse Muster erkennen, die wir hier aufzeigen wollen.
Datenbanken verändern sich. Beim SSAS kam der ganz große Schritt von 2000 auf 2005 – mit komplett neuen Paradigmen der Modellierung. Wenn Sie also auch in einem neuen System folgende Dinge feststellen, dann wurde wohl einfach das alte System 1:1 übernommen – oder noch schlimmer: es wurde so weitergemacht, wie man es vor vielen Jahren gemacht hat:
- Es existieren keine Measure Groups sondern viele getrennte Cubes, die durch MDX via Lookup Cube (Extrem langsam und außerdem abgekündigt!) oder Beladungsprozesse verbunden sind
- Es wird mit Dummy-Dimensionen gearbeitet, um „schiefe“ Dimensionalitäten auszugleichen – anstatt mehrere Measure Groups zu verwenden
- Es existieren keine benutzerdefinierten Hierarchien bzw. Attributhierarchien – sondern einfach viele Dimensionen, z.B. eine für Tage und eine für Wochen
- Es wurden keine Attributbeziehungen gepflegt
- Es wurde in MDX viel mit Calculated Cells gearbeitet
Diese Punkte lassen auch gerne erkennen, dass ein Berater nicht mit der SSAS-Modellierung generell vertraut ist, sondern auf einer anderen OLAP-Datenbank gelernt hat und seinen Stil nicht angepasst hat.
Weitere häufig anzutreffende Merkmale:
- ETL-Prozesse werden nicht frühzeitig durchgeführt sondern erst in der letzten Schicht durch Korrekturen im Visual Studio
- Das Verwenden von Parent-Child-Hierarchien ohne Not (Performance!)
- IDs im Data Warehouse sind textbasiert
- Zu viele Berechnungen erfolgen im Client und nicht in der Datenbank
- Es wird MDX verwendet, obwohl eine Echtzeitberechnung nicht notwendig wäre
- Aggregationsmöglichkeiten werden nicht genutzt
- Es ist kein Konzept zu erkennen, warum man sich für ein Single-Measure-Konzept oder eben dagegen entschieden hat.
- Die Bezeichnungen sind kryptisch und für den User unverständlich – es wurden keine „friendly names“ definiert
- Bestimmte Filtereinstellungen produzieren Fehler bzw. widersprüchliche Werte
- Es werden bestimmte Fehler nicht abgefangen, z.B. Division durch Null.
- Zeitdimensionen stören sich gegenseitig
- Wenn viele Measures die meiste Zeit den Nullwert besitzen, ist dies oft ein Zeichen schlechten Designs
- Es wird bei jeder Gelegenheit ein zeitraubendes „Full Process“ durchgeführt.
- Die Berechtigungen sind übertrieben kompliziert und/oder rauben Performance
- Es wird zu wenig mit Windows-Gruppen gearbeitet
- Es gibt zu viele Rollen mit minimalen Unterschieden anstatt dynamisches MDX für die Berechtigungen
Weitere wichtige Fragen, die man stellen sollte:
- In welcher Form fand eine Abwägung statt zwischen Single-Measure- und Multi-Measure-Konzept – wurde dies überhaupt getan?
- Wurde wirklich eine sinnvolle Technologie verwendet – oder das, was gerade „in“ ist und einen gewissen Hype erzeugt?
- Werden Berechnungen zu häufig im Frontend durchgeführt, evtl. als „dauerhaftes Provisorium“?
- Können Aufgaben zusammengefasst und automatisiert werden?
- Existiert ein aussagefähiges Logging?
- Wie steht es mit der Dokumentation?
- Welches Konzept zur Historisierung besteht?
- Wie wird das Stammdaten-Management gehandhabt?
- Kann man zur besseren Verständlichkeit und Wartbarkeit mehr in grafischer Form modellieren – z.B. mit einem guten ETL-Tool?
Nicht immer kann man alles nach Lehrbuch machen, aber zumindest sollte man die Regeln kennen, bevor man sie bricht – und gute Gründe dafür.
Sprechen Sie uns an – wir freuen uns, wenn wir auch aus Ihrem System mehr herausholen können!