Eine Technologieplattform, besser bezeichnet als eine dynamisch interpretierende Laufzeitumgebung für Services, ist für viele Softwarehersteller ein State-of-the-Art-Instrument zu Flexibilisierung der Möglichkeiten mit ihrer Anwendung zu kommunizieren. Was ein herrlich sperriger Satz, der im Grunde nur aussagen soll, dass die eigentliche Anwendung zusätzlich durch einen Browser oder einen anderen Echtzeit-Interpreter mit Daten versorgt wird und ihre Antworten über dasselbe Medium zurückgibt.

Häufig verbindet sich mit der Nutzung einer Technologieplattform eine Verlagerung der Applikation auf verteilte Systeme über service-orientierte Architekturen (SOA) oder in die Cloud. Standardisierte Applikationen und Services sind somit schnell Cloud-fähig und können von Anwendern konsumiert werden. Der Einfluss auf die Funktionalität durch den Anwender oder auch IT-Spezialisten ist gering. Fragestellungen von Kunden, die häufig nur durch individuelle Anpassungen von Standardsoftwares gelöst werden konnten, werden durch die Schwarmintelligenz des Softwareherstellers unter zur Hilfenahme von Erfahrungen und Annahmen als App oder Service in solchen Architekturen zum Konsum angeboten. Das von Entwicklern häufig verwendete „works-as-designed“ für Individualentwicklungen und deren schnell korrigierbare Missverständnisse nehmen also Einzug in den Standard. Sollte eine Fehlinterpretation der Erfahrungen und Annahmen vorliegen, werden diese entweder geduldet, mit einer der nächsten Versionen korrigiert oder salonfähig gemacht. Im Weiteren muss sich der Anwender darauf verlassen, dass die Apps oder Services in seinem Sinne weiterentwickelt werden – also die Annahmen und Erfahrungen auch in der Zukunft zum Business passen.

In den vergangenen Artikeln hatte ich immer wieder betont, dass insbesondere SAP seine Anwendungen sehr stark branchenübergreifend ausgelegt hat und somit trotz der fehlenden dynamischen Laufzeitumgebung bereits in der Vergangenheit sehr nah an eine Technologieplattform heranreicht. Durch die Weiterentwicklung der SAP Cloud Technologie und zunehmende Unabhängigkeit von der Client-Server-Struktur wird dies heutzutage immer deutlicher. Ist SAP nach der obigen Herleitung zukünftig eine Technologieplattform? Das ist ein klares Jein, denn die Anwendung an sich ist immer noch klassisch in individualisierbare Module unterteilt, die Interpretation zu den Commodity-Services in der öffentlichen Cloud ist jedoch orientiert an einem standardisierten Geschäftsprozess. Dieser Ansatz macht es für Konsumenten einfach in die SAP Welt einzusteigen und der seit Jahrzehnten verfolgte Antritt „mittelstandsfähig“ zu sein, scheint nun für das Neukundengeschäft in greifbare Nähe zu rücken. Durch Partnerschaften mit anderen Cloud-Diensten wie AWS oder Azure können auch dort beheimatete sog. Microservices mitbenutzt und entsprechende zusätzliche Rechenleistungen abgerufen werden.

Doch was passiert mit den über Jahrzehnte gewachsenen, branchenspezifischen oder kundenindividuellen Ausprägungen der SAP Anwendungen? In der privaten Cloud Version wird SAP ein konfigurierbares System zur Verfügung stellen, in das es verschiedene Migrationspfade gibt. Hierbei wird sich SAP jedoch nicht von branchenspezifischen Gedanken leiten lassen. Erste Model-Companies werden in Walldorf gerade wieder eingestampft, andere sind so generisch, dass weiterhin Kunden individuelle Entwicklungen benötigen. Ebenso wenig werden nicht alle bisherigen Individualentwicklungen des Kunden problemlos migrieren lassen. Also müssen für solche Kunden weiterhin on-premise Versionen, also solche, die der Kunde selbst betreibt außerhalb einer Cloud-Infrastruktur betreibt, vorhanden bleiben. In Zukunft braucht es also SAP Partner die branchen-, prozess- und technologieorientiert vorausdenken und ein entsprechendes Portfolio von on-premise über private und öffentliche Cloud bedienen können. Eine Herausforderung, der nicht jeder heutige Partner gewachsen sein wird.