Eine normale Plattform reicht uns nicht

Freitag, 6. Oktober 2017 06.10.2017 von Frank Fiedler 0 Kommentar

Wir befinden uns in einer Zeit, in der Wissen in immer kürzerer Zeit entsteht. Immer mehr Daten müssen verarbeitet werden und immer mehr Dienste werden miteinander vernetzt – kurz – wir befinden uns in einer Digitalen Transformation. Der Begriff Transformation ist insofern irritierend, als dass eine Transformation ein Ende hat. Bei der digitalen Transformation erwarte ich das ehrlich gesagt nicht, sondern ich gehe davon aus, dass die Technologien sich immer schneller entwickeln werden und wir es mit einem kontinuierlichen Prozess zu tun haben.

Daher müssen wir als SOPTIM ein Ökosystem schaffen, das der wachsenden Komplexität der entstehenden IT-Systeme gewachsen ist, welches die veränderlichen Bedürfnisse unserer Kunden befriedigt und gleichzeitig für unsere Kunden einfach nutzbar ist.
Zugleich gibt es den Trend zur Nutzung von Services für die verschiedensten Belange wie z. B. Infrastruktur (IaaS), Plattformen (PaaS) und auch Software (SaaS). Diese Services bieten unseren Kunden verschiedene Vorteile und es ist klar, dass auch die SOPTIM ihren Kunden die passenden Services (XaaS) anbieten möchte.

Die Digitalisierung vieler Prozesse bedeutet aber auch, dass in der Energiewirtschaft große Datenmengen – auch Big Data genannt – verarbeitet werden müssen. Hierzu sind sowohl skalierbare Lösungen notwendig, die dynamisch auf die Lastspitzen reagieren können, wie auch neue Methoden der Datenanalyse, um die gewünschte Information in der großen Datenmenge zu finden.

Technologie und Technologiekompetenz sind die Treiber neuer digitaler Geschäftsmodelle für unsere Kunden und für SOPTIM. Daher wird SOPTIM neue Softwarelösungen als Services anbieten, die modular aufgebaut, horizontal skalierbar, leichtgewichtig, ausfallsicher und hochverfügbar sind.
So entstand die Idee, eine Plattform zu schaffen, die diesen Anforderungen gerecht wird.

Was ist diese Plattform?
Zunächst möchte ich den Begriff Plattform näher beleuchten. Auf der Suche nach dem Begriff Plattform findet sich in Wikipedia das Folgende.

Plattform (Computer)
Eine Plattform – auch Schicht oder Ebene genannt – bezeichnet in der Informatik eine einheitliche Grundlage, auf der Anwendungsprogramme ausgeführt und entwickelt werden können, siehe https://de.wikipedia.org/wiki/Plattform_(Computer).

Die Plattform soll hierbei von komplizierten Details für eine Anwendungssoftware oder die Entwickler abstrahieren. Das ist aus meiner Sicht ein sehr wesentlicher Punkt. Die Plattform soll einem das Leben erleichtern.

In dem Wikipedia-Artikel wird zwischen Soft- und Hardwareplattformen unterschieden.  
Wir interessieren uns für Softwareplattformen, für die der Artikel als abstrakteste Form die „Laufzeitumgebung als Plattform“ listet. Hier kann Beispielsweise das Java Runtime Environment (JRE) genannt werden. Dieses ist für verschiedene Betriebssysteme verfügbar.

Vor dem Hintergrund der oben genannten Kriterien, wie z. B. Modularität, horizontaler Skalierbarkeit, Leichtgewichtigkeit, Ausfallsicherheit und Hochverfügbarkeit, ist diese Abstraktionsebene jedoch nicht ausreichend.

Schlussfolgerung: Keine der beschriebenen Plattformen entspricht unserer Idee einer Plattform. Die von uns angestrebte Systemgrenze/Plattformgrenze ist oberhalb der Laufzeitumgebung.

Die SOPTIM Plattform
Im Folgenden werde ich versuchen, mein Bild einer Plattform zu erläutern, und möchte dies mit der nebenstehenden Grafik tun.

Core-Funktionalität, Integrationsschicht, Apps
In der Grafik ist in der Mitte die SOPTIM Plattform dargestellt. Sie setzt sich zusammen aus einem Fundament – der sogenannten Core-Plattform. Hierbei handelt es sich um grundsätzliche Funktionalitäten wie die Persistenz von Stamm- und Bewegungsdaten, Zeitreihen- und andere Rechenoperationen oder Grundbausteine zur Prozessmodellierung. Über eine Integrationsschicht ist diese Basisfunktionalität verbunden mit verschiedensten Anwendungen – Apps genannt. Die Apps stellen Software dar, die abgeschlossene Funktionalitäten enthalten. Hierbei kann es sich um eigenständige Anwendungen handeln, wie z. B. eine App, die das Mieterstrommodell abbildet, aber auch um Funktionalität wie eine Prognose, die zumeist als Teil einer anderen App genutzt wird.

Externe Konnektivität
Für die externe Konnektivität bietet die Plattform verschiedenste Schnittstellen für eingehende Daten, wie z. B. Metering-Daten, Sensordaten, Wetterdaten etc., sowie die Möglichkeit, externe Systeme anzubinden, um ein Monitoring des Systems durchzuführen oder um programmatisch Informationen zwischen den verschiedenen IT-Systemen auszutauschen.

Versuch einer Definition
Der Begriff Plattform weckt unterschiedlichste Wünsche und Vorstellungen. Daher möchte ich im Folgenden erläutern, was ich darunter verstehe.

1.    Die Summe der vorhandenen Services und Apps gehört zur Plattform
Alle Services und Apps sind immer Teil der Plattform oder stellen sogar diese Plattform dar.

2.    Die Schnittstelle zwischen den verschiedenen Services/Modulen muss definiert sein
Die verschiedenen Bausteine der Plattform sind eigenständige Module, die mit den übrigen Modulen über ihre Schnittstelle gewissermaßen einen Vertrag schließen. Solange sich die Module an die Verträge halten, funktioniert die Plattform. Gleichzeitig sorgen die definierten Schnittstellen dafür, dass die Möglichkeit besteht, ein Modul durch ein anderes mit identischer Schnittstelle zu ersetzen. Somit kann ein dysfunktionales Modul durch ein neues ersetzt werden; es gibt dabei technologisch keinerlei Einschränkung, solange die Schnittstelle korrekt umgesetzt wird. Allerdings gilt es hierbei zu beachten, dass es vielfältige Schnittstellen gibt, die infrage kommen. Sowohl REST/JSON und SOAP/XML sind hier als einfache Webservice-Schnittstellen zu nennen, aber auch Message Broker wie z. B. MQTT (http://mqtt.org/), oder Aktoren-basierte Systeme wie Akka (http://akka.io).

3.    Teile der Plattform sind leicht(er) austauschbar - und werden auch eher ausgetauscht als verändert, um neue Anwendungsfälle abzubilden
Diese Austauschbarkeit von Services wird dazu führen, dass auch im Falle von funktionalen Erweiterungen stets die Frage zu stellen ist, ob ein bestehender Service besser angepasst oder durch einen neuen Service ersetzt wird. Das bietet große Chancen, sich regemäßig an den aktuellen Anforderungen zu orientieren und gelegentlich Ballast abzuwerfen.

4.    Jeder Service verwaltet seine Daten
Jeder Service verwaltet nur seine eigenen Daten. Aufgrund klar definierter Schnittstellen zwischen den verschiedenen Services einer Plattform macht es keinen Sinn, Abhängigkeiten über gemeinsam genutzte Daten zu schaffen. Dies würde viele Vorteile der Modularität aufheben. Insofern würde ich sogar so weit gehen und festlegen, dass jeder Service sein eigenes Datenmodell haben muss. So kann für jeden Anwendungsfall eine geeignete Persistenz ausgewählt werden - dies wird auch als Polyglot persistence bezeichnet. Das eröffnet gleichzeitig die Freiheit, aus der großen Auswahl an verfügbaren SQL- wie auch NO-SQL-Datenbanken mit unterschiedlichen Charakteristiken stets die für den Anwendungsfall optimale Technologie wählen zu können.

5.    Daten können von verschiedenen Services genutzt werden
Während wie oben dargestellt jeder Service die Persistenz der Daten selbst umsetzt, können die Daten serviceübergreifend verwendet werden. Dabei stellt der Service, der die Daten verwaltet, diese Daten für andere Services bereit. Die Daten werden somit Teil des Vertrags zwischen den Services und werden nur über die Schnittstellen des besitzenden Service zur Verfügung gestellt. Die internen Datenstrukturen bleiben stets hinter den Schnittstellen verborgen und können so bei Weiterentwicklungen beliebig verändert oder ersetzt werden, ohne die Verträge mit anderen Modulen zu verletzen.

6.    Es gibt ein Frontend/eine App pro Anwendungsfall/Nutzergruppe
In meiner Vorstellung stellt eine App die Software dar, die einen Anwendungsfall des Nutzers adressiert. Die grafische Benutzeroberfläche für diese Anwendung muss also alles dazu Notwendige enthalten. Dabei sollte die Oberfläche in sich geschlossen sein  und keine externen Abhängigkeiten zu anderen Benutzeroberflächen haben. Bei diesem Vorgehen kann – analog zur Polyglot persistence – die passende Visualisierung und Benutzerführung für die jeweilige Anwendung ausgewählt werden – diese könnte man ggf. als Polyglot visualization bezeichnen.

Mit den oben dargestellten Designvorgaben lässt sich eine sukzessive wachsende Softwareplattform erstellen, die verschiedenste Anwendungen und Services enthält. Sie bietet die Möglichkeit, unterschiedlichste Services zu einer Lösung zu kombinieren oder als separate Lösungen in einer Umgebung parallel zu betreiben.

Die Modularität der Plattform erlaubt es, eigene Softwarekomponenten und die von Technologiepartnern transparent zu einer gemeinsamen Anwendung zu entwickeln. Für den Endkunden erscheint diese Anwendung als ein Produkt, dass exakt auf seine Bedürfnisse zugeschnitten ist. Hierbei ist es unbedeutend, wie groß oder klein ein Modul der Plattform ist. Es kann sich dabei um einen grundlegenden und kleinen Service handeln, wie z. B. Zeitreihenoperationen, aber auch um ein komplettes Fremdsystem, wie einen Handelsplatz für Energie. Wichtig ist – wie bereits oben erwähnt – die Existenz klar definierter Schnittstellen des Moduls, über die innerhalb der Plattform kommuniziert wird.

Die Plattformtechnologie gibt uns unzählige Möglichkeiten, die Dinge modular, leichtgewichtig, skalierbar, ausfallsicher und hochverfügbar zu gestalten – wichtig wird sein, die zunehmende Komplexität zu beherrschen und dabei wirtschaftlich zu entwickeln.

Die Technologie und deren Entwicklung ist allerdings kein Selbstzweck – es geht um den Kundennutzen. Diesen stets fokussiert zu halten und zu maximieren, sollte unser Ratgeber für die Entwicklung der Plattform sein.

Kommentar schreiben

Ihr Kontakt Stephanie Lemken Was kann ich für Sie tun?
+49 241 918 790

Direkt anrufen