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.

Bild: Flickr / Hypnotica Studios Infinite

Dieser Artikel erschien zuerst bei se-trends.de.

  • danielsiegl

    Und plötzlich ist Enterprise Architect das einzige ( im DACH Raum etablierte) Tool das unabhängig ist.

    • pica

      Was bedeuten die Adjektive „unabhängig“ und „etabliert“ in diesem Kontext?

      Ich kenne einige Unternehmen in der DACH Region, die IBM Rational Rhapsody oder PTC UML Designer oder auch Software AG ARIS UML Designer nutzen. Warum gelten diese Tools nicht als „etabliert“?

      Was macht ein Tool „unabhängig“? Oder anders herum gefragt: Warum gelten die Tools IBM Rational Rhapsody oder PTC UML Designer oder auch Software AG ARIS UML Designer als nicht „unabhängig“?

      /pica

      • danielsiegl

        Mit „unabhängig“ meine ich Tools die nicht Teil des Portfolios eines großen Herstellers sind, sondern von einem Hersteller der sich auf diskrete Modelierung zu 100% fokusiert.

        Rhapsody ist Teil von IBM
        Artisan ist Teil von PTC
        Magic Draw jetzt eben von Dassault
        ??? – wenn wird Siemens kaufen

        Aris ist mir im SysML Umlfeld noch nicht untergekommen – d.h für mich nicht etabliert.

        das japanische Ashta ist in japan etabliert – aber im DACH Raum nicht.

        Divere Eclipse Lösungen könnte man noch aufführen – diese sind aber meist von der Usablilty nicht ganz dort wie die kommerziellen Tools.

      • pica

        Also bezieht sich das meiner Meinung nach falsch gewählte Adjektiv „unabhängig“ nicht auf das Tool sondern auf die Hersteller der Tools. Ein Hersteller der nur ein Produkt im Portefolio hat ist genauso Marktzwängen unterworfen wie ein Hersteller der mehrere Produkte im Portefolio hat. Ein Hersteller, welcher mehrere Produkte im Poertefolio hat kann jedoch querfinanieren und somit ein dringend notwendiges Refactoring eines Produktes finanzieren. Ein Hersteller, welcher mehrere Produkte im Poertefolio hat somit mehr Freiheiten, ist meiner Meinung nach unabhängiger.

        Diese Art Fehler passen aber zu Sparx Enterprise Architekt:
        Modelle mit gemäß UML/SysML Spezifikation unzulässigen Assoziationen, finde ich häufig in mit Sparx Enterprise erstellten Modellen. Als Grund hierfür sehe ich die ungenügende Regelprüfung während der Eingabe. Gut Sparx EA bietet eine sogenannte Modellprüfung an. Aber diese meckert nicht einmal zwei gleichnamige Klassen in einem Package an. Zudem ist die Modellprüfung in Sparx EA sehr gut versteckt.

        Aufgrund der mangelhaften Regelprüfung, das beim Löschen von Elementen aus dem Modell obsolet gewordene Assoziationen im Modell verbleiben und etlichen weiteren von mir für Version 6 gemeldeten und in der aktuellen Version 13.5 nachvollziehbaren Fehlern ist Sparx EA für mich als Modellierungswerkzeug indiskutabel. Als Visio Ersatz mit Repository hingegen verwende ich Sparx EA recht gerne. Zumal die Lizenzkosten von EA deutlich unter denen von Visio liegen.

        Stimmt Software AG ARIS UML Designer ist ein reines UML Werkzeug, welches die UML 2.4.1 Spezifikation nahezu wortgetreu umsetzt. SysML wird nicht unterstützt. Verwendet wird der Software AG ARIS UML Designer nur von Kunden die auch die BPM Komponenten von ARIS nutzen.

        Die MID aus Nürnberg ist noch ein rein auf Modellierungswerkzeuge spezialisierter Hersteller mit einen UML Werkzeug, welches unter Anderem von der Deutschen Post DHL genutzt wird. Jedoch SysML unterstützt der MID Innovator auch nicht.

        Modelio von ModelioSoft bietet zwar UML und SysML. Dieses Tool habe ich jedoch in DACH noch nie bei einem Kunden angetroffen. Dafür ist dieses Tool aus meiner Sicht das UML Tool mit der besten Usabilty. Modelio bietet für verschiedene Skill Level gut angepasste Perspectives (ist Eclipse basiert). Die drag ´n drop Funktionalitäten sind aus meiner Sicht einfach genial. Die gute Regelprüfung während der Eingabe mit sehr verständlich formulierten Meldungen halte ich für vorbildlich.

        /pica

        BTW Siemens hat vor kurzem Mentor Graphics gekauft. Dabei ist aber das xtUML Tool BridgePoint von Mentor Graphics nicht betroffen gewesen. Die Firma hinter BridgePoint ist somit wieder OneFact.

      • danielsiegl

        Leider ist Ihr letzter Kommentar hier nicht 😉 Würde mich über ein persönliches Gespräch freuen – Ich kann Sie hier nicht direkt kontaktieren