Die Datenwerkstatt
Anruf: +49 711 896 601 75

Warum DBaaS Projekte scheitern – Top 3

Startseite Foren Forum: Database Orchestration, DBaaS Warum DBaaS Projekte scheitern – Top 3

Dieses Thema enthält 0 Antworten und 1 Teilnehmer. Es wurde zuletzt aktualisiert von  Thomas Kucher vor 3 Jahre, 9 Monate.

  • Autor
    Beiträge
  • #681

    Thomas Kucher
    Moderator

    Die Top 3 Gründe warum DBaaS Projekte scheitern

    1. „Bottom Up – Top down“ – Financial Engineering

    DBaaS steht auf der Agenda der IT Transformation.
    Das Engineering wird beauftragt den DBaaS zu Konzeptionieren.
    „Man macht sich Schlau“, trifft eine Reihe von Herstellern, analysiert die eigenen Best Practises.
    Führt Workshops mit Security, Betrieb, ITSM, Netzwerk, etc. durch. Monate an Arbeit sind investiert.

    Die technische Lösung steht, Proof of Concepts werden durchgeführt, die Technik kann beschafft werden.

    Hoppla! Wie sieht das Lizenzmodell für die DB Landschaft aus!? – „Das wird alles viel zu teuer!“ – „Wir müssen das DBaaS Projekt einstellen“

    Was ist passiert?
    Die Infrastruktur wurde nach Best Practise Gesichtspunkten definiert – Das Lizenzmodell außer Acht gelassen.
    Der Bottom Up Ansatz – Von der technischen zur kommerziellen Konzeptionierung des DBaaS.

    Top Down – Definieren der finanziellen Ziele – Ableitung der technischen Lösung

    An erster Stelle des DBaaS Projekts steht die Analyse des Lizenzmodells. Was sind die Lizenzmodelle, wie funktionieren sie, welche Vor- und Nachteile haben sie für einen DBaaS. Entwicklung einer Entscheidungsmatrix mit Lizen-, Wartungkosten, HW Kosten, Flexiblitäts- und Zukunftsfaktoren wird erstellt. Die optimale Wahl wird ermittelt.

    Das Engineering kann mit der technischen Konzeptionierung beginnen – PoC, etc..

    Das DBaaS Projekt ist ein Erfolg

    2. DB Orchestrierung unterschätzt

    „Als Tiger gestartet, als Papiertiger gelandet“
    Deploy und Delete von DBs geht schnell und einfach. VM Images sind schnell definiert und können deployed werden.

    Skripte übernehmen die spezifische Konfiguration nach dem Deployment vor.
    Es soll ein echter DBaaS sein. Life Cycle automatisiert – Passt die Konfiguration auch für den Life Cycle?
    Von Development DB bis Production DB heißt von Basis SLA bis Mission Critical SLA mit HA, DR alles möglich sein.
    Was ist alles zu berücksichtigen wenn eine Standalone zur Cluster DB wird? Ohne IP Adressänderung, etc.
    Die Lizenzierung sollte idealerweise auch berücksichtigt werden.

    Das ist mehr als ein Paar kleinere Skripte, der Aufwand nicht schnell zu.
    Wie hoch ist der Pflegeaufwand?
    Wie lang ist der DBaaS Service Katalog geworden? Mittlerweile sicher eine Zahl im mittleren bis hohen 2-stelligen Bereich.

    „Der Aufwand ist einfach zu hoch“
    Das DBaaS Projekt wird abgespeckt. Der Anforderer macht wieder alles selbst, es werden keine Standards erreicht, die Durchlaufzeiten sind wieder im Tages/Wochenbereich. Das DBaaS Projekt ist zum Papiertiger geworden.

    3. Integration der Umsysteme

    Virtualisierung ist relativ überschaubar. Er besteht aus wenigen Konfigurationselementen- Die Einpflegung in in umgebenden Systeme sind wenig umfangreich. Auch manuell ist dies noch machbar.
    DBaaS besteht aus vielen Konfigurationselementen und Parametern, die nun in die Systeme integriert werden müssen – Vollautomatisch wohlgemerkt. 20-50 Konfigurationselemente, Parameter kommen bei einem DBaaS mit Cluster, DR schnell zusammen.

    Die Herausforderung und Komplexität liegt darin eine Reihe von Systeme einzubinden – Vollautomatisch:
    CMDB, ITSM, ERP
    DBaaS bedeutet komplexe Service Bäume zu managen. Häufig ist es das erste Mal, daß umfangreiche Service Bäume in ITSM, CMDB, ERP vollautomatisch integriert werden müssen.
    Backup, Monitoring, DB Management etc. dürfen nicht fehlen.
    Lizenz Asset Management – DBaaS wie IaaS sind von einer gesteigerten Volatilität geprägt. Es ist unabdingbar Lizenzverstöße zu verhindern. Ein Echtzeitabgleich mit der Lizenzsituation ist bei jeder Änderung des DBaaS Pflicht.

    All dies soll/muß vollautomatisch funktionieren.
    DBaaS hat den Anspruch ein Private/Public Cloud Service zu sein – Real-Time Service für den internen/externen Kunden. Es geht um Minuten/Stunden statt Tage/Wochen.

    Min. 80% einer DBaaS Implementierung werden in diesem Bereich aufgwendet. Je nachdem wie smart ein Orchestrierungsframework dies unterstützt ist geringer Aufwand oder hunderte Tage Aufwand die Regel.

    Die Investitionskosten für die Integration des DBaaS führen häufig zum Scheitern von DBaaS Projekten

    • Dieses Thema wurde geändert vor 3 Jahre, 9 Monate von  Thomas Kucher.
    • Dieses Thema wurde geändert vor 3 Jahre, 9 Monate von  Thomas Kucher.
    • Dieses Thema wurde geändert vor 3 Jahre, 9 Monate von  Thomas Kucher.
    • Dieses Thema wurde geändert vor 3 Jahre, 9 Monate von  Thomas Kucher.
    • Dieses Thema wurde geändert vor 3 Jahre, 9 Monate von  Thomas Kucher.

Du musst angemeldet sein, um auf dieses Thema antworten zu können.