Iteratives Lifecycle Management für BO-Systeme: Unmöglichkeit oder Notwendigkeit? [A2] Raphael Branger Uetliberg,

Transkript

1 : Unmöglichkeit oder Notwendigkeit? [A2] Raphael Branger Uetliberg,

2 Responding to change over following a plan. (4. Grundatz des Agile Manifesto; AGENDA Einleitung Iteratives vs. reguläres Projektvorgehen Fallbeispiel: Migration auf BO 4.1 Fazit Slide 2

3 EINLEITUNG

4 REGELMÄSSIGER SERVICE FÜR IHR BO-AUTO Sie bringen Ihr Auto auch regelmässig in den Service, oder? Genau so muss auch ein BusinessObjects- System regelmässig aktualisiert werden. Dadurch erreichen Sie drei Dinge: Patch-Support durch den Hersteller sicherstellen, damit bei Bedarf Software-Bugs rasch behoben werden können. Kompatibilität zu abhängigen Systemen und Komponenten sicherstellen (z.b. Betriebssystem-Version, Datenbankserver-Version, Java-Version etc.), um einen reibungslosen Betrieb für alle Nutzerkreise zu gewährleisten. Abdecken neuer Fachanforderungen. Bild-Quelle: Slide 4

5 SYSTEM ENGINEERING LIFECYCLE MANAGEMENT IM BIG PICTURE Architektur / Sizing / Verfügbarkeit / SLA Operations Monitoring Issue and Problem Management Deployment Backupkonzept Disaster Recovery Plan Clientinstallationen (Citrix) Serverinstallationen Setup Berechtigungskonzept Active Directory Authentication (SSO) Delegated Administration Zugriffsrollen Content-Plan (Ordnerstruktur) Lifecycle Management (Entwicklung / Test / Produktion) Reports / Universen Funktionale Rollen Konfiguration Sicherheitskonzept Funktionsanforderungen Systeme (z.b. neue Updates) Gegenseitige Abhängigkeit Slide 5

6 BEGRIFFSDEFINITION Der Begriff System Engineering Lifecycle Management umfasst u.a. folgende Arbeiten: Aktuell-Halten der BO-Server-Software Aktuell-Halten der BO-Client-Tools Aktuell-Halten der 360-Produkte Aktuell-Halten der Datenbank-Middleware Anpassen der bestehenden Konfigurationen an neue Anforderungen (z.b. aus den Bereichen Sicherheit) Slide 6

7 Mindestens vier Faktoren führen zu langen Durchlaufzeiten von Upgrade-Vorhaben. UPGRADES EINSPIELEN IST EIN HÜRDENLAUF. Vielzahl an Stakeholdern und Umsystemen Verzögerungen durch Abklärung und Test der Kompatibilität zu Umsystemen(z.B. neue Java- Version) bzw. der Auswirkungen auf Umsysteme Keine Verfügbarkeit oder mangelnde zeitliche Ressourcen von Fach-Usern / Stakeholdern BO Client Tools welche mit neuen Patches kompatibel sein müssen Installation und allenfalls Paketierung sind oft ein langwieriger Prozess. Vielzahl an Berichten, die mit ihrer Komplexität die Kapazität von BO am Limit ausreizen Hohe Testingaufwände von Entwicklern (stimmt der Bericht technisch?) und Fachbenutzern (stimmen die Daten?) Technische Hürden (z.b. durch CPU-Limit) die z.b. das Report- Testing verzögern Auftretende Bugs in BO und anderen Softwarekomponenten selbst Verzögerung durch Fehleranalyse (Server? Plattform? Tomcat? Umsysteme? Patch?) Verzögerung durch Wartezeiten auf den nächsten Patch des Herstellers Bild-Quelle: Slide 7

8 Durch die Kombination von langen Durchlaufzeiten beim Einspielen von Upgrades mit der hohen Kadenz neuer Patches und Versionen für BO ergibt sich eine Situation wo Patching nicht ein Einmal-Ereignis ist, sondern ein kontinuierlicher Prozess. NACH DEM UPGRADE IST VOR DEM UPGRADE Bild-Quelle: Major-Release (z.b.4.x) Minor-Release (z.b. 4.1) Support Package (z.b. 4.1 SP2) Patch (z.b. 4.1 SP2 Patch 1) ca. alle drei - vier Jahre ca. alle ein - zwei Jahre ca. alle sechs Monate alle vier bis sechs Wochen Auf Ebene Major/Minor-Release gilt es den Maintenance-Zyklus zu beachten: BO XI 3.1 BO 4.1 bis Ende 2015 unterstützt. bis Ende 2016 unterstützt. Patch-Support gilt bei der SAP immer für das aktuelle Support Package sowie eins davor. Für alle Packages davor werden keine neuen Patches mehr geliefert! Slide 8

9 IST EIN UPGRADE-VORHABEN ZEITLICH PLANBAR? Fallbeispiel: Entscheid, anfangs 2013 auf XI 3.1 SP6 zu aktualisieren Mitte Mai: Feststellung, dass die Funktion IsNull in Webi nicht mehr korrekt funktioniert. Mitte August: Wir können SAP beweisen, it s a bug, not a feature Dezember: ein Fixpack löst das Problem Man kann grundsätzlich Erfahrungswerte für die zeitliche Planung hinzuziehen, jedoch bleiben es Schätzungen und keine präzisen Vorhersagen. Wie kann man mit dieser Unsicherheit sinnvoll umgehen? Slide 9

10 ITERATIVES VS. REGULÄRES PROJEKTVORGEHEN

11 SO TUN ALS OB ES EINE PLANUNGSSICHERHEIT GIBT Grundlage für dieses Vorgehen ist, dass man auf Basis einer abgeschlossenen Anforderungsanalyse einen Umsetzungsplan erstellt und diesen dann nach und nach umsetzt: Man ignoriert, dass der Verlauf der Arbeiten und damit die Schätzung von Aufwänden und einer Timeline de facto nicht absehbar ist. Kostendach und Zeitplan basieren einzig und allein auf Grund von Erfahrungswerten und Annahmen und müssen höchstwahrscheinlich laufend revidiert werden. (Schein-) Vorteile: Bild-Quelle: Collier 2012; Addison-Wesley Man kann dem Management eine (Schein-) Sicherheit vorgaukeln hinsichtlich Planung und Kosten. Der Auftraggeber muss sich nur zu Beginn des Projekts sowie am Schluss bei der Abnahme ins Projekt einbringen. Ansonsten braucht er sich nicht darum zu kümmern Slide 11

12 SO TUN ALS OB ES EINE PLANUNGSSICHERHEIT GIBT Nachteile: Entweder man kommuniziert dem Management laufend die auftretenden Verzögerungen oder häufiger es wird kaum oder intransparent kommuniziert, weil jede Verzögerung tendenziell als Versagen des Projektteams gewertet wird. Verändern sich die Rahmenbedingungen (und damit u.a. die Aufwände), müssen vor allem im Hinblick auf externe Auftragnehmer die Verträge angepasst werden. Gleichzeitig muss in einem aufwändigen Change-Management-Verfahren laufend entschieden werden, ob ein neuer, zusätzlicher Aufwand zu lasten des Auftraggebers oder Auftragnehmers geht. Anstatt die volle Energie auf die Problemlösung zu investieren, fliesst ein nicht unwesentlicher Anteil in Save my Ass Aktivitäten. Bild-Quelle: Slide 12

13 AKZEPTIEREN, DASS ES NUR EINE BEDINGTE PLANUNGSSICHERHEIT GIBT Eine mögliche Alternative zum vorher skizzierten Plan-Do-Verfahren ist das Envision-Explore- Verfahren. Dieses besteht im Wesentlichen auf zwei Kreisläufen: Dem Envision Cycle und dem Explore-Cycle. Diese beeinflussen sich wechselseitig. Was ist die Zielsetzung des nächsten Releases? Was ist im Scope, wo liegen die Grenzen? Inwiefern betrifft das Projekt die Fachbereiche? Welche Stakeholder / Personen müssen in das Projekt miteinbezogen werden? Wie sieht die Entwicklungs- und Releasestrategie der Softwarehersteller aus? Planung der nächsten Iteration Bild-Quelle: Collier 2012; Addison-Wesley Umsetzung der priorisierten Arbeitspakete in Form von explorativem / experimentellem Herantasten an die im Envision Cycle formulierten Ziele Review / Rework der Grobplanung aus dem Envision Cycle Slide 13

14 TIMEBOXING Der Explore-Cycle basiert auf dem Timeboxing-Verfahren. Dabei werden die Aspekte Kosten und Zeit fixiert, variabel bleiben die in der fixierten Zeit gelieferten Features. Bild-Quelle: Collier 2012; Addison-Wesley Wenn Anforderungen, Kosten und der Terminplan de facto fixiert werden, kommt es zwangsläufig zu Spannungen. Der agile Ansatz fixiert in erster Linie Zeit und Kosten (in Form einer bestimmten Anzahl Personentage pro Iteration) und lässt es offen, welche Features pro Iteration geliefert werden können. Es ist offensichtlich, dass dieser Ansatz viel stärker auf Vertrauen zwischen Auftraggeber und Auftragnehmer beruht, als die traditionelle Vorgehensweise Slide 14

15 VORGEHEN IM EXPLORE-CYCLE Zu Beginn jeder Phase (Periode und Iteration können synonym dazu verwendet werden) wird im Team zusammen mit den Stakeholdern bestimmt, welche Ziele erreicht werden sollen / können mit Bezug zu der verfügbaren Kapazität. Am Ende der Phase gibt es ein Debriefing, wo analysiert wird, was erreicht wurde und was nicht (und allenfalls warum nicht; dies im Hinblick auf die nächste Periode). Die Periodenlänge muss so gewählt werden, dass sie greifbar bzw. überblickbar bleibt, d.h. im Falle von System Engineering Arbeiten empfehlen wir eine Länge von vier Wochen. Alles was darüber hinausgeht, birgt bereits wieder zu viele Unsicherheiten in sich. Gemeinsame Zielbestimmung Debriefing vergangene Phase Zielbestimmung nächste Phase Slide 16

16 BEWERTUNG DES EXPLORE-CYCLES Vorteile Es wird sichergestellt, dass nach jeder Periode konkrete Outputs bereitstehen, welche im Kontext des Envision-Cycles auf ein übergeordnetes Ziel hin Sinn machen. Das Management wird transparent über den Fortschritt der Arbeiten informiert und kann auf Basis jeder neuen Periode Einfluss hinsichtlich Priorisierung nehmen. Stabile Kosten: Der Vorteil eines Timeboxing-Verfahrens sind stabile Kosten. Es werden keine Schein-Termine kommuniziert, sondern höchstens Erwartungswerte. Kritische Beurteilung dieses Vorgehens: Dieses Vorgehen ist für viele Management-Stakeholder gewöhnungsbedürftig, da man auf den ersten Blick das Gefühl hat, man gebe Geld aus ohne dem Auftragnehmer (intern oder extern) ein klares Ziel vorzugeben. Im Envision-Cycle werden mittel-bis langfristige Ziele formuliert. Im Explore-Cycle werden pro Iteration überprüfbare, kurzfristige Ziele vereinbart. Es mag der Eindruck entstehen, dass man auch gegenüber weiteren Involvierten (z.b. Serverbetrieb) keinen Termindruck aufbauen könne, weil es ja keine grosse Deadline gibt, Das Gegenteil ist der Fall. Mit jeder Periode gibt es eine Deadline, welche greifbar ist, nämlich alle vier Wochen Slide 17

17 Im Zentrum stehen die Product Owners. Diese entscheiden in Rücksprache mit ihren Ansprechpartnern der verschiedenen Stakeholder über die jeweiligen Priorisierungen für die nächste Periode. ORGANISATION BO Applikations -betrieb Plattform-Aufbau & -konfiguration Inhaltsmigration & Testing Fachbereich A Serverbetrieb DB-Team Projektleiter / Koordinator BICC Fachbereich B Portal- Integration Technical Product Owner Business Product Owner Fachbereich C Slide 18

18 Ein iterativer Ansatz erfordert kontinuierliches Regression-Testing. Dies lässt sich mit den Mitteln von BO, der 360-suite und / oder Tosca Testsuite erreichen. AUTOMATISIERTES TESTING Variante Tosca Testsuite Variante 360bind BusinessObjects System 1 (Referenz) BusinessObjects System 2 (Vergleich) BusinessObjects System 1 (Referenz) BusinessObjects System 2 (Vergleich) 360cast 360cast 360bind Tosca Testsuite File Compare Test Case Design Test Management & Reporting File Compare Slide 19

19 Mittels Tosca können z.b. Test Case Templates definiert werden. In einem POC haben wir bei IT-Logix erfolgreich einen XLS(X) und PDF-Vergleich implementiert. TEST CASE DESIGN MIT TOSCA Slide 20

20 Beim PDF-Vergleich gibt es sowohl einen Textbasierten Vergleich als auch einen Bildvergleich einzelner Graphiken (z.b. Diagramme). BEISPIEL-RESULTATE PDF-VERGLEICH Slide 21

21 360BIND Das Produkt ist aktuell im Entwurfsstadium und soll komplett webbasiert sein (und damit integriert in die 360View-Oberfläche). Die Entwicklung erfolgt im Q4/2014 und steht anfangs 2015 in einer ersten Version zur Verfügung. Wer bereits heute eine Vorschau sehen möchte: Heute Abend ab 18:30: Exklusive Präsentation von Neuigkeiten rund um die bestehenden und neuen 360-Produkte. Mit Léonard Barnoux, Product Manager bei GB & Smith Raum: Passio Remote-Präsentationstermin: Jederzeit auf Anfrage Slide 22

22 FALLBEISPIEL: MIGRATION AUF BO 4.1

23 Bei unserem Kunden ASTRA sind wir aktuell mitten imaufbau der BO4.1 Umgebung. Die Rollen Projektleiter, Technical & Business Product Owner werden durch einen Mitarbeiter in Personalunion wahrgenommen. AUSGANGSLAGE BO: IT-Logix Serverbetrieb: BIT Plattform-Aufbau & -konfiguration Coach Inhaltsmigration & Testing Projektleiter / Koordinator VU, ETC, MOFIS, ADAMS VMON DB-Team: BIT Portal- Integration: EJDP Technical Product Owner ASTRA DWH Team Business Product Owner TDcost VUGIS Slide 24

24 RAHMENBEDINGUNGEN & ZIELE Migration auf BO 4.1 mit neuen Servern Abstellen der XI 3.1 Systeme bis spätestens Ende 2015 Phasenlänge 4 Wochen Aufwand auf Seiten BO / IT-Logix maximal 8 Tage pro Monat Keine garantierte Ressourcen-Zusage auf Seiten BIT Slide 25

25 Die Planung des BO4.1 Upgrades erfolgt in monatlichen Phasen. Parallel dazu wurde im ersten halben Jahr auch noch der Upgrade auf XI 3.1 SP6.3 abgeschlossen. WAS BISHER GESCHAH Q1 / 2014 Skizzierung iteratives Vorgehen Grob-planung Kick-Off Definition Iteration April April Installation Pilotumgebung geplant Mai Installation Pilotumgebung 4.1 SP3 Patch 1 Juni Funktionstests (ohne Inhalte) Konfiguration Pilotumgebung Backup & Audit sicherstellen AD-Integration mit SSO Juli Erste Tests mit Fachbereichen Test & Konfiguration LiveOffice August Besprechungen mit Fachbereichsverantwortlichen Upgrade Pilotumgebung auf 4.1 SP4 Patch 2 September Portal-Integration Fachtests Installation der restlichen drei BO-Umgebungen. Oktober Erstellen Betriebsbereitschaft Erste Fachbereiche gehen live 2015 Fachbereich für Fachbereich wird migriert Spätestens Ende 2015 soll XI 3.1 abgestellt werden können Nach dem Upgrade ist vor dem Upgrade 4.1 nur bis Ende 2016 supported Slide 26

26 Sämtliche Aufgaben werden in dem Product Backlog erfasst und initial sachlogisch priorisiert. DAS PRODUCT BACKLOG DER MIGRATION (1/2) Slide 27

27 Je Aufgabe wird der erwartete Output definiert und eine initiale Aufwandschätzung gemacht. Die Zuweisung der Aufgaben zu einer konkreten Phase erfolgt im Phasenmeeting in Rücksprache mit allen relevanten Stakeholdern. DAS PRODUCT BACKLOG DER MIGRATION (2/2) Slide 28

28 PHASENMEETING Vor / Nach jeder Phase wird ein Phasenmeeting mit dem Kernteam durchgeführt. Das Kernteam besteht aus folgenden Personen: Traktanden: Product Owner / Koordinator (& sein Coach) ASTRA DWH Leiter Serveradministrator (BIT) Debriefing letzte Phase Planung nächste Phase Tracken der Aufgaben via Change Mgt. Tool Slide 29

29 FAZIT

30 RESPONDING TO CHANGE OVER FOLLOWING A PLAN! Vieles ist unvorhersehbar - Change ist Realität; besser man stellt sich darauf ein. Iteratives Lifecycle Management funktioniert. Aber: Eine iterative Planung braucht mindestens so viel Disziplin wie ein sequentielles Vorgehen. Alle müssen am gleichen Strick ziehen herausfordernd sind virtuelle Teams, weil die Ressourcenallokation durch unterschiedliche Stellen verfügt wird. Dem Management / Sponsor muss aufgezeigt werden, dass ein BO-System ab einer bestimmten Grössenordnung kontinuierliche Wartung benötigt und daher als kontinuierlicher Prozess und nicht auf Projektbasis organisiert werden muss. In diesem Sinne: Nach dem Upgrade ist vor dem Upgrade Slide 31

31 Lernen auch Sie systematisch mit der Dynamik einer BO-Plattform umzugehen. Bitte beachten Sie die Thementische während dem Mittagessen! Raphael Branger Senior Solution Architect / Chief Knowledge Officer rbranger@it-logix.ch Follow Blog: