Mag 22-03 No/Name - Kolumne

Riskante Wette oder Hana auf GitHub?

NoName
Game changer
Geschrieben von no-name

SAP ist mit Hana eine riskante Wette eingegangen. Die feste Bindung von S/4 an die Datenbankplattform Hana bedeutet, dass die ERP-Leistung für immer an das Können von SAP und die Performance von Hana gekoppelt ist.

Gute Software kann noch besser werden, wenn etwa die darunterliegende Datenbankplattform, das Betriebssystem und die Hardware besser werden. Eine triviale Erkenntnis, die sich in allen IT-Bereichen beobachten lässt. Was aber, wenn die Schnittstellen zwischen Applikations-, Middle-, DB- und Hardware fest verdrahtet sind?

Vor vielen Jahren konnten zahlreiche Kollegen ihr SAP-ERP-System „boostern“, indem sie die Datenbank wechselten. Ich war damals mit viel Enthusiasmus Group CIO geworden und wir standen vor der Entscheidung: weiter mit Oracle oder das sehr verlockende Angebot von IBM für DB2 annehmen? SAP selbst ist mit Hana eine riskante Wette eingegangen: Hana hat keinen Mehrwert! Hana kann eine hervorragende Datenbankplattform für S/4 sein – mehr aber auch nicht. „Sei nicht unbescheiden“, ermahnte mich meine Frau, als ich ihr von dieser Kolumne erzählte: „Letztendlich musst du auch ein Leben lang mit mir auskommen – oder gehst du neuerdings fremd?“

Ich erwiderte sofort: „mit lebenslanger und ungeteilter Treue“, meinte aber, dass ich mit ihr sowohl ans Meer als auch in die Berge auf Urlaub fahren könne. Mit Hana kann ich nur S/4 betreiben! Ex-SAP-Technikvorstand Vishal Sikka hatte noch ganz andere Pläne. Er wollte Hana als neues Angebot im Datenbankmarkt etablieren und er träumte von einem breiten Hana-Einsatz jenseits des SAP’schen ERP. Es gab sogar Pläne, Hana als Open Source zu positionieren, und Sikka präsentierte in Palo Alto, Kalifornien, einige Start-ups, die ansetzten, ihre Innovationen auf Hana zu implementieren.

Meine SAP-Stammtischschwestern und -brüder wissen, dass mittlerweile Vishal Sikka bei Oracle einen Beratungsvertrag hat und es keine Start-ups mehr gibt, die nachhaltig für Hana kämpfen. Hana ist ein SAP-Softwareprodukt wie viele andere Applikationen auch und dieser Umstand ist für uns Bestandskunden ein Risiko: Wer entwickelt Hana weiter? Wer befeuert Hana mit neuen Algorithmen? Wer kümmert sich um ein Ecosystem rund um die Hana-Datenbankplattform? Wer übernimmt die Kosten und Lizenzgebühren für einen parallelen DB-Betrieb mit Hana und AnyDB?

Weil Hana singulär in der SAP-Welt verortet ist, bleibt auch SAP der alleinige Verantwortliche für dieses Produkt. Das ist eine große Verantwortung – und es ist zu befürchten, dass in den kommenden turbulenten Jahren SAP dieser Verantwortung nicht immer gerecht werden kann. Schon jetzt werden Rufe nach einem Hana 3 laut, welches fälschlicherweise von Chefredakteur Färbinger immer wieder angekündigt wurde – ganz so, als könnte er SAP dazu zwingen. Unabhängig von seinen Fantasien steht aber eine Hana-Runderneuerung an.

SAP steht noch in Gesprächen mit Microsoft, IBM und Oracle bezüglich einer konzilianten AnyDB-Übergangsperiode bis 2030, aber das Misstrauen hinsichtlich DB-Strategie ist zwischen den Beteiligten groß. Ein weiterer DB-Wechsel von Hana zu AnyDB für einen S/4-Nachfolger wäre vielleicht betriebswirtschaftlich zu argumentieren, es würde aber organisatorisch die meisten SAP-IT-Abteilungen überfordern.

SAP wird auch in den kommenden Jahren seinen Verpflichtungen hinsichtlich Hana-Pflege nachkommen. Die Frage aber lautet: Wer entwickelt Hana innovativ weiter? Es gibt keine freie Hana-Community. Es gibt keine Start-ups, die darauf brennen, auf Hana zu entwickeln. Es gibt keinen Markt für Hana-Add-ons und Dienstleistungen außerhalb der engen Grenzen von S/4. Die alleinige Verantwortung für Hana trägt SAP.

Eine Lösung des Dilemmas wäre, auf die Idee von Vishal Sikka zurückzugreifen und Hana in die Open-Source-Szene zu entlassen: also den Hana- Sourcecode auf GitHub abzulegen und zu hoffen, dass freie Entwickler auch Interesse daran finden, das Datenbanksystem weiterzuentwickeln. Eine ganz kühne Idee wäre etwa, mit IBM gemeinsam dieses Open-Source-Hana zu betreiben und in eine Arbeitsgemeinschaft mit Red Hat einzubringen. Unsere jungen Softwareentwickler bekommen feuchte Augen bei der Kombination aus IBM Power, Red Hat Linux und Hana. Gut, auch in der SAP-Community ist träumen erlaubt – aber eine tragfähige Lösung für Hana brauchen wir alle gemeinsam.

Über den Autor

no-name

Unser geheimnisvoller, anonymer Kolumnist.

Hinterlassen Sie einen Kommentar