Dassault Systèmes kauft No Magic: Was bedeutet das?
Es war absehbar, nachdem Dassault und No Magic bereits eine engere Zusammenarbeit angekündigt hatten. Seit kurzem ist es offiziell, dass eine Akquisition geplant ist.
Dassault ist ein französischer Milliardenkonzern, der im SE für Produkte wie Catia, Simulia und viele andere. NoMagic ist eine kleine Firma aus Litauen, die sich aber einen Namen in der Modellierung (UML, SysML) gemacht hat.
Die Akquisition macht für Dassault Sinn: MagicDraw ist eine sinnvolle Ergänzung von Dassault’s Portfolio und konkurriert kaum mit dem existierenden Angebot. Ob der Kauf auch für den Kunden gut ist, soll hier untersucht werden.
Alles aus einer Hand
Wie manch anderer Konzern hat Dassault dessen Produkte unter einer übergeordneten Marke angeordnet, in diesem Fall 3D Experience. Die Idee ist simpel: Durch diesen Portfolioansatz können Kunden nur die benötigten Komponenten kaufen und damit die Kosten optimieren. Der übergeordnete Rahmen stellt sicher, dass die Werkzeuge aufeinander abgestimmt sind und integriert sind. Dieser Ansatz wird bspw. auch von IBM mit dessen Jazz-Plattform verfolgt.
Das klingt verlockend und kann in der Praxis auch gut funktionieren. Es ist aber in mehrfacher Hinsicht risikobehaftet: Zum einen ist man auf einen Anbieter festgelegt. Wenn dieser Probleme bekommt, oder die strategische Rolle beim Kunden ausnutzt, hat der Kunde ein großes Problem. In einer heterogenen Werkeuglandschaft ist in so einer Situation das Problem entsprechend kleiner.
Zum anderen ist man (in der Regel) auf die Werkzeuge des Herstellers angewiesen. Dadurch werden möglicherweise schwache Komponenten verwendet, da bessere nur schwer in das Ökosystem zu integrieren sind. Dazu weiter unten mehr.
Problematisch ist auch, wenn der Anbieter mehrere Komponenten für die selbe Aufgabe hat. Das kann bspw. durch Akquisitionen passieren, und dann kann es durchaus passieren, dass eine Komponente irgendwann eingestampft wird. Ärgerlich, wenn da auf das „falsche Pferd“ gesetzt wurde. Unter diesem Gesichtspunkt wird es interessant zu verfolgen, wie Siemens mit der Akquisition von Polarion umgeht. Denn Siemens hat bereits ein RE-Werkzeug im Portfolio (Teamcenter Requirements).
Modularität und Offenheit
Die Alternative ist es, Werkzeuge verschiedener Hersteller zu integrieren. Die Kernfrage ist, ob eine modulare Lösung jemals so nahtlos sein kann wie eine Lösung, die aus einer Hand kommt.
Diese Frage lässt sich nicht so ohne weiteres beantworten und muss individuell evaluiert werden. Ein konkretes Beispiel aus der Softwareentwicklung: Dort benötigt man sowohl einen Editor zum Bearbeiten von Quellcode, als auch einen Compiler zum Verarbeiten des Codes. Historisch waren diese zwei Werkzeuge von Anfang an getrennt, was aber kaum Probleme bereitete. Mit der Zeit etablierten sich integrierte Entwicklungsumgebungen (IDE). Doch auch diese ermöglichen in der Regel das transparente Austauschen des Compilers.
Leider nicht so gut funktioniert es bisher mit dem Austausch von Anforderungen: Lange Zeit gab es keine zufriedenstellende Lösung, und Kunden waren entweder auf proprietäre Lösungen angewiesen, oder mussten verlustbehaftete Formate wie PDF, Word oder Excel nutzen. Inzwischen gibt es mit ReqIF einen ordentlichen Standard, der aber von vielen Werkzeugen zur Zeit nur unvollständig und/oder stiefmütterlich unterstützt wird.
Hier ist IBM ein interessanter Fall: IBM setzt auf deren Jazz-Plattform. Gleichzeitig benutzt Jazz einen offenen Standard, OSLC, um die Komponenten von Jazz zu integrieren. OSLC wurde von IBM maßgeblich mitentwickelt, und schon Anfang 2000 hat IBM Offenheit strategisch eingesetzt: Damals haben sie mit der Open Source-Plattform Eclipse die Welt der Java-Entwicklungswerkzeuge auf den Kopf gestellt.
Der Ansatz von IBM ist insofern interessant, da hier wirklich die Option besteht, über OSLC andere Werkzeuge in die Werkzeuglandschaft einzuführen. Wie gut das in der Praxis funktioniert ist noch mal eine andere Frage.
Und Dassault?
Bei Dassault bin ich leider nicht ganz so optimistisch, denn im Gegensatz zu NoMagic hat sich Dassault bei offenen Schnittstellen und Integrationsmöglichkeiten eher zurückgehalten. Christian Muggeo hat dazu einen interessanten Artikel verfasst.
MagicDraw ist ein hervorragendes Werkzeug. Das wird es sicherlich bleiben. Die Frage ist eher, wie es sich bei Dassault weiterentwickeln wird. Bleiben die offenen APIs? Werden die Standardformate wie XMI oder ReqIF weiterentwickelt? Offizielle Statements zu solchen Themen sollten mit Vorsicht genossen werden.
Der zweite Vorbehalt ist, dass nach einer Akquise die Integration ins existierende Portfolio in der Regel eine höhere Priorität hat als neue Features zu entwickeln. Auch das ist für Nutzer von No Magic nicht unbedingt die beste Nachricht. Interessanterweise kann dies durchaus für die Kunden messbare Vorteile bringen, auch wenn sich für die Ingenieure die Situation gefühlt verschlechtert.
Andererseits hat eine Firma wie Dassault ganz andere Ressourcen, und kann dementsprechend viel bewegen. Nur die Zeit wird zeigen, was dies für MagicDraw bedeutet.
