End of Life – Eine Applikation wird abgelöst

Es gibt weitere Phasen im Leben einer Applikation, welche vom aktuellen Entwurf des Application Lifecycle Managements nicht beachtet werden, da sie für das eigentliche Produkt nicht relevant sind. Dennoch sollten sie in einem ganzheitlichen Ansatz beachtet werden. Es geht um die Stilllegung der Applikation.

Jede Applikation wird früher oder später abgeschaltet werden. Sei es, weil sich die Anforderungen des Kunden verändert haben oder weil das zugrundeliegende Framework nicht mehr gewartet wird. Als Berater sollten wir auch diese Phase im Auge behalten, da sie auch vom Kunden oft übersehen wird und dennoch einen enormen Mehrwert bieten kann.

Natürlich könnten wir jetzt sagen, was haben wir damit zu tun? Wenn die Applikation nicht mehr gepflegt werden kann, dann haben wir auch keinen Auftrag mehr. So zuletzt oft gesehen mit IBM und Lotus Notes. Die bestehende Software wird abgeschaltet und durch eine komplett neue Technologie mit neuen Beratungsunternehmen ausgetauscht. Doch das muss nicht sein. Was wäre zum Beispiel, wenn wir eine Farmsolution aus SharePoint 2010 künftig in die O365-Cloud transferieren sollen? Und zwar nicht einfach 1:1, sondern angepasst auf den aktuellen Stand der Technik. Mit neuen Social Features und Gruppenräumen? Nun, in diesem Fall wäre es sicherlich gut, wenn wir möglichst einfach die Geschäftsdaten transferieren könnten.

Auf die Einstellung kommt es an!

Oftmals wird ein Migrationsprojekt verharmlost und nur selten dem ALM-Prozess unterworfen. Schließlich handelt es ich nur um eine Einmalaktion und muss nicht ständig gewartet und verbessert werden. Es handelt sich also um ein schnelles Projekt ohne besondere Herausforderungen an die Qualität und Wartbarkeit. In der Regel ist jedoch das Gegenteil der Fall! Eine Migration sieht sich mit Daten aus dem kompletten Lebenszyklus der Applikation konfrontiert. Je nachdem wie gut die Applikation gewartet wurde, kann es also durchaus Daten geben, die nur zu einem bestimmten Zeitpunkt gültig waren und nun gar nicht mehr in die aktuelle Informationsarchitektur passen oder neu aufbereitet werden müssen. Dem Projektteam sollte dieser Umstand klar sein und im Idealfall sollten möglichst viele Beteiligte des Lebenszyklus der Applikation konsultiert werden, um auf derartige Fallen vorbereitet zu sein. Natürlich ist auch an dieser Stelle eine saubere Dokumentation Gold wert, da viele Dokumente erst zu diesem späten Stadium wieder wirklich relevant werden.

Vorarbeiten im ALM-Prozess

Damit es möglich ist, eine Applikation möglichst problemlos abzuschalten, muss die Gesamt- und insbesondere die Informationsarchitektur der Lösung gut durchdacht und – auch hier wieder – dokumentiert werden. Dies ist besonders wichtig, da die Verantwortlichen der Lösung bei Abschaltung gegebenenfalls nicht mehr bei der Firma oder für diese Applikation arbeiten und ihr Wissen nach dem Abschluss des Projektes unter Umständen auch nicht weitergegeben wurde. Aus diesem Grund ist es essentiell Dokumente zu haben, aus denen ersichtlich wird, wie die Daten in Verbindung stehen, wo sie abgelegt sind und wie diese möglichst einfach herausgezogen werden können.

Im Idealfall gibt es bereits Schnittstellen um diese Daten abzugreifen oder sie werden im Rahmen der Applikationsentwicklung eingerichtet. Solche Schnittstellen sind nicht nur für das Ende der Applikation hilfreich, sondern helfen auch dabei das Programm in die Systemlandschaft zu integrieren und Informationen in anderen Applikationen zu verwenden. SharePoint bietet diese Schnittstellen bereits out of the box. Wichtig ist nur, dass auch die neu hinzugefügten Applikationen und ihre Datenhaltung diese Schnittstellen nutzen können oder neue implementiert und dokumentiert werden.

Die Transfervorbereitung

In der Transferphase geht es hauptsächlich um einen Aspekt, der dieser auch den Namen gibt. Wie bekomme ich die bestehenden Geschäftsdaten am besten aus meiner Alt-Applikation, um die Applikation verlustfrei abschalten zu können?

Hier kommen meist Third Party Migrationstools zum Einsatz, welche die Daten aus einer Applikation herausholen und in eine andere hineinschieben können. Der Architekt der Alt-Applikation sollte, wie oben erwähnt, bereits in der Konzeptionsphase des ALM darauf achten, dass dieser Weg möglichst einfach ist. Für SharePoint gibt es bereits gute Migrationstools. Im Idealfall setzt auch die Applikation auf dem SharePoint Standard auf oder stellt geeignete Schnittstellen für die Datenmigration bereit.

Ziel ist es demnach, dass in der Transferphase alle Vorbereitungen getroffen werden, um die Daten aus dem Altsystem in das neue System überführen zu können. Zu den Liefergegenständen dieser Phase gehören Vorgehensbeschreibungen, Migrationsskripte und -tools und Rollback-Szenarien. Beteiligt sind an dieser Phase meistens das alte und das neue Operations-Team sowie die alte und neue Wartungsmannschaft der Zulieferer. Im Idealfall sind auch die Architekten beider Lösungen noch greifbar. Erforderlich sind meist auch der Architekt und die Entwicklungsmannschaft der neuen Lösung. Diese Phase sollte, wie aus dem ALM gewohnt, auch den Dokumentations- und Qualitätsrichtlinien entsprechen.

Die Stilllegung und das neue Go Live

Die Stilllegungsphase ist der kritische Teil einer Migration. Hier wird das alte System ab- und das neue System live geschaltet. Wie genau findet dieser Prozess nun statt und wie kommen die Daten nun wirklich in das System?

Wichtig ist zu beachten, dass die meisten Applikationen eine gewisse Kritikalität für den Kunden haben und daher die Übergangsphase möglichst reibungslos ablaufen muss. Dafür gibt es zwei Ansätze. Der erste ist die Abschaltung des Altsystems, der Transfer der Daten und die Anschaltung des neuen Systems. Meistens ist jedoch die Transferzeit zu lang, sodass es eine Zeitspanne gibt, in der ein Parallelbetrieb beider Applikationen stattfindet. In diesem Fall gibt es meist auch nicht nur einen einzelnen Datentransfer, sondern die Daten werden mehrfach vom Altsystem in das Neusystem repliziert. Dabei muss besonders darauf geachtet werden, dass es zu jedem Zeitpunkt nur einen Single Point of Truth gibt – also neue Daten immer nur in einem System erfasst werden können.

Die Migration findet nun nach den vorher definierten Prozessen statt. Obwohl dieser Teil sehr wichtig für den Erfolg ist, gibt es dazu wenig zu erklären. Sämtliche Prozesse wurden im Vorfeld bereits definiert und werden nun abgehandelt. Wichtig ist nur, dass alle aufgetretenen Probleme und spontanen Änderungen ebenfalls sauber dokumentiert und festgehalten werden, sodass die Migrationsprozesse sauber nachvollzogen werden können.

Am Ende der Phase gibt es zwei mögliche Zustände. Entweder die Migration ist erfolgreich durchgelaufen und es gibt nun ein neues System. In diesem Fall greift wieder der normale ALM Prozess und das Team der neuen Applikation kann in die Betriebs- und Optimierungsphase übergehen. Oder die Migration ist fehlgeschlagen und es muss das Rollback-Szenario ausgeführt werden, sodass das Altsystem weiterhin das führende System ist. In diesem Fall muss erneut in die Transferphase übergegangen werden und die aufgetretenen Fehler müssen analysiert, dokumentiert und beseitigt werden.

Erfahren Sie mehr

novaCapta auf der Fachtagung für Interne Revision
Event
Event

novaCapta auf der Fachtagung für Interne Revision

Das Expertenteam der novaCapta präsentiert am 15. und 16. November ihre innovative Audit Management Lösung auf dem DIIR-Kongress in Dresden. Besuchen Sie unsere...

Jan
25
Webcast mit Microsoft: Fit für die digitale Arbeitswelt
Webinar
Webinar

Webcast mit Microsoft: Fit für die digitale Arbeitswelt

Die digitale Transformation und die Veränderung der Arbeitswelt ist längst in vielen Unternehmen und in den öffentlichen Einrichtungen angekommen. Dennoch stell...

Valo ist neuer Partner der novaCapta für Intranets
News
News

Valo ist neuer Partner der novaCapta für Intranets

Durch die Partnerschaft mit Valo, dem Ready-2-Go Intranet-Baukasten aus Finnland baut die novaCapta ihr Angebot bei der Umsetzung von schnellen und funktionalen...

SharePoint Framework Client-Side Webparts mit React
Blog
Blog

SharePoint Framework Client-Side Webparts mit React

React ist ein Framework zur Erstellen von Benutzeroberflächen. In der SharePoint Online Entwicklung bietet es sich für die Entwicklung von Client-Side Webparts...

Sliding to heaven – A short story of a SPFx Slider Webpart
Blog
Blog

Sliding to heaven – A short story of a SPFx Slider Webpart

SharePoint Framework, kurz SPFx, ist eine zukunftsträchtige Technologie zur Erstellung von Webparts oder Extensions auf der Basis von TypeScript.

Bundesliga-Tippspiel

Bundesliga-Tippspiel

Fußball ist in Ihrem Unternehmen jeden Montag Gesprächsthema Nummer eins? Dann holen Sie sich die Fußball Bundesliga in Ihr Intranet!

novaBirthday

novaBirthday

novaBirthday erweitert Ihr SharePoint-Intranet um ein soziales Feature und kann damit die Akzeptanz und Reichweite verbessern.

PayPal-Zahlung in einer MVC Anwendung
Blog
Blog

PayPal-Zahlung in einer MVC Anwendung

In diesem Blogbeitrag möchte ich demonstrieren, wie eine Einbindung von PayPal in eine MVC Applikation funktioniert.

Ich bin im Flow! – Eine Übersicht zu Microsoft Flow
Blog
Blog

Ich bin im Flow! – Eine Übersicht zu Microsoft Flow

Die Power Platform wird aktuell von Microsoft sehr stark gepusht. Zeit, sich mit dem Potenzial der einzelnen Komponenten zu beschäftigen. Heute: Flow.

DevOps und Container
Blog
Blog

DevOps und Container

DevOps an sich ist nicht an eine Technologie gebunden, jedoch haben sich Container-Technologien und DevOps als Verwandte im Geiste gefunden.

SharePoint Hosted Add-in mit AngularJS 2
Blog
Blog

SharePoint Hosted Add-in mit AngularJS 2

Voraussetzungen und Umsetzung eines SharePoint Hosted Add-in mit AngularJS 2.

PowerApps – Neuigkeiten, Übersicht, Tipps & Tricks
Blog
Blog

PowerApps – Neuigkeiten, Übersicht, Tipps & Tricks

Neues aus der Welt von PowerApps