BEKOM MANAGEDBetriebsmodelle für AnwendungenOn-Premise, Cloud oder Hybrid
BEKOM betreibt Geschäftsanwendungen in der eigenen Betriebsstätte, in Cloud-Umgebungen oder in kombinierten Szenarien – mit identischen SLAs.
Was das Betriebsmodell einer Anwendung bestimmt
Auf Infrastrukturebene bestimmt vor allem der Standort, ob eine Komponente in der eigenen Betriebsstätte oder in der Cloud läuft. Auf der Anwendungsebene kommen drei zusätzliche Faktoren hinzu: das Lizenzmodell des Herstellers, die technischen Vorgaben des Anbieters und die Architektur der Anwendung selbst. Diese drei Faktoren schränken den Entscheidungsspielraum ein – teilweise stärker als bei Infrastruktur oder Plattformen.
Anwendungs-Betriebsmodelle bestimmen direkt die Verfügbarkeit geschäftskritischer Systeme wie ERP, CRM oder Produktionssteuerung. Falsche Architekturentscheidungen gefährden die Geschäftsprozesse durch Latenzprobleme, Compliance-Lücken oder Herstellerabhängigkeiten, die den operativen Betrieb beeinträchtigen. → BEKOM MANAGED Applications
Warum Anwendungen anders entschieden werden als Infrastruktur
Infrastruktur vs. Plattform vs. Anwendung: Während Infrastruktur-Betriebsmodelle primär den physischen Standort von Hardware festlegen und Plattform-Modelle die Verteilung von Laufzeitumgebungen regeln, unterliegen Anwendungen zusätzlichen Beschränkungen. Ein Serverschrank kann grundsätzlich in jeder geeigneten Betriebsstätte stehen. Eine Anwendung kann das häufig nicht.
- Lizenzvorgaben: Microsoft 365 lässt sich ausschließlich als Cloud-Dienst beziehen – ein Betrieb in der eigenen Betriebsstätte ist vertraglich und technisch ausgeschlossen
- Herstellerarchitektur: SaaS-Produkte setzen die Infrastruktur des Herstellers voraus; Self-Hosted-Varianten erlauben beide Modelle
- Anwendungsabhängigkeiten: Legacy-Anwendungen mit lokalen Datenbankbindungen oder proprietären Schnittstellen erfordern Anpassungen, bevor sie in Cloud-Umgebungen verlagert werden können
- Folge: Bei Anwendungen schränkt das Lizenzmodell den Entscheidungsspielraum stärker ein als bei Infrastruktur oder Plattformen
BEKOM analysiert im Application-Assessment diese drei Dimensionen pro Anwendung und dokumentiert, welches Betriebsmodell technisch und lizenzrechtlich möglich ist – bevor operative Präferenzen in die Entscheidung einfließen.
Lizenzmodelle als Betriebsmodell-Treiber
Das Lizenzmodell einer Anwendung bestimmt, welche Betriebsmodelle überhaupt zur Verfügung stehen. Drei Lizenztypen mit jeweils unterschiedlichen Konsequenzen für den Betrieb.
Cloud-Only-Lizenzen
Einige Hersteller bieten ihre Anwendungen ausschließlich als Cloud-Dienst an. Das Lizenzmodell bestimmt das Betriebsmodell – ohne Verhandlungsspielraum.
Vorteile
- Microsoft 365: Exchange Online, SharePoint Online, Teams und OneDrive ausschließlich als Cloud-Dienst. Ein Betrieb in der eigenen Betriebsstätte ist weder lizenzrechtlich noch technisch vorgesehen
- Dynamics 365 Online: Produktstrategie sieht ausschließlich Cloud-Betrieb vor. Bestehende On-Premise-Installationen (Dynamics NAV, AX) erhalten Support bis Lifecycle-Ende, Neulizenzen sind cloud-only
- Salesforce: Alle Editionen setzen die Salesforce-Infrastruktur voraus. Eine Self-Hosted-Variante existiert nicht
Tenant-Management, Sicherheitskonfiguration (Conditional Access, MFA-Policies, Defender-Einstellungen) und Lizenzmanagement – die Infrastrukturverantwortung verbleibt beim Hersteller.
Fazit
Organisationen mit Cloud-Only-Produkten haben kein Betriebsmodell zu wählen, sondern die Konfigurationsebene zu gestalten.
Dual-License
Andere Hersteller bieten beide Lizenzmodelle parallel an. Die Wahl des Betriebsmodells liegt bei der Organisation – mit jeweils unterschiedlichen Implikationen.
Vorteile
- Lizenzkonvertierung: Der Wechsel zwischen On-Premise-Lizenz (Named User, Engine-basiert) und Cloud-Edition (Subskription) verändert Kostenstruktur (CAPEX zu OPEX) und Funktionsumfang
- Vertragliche Bindung: On-Premise-Lizenzen beinhalten Wartungsverträge mit jährlicher Gebühr. Cloud-Subskriptionen binden an Laufzeiten. Ein Wechsel ist an Vertragstermine gebunden
- Funktionsparität: Nicht alle Funktionen sind in beiden Modellen identisch verfügbar. SAP stellt neue Funktionen bevorzugt in der Cloud-Edition bereit
Analyse der bestehenden Lizenzstruktur, Restlaufzeiten und Konvertierungsoptionen im Assessment. Die Betriebsmodell-Empfehlung berücksichtigt lizenzrechtliche und wirtschaftliche Faktoren neben den technischen Anforderungen.
Fazit
Die Modellwahl bei Dual-License-Produkten ist reversibel – erfordert aber Lizenzkonvertierung und vertragliche Abstimmung.
Open Source und Eigenentwicklung
Bei Open-Source-Anwendungen und Eigenentwicklungen existieren keine herstellerseitigen Betriebsmodell-Einschränkungen. Die Anwendungsarchitektur bestimmt das Modell.
Vorteile
- Nextcloud, Collabora, Mattermost: Self-Hosted in der eigenen Betriebsstätte oder in Cloud-Umgebungen – die Lizenz erlaubt beides. Integrationsanforderungen bestimmen das Modell
- Kundenindividuelle Anwendungen: Eigenentwicklungen unterliegen keiner Fremdlizenz. BEKOM betreibt diese im Modell, das ihrer Architektur und den organisatorischen Anforderungen entspricht
- Containerisierte Stacks: Anwendungen mit Container-Architektur (Docker, Kubernetes) lassen sich in beiden Umgebungen identisch deployen. Die Entscheidung fällt nach operativen Kriterien
Identische SLAs und Betriebsprozesse wie bei kommerziellen Produkten – unabhängig vom gewählten Betriebsmodell.
Fazit
Bei Open-Source-Anwendungen entscheidet die Architektur über das Betriebsmodell, nicht die Lizenz.
| Cloud-Only-Lizenzen | Dual-License | Open Source und Eigenentwicklung | |
|---|---|---|---|
Betriebsmodell | Einige Hersteller bieten ihre Anwendungen ausschließlich als Cloud-Dienst an. Das Lizenzmodell bestimmt das Betriebsmodell – ohne Verhandlungsspielraum. | Andere Hersteller bieten beide Lizenzmodelle parallel an. Die Wahl des Betriebsmodells liegt bei der Organisation – mit jeweils unterschiedlichen Implikationen. | Bei Open-Source-Anwendungen und Eigenentwicklungen existieren keine herstellerseitigen Betriebsmodell-Einschränkungen. Die Anwendungsarchitektur bestimmt das Modell. |
Vorteile |
Tenant-Management, Sicherheitskonfiguration (Conditional Access, MFA-Policies, Defender-Einstellungen) und Lizenzmanagement – die Infrastrukturverantwortung verbleibt beim Hersteller. |
Analyse der bestehenden Lizenzstruktur, Restlaufzeiten und Konvertierungsoptionen im Assessment. Die Betriebsmodell-Empfehlung berücksichtigt lizenzrechtliche und wirtschaftliche Faktoren neben den technischen Anforderungen. |
Identische SLAs und Betriebsprozesse wie bei kommerziellen Produkten – unabhängig vom gewählten Betriebsmodell. |
Fazit | Organisationen mit Cloud-Only-Produkten haben kein Betriebsmodell zu wählen, sondern die Konfigurationsebene zu gestalten. | Die Modellwahl bei Dual-License-Produkten ist reversibel – erfordert aber Lizenzkonvertierung und vertragliche Abstimmung. | Bei Open-Source-Anwendungen entscheidet die Architektur über das Betriebsmodell, nicht die Lizenz. |
Anwendungsarchitektur und Betriebsmodell
Die Architektur einer Anwendung bestimmt, wie gut sie sich für ein bestimmtes Betriebsmodell eignet. Drei Architekturtypen prägen die Anwendungslandschaften im Mittelstand.
Monolithische Anwendungen
Monolithische Anwendungen bündeln alle Funktionen in einem einzelnen Deployment-Artefakt. Diese Architektur prägt den Großteil der gewachsenen Anwendungslandschaften.
Vorteile
- Enge Kopplung: Datenbank, Geschäftslogik und Benutzeroberfläche bilden eine Einheit. Ein Ausfall einer Komponente betrifft die gesamte Anwendung
- Lokale Abhängigkeiten: Direktzugriff auf lokale Dateisysteme, spezifische Betriebssystemversionen oder proprietäre Middleware binden die Anwendung an bestimmte Laufzeitumgebungen
- Migrationsaufwand: Eine Verlagerung in Cloud-Umgebungen erfordert Re-Hosting (Lift-and-Shift ohne Architekturänderung) oder Re-Architecting (Umstellung auf entkoppelte Komponenten)
- Patch-Management: OS-Patches und Middleware-Updates in abgestimmten Wartungsfenstern mit Staging-Validierung
- Datensicherung: Anwendungskonsistente Backups mit regelmäßigen Wiederherstellungstests
- Performance-Monitoring: Datenbankabfragen, Speicherverbrauch, Antwortzeiten der Anwendung
- Kapazitätsplanung: Dimensionierung bei steigendem Datenvolumen oder wachsender Nutzerzahl
Fazit
Monolithische Anwendungen verbleiben in der Regel in der eigenen Betriebsstätte – eine Migration erfordert Architekturanpassungen.
Cloud-Native und containerisierte Anwendungen
Cloud-native Anwendungen sind für verteilten Betrieb konzipiert. Ihre Architektur setzt keine bestimmte physische Umgebung voraus.
Vorteile
- Microservices: Einzelne Funktionen laufen als unabhängige Dienste mit definierten API-Schnittstellen. Skalierung erfolgt pro Service, nicht für die gesamte Anwendung
- Container-Orchestrierung: Kubernetes oder vergleichbare Plattformen verwalten Deployment, Skalierung und Ausfallbehandlung automatisiert
- Zustandslosigkeit: Anwendungsinstanzen speichern keinen lokalen Zustand. Persistenz liegt in externen Datenspeichern. Beliebige Skalierung und Standortwechsel sind möglich
- Image-Management: Vulnerability-Scanning, Registry-Pflege, Image-Promotion zwischen Umgebungen
- Deployment-Koordination: Rolling Updates, Blue-Green-Deployments, automatisiertes Rollback bei Fehlern
- Service-Monitoring: Health-Checks, Latenz und Fehlerraten pro Microservice, Alerting bei Schwellwertüberschreitung
- Auto-Scaling: Skalierungsregeln pro Service, Ressourcenlimits, Lastverteilung
Fazit
Weiterführende Informationen zur Plattformebene: BEKOM MANAGED Platforms. Fazit: Cloud-native Anwendungen profitieren von Cloud-Diensten, lassen sich bei Bedarf aber auch in der eigenen Betriebsstätte betreiben.
SaaS vs. Self-Hosted
Dieselbe Anwendung kann als SaaS-Dienst oder als Self-Hosted-Installation existieren. Die Verantwortungsverteilung unterscheidet sich grundlegend.
Vorteile
- SaaS-Betrieb: Der Hersteller verantwortet Infrastruktur, Plattform und Basisanwendung. BEKOM übernimmt Konfiguration, Benutzermanagement, Sicherheitsrichtlinien und Lizenzoptimierung
- Self-Hosted-Betrieb: BEKOM betreibt den vollständigen Stack – Infrastruktur, Betriebssystem, Middleware und Anwendung. Die Organisation behält volle Kontrolle über Datenstandort, Update-Zeitpunkte und Konfiguration
- Entscheidungskriterien: Datensouveränität, Update-Kontrolle, Anpassungstiefe und Kostenstruktur (Subskription vs. Eigenbetrieb)
- Tenant-Konfiguration: Sicherheitsrichtlinien, Berechtigungsstrukturen, Compliance-Einstellungen
- Lizenzoptimierung: Nutzungsanalyse, ungenutzte Zuweisungen identifizieren, Lizenztypen anpassen
- Inzidenz-Response: Störungsanalyse auf Anwendungsebene, Koordination mit dem Hersteller-Support
- Stack-Betrieb: Betriebssystem, Middleware, Datenbank und Anwendung als Gesamtpaket
- Update-Planung: Sicherheitspatches und Feature-Updates nach organisationseigenen Zyklen
- Datensicherung: Anwendungskonsistente Backups mit definierten Wiederherstellungszielen
Fazit
Die Entscheidung zwischen SaaS und Self-Hosted hängt von Datensouveränität, Update-Kontrolle und Anpassungstiefe ab.
| Monolithische Anwendungen | Cloud-Native und containerisierte Anwendungen | SaaS vs. Self-Hosted | |
|---|---|---|---|
Betriebsmodell | Monolithische Anwendungen bündeln alle Funktionen in einem einzelnen Deployment-Artefakt. Diese Architektur prägt den Großteil der gewachsenen Anwendungslandschaften. | Cloud-native Anwendungen sind für verteilten Betrieb konzipiert. Ihre Architektur setzt keine bestimmte physische Umgebung voraus. | Dieselbe Anwendung kann als SaaS-Dienst oder als Self-Hosted-Installation existieren. Die Verantwortungsverteilung unterscheidet sich grundlegend. |
Vorteile |
|
|
|
Fazit | Monolithische Anwendungen verbleiben in der Regel in der eigenen Betriebsstätte – eine Migration erfordert Architekturanpassungen. | Weiterführende Informationen zur Plattformebene: BEKOM MANAGED Platforms. Fazit: Cloud-native Anwendungen profitieren von Cloud-Diensten, lassen sich bei Bedarf aber auch in der eigenen Betriebsstätte betreiben. | Die Entscheidung zwischen SaaS und Self-Hosted hängt von Datensouveränität, Update-Kontrolle und Anpassungstiefe ab. |
Hersteller-Release-Management pro Betriebsmodell
Cloud-Dienste: Herstellergesteuerte Updates
Bei Cloud-Diensten bestimmt der Hersteller den Update-Zeitpunkt. Neue Funktionen, Sicherheitsupdates und Konfigurationsänderungen werden ohne aktive Zustimmung der Organisation ausgerollt.
Betriebspraxis mit BEKOM MANAGED:
- Bewertung vor Aktivierung: BEKOM prüft angekündigte Funktionsänderungen (z. B. Microsoft 365 Message Center) auf Auswirkungen auf bestehende Konfigurationen und Sicherheitsrichtlinien
- Konfigurations-Drift-Erkennung: Regelmäßige Abgleiche der Ist-Konfiguration gegen die dokumentierte Soll-Konfiguration identifizieren unbeabsichtigte Abweichungen nach Hersteller-Updates
- Rollout-Steuerung: Wo der Hersteller Rollout-Optionen anbietet (Targeted Release, Standard Release), nutzt BEKOM diese zur kontrollierten Einführung – Testgruppe zuerst, Gesamtorganisation nach Validierung
- Kommunikation: BEKOM informiert die Organisation über relevante Änderungen und deren Auswirkungen auf Arbeitsabläufe, bevor diese produktiv wirksam werden
Fazit: Bei Cloud-Diensten liegt der Schwerpunkt auf Bewertung und Steuerung herstellerseitiger Änderungen, nicht auf deren Planung.
On-Premise-Anwendungen: Kontrollierte Update-Zyklen
Bei On-Premise-Anwendungen liegt die Update-Kontrolle bei der Organisation. BEKOM plant und koordiniert diese Zyklen als Teil des Managed Service.
Betriebspraxis mit BEKOM MANAGED:
- Patch-Management: BEKOM plant Sicherheitspatches, Support Packages und Feature Updates nach definierten Zyklen. Kritische Sicherheitspatches werden priorisiert und außerhalb des regulären Zyklus eingespielt
- Staging-Validierung: Vor dem Produktiv-Deployment wird jedes Update in einer Staging-Umgebung getestet – Funktionsvalidierung, Regressionstest, Performance-Messung
- Wartungsfenster-Koordination: Updates erfolgen in abgestimmten Wartungsfenstern. BEKOM koordiniert die Terminierung mit den Fachabteilungen, um Betriebsunterbrechungen zu minimieren
- Rollback-Fähigkeit: Für jedes Update dokumentiert BEKOM einen Rollback-Pfad. Bei Problemen nach dem Update kann der vorherige Zustand wiederhergestellt werden
Fazit: Bei On-Premise-Anwendungen bestimmt die Organisation den Update-Zeitpunkt – BEKOM koordiniert Planung, Test und Durchführung.
Hybrid: Schnittstellen-Versionsmanagement
Wenn On-Premise-Komponenten und Cloud-Dienste über Schnittstellen kommunizieren, entsteht eine zusätzliche Komplexitätsebene: Beide Seiten entwickeln sich in unterschiedlichen Zyklen weiter.
Betriebspraxis mit BEKOM MANAGED:
- API-Versionskompatibilität: BEKOM prüft bei jedem Update auf beiden Seiten, ob die Schnittstellenversionen kompatibel bleiben. Inkompatible Änderungen werden vor dem Rollout identifiziert
- Authentifizierungsprotokoll-Alignment: Wenn Cloud-Dienste Authentifizierungsprotokolle aktualisieren (z. B. Deprecation älterer OAuth-Versionen), koordiniert BEKOM die Anpassung auf der On-Premise-Seite
- Datenformat-Konsistenz: Änderungen an Datenaustauschformaten (API-Payloads, Datenbankreplikations-Schemata) werden in beiden Umgebungen synchron angepasst, um Datenverlust oder Verarbeitungsfehler zu vermeiden
- Monitoring der Integrationspunkte: Die Monitoring-Plattform überwacht Latenz, Fehlerraten und Verfügbarkeit aller Schnittstellen zwischen On-Premise- und Cloud-Komponenten durchgehend
Fazit: Im Hybrid-Betrieb liegt die Komplexität in der Synchronisation der Update-Zyklen beider Seiten über die Schnittstellen hinweg.
Kostentreiber bei Betriebsmodell-Entscheidungen für Anwendungen
Die Kostentreiber bei Anwendungs-Betriebsmodellen unterscheiden sich erheblich von reinen Infrastruktur-Entscheidungen. Im Eigenbetrieb entstehen variable Aufwände durch Lizenzberatung verschiedener Hersteller, Kompatibilitätsprüfungen zwischen Legacy-Anwendungen und Cloud-Zielarchitekturen sowie Migrationsplanung bei veränderten Herstellervorgaben. Besonders aufwendig sind Assessments zur Abhängigkeitsanalyse proprietärer Schnittstellen und die laufende Bewertung von SaaS- versus Self-Hosted-Varianten derselben Anwendung. BEKOM strukturiert diese Komplexität durch eine Monatspauschale, die sowohl die Betriebsmodell-Beratung als auch die technische Umsetzung verschiedener Anwendungsarchitekturen abdeckt. Dadurch entstehen planbare Betriebskosten statt projektbezogener Einzelbewertungen.
Verwandte Themen: Anwendungs-Betriebsmodelle verzahnen sich mit Managed Microsoft für Microsoft-zentrische Stacks und Managed Open Source für Open-Source-Plattformen; die Open-Source-Perspektive ist unter Open-Pro-Anwendungen-Betriebsmodelle beschrieben; für strukturierte Microsoft-Ablösungen siehe das Szenario Microsoft-365-Exit.
Häufige Fragen zu Anwendungs-Betriebsmodellen
Bestimmt der Softwarehersteller, wo eine Anwendung betrieben werden muss?
Bei einigen Produkten ja. Microsoft 365 ist ausschließlich als Cloud-Dienst verfügbar – ein Betrieb in der eigenen Betriebsstätte ist nicht vorgesehen. SAP S/4HANA bietet beide Modelle an. Open-Source-Anwendungen unterliegen keiner Herstellerbeschränkung. BEKOM analysiert im Application-Assessment die Lizenzbedingungen jeder Anwendung und dokumentiert, welche Betriebsmodelle vertraglich und technisch möglich sind – bevor operative Präferenzen berücksichtigt werden.
Was passiert bei einem automatischen Microsoft-365-Feature-Rollout?
Microsoft veröffentlicht regelmäßig Funktionsänderungen, die ohne aktive Zustimmung ausgerollt werden. BEKOM überwacht das Microsoft 365 Message Center, bewertet angekündigte Änderungen auf Auswirkungen und informiert die Organisation vor der Aktivierung. Wo Rollout-Optionen bestehen (Targeted Release, Standard Release), nutzt BEKOM diese zur kontrollierten Einführung. Nach dem Rollout prüft BEKOM die Ist-Konfiguration auf Abweichungen von den dokumentierten Sicherheitsrichtlinien.
Kann eine SAP-Lizenz von On-Premise auf Cloud umgestellt werden?
SAP bietet Konvertierungsprogramme zwischen On-Premise- und Cloud-Lizenzen an. Der Wechsel verändert die Kostenstruktur (von CAPEX auf OPEX), den verfügbaren Funktionsumfang und die Update-Kontrolle. Nicht alle On-Premise-Funktionen stehen in der Cloud-Edition identisch zur Verfügung. BEKOM analysiert im Assessment die bestehende Lizenzstruktur, Restlaufzeiten und vertragliche Konvertierungsoptionen. Die Empfehlung berücksichtigt neben technischen Anforderungen auch wirtschaftliche Faktoren wie Wartungsvertragskosten im Vergleich zu Subskriptionsgebühren.
Wie wird Konfigurations-Drift bei Cloud-Anwendungen erkannt?
Konfigurations-Drift entsteht, wenn die tatsächliche Konfiguration eines Cloud-Dienstes von der dokumentierten Soll-Konfiguration abweicht – etwa durch automatische Hersteller-Updates, manuelle Änderungen oder Policy-Aktualisierungen des Anbieters. BEKOM führt regelmäßige Soll-Ist-Abgleiche durch: Sicherheitsrichtlinien, Berechtigungsstrukturen, Compliance-Einstellungen und Funktionskonfigurationen werden gegen die dokumentierte Baseline geprüft. Abweichungen werden klassifiziert, bewertet und entweder korrigiert oder als bewusste Anpassung dokumentiert.
Welche Anwendungen eignen sich nicht für Cloud-Betrieb?
Anwendungen mit enger Kopplung an lokale Infrastruktur erfordern Anpassungen vor einer Verlagerung in Cloud-Umgebungen: Legacy-Systeme mit proprietären Schnittstellen zu lokalen Datenquellen, Anwendungen mit Latenzanforderungen unter fünf Millisekunden zum lokalen Netzwerk oder Software mit Abhängigkeiten von spezifischen Betriebssystemversionen, die in Cloud-Plattformen nicht verfügbar sind. BEKOM dokumentiert diese Einschränkungen im Assessment und empfiehlt entweder den Verbleib in der eigenen Betriebsstätte oder eine strukturierte Architekturanpassung.
Wer verantwortet Sicherheitsupdates bei SaaS-Diensten?
Die Verantwortung ist geteilt. Der SaaS-Anbieter verantwortet Sicherheitsupdates der Infrastruktur und der Basisanwendung. BEKOM verantwortet die Sicherheitskonfiguration auf Tenant-Ebene: Conditional-Access-Policies, MFA-Konfiguration, Defender-Einstellungen, Berechtigungsstrukturen und Compliance-Richtlinien. Diese Abgrenzung wird im Service-Design-Dokument pro Anwendung dokumentiert. BEKOM prüft herstellerseitige Sicherheitsupdates auf Auswirkungen auf die konfigurierte Sicherheitsarchitektur.
Welche Kosten entstehen bei einem Wechsel zwischen Anwendungs-Betriebsmodellen?
Die Kosten hängen stark von der Anwendungsarchitektur und den Lizenzbedingungen ab. SaaS-zu-Self-Hosted-Migrationen erfordern Infrastruktur-Setup und Datenexport, während Self-Hosted-zu-Cloud-Wechsel Kompatibilitätsprüfungen und API-Anpassungen umfassen. BEKOM bewertet vorab die technischen Abhängigkeiten und Lizenzübertragbarkeit, um unvorhergesehene Migrationsaufwände zu vermeiden. Die Bewertung umfasst auch Folgekosten durch veränderte Backup-Strategien oder Compliance-Anforderungen je Betriebsmodell.
Kann man vom Cloud-Betrieb zurück zum Eigenbetrieb einer Anwendung wechseln?
Das hängt primär vom ursprünglichen Lizenzmodell und der Anwendungsarchitektur ab. Reine SaaS-Produkte wie Microsoft 365 erlauben keinen Eigenbetrieb, während Self-Hosted-Varianten meist portabel bleiben. Kritisch sind proprietäre Cloud-APIs und Datenexport-Beschränkungen des Herstellers. BEKOM prüft vor Betriebsmodell-Entscheidungen die Exit-Optionen und dokumentiert Portabilitätsbedingungen. Bei hybriden Architekturen können Teilkomponenten schrittweise verlagert werden, ohne vollständige Systemwechsel zu erzwingen.
Nächster Schritt: Betriebsmodell analysieren
Der Einstieg beginnt mit einem Application-Assessment, das Lizenzstrukturen, Anwendungsarchitekturen und Herstellervorgaben pro Anwendung erfasst und bewertet.
Ein Assessment der Anwendungs-Betriebsmodelle liefert eine strukturierte Bestandsaufnahme aller Lizenzmodelle, Herstellervorgaben und Architekturabhängigkeiten im aktuellen Anwendungsportfolio. BEKOM erstellt eine Übersicht über Exit-Optionen, Portabilitätsbeschränkungen und Migrationspfade zwischen On-Premise-, Cloud- und Hybrid-Varianten. Das Ergebnis ist eine konkrete Empfehlung für optimale Betriebsmodelle je Anwendung samt Service-Design für die technische Umsetzung.
Ausgangslage erfassen
BEKOM erfasst im Application-Assessment die bestehende Anwendungslandschaft und analysiert pro Anwendung drei Dimensionen: welches Betriebsmodell die Lizenz erlaubt, welche Einschränkungen die Anwendungsarchitektur mit sich bringt und welche Herstellervorgaben zu beachten sind.
Betriebsmodell zuordnen
Auf Basis der Analyse erstellt BEKOM eine dokumentierte Empfehlung pro Anwendung: Cloud-only (herstellerbedingt), On-Premise (architekturbedingt), wahlfreies Modell (bei Dual-License oder Open Source) oder Hybrid (bei gemischten Anforderungen). Die Empfehlung enthält Lizenzimplikationen, Kostenvergleich und technische Abhängigkeiten.
Service-Design erstellen
Nach Freigabe der Zuordnung entsteht das Service-Design-Dokument: SLAs pro Anwendung, RACI-Matrix mit Aufgabenverteilung zum jeweiligen Hersteller, Release-Management-Prozess (herstellergesteuert vs. kontrolliert) und Schnittstellendokumentation für Hybrid-Szenarien.