„Sind Sie bereit, bereit für das Unbekannte?
Für eine neue Erfahrung, die alles in Frage stellen könnte,
was Sie zu wissen glauben?
Was Sie jetzt sehen werden, wird Ihr Bewusstsein verändern,
denn hinter der vertrauten Realität lauert das Unfassbare.
Hinter dem Sichtbaren verbergen sich geheimnisvolle Rätsel.
Hinter dem Augenscheinlichen liegt noch eine andere Wahrheit.»
(Outer Limits – Die unbekannte Dimension, Mario Azzopardi et al., USA, 1995 – 2002)
Dieses Zitat aus der US-amerikanischen Science-Fictionserie «Outer Limits – Die unbekannte Dimension» erklang zu Beginn jeder Episode und sollte dem Zuschauer quasi die Stimmung von Mysterien und unbekannten Dingen bzw. Überraschungsmomente vermitteln.
Auch bei BO-Migrationen gibt es oft «Mysterien», unbekannte Hürden und zum Teil Überraschungsmomente – dies alles ist jedoch keine Fiktion, sondern Wirklichkeit.
Erfahrungen zeigen, dass viele BO-Migrationen aufgrund von zum Teil erwarteten aber leider auch unerwarteten Problemen gebremst, verlängert oder auch gestoppt werden. Bei stabilen Systemen ist man daher versucht, eine Migration so weit wie möglich hinauszuzögern. Jedoch spätestens, wenn man kurz vor dem End-Of-Life-Termin steht, müssen diese Probleme in Angriff genommen oder zum Teil sogar akzeptiert werden, um weiterhin im Supportfall entsprechende Hilfestellung von SAP zu erhalten. Mit folgenden Überlegungen und Best Practices kann man den verschiedensten Showstoppern entgegenwirken und sich das Leben rund um die BO-Migration erheblich erleichtern:
- Projektmanagement und Planung
BO-Migrationen können aufgrund von Zeit, Kosten und Personalaufwand schnell Projektcharakter besitzen und sollten daher auch so behandelt werden. Man kann nun so tun, als ob es Planungssicherheit in BO-Migrations-Projekten gibt aber dieses Vorgehen (zumeist Wasserfall) wird in den meisten Fällen dazu führen, dass das Ende der geplanten Projektzeit mehrfach verschoben wird und die Kostenschätzung eher einem Ratespiel gleicht. Um diesen Unsicherheiten entgegenzuwirken, empfiehlt es sich, auf agile Vorgehensmethoden zu setzen. D.h. Timeboxing-Vorgehen, bei welchem Kosten und Zeit fixiert und die einzelnen «Migrations-Meilensteine» variabel gehalten werden. - Umgebungsanalyse & Housekeeping
Obwohl viele Plattform-Administratoren eine Migration im Sinne einer sogenannten «1:1-Migration» möglichst schnell über die Bühne bringen möchten, empfiehlt es sich, einen Blick auf die bestehende BO-Landschaft zu werfen, um Einsparungspotenzial zu erkennen und z.B. historisch gewachsenen «BO-Müll» loszuwerden. Dies kann entweder durch den Abgleich mit bestehenden Dokumentationen (z.B. Betriebshandbuch) oder durch professionelle Metadatenanalyse-Tools (z.B. 360eyes von GB&Smith) gemacht werden. - Sizing & Systemarchitektur
Besonders wenn es sich um eine Migration auf die nächste Major-Version handelt, wird über neue Hardware gesprochen. Einfach nur einen Standard-Server gemäss IT-Vorgaben hinzustellen, ist jedoch keine vernünftige Lösung. SAP stellt nicht nur einfach Systemanforderungen, sondern sogar einen eigenen Sizing-Guide und ein Gratis-Tool (Resource Usage Estimator), um eine (neue) BO-Plattform auf die Hardwareanforderungen abzustimmen. - Supported Platforms
Ein BO-System ist niemals alleine, sondern arbeitet zumeist mit vielen Umsystemen zusammen. Vom Betriebssystem des Servers, über die verwendete Systemdatenbank, bis hin zum eingesetzten Browser beim End-client. Je nach Version und Patch-Level werden Umsysteme unterstützt oder auch nicht. SAP gibt hierzu detaillierte Informationen über das Supported Platforms Dokument bzw. über die sogenannte ProdcutAvailabilityMatrix (PAM). Dieses Dokument sollte vor allen Migrationen aber auch vor dem Einspielen des kleinsten Patchlevels konsultiert werden, um Überraschungen hinsichtlich nicht unterstützter Systeme zu vermeiden. - Integration aller Stakeholder
Eine Migration betrifft oft mehr Personen und Stellen, als man denkt. Eine Hürde ist oftmals der Informationsfluss an die verschiedenen Stakeholder, welche von der Migration betroffen sind. Nicht nur im Bereich BO, sondern gerade im Bereich aller Umsysteme, sollte sichergestellt sein, dass alle notwendigen Informationen an die zuständige/verantwortliche Person gehen. Alle Stakeholder sollten auf jeden Fall in den Betriebsunterlagen dokumentiert sein, damit jederzeit klar ist, an wen die Information gehen muss. - Dokumentation & Changemanagement
Im Zuge der Migration sollte nicht nur die bestehende Dokumentation konsultiert werden, um zu wissen, wo man steht. Wichtig ist auch, dass sämtliche Aktionen/Schritte/Kommunikations-Informationen lückenlos dokumentiert werden. Nicht nur, um bei einem auftretenden Fehler zu wissen, wo dieser passiert sein könnte – vor allem für zukünftige Migrationen sind dokumentierte Vorgehensweisen perfekte Anleitungen und sparen dadurch viel Zeit. - Pilotsystem
Für die Migration auf den nächsten Major-Release sollte vorab ein Pilot-System errichtet werden, welches so installiert und konfiguriert wird, wie es das zukünftige Produktiv-System sein wird. So kann man sich an einem unkritischen System «austoben» und Systemfehler ohne Einfluss auf den produktiven Betrieb analysieren. Entsprechend dokumentiert dient die Installation ausserdem hervorragend als Vorlage für alle weiteren Systeme. - Testing
Egal, ob es nur ein einfacher Patch oder der Upgrade auf eine Major-Version war. Funktionen und BO-Objekte sollten ausreichend getestet werden, um spätere Überraschungen zu vermeiden. Ein Fehler der in einem bereits produktiven System erkannt wird, ist ein zu spät erkannter Fehler. Im besten Fall ist bereits eine automatisierte Lösung im Einsatz, mit dessen Hilfe entsprechende Regressionstests gemacht werden können.
Testing als Kernstück der BO-Qualitätssicherung
Ob während einer Migrationsphase oder im laufenden Betrieb, ein BO-System sollte einwandfrei funktionieren, stabil laufen und frei von Fehlern sein. D.h. es sollten, wenn möglich, alle Funktionen und verarbeiteten Daten «qualitätsgesichert» also getestet sein. Das Thema «Testing» ist keine Floskel der Neuzeit, sondern existiert zum Beispiel im Bereich der Softwareentwicklung schon seit den 50er-Jahren. Im Bereich Datawarehousing und Business Intelligence bekommt das Thema erst sehr langsam Flügel.
Wer gibt schon gerne zu, dass die Qualitätssicherung im BO-Bereich aufgrund von zu geringem Testingaufwand zum Teil auf der Strecke bleibt? Vielen kann man es nicht einmal verübeln, denn oft rechtfertigt der Aufwand den Ertrag nicht. Getestet wird vielfach manuell und eingesetztes Personal verbraucht viel Zeit und Kosten. Testingqualität und Risikoabdeckung sind dabei oft gering und es fehlen unterstützende Technologien.
Spätestens wenn es um fehlerhafte Daten, schlecht oder nicht funktionierende Produktivsysteme und unzufriedene User geht, wird der Testingansatz neu überdacht und das Thema «Testautomatisierung» wird in den Fokus gestellt:
Der Markt für Anbieter von Automatisierungslösungen ist überschaubar und leider ist noch keine ganzheitliche DWH-Testing-Lösung (Backend & Frontend) für BO vorhanden. Verschiedene Anbieter beschreiten jedoch bereits die richtige Richtung und zeigen das Potenzial auf:
- 360Bind von GB&Smith
Mit dieser Lösung können Webintelligence- oder Crystal-Berichte von verschiedenen BO-Systemen oder auch verschiedenen BO-Versionen automatisiert exportiert und 1:1 verglichen werden. Der Vergleich beinhaltet nicht nur die Daten des jeweiligen Berichts, sondern auch die Pixelgenauigkeit von Charts. Die Lösung ist per Lizenzfile einfach im Komplettpaket 360Suite aktivierbar.
- BigEval von Bolt Technology Consulting GmbH
Diese Lösung dient zum automatisierten und zeitgesteuerten Testen von Backend-Systemen (Datenbanken, ETL-Stacks). Der Feature-Umfang des webbasierten Programms kann neben einzelnen Abfrage-Ergebnisse auch Tabellen-Strukturen vergleichen und dient des Weiteren auch zum Vergleich von Abfrage-Performance.
- Tosca Testsuite von Tricentis GmbH
Unter den Testinglösungen ist Tosca mittlerweile ein global player und bedient mit ihrer Dynamik viele verschiedene Technologien. Tosca ist eine ganzheitliche (im Sinne eines Testinglifecycles) Lösung zur automatisierten Betestung verschiedenster Technologien. Obwohl nicht direkt auf BI oder BO-Lösungen ausgerichtet, kann Tosca z.B. automatisiert exportierte Berichte im PDF- oder XLS(X)-Format vergleichen. Auch der pixelgenaue Vergleich von Charts ist möglich. In der Pipeline steht derzeit noch die Integration einer Backend-Testing-Lösung.
Für weitere Informationen und Erfahrungen zum Thema Testautomatisierung im BO-Bereich sowie zu den genannten Lösungen, kontaktieren Sie uns unter contact@it-logix.ch.