Wolfram Jost, CTO der Software AG, im Gespräch

Inhaltsverzeichnis

heise Developer sprach auf der CeBIT mit Dr. Wolfram Jost, CTO der Software AG, über neue Techniken, Produkt- und Release-Strategie und warum sich das Unternehmen aufgrund seiner flachen Hierarchien im Vorteil gegenüber der Konkurrenz sieht.

heise Developer: Die Software AG hat auf der CeBIT Terracotta In-Genius angekündigt. Was genau darf man sich darunter vorstellen?

Wolfram Jost: Im Kern ist In-Genius die BigMemory-Technik von Terracotta [eine Firma, die die Software AG im Mai 2011 übernommen hatte; Red.], allerdings erweitert um Complex Event Processing (CEP), Messaging, Hadoop und ein Dashboard zur Visualisierung der Daten. Mit BigMemory schreibt und liest eine Java-Applikation Daten nicht in eine Datenbank, sondern sie legt diese im Hauptspeicher ab. Die Technik ist also eine Art Data Store, der "In-Memory" arbeitet. Mit In-Genius haben wir das Prinzip erweitert: Wenn wir die Daten schon In-Memory vorliegen haben, warum sollen wir sie erst auf eine Platte spielen und dann in ein Data-Warehouse geben, um sie zu analysieren? Wir analysieren lieber die Daten so schnell, wie sie in den Hauptspeicher kommen, zumindest die Daten, die schnell zu verarbeiten sind.

Mehr Infos

Porträt

Dr. Wolfram Jost ist Chief Technology Officer (CTO) und seit August 2010 Mitglied des Vorstands der Software AG sowie verantwortlich für Forschung und Entwicklung. Zuvor war er Mitarbeiter am Institut für Wirtschaftsinformatik (IWi) der Universität des Saarlandes und bei IDS Scheer beschäftigt, bei der er zunächst die Leitung der ARIS-Produktentwicklung und ab 1998 den Geschäftsbereich ARIS-Produktstrategie inne hatte. Er war von 1994 an Mitglied der Geschäftsleitung und bekleidete diese Position bis zu seiner Bestellung zum Vorstandsmitglied 2000. Diese Funktion erfüllte er bis zum Abschluss der Übernahme durch die Software AG. Jost ist Autor zahlreicher Fach- und Zeitschriftenartikel sowie (Mit-)Herausgeber von mehr als zehn Fachbüchern.

Deswegen haben wir jetzt neben dem Data Store eine CEP-Engine mit Terracotta integriert. Ein Beispiel: Sobald ein Kunde einen Auftrag anlegt und in den Hauptspeicher schreibt, kann die CEP-Engine dieses Event erfassen und daraus direkt den gesamten Datensatz des Tages, des Monats und so weiter neu kalkulieren – mit allen daran hängenden Kennzahlen. Man kann aber auch Events koppeln: Wann immer ein neuer Auftrag angelegt wird, zum Beispiel vom Kunden x mit einem Volumen größer als 100.000 Euro, kann ab sofort der Gesamtumsatz des Kunden im letzten Monat oder im letzten Vierteljahr analysiert werden. Das heißt, durch die Integration von CEP mit In-Memory können wir die Daten nahezu in Echtzeit analysieren, so schnell wie sie eben aus dem Hauptspeicher kommen.

Die dritte Komponente, die wir integriert haben, ist das Messaging. Das gibt uns zum Beispiel die Möglichkeit, Daten, die wir im Hauptspeicher vorhalten, an mobile Endgeräte zu übertragen oder diese Daten mit Desktop-Applikationen zu verbinden beziehungsweise die Daten mit einem WAN-Netzwerk zu verteilen. Die vierte Komponente ist die Hadoop-Integration. Wir können jetzt auch Daten, die in einem Hadoop-Cluster liegen, in den Hauptspeicher portieren und diese Daten dort mit den Business-Daten verknüpfen und analysieren.

heise Developer: In-Memory-Techniken sind vor allem in letzter Zeit populär geworden, obwohl das Konzept schon seit den 90ern bekannt ist. Wie definieren Sie In-Memory für sich?

Jost: Wir sind nicht die einzigen, die In-Memory-Techniken anbieten. Aber durch die Weiterentwicklung des Data Stores zu einer vollständigen In-Memory-Middleware, die viel mehr macht, als nur Daten zu lesen und zu schreiben, sind wir führend im Markt. Das bestätigen uns auch die Analysten.

heise Developer: Und welche Zielgruppe haben Sie dafür vorgesehen?

Jost: Das sind Entscheider im Unternehmen, zum Beispiel auf strategischer Ebene für Business-Events. Das sind aber auch Mitarbeiter im Vertrieb, im Marketing und im Support, weil deren zentrale, riesigen Data-Warehouses ja sehr schwerfällig sind. Deswegen geht der Trend zunehmend zu Department-Dashboards. Das heißt, das Marketing hat ein anderes Dashboard als der Vertrieb oder der Einkauf mit zudem sehr kurzen Änderungszyklen, und das bekommt man eben schlecht in ein großes Data-Warehouse, bei dem standardmäßig eher das Controlling und Reporting aufgehängt sind. Das Standard-Reporting für Quartals- oder Montasbetrachtungen verlangt in der Regel Data-Warehouses, was auch gewissen gesetzlichen Anforderungen folgen muss. Aber das agile, flexible Reporting, das täglich in den Fachbereichen geschieht, eignet sich eher für In-Memory-Systeme.

heise Developer: Nun ist so ein System sicherlich nicht billig. Zielt Ihr Angebot vor allem auf große Unternehmen ab?

Jost: Man bekommt es sicherlich nicht für 10.000 Euro. Unternehmen müssen aber auch keine zwei Millionen bezahlen. Das heißt also, für 400.000 bis 500.000 Euro bekommen sie schon sehr gute Lösungen.

heise Developer: Das ist dann wahrscheinlich auch branchenübergreifend zu sehen?

Jost: Genau.

heise Developer: Es gibt ja immer wieder Szenarien, bei denen reines In-Memory keinen Sinn ergibt. Sie haben in Ihrer Ankündigung von einem Prototypen gesprochen, bei dem Adabas, Terracotta und Hadoop als Mischform laufen. Muss man also tatsächlich immer wieder und vor allem in der Zukunft hybride Ansätze anbieten?

Jost: Ich glaube schon, dass man zusätzlich zu einem In-Memory-System eine Persistenzeinheit braucht – man kann ja nie sagen, ob ein Computer eventuell ausfällt. Aber die Persistenzschicht ist wirklich nur noch dazu da, um Daten zu speichern und eventuell einen Restart/Reboot durchzuführen beziehungsweise aufgrund von Compliance-Anforderungen. Allerdings sind die Systeme keine Datenbanken mehr wie heute, die Hochgeschwindigkeit und Skalierbarkeit brauchen und mächtige Funktionen haben. Sie sind dann wirklich auf das Persistieren der Daten reduziert.

Mobile Strategie mit Java

heise Developer: Mit webMethods 9 hat die Software AG nun eine Suite integriert, mit der Unternehmen mobile Anwendungen erstellen und verteilen können. Sie ist aus der Übernahme des englischen Unternehmens Metismo hervorgegangen. Welche mobile Plattformen unterstützen Sie?

Jost: Es gibt verschiedene Ansätze im mobilen Bereich: einerseits die nativen Plattformen und andererseits den Cross-Plattform-Ansatz, bei dem in einer Sprache, in unserem Fall Java, programmiert und dann aus diesem Code Versionen für iOS, Android, Windows oder BlackBerry usw. generiert werden.

heise Developer: Kann man Ihr Vorgehen etwa mit dem bei Web-Apps vergleichen, wo durch Hilfsmittel wie PhoneGap oder Appcelerator Titanium native Versionen für verschiedene Systeme entstehen?

Jost: Es besteht die Möglichkeit, nativ zu entwickeln, Cross-Kompilierung durchzuführen oder mobile Browser-Apps zu schreiben. Für alle Herangehensweisen gibt es Vor- und Nachteile. Bei nativer Entwicklung hat man die größten Freiheitsgrade, aber die Applikation ist für jedes System neu zu schreiben, was man in den seltensten Fällen bezahlen kann. Cross-Kompilierung bedeutet, dass man nur einmal den Entwicklungsaufwand hat, aber nicht jedes letzte Feature einer Plattform nutzen kann, weil nicht alle Plattformen dieses unterstützen. Man sucht hier den gemeinsamen Nenner. Bei Anwendungen im mobilen Web-Browser braucht man immer eine Verbindung und kann nicht offline arbeiten, denn lokal sind keine Anwendungen vorhanden.

Für uns ist also die native Entwicklung ein No-Go, Mobile Web unterstützen wir durch HTML5, aber unser Favorit ist die Cross-Kompilierung mit einer in Java geschriebenen Basis.