Ein­füh­rung

Ein funk­tio­nie­ren­des Change Manage­ment ist der Grund­pfei­ler für Wei­ter­ent­wick­lun­gen am bestehen­den Sys­tem. Dabei ist es wich­tig, Neue­run­gen nicht nur pro­duk­tiv zu set­zen, son­dern diese auch gewis­sen­haft zu prü­fen. Eine Qua­li­täts­si­che­rung (QS) sollte daher mit dem Change Manage­ment immer Hand in Hand ein­her­ge­hen. Dabei müs­sen sowohl die Aus­wir­kung des Chan­ges als auch die bereits bestehen­den Anwen­dun­gen gründ­lich qua­li­täts­ge­si­chert wer­den. Nur so kann sicher­ge­stellt wer­den, dass der Change in einem Bereich nicht gleich­zei­tig zu einem Rück­schritt in einen ande­ren führt.

Schließ­lich soll der End­kunde ein mög­lichst zuver­läs­si­ges Pro­dukt erhal­ten und bestehende Pro­dukte sol­len nicht beschä­digt wer­den. Um hier ein struk­tu­rier­tes Vor­ge­hen zu gewähr­leis­ten, wird im Fol­gen­den ein exem­pla­ri­sches Pro­zess­vor­ge­hen vor­ge­stellt und auf­ge­zeigt, wel­che Tool-Unter­stüt­zung sei­tens MicroStra­tegy besteht.

Change Manage­ment mit MicroStrategy

Die klas­si­sche drei­stu­fige Sys­tem­um­ge­bung mit Ent­wick­lung, Test und Pro­duk­tion gibt die Rei­hen­folge des Change Manage­ments vor. Eine geord­nete Migra­tion sollte grund­sätz­lich von der Ent­wick­lung über die Test- bis zur Pro­duk­ti­ons­um­ge­bung erfol­gen. Dabei erhö­hen Ein­heit­lich­keit und Auto­ma­ti­sie­rung im Pro­zess­vor­ge­hen die Trans­pa­renz und Repro­du­zier­bar­keit. Die Mög­lich­keit einer (optio­na­len) Rück­ab­wick­lung der durch­ge­führ­ten Chan­ges ver­rin­gert das Risiko bei Pro­duk­tiv­set­zun­gen und kann im Fall eines Pro­blems Ner­ven spa­ren. MicroStra­tegy unter­stützt das Vor­ge­hen mit dem Object- und Integrity-Manager.

Object-Mana­ger – Drag & Drop vs. Paketierung

Ände­run­gen las­sen sich inner­halb von MicroStra­tegy mit­hilfe des Objekt-Mana­gers durch­füh­ren. Dabei kön­nen Ände­run­gen an Objek­ten durch Drag & Drop oder durch die Erstel­lung von Pake­ten zwi­schen zwei Umge­bun­gen ver­scho­ben wer­den. Die Mög­lich­keit, Objekte via Drag & Drop zu ver­schie­ben, ist intui­tiv und schnell. Jedoch gefähr­det dies einen ein­heit­li­chen, nach­voll­zieh­ba­ren und trans­pa­ren­ten Change-Pro­zess. Neben­bei müs­sen bei die­ser Art der Migra­tion Quelle- und Ziel­um­ge­bun­gen aktiv sein und wer­den für die Migra­tion gesperrt. Dies ist nicht immer möglich.

Eine ele­gan­tere Mög­lich­keit wird mit der Erstel­lung von soge­nann­ten Objekt-Mana­ger Pake­ten erreicht. Bei die­sem Vor­ge­hen wer­den zu migrie­rende Objekte inner­halb eines Pakets gebün­delt. Diese Pakete spei­chern den aktu­el­len Stand der Objekte und las­sen sich zu einem spä­te­ren Zeit­punkt auf der jewei­li­gen Umge­bung ein­spie­len. Wei­ter­hin kann so sicher­ge­stellt wer­den, dass Pakete, die auf der Pro­duk­ti­ons­um­ge­bung ein­ge­spielt wer­den, zuvor genauso auf der Test­um­ge­bung ein­ge­spielt wur­den. Bei die­ser Art der Migra­tion muss ins­be­son­dere sicher­ge­stellt wer­den, dass Objekte nicht in mul­ti­plen Pake­ten beinhal­tet sind. Sollte dies der Fall sein, muss situa­tiv vor­ge­gan­gen und geprüft wer­den, in wel­cher Rei­hen­folge Pakete ein­ge­spielt werden.

Inte­grity-Mana­ger – Testtypen

Inte­gra­ler Bestand­teil des Change Manage­ments sollte die Qua­li­täts­si­che­rung sein. Zum Tes­ten von MicroStra­tegy Objek­ten wie Reports, Doku­men­ten und Dos­siers und der darin ent­hal­ten Objekte eig­net sich der Inte­grity-Mana­ger. Die­ser kann auf Daten und SQL Dif­fe­ren­zen prü­fen und bie­tet vier Testtypen:

Pro­jekt vs. Projekt

Ver­gleicht zwei Reports unter­schied­li­cher Pro­jekte mit­ein­an­der. Die Pro­jekte müs­sen zum Test­zeit­punkt aktiv sein.

Base­line vs. Projekt

Ver­gleicht einen Report eines Pro­jek­tes gegen eine zuvor erstellte Base­line. Eig­net sich um fest­zu­stel­len, wel­che Ver­än­de­run­gen ein neu ein­ge­spiel­ter Change verursacht.

Base­line vs. Baseline

Ver­gleicht zwei zuvor erstellte Base­lines gegen­ein­an­der. Pro­jekte müss­ten zum Zeit­punkt des Tests nicht aktiv sein. Kann bei Per­for­mance-Tests nütz­lich sein.

Ein­zel­nes Pro­jekt (Base­line)

Erstellt eine Base­line die spä­ter in obi­gen Test­ty­pen ver­wen­det wer­den kann. Dabei wird eine vor­de­fi­nierte Liste von Reports, Doku­men­ten oder Dos­siers getes­tet. So könn­ten z. B. Dif­fe­ren­zen, nach einem Upgrade auf eine neue MicroStra­tegy Ver­sion oder Ände­run­gen der VLDB Ein­stel­lung erkannt werden.

Im Nach­fol­gen­den wird ein Pro­zess vor­ge­stellt, der das Change Manage­ment mit­hilfe von MicroStra­tegy Pake­ten durch­führt. Zur Qua­li­täts­si­che­rung wird der MicroStra­tegy Inte­grity-Mana­ger verwendet.

Pro­zess mit MicroStrategy

Der Ablauf des vor­ge­stell­ten Change Manage­ment Pro­zes­ses erfolgt sequen­zi­ell in zwölf Schrit­ten. Diese Schritte sind in der nach­fol­gen­den Abbil­dung und der daran anschlies­sen­den Tabelle auf­ge­führt. Eine struk­tu­rierte Migra­tion wird durch die Nut­zung fol­gen­der Tools erreicht:

• MicroStra­tegy Deve­lo­per (Ent­wick­lung Objekte),
• MicroStra­tegy Object-Mana­ger (Migra­tion Pakete),
• MicroStra­tegy Inte­grity-Mana­ger (QS Ent­wick­ler) und
• MicroStra­tegy Web (QS Kunde).

0 – Ent­wick­lung neuer Objekte in der MicroStrategy-Entwicklungsumgebung

Die Ent­wick­lung neuer bzw. ver­än­der­ter Objekte erfolgt im MicroStra­tegy-Deve­lo­per. Der Ent­wick­ler erstellt alle Objekte zunächst nach den Ent­wick­lungs­kon­ven­tio­nen. Diese kön­nen bei­spiels­weise kon­krete Namens­kon­ven­tio­nen, ACL-Sicher­heits­ein­stel­lun­gen oder Pfad­an­ga­ben für die Objekte vorgeben.

Nach Abschluss der Ent­wick­lungs­ar­bei­ten wer­den Short­cuts zu allen neuen oder geän­der­ten Objek­ten im Paket­fol­der erstellt. Dafür kann die MicroStra­tegy Ord­ner­struk­tur wie im Screen­shot zu sehen erwei­tert werden.

Die erstell­ten Short­cuts in den Paket­fol­dern wer­den im 3. Schritt für die Erstel­lung des MicroStra­tegy Pakets genutzt.

1 – Durch­füh­rung von Ent­wick­ler­tests in der MicroStrategy-Entwicklungsumgebung

Der Ent­wick­ler prüft, ob alle Objekte gemäss Ent­wick­lungs­richt­li­nien ent­wi­ckelt wurden.

Dar­über hin­aus erfolgt die Prü­fung der Paket­ob­jekte durch die Erstel­lung von Unit-Tests. Dies kann z. B. durch Reports erfol­gen, die Bestand­teil des Pakets wer­den. Die Reports beinhal­ten alle neuen Attri­bute und Metri­ken des Pakets. So kann die Lauf­fä­hig­keit der neuen Objekte geprüft werden.

2 – Erstel­lung eines Pake­tes in der MicroStrategy-Entwicklungsumgebung

Mit dem MiroStra­tegy Object-Mana­ger wird ein Paket erzeugt, das alle im 1. Schritt spe­zi­fi­zier­ten Objekte ent­hält. Dabei wer­den die Short­cuts im Paket­fol­der genutzt. So ist jeder­zeit Repro­du­zier­bar­keit und Trans­pa­renz gewähr­leis­tet. Das Paket sollte an einem zen­tra­len Ort, z. B. einem Netz­werk­lauf­werk gesi­chert werden.

3 – Erstel­lung einer Base­lines für Inte­gra­ti­ons­tests in der MicroStrategy-Testumgebung

Vor dem Ein­spie­len des neue Pakets auf der Test­um­ge­bung, wird dort eine Base­line erstellt. Somit hält man den Stand vor dem Ein­spie­len des Pakets fest. Die Erstel­lung der Base­line erfolgt mit dem Inte­grity-Mana­ger. Dort wird der Test­typ «Ein­zel­nes Pro­jekt (Base­line)» ver­wen­det. Der Umfang des Test-Sets sollte zuvor defi­niert werden.

4 – Migra­tion des Pake­tes in die MicroStrategy-Testumgebung

Zur Migra­tion auf die Test-Umge­bung wird der MicroStra­tegy Object-Mana­ger genutzt. Bei der Migra­tion emp­fiehlt sich, ein soge­nann­tes Undo-Paket zu erzeu­gen. Dies kann genutzt wer­den, um den Ursprungs­zu­stand wie­der her­stel­len. Durch Ein­spie­len des Undo-Pakets erhält man den Zustand vor der Migra­tion des Pakets.

5 – Durch­füh­rung eines Inte­gra­ti­ons­tests in der Microstrategy-Testumgebung

Nach erfolg­rei­chem Ein­spie­len des Pakets erfolgt eine Kon­trolle der neuen Objekte. Dazu wer­den sowohl der im 2. Schritt und 5. Schritt ange­legte Unit-Test bzw. Base­line genutzt. Der Inte­gra­ti­ons­tests auf der Test­um­ge­bung erfolgt durch auto­ma­ti­sierte Prü­fung des Ein­flus­ses der im Release ent­hal­te­nen Objekte. Hierzu stellt der im Paket ent­hal­tene Unit-Test die Funk­ti­ons­weise der neuen Objekte sicher. Mit­hilfe des Inte­grity-Mana­gers wird die im 5. Schritt ange­leg­ten Base­line (vor Ein­spie­len des Pakets) mit dem neuen Stand (nach Ein­spie­len des Pakets) gegen­über gestellt. Dazu wird ein Regres­si­ons­test vom Typ Base­line vs. Pro­jekt durchgeführt.

6 – Erstel­lung von Base­line, die den Zustand der MicroStra­tegy-Test­um­ge­bung nach Migra­tion des Pake­tes wiederspiegelt

Oft­mals bestehen neben der Qua­li­täts­si­che­rung im Rah­men des Change Manage­ments wei­tere auto­ma­ti­sierte Test. Diese kön­nen z. B. regel­mä­ßige Per­for­mance-Tests oder monat­li­che Tests zur Sicher­stel­lung der Daten­qua­li­tät sein. Wird die in Schritt 3 ange­legte Base­line ander­orts ver­wen­det, emp­fiehlt sich eine Aktua­li­sie­rung der Base­line nach dem Ein­spie­len des Pakets.

7 – Durch­füh­rung der Vor­ab­nahme in der MicroStrategy-Testumgebung

Die Vor­ab­nahme in der MicroStra­tegy-Test­um­ge­bung erfolgt durch manu­elle Prü­fung der im Paket ent­hal­te­nen Objekte in der MicroStra­tegy-Test­um­ge­bung. Geprüft wer­den die Funk­tio­na­li­tät, die Über­set­zun­gen, die ACL etc. Die Prü­fung erfolgt durch die im Change Manage­ment fest­ge­legte Person.

Schritte 8 – 12

Die Schritte 7 – 12 wer­den auf der Pro­duk­ti­ons­um­ge­bung,  ana­log der Schritt 3 – 7 durchgeführt.

Fazit

Im Blog­ein­trag wurde auf die unter­schied­li­che Tool-Unter­stüt­zung sei­tens MicroStra­tegy beim Change Manage­ment ein­ge­gan­gen. Ins­be­son­dere das Pake­tie­ren mit dem Object-Mana­ger und die ver­schie­de­nen Test­ty­pen des Inte­grity-Mana­gers erwei­sen sich als wich­tige Tools. Neben dem kor­rek­ten Ein­satz der Tools ist ein abge­stimm­ter Change Manage­ment Pro­zess essen­zi­ell. Ein ver­nünf­ti­ger auf­ge­setz­ter Pro­zess ist nicht tri­vial, doch wirkt sich nach­hal­tig auf die Qua­li­tät der pro­duk­tiv gesetz­ten Ände­run­gen aus.

Wei­ter­hin emp­fiehlt sich die Ver­wen­dung von Stan­dards bei Benen­nung und Spei­che­rung der Objekte wie Paket­da­teien, Logs und Test­de­fi­ni­tio­nen. Die Nut­zung von vor­de­fi­nier­ten Tem­pla­tes erhöht die Ein­heit­lich­keit und die Mög­lich­keit, Teil­schritte wie das Test­ing zu auto­ma­ti­sie­ren, führt zu Zeit­er­spar­nis­sen beim Change Management.

Saracus ver­fügt über lang­jäh­rige Erfah­rung im Change Manage­ment und unter­stützt Kun­den aus unter­schied­lichs­ten Bran­chen bei MicroStra­tegy Change Manage­ment Pro­zess. Dank einer umfas­sen­den Rol­len- und Pri­vi­le­gi­en­ver­wal­tung in MicroStra­tegy kön­nen spe­zi­elle Kun­den Sicher­heits­be­dürf­nisse bei der Migra­tion in der Regel berück­sich­tigt werden.