Wenn der TM1-Modellordner verschwindet
Migration und Deployments nach Planning Analytics as a Service (PAaaS) und Planning Analytics Local 3.1: Was sich verändert hat und wie man damit umgeht
Viele TM1- und Planning-Analytics-Teams kennen den klassischen Weg: Die Instanz läuft on-premise, das Modell liegt im Dateisystem, und im Ernstfall weiß man, wo man ansetzen muss. Für Migrationen zwischen Servern, Dev/Test/Prod-Promotions oder die Wiederherstellung einzelner Modellzustände hat man direkt im Modellordner gearbeitet. Nicht immer elegant, aber greifbar und verlässlich.
Mit der neuen Planning Analytics Engine (TM1 v12), entweder als PAaaS oder als on-premise Installation, hat sich dieses Betriebsmodell grundlegend verändert. Der direkte Zugriff auf das Dateisystem und damit auf den bekannten TM1-Modellordner entfällt. IBM und der Hyperscaler übernehmen Betrieb, Infrastruktur und Plattformverantwortung, was aus Managed-Services-Sicht durchaus sinnvoll ist, wirft für PA TM1 Administratoren und Implementierungspartner aber eine sehr konkrete Frage auf:
Wie migriert man ein Planning-Analytics-Modell vollständig, kontrolliert und nachvollziehbar, wenn man keinen direkten Zugriff auf die Modelldateien hat?
Genau diese Lücke schließen wir bei BIConcepts mit einem leichtgewichtigen, API-basiertes Migrationstool: TurboMigrator für IBM Planning Analytics TM1.
SaaS löst Infrastrukturprobleme, aber verändert Migration
Der Wechsel in die Cloud nimmt vielen Unternehmen operative Arbeit ab. Serverbetrieb, Plattformwartung und Infrastrukturthemen rücken in den Hintergrund. Was dabei oft unterschätzt wird: Gleichzeitig verschwinden vertraute Administrationswege.
On-premise war PA TM1 Migration häufig ein Datei-Thema: Instanzen kopieren, Verzeichnisse sichern, Modelle zwischen Servern bewegen, bei Bedarf manuell eingreifen. Bei PA 3.1 Umgebungen ist dieser Weg schlicht nicht mehr verfügbar. PA TM1 Modelle leben hinter Service-Grenzen und werden ausschließlich über unterstützte Schnittstellen angesprochen. Für den laufenden Betrieb ist das kein Problem. Für Migrationen, parallele Umgebungen, kontrollierte Modellübertragungen oder Exit-Szenarien wird das aber deutlich anspruchsvoller.
Was ist mit der Git-Integration in PAW?
IBM hat eine Git-Repository-Anbindung in Planning Analytics Workspace (PAW) integriert. Das ist ein wichtiger Schritt und für bestimmte Szenarien durchaus nützlich. Wer allerdings aus der Softwareentwicklung kommt und Git kennt, stellt schnell fest, dass die PAW-Git-Integration ein anderes Werkzeug ist.
Branches, Pull Requests, kontrollierte Merges, Diffs, Reviews, reproduzierbare Releases: Das sind die Konzepte, mit denen Entwickler Git assoziieren. Die PAW-Git-Integration funktioniert eher als Transport- und Verwaltungsmechanismus für ausgewählte Planning-Analytics-Objekte. Das ist nicht falsch, aber es ist auch kein vollständiger Ersatz für das, was bei realen Migrationen gebraucht wird.
Sobald komplette Instanzen bewegt werden müssen, inklusive Daten, Security-Objekten, Prozessen, Chores, Cubes, Dimensionen, Views, Subsets und den Abhängigkeiten dazwischen, stoßen reine Git-basierte Ansätze schnell an ihre Grenzen.
Der eigentliche Use Case: Modell-Portabilität
Das Problem wird besonders sichtbar, sobald Modelle zwischen verschiedenen Umgebungen übertragen werden müssen. Der häufigste Fall sind kontrollierte Dev/Test/Prod-Promotions, bei denen Änderungen konsistent, nachvollziehbar und vollständig zwischen Entwicklungs-, Test- und Produktivumgebungen übertragen werden sollen. Hinzu kommen parallele Umgebungen, beispielsweise für unterschiedliche Teams, Regionen oder Mandanten, die synchron gehalten werden müssen.
Darüber hinaus entstehen Anforderungen durch Migrationen, etwa von On-Premises nach SaaS oder zwischen verschiedenen Plattformen und Betriebsmodellen. Ebenso relevant sind Exit-Szenarien, bei denen ein Modell aus einer SaaS-Umgebung wieder in eine eigene Infrastruktur oder in eine alternative Umgebung überführt werden soll.
Früher reichte dafür häufig der reine Modellordner aus. In modernen SaaS-Umgebungen ist das jedoch nicht mehr praktikabel. Ein manueller Neuaufbau ist ebenfalls keine realistische Option, sobald ein Modell produktiv gewachsen ist. Zu viele Objekte, Abhängigkeiten, Regeln, Datenbereiche, Sicherheitsinformationen und Sonderfälle sind miteinander verknüpft. Ohne ein geeignetes Tool lassen sich solche Modelle kaum konsistent, vollständig und wirtschaftlich zwischen Umgebungen übertragen.
Was TurboMigrator für Planning Analytics TM1 macht
TurboMigrator ist ein leichtgewichtiges Migrationswerkzeug für IBM Planning Analytics TM1. Es arbeitet nicht über direkten Dateisystemzugriff, sondern über die TM1 REST API und kann damit auch in Umgebungen eingesetzt werden, in denen kein Zugriff auf Modellverzeichnisse möglich ist.
Über eine einfache Oberfläche werden Quelle und Ziel definiert. In wenigen Klicks lassen sich Verbindungen zu PA-Instanzen herstellen und kontrollierte Modellübertragungen durchführen. Dabei können sowohl komplette Instanzen als auch gezielt ausgewählte Objekte zwischen Umgebungen migriert werden.
Typische Einsatzszenarien sind:
- Dev/Test/Prod-Promotions
- Übertragung von Modellbestandteilen zwischen parallelen Test-, Projekt- oder Fachbereichsumgebungen
- Selektive Migration einzelner Cubes, Dimensionen, Prozesse oder Chores
- Migration von On-Premises nach SaaS
- Migration zwischen verschiedenen SaaS-Umgebungen
- Migration von SaaS zurück nach On-Premises oder in andere Zielplattformen
Der Fokus liegt nicht auf einem schweren Enterprise-Deployment-Framework, sondern auf der Umsetzung eines komplexen Prozesses mit einem einfachen Werkzeug: Verbindung wählen, Ziel definieren, Scope festlegen, Migration ausführen – pragmatisch, konsistent und nachvollziehbar.
Warum API-basierte Migration der richtige Ansatz ist
Planning Analytics Workspace ist das Frontend. Die eigentliche Logik eines PA-Modells steckt jedoch in den Objekten selbst – etwa in Cubes, Dimensionen, Regeln, Prozessen, Chores und Sicherheitsstrukturen. Deshalb setzt TurboMigrator auf die TM1 REST API als Migrationsschnittstelle.
Das bringt drei konkrete Vorteile mit sich:
Plattformunabhängigkeit. Der Ansatz funktioniert unabhängig davon, ob die Quelle on-premise oder SaaS ist beziehungsweise ein PA-Server der Version 2.1 (TM1 v11) oder 3.1 (TM1 v12) im Einsatz ist. Entscheidend ist nicht der Zugriff auf einen Modellordner, sondern der Zugriff auf die unterstützte API.
Abhängigkeitsbewusstsein. Eine Dimension muss vor einem Cube vorhanden sein, Subsets setzen auf Dimensionen auf sowie Views auf Cubes. Prozesse können andere Prozesse aufrufen. Security-Objekte haben eigene Reihenfolgen. Eine zuverlässige Migration muss diese Zusammenhänge erkennen und berücksichtigen.
Nachvollziehbarkeit. Statt Dateien manuell zu verschieben oder einzelne Objekte über Oberflächen zu transportieren, entsteht ein kontrollierter Ablauf, der prüfbar und dokumentierbar ist. Ein weiterer Vorteil API-basierter Migrationen ist, dass viele Übertragungsszenarien ohne direkten Eingriff in die laufende Instanz umgesetzt werden können. Dadurch lassen sich Änderungen in vielen Fällen ohne Neustart des Modells und ohne Unterbrechung des laufenden Betriebs durchführen.
Selektiv oder komplett:
In der Praxis sind vollständige Instanzmigrationen wichtig, aber nicht der regelmäßige Anwendungsfall. Oft geht es um gezielte Änderungen: ein neuer Cube, ein geänderter Prozess, eine aktualisierte Dimension, ein bestimmter Fachbereich.
TurboMigrator für Planning Analytics TM1 unterstützt deshalb nicht nur komplette Migrationen, sondern auch selektive Übernahmeszenarien. Entwickler und Administratoren können abhängig vom Zielsystem entscheiden, welche Objekte übertragen werden sollen. Gerade für Dev/Test/Prod-Landschaften ist das entscheidend, weil nicht jede Änderung pauschal alles überschreiben darf.
Hier zeigt sich der wesentliche Unterschied zu einfachen Export-/Import-Ansätzen oder der PAW-Git-Integration. Migrationen in Planning Analytics TM1 ist selten nur Objekttransport. Es geht um Reihenfolge, Zielzustand, bestehende Inhalte, Sicherheitsobjekte, Daten und technische Unterschiede zwischen Versionen oder Deployment-Umgebungen.
Für wen ist das relevant?
TurboMigrator richtet sich an Unternehmen und Teams, die Planning Analytics TM1 in Betrieb haben und ihre Modelle portabel halten müssen. Besonders relevant ist das für:
- Teams mit geregelten Dev/Test/Prod-Prozessen
- Organisationen mit mehreren parallelen PA-Umgebungen
- Organisationen, die Migrationen auditierbar, reproduzierbar und kontrolliert durchführen müssen
- Organisationen mit produktiven PA-Umgebungen, in denen Migrationen ohne Downtime beziehungsweise ohne Neustart der TM1-Instanz erfolgen müssen
- Partner, die Modelle zwischen Kunden-, Demo- und Testsystemen bewegen
- Kunden, die von On-Premises nach SaaS wechseln oder bereits gewechselt sind
- Unternehmen mit möglichem SaaS-Exit- oder Repatriation-Szenario
Das Ziel ist nicht, bestehende IBM-Funktionen dort zu ersetzen, wo sie gut passen. Das Ziel ist, die Lücke zu schließen, die dadurch entsteht, dass der Dateisystemzugriff fehlt und Standardmechanismen nicht ausreichen.
Fazit
Die neue Planning Analytics Engine Version und PAaaS verändert nicht nur den Betrieb, sondern auch die Art, wie Migration gedacht werden muss. Der alte Weg über den Modellordner ist dort nicht mehr verfügbar. Gleichzeitig erwarten Unternehmen weiterhin Portabilität, kontrollierte Deployments und die Möglichkeit, Modelle zwischen Umgebungen zu bewegen.
Git in PAW ist ein hilfreicher Baustein, aber kein vollständiger Ersatz für eine API-basierte, kontrollierte Migration kompletter TM1-Instanzen mit allen Abhängigkeiten.
Mit TurboMigrator für Planning Analytics TM1 schließen wir bei BIConcepts genau diese Lücke: ein pragmatisches, leichtgewichtiges Werkzeug für die kontrollierte Migration von Planning-Analytics-Modellen über Servergrenzen hinweg. Ob entlang klassischer Dev/Test/Prod-Strecken, zwischen parallelen SaaS- oder Projektumgebungen, von On-Premises nach SaaS oder im Rahmen eines SaaS-Exit-Szenarios zurück auf On-Premises – TurboMigrator macht Modellportabilität praktisch umsetzbar.
Für Unternehmen, die IBM Planning Analytics TM1 im Einsatz haben, ist Modell-Portabilität kein Nice-to-have. Sie ist Teil einer belastbaren Plattformstrategie.