Wolfram Jost, CTO der Software AG, im Gespräch
Seite 2: M2M, Release-Strategie, Übernahmen
Noch Zukunftsmusik
heise Developer: Mit der Machine-to-Machine-Komminikation (M2M) haben Sie einen weiteren Trend auf der CeBIT aufgegriffen. Wie sieht die Software AG als deutsches Unternehmen hier den Stand der Dinge, vor allem weil wir in Deutschland ja so ingenieursstarke Unternehmen wie Bosch und Siemens oder die Automobilindustrie insgesamt haben?
Jost: Über Themen wie Internet der Dinge und M2M wird viel geschrieben, allerdings kommen Entwicklungen aus diesem Bereich nur langsam in die Praxis. Das hat auch viel mit dem Thema Big Data zu tun, da die meisten Maschinen im Vergleich mit Business-Applikationen Unmengen nicht strukturierter Daten erzeugen. Mit In-Genuis machen wir hier einen ersten Schritt. Man beginnt langsam, diese Daten erfassen, speichern und analysieren zu können. Zu berücksichtigen sind hier unterschiedliche Datentypen: Audio-, Video-, Text- und soziale Daten.
Wir haben schon viele automatisierte Systeme in Produktion, beispielsweise Maschinensteuerungen. Nur fehlt bis jetzt noch die Kommunikation der Maschinen untereinander und eine Möglichkeit, die Daten, die daraus entstehen, analysieren zu können. Mit der Kommunikation dieser Embedded- oder Cyber-physischen Systeme fängt man erst langsam an. Die Systeme an sich gibt es schon lange. Dafür sind Standards wichtig und wie ich Daten erfassen und analysieren kann. Wie kann ich also frühzeitig merken, dass eine Turbine kaputt geht oder eine Maschine Wartung braucht. Das kann man an den Daten erkennen, die die Maschine regelmäßig weitergibt.
Agile Prozesse
heise Developer: Ein Trend aus dem Web-2.0-Bereich ist, mehr Releases in kürzerer Zeit auszuliefern. Aber auch große Unternehmen wie Microsoft streben Continuous Delivery nicht nur im Rahmen von Cloud Produkten wie Windows Azure, sondern auch für Produkte wie Visual Studio an. Was verfolgt hier die Software AG?
Jost: Ich glaube, das ist heute ein genereller Trend. Man hat bei einem Release-Zyklus von etwa 18 Monaten ja viele Funktionen einer Software schon früher fertig – nur kommen die noch nicht zum Kunden, weil andere Dinge noch Zeit brauchen. Das heißt, man hat Teile entwickelt, die der Kunde leider noch nicht nutzen kann, was nicht im Sinne des Erfinders ist. Deshalb wollen wir auf Sechs-Monats-Zyklen umstellen. Das heißt jedoch nicht, dass sich die Kunden alle sechs Monate umstellen müssen.
Die Software AG hat ganz unterschiedliche Kunden: Bestandskunden auf der einen Seite, die auf keinen Fall alle sechs Monate migrieren können. Auf der anderen Seite gibt es Neukunden, die natürlich immer alle neuen Funktionen haben möchten. Wir verbinden das: Ein Kunde, der zum Beispiel das Release 8 verwendet, kann bei Release 10 oder 12 wieder einsteigen. Es ist dann unsere Aufgabe, die Versionen aufeinander abzustimmen. Wir haben damit den Vorteil, dass wir alle sechs Monate ein wettbewerbsfähiges Produkt auf dem Markt haben. Und für Neukunden zählt ja nicht Migration. Sie fangen neu an, und das verschafft uns einen Vorteil gegenüber den Unternehmen, die 18-Monats-Zyklen fahren.
Für Adabas und Natural, also Produkte, mit denen die Software AG groß geworden ist, soll das eher nicht gelten. Wir sind in diesem Bereich in der Entwicklung kundenorientiert und haben viele Bestandskunden, deren Anforderungen wir weiterhin bedienen. Da werden auch mal Funktionen für strategische Kunden entwickelt und schnell ausgeliefert. Hier müssen wir sehr flexibel sein. Der Zyklus muss also nicht zwangsläufig dem der Produkte des BPE-Bereichs (Business Process Excellence) entsprechen.
Durch die Verkürzung der Releasezyklen verbessert sich auch die Prognosequalität. Beim 18-monatigen Zyklus ist die Wahrscheinlichkeit, dass ich heute schon weiß, was ich in anderthalb Jahren haben werde, relativ gering. Manchmal weiß man zunächst gar nicht, wie etwas zu realisieren ist, aber man schreibt die Anforderungen trotzdem auf die Roadmap – man hat ja 18 Monate Zeit zum Entwickeln. Bei 6-Monats Zyklen kann man sich nur Dinge vornehmen, die tatsächlich innerhalb der Zeit zu schaffen sind. Die Vorhersagegenauigkeit wird viel größer, weil man kleinere Abstände hat und kleinere Arbeitspakete definiert. Also ist auch für den Kunden viel klarer, was er mit dem nächsten Release erwarten kann.
Das Problem dabei ist allerdings, dass es immer noch Funktionen gibt, die länger brauchen als sechs Monate. Wir können ja nicht nur Dinge entwickeln, die innerhalb dieses Zeitraums fertig sind – dann würden wir nur noch kleine Bausteine liefern. Natürlich wird es auch Funktionen geben, die zwölf Monate Arbeit benötigen. Die sind dann in einem Release versteckt und noch nicht für den Anwender sichtbar, kommen aber beim nächsten Release zum Vorschein. Das hat Auswirkungen auf die Organisation und die internen Prozesse. Man muss viel genauer sein, viel klarer. Wenn man für 18 Monate plant, schreibt man immer mehr auf die Liste, weil 18 Monate ja wie eine lange Zeit scheinen. Bei sechs Monaten wird hingegen nur das Machbare definiert.
Der Übernahmen kein Ende
heise Developer: Mit WebMethods und Terracotta hat das deutsche Unternehmen Software AG zwei US-amerikanische Firmen integriert. Können Sie ein Fazit darüber abgeben, wie die Kulturen – die deutsche und die amerikanische – hier zusammengepasst haben, oder wo es Reibungspunkte in den Kulturen gab?
Jost: Das Thema Kultur ist immer ein sehr schwieriges. Ich glaube nicht, dass ein Unternehmen, das mehrere Akquisitionen durchgeführt hat, dieselbe Kultur hat wie ein "klassisches Unternehmen". Uns geht es nicht darum, eine Kultur zu standardisieren, sondern die Vielzahl an Kulturen managen zu können. Man will ja nicht ein amerikanisches Unternehmen kaufen und dessen Kultur ändern. Und man will auch kein deutsches Unternehmen zu einem amerikanischen machen. Jede Firmenkultur hat ja ihre Stärken und Schwächen. Wir möchten diese synergetisch nutzen und versuchen, das Beste aus beiden Welten zu vereinen. Es gibt sicherlich Leitlinien, die einzuhalten sind, aber diese sind breiter als in einem rein organisch gewachsenen Unternehmen.
Die Identität von Marken wie ARIS [ebenfalls durch den Zukauf von IDS Scheer übernommen, Red.] und webMethods soll darüber hinaus ja erhalten bleiben, aber die Techniken müssen in einer Art und Weise integriert werden, die zusätzlichen Nutzen bietet. Das bedeutet Unabhängigkeit, aber gleichzeitig eine gute Integration, ohne dass die Produkte ihren Charakter aufgeben müssen.
heise Developer: Wo sehen Sie denn noch Potenzial, beziehungsweise was fehlt noch im Portfolio der Software AG?
Jost: Natürlich gibt es immer Akquisitionsobjekte, die man zwei bis drei Jahre vorher nicht gesehen hat. Wenn uns jemand vor ein paar Jahren gefragt hätte, ob wir mal eine In-Memory-Technik kaufen würden, hätten wir sicherlich gesagt, dass wir uns das so nicht vorstellen können. Wir müssen heute damit leben, dass der Horizont immer kleiner wird. Das heißt, man kann heute nicht mehr sagen, dass man weiß, was technologisch in den nächsten fünf bis sechs Jahren passiert. Ich glaube, dass es sehr wenig Personen mit dieser Weitsicht gibt. Flexibilität und Handlungsgeschwindigkeit sind gefragt. Man kauft vielmehr immer dazu, sobald man die Notwendigkeit erkennt. Wichtig ist, dass man allzeit bereit ist, seine Strategie zu justieren.
Ich kann heute schlecht sagen, welche Unternehmen wir in den nächsten fünf Jahren kaufen werden. Ich kann aber sagen, dass wir in den nächsten fünf Jahren sicherlich Unternehmen kaufen werden. Wir haben einige schon im Kopf, aber es gibt sicherlich auch welche, die sich erst im Laufe der Zeit anbieten werden. Es geht darum, sehr schnell zu justieren und schnell Entscheidungen treffen zu können. Dafür ist es gut, den nötigen Freiraum zu haben, und man ist mit flachen Hierarchien schneller als manch größeres Unternehmen. Das hat uns auch schon geholfen, Objekte zu kaufen, an denen große Unternehmen vielleicht ebenfalls Interesse gehabt haben, die aber einfach nicht schnell genug waren.
heise Developer: Herr Jost, wir bedanken uns für das Gespräch.
Das Interview führte Alexander Neumann. Die Transkription übernahm Julia Schmidt. (ane)
