Dieser Grundlagenstreit um MDA und MOF könnte laut Bast den sowieso schon mehrfach modifizierten Fahrplan für UML 2.0 weiter durcheinanderbringen. Ferner gebe es eine weitere OMG-Fraktion, zu der etwa Telelogic gehört, die UML in eine kompilierbare Sprache für bestimmte Plattformen verwandeln und so den heutigen Programmieraufwand obsolet machen wolle. Dieser Ansatz verschärfe laut Bast den Gegensatz zu MDA, da hierzu eine sehr detaillierte Definition von UML das Ziel sei, während MDA von Haus aus wenig detailliert und plattformunabhängig ist.
Bast kann zudem der Kritik seines Kollegen Boge an den Streitereien in der OMG nur zustimmen. „Große Werkzeughersteller haben kein Interesse an einer Standardisierung ihrer Produkte und machen in erster Linie aus Marketing-Gründen mit. Die kleinen Anbieter brauchen hingegen die UML-Standards, um ihre Produkte besser gegen die Konkurrenz positionieren zu können.“ Es komme nicht selten vor, dass kurz vor der Verabschiedung neuer Spezifikationen in letzter Minute eine Eingabe gemacht werde, um das Verfahren zu behindern. „Offziell ist das natürlich schwer nachzuweisen.“ Zudem sei die Rolle der OMG heute längst nicht mehr unangefochten. Ursprünglich als Gegenpol zu Microsoft gegründet, gerate sie nun deshalb in die Kritik, weil die Verhältnisse im Markt heute nicht mehr so eindeutig seien: „Microsoft wird nicht mehr als Bedrohung im Backend gesehen, und IBM beispielsweise übt immer mehr den Alleingang.“
Pragmatisches Vorgehen empfohlen
Ob daher in diesem Quartal eine Abstimmung über die Pakete von UML 2.0 gelingt und damit die Abschlussarbeiten beginnen können, vermag Bast nicht zu sagen. Die UML-Anwenderschaft sollte pragmatisch vorgehen und nicht auf die Erfüllung einzelner Requests for Proposals warten oder frühen Versprechungen, die Tool-Anbieter wie Telelogic zu UML 2.0 abgegeben haben, zu viel Aufmerksamkeit schenken. Vielmehr sollten Benutzer „ihren Horizont erweitern“, indem sie sich mit dem über UML hinausgehenden Konzept von MDA vertraut machen und prüfen, ob dies für ihre Projekte Sinn gibt und UML oder vielleicht andere Modellierungssprachen besser zu den eigenen Anforderungen passen. Im nächsten Schritt sollten sie die Tools und die Spezifikationen anschauen und nur die für die eigenen Zwecke hilfreichen Teile verwenden.