DE

Dieser Text dient ausschließlich Informationszwecken. Eine Zusammenfassung dieser Entscheidung wird in allen Amtssprachen der Gemeinschaft im Amtsblatt der Europäischen Union veröffentlicht.

Nur der englische Text ist verbindlich

VERORDNUNG (EG) Nr. 139/2004 FUSIONSKONTROLLVERFAHREN

Artikel 8 Absatz 1 Datum: 5.3.2008

DE

DE

Brüssel, den 5.3.2008

K(2008) D/200977

NICHTVERTRAULICHE FASSUNG

ENTSCHEIDUNG DER KOMMISSION

vom 5. März 2008

über die Vereinbarkeit eines Zusammenschlusses mit dem Gemeinsamen Markt und dem EWR-Abkommen

(Sache COMP/M.4747 - IBM/ TELELOGIC)

DE

DE

Entscheidung der Kommission

vom 5.3.2008

über die Vereinbarkeit eines Zusammenschlusses mit dem Gemeinsamen Markt und dem EWR-Abkommen

Sache COMP/M.4747 – IBM/ TELELOGIC

(Nur der englische Text ist verbindlich)

(Text von Bedeutung für den EWR)

DIE KOMMISSION DER EUROPÄISCHEN GEMEINSCHAFTEN –

gestützt auf den Vertrag zur Gründung der Europäischen Gemeinschaft,

gestützt auf das Abkommen über den Europäischen Wirtschaftsraum, insbesondere auf Artikel 57,

gestützt auf die Verordnung (EG) Nr. 139/2004 des Rates vom 20. Januar 2004 über die Kontrolle von Unternehmenszusammenschlüssen, insbesondere auf Artikel 8 Absatz 1,

angesichts der Entscheidung der Kommission vom 3. Oktober 2007, in dieser Sache das Verfahren einzuleiten,

nach Anhörung des Beratenden Ausschusses für Unternehmenszusammenschlüsse,

in Kenntnis des Abschlussberichts des Anhörungsbeauftragten in dieser Sache,

IN ERWÄGUNG NACHSTEHENDER GRÜNDE:

I. EINLEITUNG

1.Am 29. August 2007 ging infolge einer Verweisung nach Artikel 4 Absatz 5 der Verordnung des Rates (EG) Nr. 139/2004 („Fusionskontrollverordnung“) die Anmeldung eines Zusammenschlussvorhabens nach Artikel 4 der Fusionskontrollverordnung bei der Kommission ein. Danach ist Folgendes beabsichtigt: Das Unternehmen International Business Machines Corporation

1ABl. L 24 vom 29.1.2004, S. 1

(„IBM“, USA) erwirbt im Sinne von Artikel 3 Absatz 1 Buchstabe b der Fusionskontrollverordnung durch ein am 11. Juni 2007 angekündigtes Übernahmeangebot die alleinige Kontrolle über das Unternehmen Telelogic AB („Telelogic“, Schweden).

2.Nach Prüfung der Anmeldung kam die Kommission am 3. Oktober 2007 zu dem Schluss, dass das angemeldete Vorhaben unter die Fusionskontrollverordnung fällt und hinsichtlich seiner Vereinbarkeit mit dem Gemeinsamen Markt und dem EWR-Abkommen zu ernsten Bedenken Anlass gibt. Daher leitete sie das Verfahren nach Artikel 6 Absatz 1 Buchstabe c der Fusionskontrollverordnung ein.

3.Im Hinblick auf eine eingehende Prüfung des angemeldeten Vorhabens übermittelte die Kommission IBM am 19. Oktober 2007 ein Auskunftsverlangen gemäß Artikel 11 Absatz 3 der Fusionskontrollverordnung. Da IBM innerhalb des im Auskunftsverlangen vorgegebenen Zeitraums keine korrekten und vollständigen Angaben gemacht hat, nahm die Kommission am 15. November 2007 eine Entscheidung gemäß Artikel 11 Absatz 3 der Fusionskontrollverordnung an, mit der sie die für die Bewertung des Vorhabens erforderlichen Informationen anforderte. Gleichzeitig setzte sie die von der Fusionskontrollverordnung vorgesehenen Fristen ab dem 5. November 2007 aus. Nach Erfüllung des Auskunftsverlangens durch IBM wurde die Aussetzung der Fristen am 3. Dezember 2007 wieder aufgehoben.

Der Beratende Ausschuss erörterte den Entwurf dieser Entscheidung am 20. Februar 2008.

II. DIE BETEILIGTEN UNTERNEHMEN

5.Das US-Unternehmen IBM (der „Anmelder“) ist weltweit in den Bereichen Entwicklung, Produktion und Vermarktung einer Vielzahl von Produkten, Software und Dienstleistungen der Informationstechnologie („IT“) tätig. Zu den verschiedenen Tätigkeiten im Softwarebereich von IBM gehören auch die Entwicklung und der Verkauf von Softwareentwicklungswerkzeugen, d. h. Software, die zur Konzeption und zur Entwicklung von Software eingesetzt wird.

6.Das schwedische Unternehmen Telelogic ist in der Entwicklung und dem Verkauf von Softwareentwicklungswerkzeugen tätig.

III. DAS VORHABEN

7.Am 11. Juni 2007 kündigt IBM offiziell seine Absicht an, ein öffentliches Übernahmeangebot für die Gesamtheit des Aktienkapitals von Telelogic zu unterbreiten. Das Angebot von IBM war u.a. an die folgenden beiden Bedingungen geknüpft: (i) IBM erwirbt mindestens 90 % der von Telelogic ausgegebenen Aktien und (ii) die zuständigen Wettbewerbsbehörden stimmen dem Vorhaben zu. Nach

4Telelogic und IBM werden nachstehend gemeinsam auch als die „beteiligten Unternehmen“ bezeichnet.

Abschluss des Vorhabens würde IBM über eine Beteiligung in Höhe von mindestens 90 % und damit über die alleinige Kontrolle über Telelogic verfügen.

IV. DER UNTERNEHMENSZUSAMMENSCHLUSS

Das angekündigte Vorhaben umfasst den Erwerb der alleinigen Kontrolle über Telelogic durch IBM. Daher stellt es einen Unternehmenszusammenschluss im Sinne von Artikel 3 Absatz 1 Buchstabe b der Fusionskontrollverordnung dar.

V. GEMEINSCHAFTSWEITE BEDEUTUNG

Der angemeldete Zusammenschluss liegt unterhalb der Umsatzschwellen gemäß Artikel 1 Absatz 2 und 3 der Fusionskontrollverordnung

Am 28. Juni 2007 ging bei der Kommission ein vom Anmelder gestellter Verweisungsantrag nach Artikel 4 Absatz 5 der Fusionskontrollverordnung ein, der an alle Mitgliedstaaten weitergeleitet wurde. Da der angemeldete Zusammenschluss für eine Prüfung nach den nationalen Wettbewerbsvorschriften von zehn Mitgliedstaaten in Frage kommt und kein Mitgliedstaat innerhalb der in Artikel 4 Absatz 5 vorgegebenen Fristen Einwände gegen den Antrag auf Verweisung der Sache an die Kommission erhoben hat, geht die Kommission in dem Entscheidungsentwurf von der gemeinschaftsweiten Bedeutung des Zusammenschlusses aus.

VI. DIE RELEVANTEN MÄRKTE

VI.1. Die sachlich relevanten Märkte

VI.1.1. Definition der sachlich relevanten Märkte

11.Der geplante Zusammenschluss hat Auswirkungen auf den Markt für Softwareentwicklungswerkzeuge. Softwareentwicklungswerkzeuge dienen zur Entwicklung neuer und zur Weiterentwicklung bestehender Softwareanwendungen. Im Einzelnen dienen diese Werkzeuge der Steigerung der Effizienz des Softwareentwicklungsprozesses. In einer internen Unterlage von IBM werden Softwareentwicklungswerkzeuge definiert als „eine Kategorie von Software, die Organisationen während ihres gesamten Lebenszyklus bei der Schaffung und beim Management von Softwareprodukten dient. Unter Softwareprodukten sind Softwareanwendungen, -dienste und in Geräte oder Systeme eingebettete Software zu verstehen“ .

Sowohl IBM als auch Telelogic bieten Softwareentwicklungswerkzeuge an. In ihrer Entscheidung über die Einleitung des Verfahrens war die Kommission zunächst zu

Teile dieses Textes wurden geändert, um vertrauliche Daten zu schützen; die betreffenden Passagen wurden durch eckige Klammern und einen Asteriskus kenntlich gemacht.

dem Schluss gelangt, dass das Vorhaben erhebliche Zweifel hinsichtlich seiner Vereinbarkeit mit zwei vermeintlichen sachlich relevanten Märkten auslösen würde, dem Markt für Anforderungsmanagementwerkzeuge und dem Markt für UML-basierte Modellierungswerkzeuge.

Die von der Kommission durchgeführte eingehende Untersuchung bestätigte weitgehend, dass Anforderungsmanagementwerkzeuge und UML-kompatible Modellierungswerkzeuge als die sachlich relevanten Märkte zu betrachten sind. Allerdings zeigte sich auch, dass im vorliegenden Fall bei der Abgrenzung der sachlich relevanten Märkte aus verschiedenen Gründen Vorsicht angebracht ist. Zum besseren Verständnis der Gründe für diese Vorsicht soll zunächst ein Überblick über die Hauptmerkmale des Marktes vermittelt werden.

VI.1.2. Industriespezifische Merkmale von Softwareentwicklungswerkzeugen

VI.1.2.1. Der Softwareentwicklungszyklus

Der Prozess der Softwareentwicklung kann in fünf Hauptphasen unterteilt werden. In jeder dieser Phasen stehen den Kunden unterschiedliche Kategorien von Werkzeugen zur Verfügung.

15.Die erste Phase entspricht der konzeptuellen Analyse zur Bestimmung der Funktionalitäten, die eine neue Softwareanwendung bieten soll. Analysewerkzeuge (häufig auch „Anforderungsmanagementwerkzeuge“ genannt) unterstützen diesen Prozess, da die Anwenderanforderungen auf diese Weise gesammelt, strukturiert, gespeichert, verwaltet und anschließend durch den gesamten Entwicklungsprozess hindurch gekennzeichnet werden können. Nach Forrester, einem auf die Softwarebranche spezialisierten Analyseunternehmen, „besteht der Zweck des Anforderungsmanagements in der Maximierung der Wahrscheinlichkeit, dass eine Anwendung wie geplant funktioniert und dem Unternehmen seinen vorausberechneten Wert erbringt“. Forrester definiert Anforderungsmanagement als „die Speicherung von Anforderungen, die Herstellung von Relationen zwischen Anforderungen und die Kontrolle der Veränderungen an einzelnen Anforderungen und Gruppen von Anforderungen“.

Steht die von der Softwareanwendung verlangte Funktionalität erst einmal fest, werden die Einzelheiten der Softwarearchitektur während der Modellierungs- oder Designphase entworfen. Während in der Analysephase die Frage lautet: „Welche Funktionen sollte die Software ausführen?“ lautet die Frage in der Design-/Modellierungsphase: „Wie soll die Software die festgelegten Funktionen ausführen?“. Dabei unterstützen Modellierungswerkzeuge den Entwickler bei einer Vielzahl von Aufgaben, so auch bei der Erstellung visueller Modelle („Diagramme“), bei der Definition von Daten und bei der Festlegung von Programmierspezifikationen. Einige Modellierungswerkzeuge können diese Modelle und damit verbundene Informationen nutzen und automatisch Quellcodes generieren. Je nach Detaillierungsgrad der Modelle unterscheiden sich die Codes und reichen von einfachen Code-Frameworks (die später manuell auszufüllen sind) bis zu vollständigen Codes, die keiner weiteren Eingriffe durch den Entwickler mehr bedürfen.

17.Nach Abschluss der Design- und Modellierungsphase muss die Anwendungssoftware umgesetzt werden. Die Umsetzungs- (oder Konstruktions-, oder Kodierungs-) Phase umfasst im Wesentlichen das Schreiben des Software-Codes (der Programmierung). Dies geschieht weitestgehend innerhalb einer Integrierten Entwicklungsumgebung (Integrated Development Environment – „IDE“), einer Softwareanwendung, die das Schreiben eines Software-Codes erleichtert. Wie vorstehend erwähnt können manche Modellierungswerkzeuge automatisch sämtliche oder einen Teil der Quellcodes generieren. Im einfachsten Fall bieten die Bau- (oder Konstruktions-) Werkzeuge Programmeditoren- und Compiler-Funktionen, die zur Übersetzung von höheren Programmiersprachen wie C, C++, COBOL oder Java in eine Sprache auf niedrigerer Ebene erforderlich sind, die von der in Betracht gezogenen Einsatzplattform (Deployment Platform) schneller ausgeführt werden kann.

18.Nach Abschluss der Programmierung der Anwendungssoftware muss sie auf Schwachstellen getestet werden („Debugging“), um sicherzustellen, dass die Software erfolgreich auf der vorgesehenen Einsatzplattform wie den Betriebssystemen Windows, Linux oder UNIX funktioniert. Mit speziellen Testwerkzeugen lassen sich derartige Tests automatisch ausführen, wohingegen bisweilen einige grundlegende Testfunktionalitäten entweder direkt vom Modellierungswerkzeug oder von der integrierten Entwicklungsumgebung bereitgestellt werden.

19.Während und nach der Softwareentwicklung müssen Entwickler konsequent zusammenarbeiten, um die Anwendungsmöglichkeiten der Software ständig zu erweitern. Softwareentwicklungsteams können einige wenige Entwickler – für einfache Projekte – bis zu Hunderten von Mitarbeitern umfassen, die an verschiedenen Standorten gleichzeitig an den kompliziertesten Projekten arbeiten. Die Zusammenarbeit zwischen Softwareentwicklern findet in der Regel über ein Netzwerk statt, über das alle Mitarbeiter verbunden sind, und in das spezialisierte Servercomputer integriert sind, z. B. zur Aufzeichnung des erzeugten Softwarecodes oder um zu gewährleisten, dass verschiedene Teile einer noch in Entwicklung befindlichen Anwendung synchron voranschreiten. Teammanagementwerkzeuge, häufig auch „Software (Change&) Configuration Management“ („SCCM“ oder „SCM“) Werkzeuge genannt, ermöglichen die Speicherung und den Abruf von Teilen der Softwareanwendung und bieten außerdem Reportingfunktionen für Kontrollen und geänderte Fassungen von Softwareanwendungen.

VI.1.2.2. IT-Software and System-Software

20.Der vorstehend beschriebene Softwareentwicklungsprozess trifft auf die beiden Hauptarten von Software zu: Software für IT-Anwendungen und System-Software. Software für IT-Anwendungen ist für den Einsatz auf Standard-Betriebssystemen oder Plattformen konzipiert und in der Regel auf einem Allzweck-Computer installiert (z. B. einem unternehmenstauglichen Server mit einem Linux- oder Windows- Server-Betriebssystem oder auf der Clientseite auf Standard Desktop- oder Laptop-PCs). Diese Art von Software ist insbesondere für den Gebrauch durch den Endanwender konzipiert, so dass der Endanwender damit bestimmte Aufgaben ausführen kann. Software für IT-Anwendungen umfasst eine breite Palette von Programmen, die u.a. folgende Anwendungen umfassen: (i) persönliche Produktivitätsanwendungen (Textverarbeitung, Spreadsheets, usw.) und (ii) Software für unternehmensbasierte Anwendungen (Lohn- und Gehaltsabrechnungsmanagement, Kundenbeziehungsmanagement, Lieferantenmanagement, usw.).

21.System-Software hingegen steuert und kontrolliert Hardware-Komponenten, damit IT-Anwendungssoftware Zugang zu dieser Hardware erhält und eine Aufgabe ausführen kann. Damit ist System-Software auf das Engste mit den Hardware-Komponenten verbunden, die entweder zu allgemeinen Zwecken (z. B. ein Universal-PC oder –Server) oder branchenspezifisch (z. B. Telekomsysteme, Luft- und Raumfahrtsysteme, Medizingerätesysteme) konzipiert sind. In der Regel haben die Endanwender keinen direkten Kontakt zu dieser Art von Software.

22.Innerhalb der Kategorie Systemsoftware kann die eingebettete (embedded) Software als eine Unterkategorie angesehen werden. Im Gegensatz zu allgemeiner Systemsoftware wurde die eingebettete Software eigens für ganz bestimmte Hardwarekomponenten entwickelt, mit denen sie aufs Engste verbunden ist. Damit stellt sie einen integrierenden Teil des Systems (oder Subsystems) dar, mit dem sie geliefert wird. Im Gegensatz zu Software für IT-Anwendungen besteht die Hauptfunktion von eingebetteter Software nicht darin, Endanwendern die Ausführung bestimmter Aufgaben zu gestatten, sondern das Zusammenwirken der Hardwarekomponenten, in die sie eingebettet ist, mit externen Faktoren (wie z. B. Licht, Druck, Geschwindigkeit, usw.) zu steuern und kontrollieren. Eingebettete Software befindet sich in der Regel in Autos, Mobiltelefonen, Medizingeräten, usw.

23.Eingebettete Software kann in komplexen Systemen wie Flugzeugen, Raketen und Satelliten eine sehr hohe Komplexität aufweisen. In derartigen komplexen Systemen hat die eingebettete Software mit zahlreichen anderen im System enthaltenen Subsystemen zu interagieren. Eingebettete Software hat zum Teil unter strikten zeitlichen Zwängen (in Echtzeit) die geforderte Leistung zu erbringen. In solchen Fällen erfolgt der Einsatz von eingebetteter Software in der Regel auf spezifischen Betriebssystemen, Echtzeit-Betriebssysteme (Real-Time Operating System - „RTOS“) genannt, im Gegensatz zu Standard-Betriebssystemen, die in Allzweck-Computern zu finden sind, wie Windows-Server.

Allzweck-Computern zu finden sind, wie Windows-Server. Eingebettete Software führt zum Teil Aufgaben aus, die für die Sicherheit ausschlaggebend sind. In solchen Fällen werden die dazu eingesetzten Software-Entwicklungswerkzeuge von den Sicherheitsbehörden zertifiziert, wie z. B. der US Federal Aviation Authority oder der Europäischen Aviation Safety Agency.

VI.1.2.3. Anbieter von Software-Entwicklungswerkzeugen

24.Es gibt die verschiedensten Anbieter von Softwareentwicklungswerkzeugen, von kleinen privaten Firmen, die lediglich ein oder zwei Werkzeuge anbieten, bis hin zu sehr großen IT-Unternehmen, die ein mehr oder weniger breites Angebot bieten (z. B. IBM, Hewlett Packard („HP“), Oracle und Microsoft). Der Geschäftsbereich Software-Entwicklungswerkzeuge von IBM trägt seit der Übernahme von Rational im Jahr 2003 den Namen IBM Rational. Das Anforderungsmanagementprodukt von IBM trägt die Bezeichnung Requisite Pro, und die Hauptproduktfamilien für Softwaremodellierung sind Rational Software Architect („RSA“) und Rational Rose. Zur Produktfamilie von Rational Rose gehören Rational Rose Enterprise, Rational Rose XDE, Rational Modeler, und Rose Technical Developer. Bei diesen Produkten handelt es sich um Legacy-Software, d. h. es werden nicht ständig Updates vorgenommen, und sie werden von IBM nicht mehr aktiv an neue Kunden vermarktet. Folglich stammt das von IBM mit diesen Produkten erwirtschaftete Einkommen aus der Wartung und der Unterstützung dieser Produkte.

25.Zwischen diesen beiden Enden des Anbieterspektrums befinden sich weitere mittelgroße Unternehmen (wie Telelogic), die einige wenige Softwareentwicklungswerkzeuge in ihrer Produktpalette haben. Zu den Hauptprodukten von Telelogic zählen Doors, Focal Point, Rhapsody, TAU, Synergy, Statemate, SDL Suite und System Architect, auf die zusammen 2006 fast der gesamte Umsatz von 175,87 Mio. EUR entfiel. Das Hauptanforderungsmanagementwerkzeug von Telelogic ist DOORS, und die wichtigsten Modellierungswerkzeuge sind Rhapsody, TAU, Statemate und SDL Suite, wobei es sich bei den beiden letztgenannten um Legacy-Produkte handelt. Telelogic erwarb Rhapsody mit der Übernahme von I-logix im Jahr 2006.

26.Die Anbieter vermarkten ihre Werkzeuge entweder direkt über ihre eigene Absatzstruktur oder indirekt über Systemintegratoren. Anbieter wie IBM und Telelogic organisieren ihre Absatzstrukturen weltweit nach verschiedenen geografischen Regionen mit eigens auf diese Regionen spezialisierten Vertriebsstrukturen. Innerhalb dieser Regionen können sich einige dieser Vertriebsstrukturen auch auf bestimmte Großkunden, Branchen oder Produktgruppen spezialisieren. So beschäftigt IBM z. B. in seiner Abteilung „Americas“ […]* und in seiner Abteilung „Südwesteuropa/Naher Osten/Afrika“ […]*. Desgleichen hat Telelogic eigene Vertriebsmanager für […]* in seiner EMEA Abteilung und einen Vertriebsmanager, der in der Asien/ Pazifik-Abteilung für […]* zuständig ist.

27.Systemintegratoren sind unabhängige Serviceprovider, die sich auf den Bau kompletter Computersysteme im Auftrag von Kunden spezialisieren, indem sie Komponenten verschiedner Hardware- und Softwareanbieter zusammenbauen.

VI.1.2.4. Die Nachfrage nach Software-Entwicklungswerkzeugen

28.Anhand der Verwendungszwecke der Softwareentwicklungswerkzeuge können die Abnehmer in drei Hauptkategorien eingeteilt werden.

29.Die erste Gruppe bilden Abnehmer von Softwareentwicklungswerkzeugen, die ein Update oder eine Neuentwicklung von Softwareanwendungen vornehmen möchten, die auf ihre eigenen spezifischen Verwendungszwecke zugeschnitten sind. Von dieser Kundengruppe entwickelte Softwareanwendungen sind nicht für den Handel bestimmt. Diese Kunden verwenden Softwareentwicklungswerkzeuge entweder zur Entwicklung von IT-Softwareanwendungen oder von System-Software oder eingebetteter Software. Letztere sind in der Regel in industriellen oder technischen Sektoren tätig (z. B. Luft- und Raumfahrt/Rüstungsindustrie, Automobilsektor, Energie, Telekom, Medizingeräte, Elektronik, usw.), die anderen in der Regel in den Sektoren IT, öffentliche Verwaltung oder in den Dienstleistungssektoren (z. B. Vertrieb/Einzelhandel, Verkehrssektor, Banken/ Finanzinstitutionen/ Versicherungen, usw.).

30.Auf operationeller Ebene ergibt dies unterschiedliche Nutzerprofile: IT-Software wird von Softwareentwicklern gemeinsam mit den Analytikern aus dem Bereich IT/Geschäftsprozesse und Softwarearchitekten entwickelt, während Systemsoftware von Systemdesignern gemeinsam mit Systemanalytikern und Systemingenieuren entwickelt wird.

31.In diesem Zusammenhang ist darauf hinzuweisen, dass die Kunden von der industriellen/technischen Seite bei der Entwicklung technischer Systeme (einschließlich ihrer Hardware- und Softwarekomponenten) häufig Anforderungsmanagement- und Modellierungswerkzeuge verwenden und nicht Software allein einsetzen. Die Konzeption und Entwicklung technischer Systeme, insbesondere großer und komplexer Systeme erfordert die gleichen Analyse- und Modellierungsverfahren wie die reine Softwareentwicklung.

Siehe […]*, von IBM am 19. Oktober 2007 vorgelegt, und […]*, von IBM am 18. Oktober 2007 vorgelegt.

32. Dazu erklärt der Anmelder: „Während in der Mehrzahl der Fälle Modellierung in der Softwareindustrie gewissermaßen eingesetzt wird, damit Entwicklungsteams verstehen und kommunizieren können, was die Software leistet und wie ihre Architektur beschaffen ist, verwenden Ingenieure, die ihre komplexen Systemmodelle validieren möchten, häufig bereits ausführbare Modelle, um das tatsächliche Verhalten (d .h. die Logik) der Software zu beschreiben“ .

Z. B. VsWorkd, Windows CE oder hausinterne rechtlich geschützte Betriebssysteme

33.Eine ähnliche Erklärung führt IBM in Bezug auf Anforderungsmanagementwerkzeuge an: „DOORS ist ein „datenbankzentriertes“ fortschrittliches Werkzeug für komplexe Projekte mit ausgereiften stark strukturierten Prozessen, die eine große Anzahl von Anforderungen mit einem intensiven Prozess zur Anforderungsanalyse beinhalten. DOORS wird in der Regel von Systemingenieuren (z. B. in der Entwicklung eines Luft- und Raumfahrtsystems) verwendet. Umgekehrt ist Requisite Pro ein „dokumentzentriertes“ leichtes auf IT ausgerichtetes Werkzeug, das in der Regel von auf Geschäftsprozesse ausgerichteten Analytikern verwendet wird“ .

34.Die Kunden, die Softwareentwicklungswerkzeuge für ihren eigenen internen Bedarf beschaffen, tun dies entweder direkt, möglicherweise mit Hilfe eines externen Beraters, oder indirekt über Systemintegratoren.

35.Unabhängige Softwareanbieter (Independent Software Vendors – „ISV“) bilden die zweite Kategorie von Kunden für Softwareentwicklungswerkzeuge. ISV sind Unternehmen, die sich auf die Entwicklung und die Vermarktung von Software spezialisiert haben. In der Regel entwickeln und vermarkten ISV IT-Softwareanwendungen.

36.Die letzte Kategorie von Kunden besteht aus Systemintegratoren, die im Auftrag ihrer Kunden Software-Entwicklungswerkzeuge zusammen mit anderen Software- und Hardware-Komponenten nachfragen.

VI.1.2.5. Preisstruktur

37.Die Kosten, die dem Kunden bei der Anschaffung von Software-Entwicklungswerkzeugen entstehen, setzen sich aus folgenden Kostenkomponenten zusammen: Die Kosten für die Lizenz; die Wartungs- und Unterstützungskosten und die Implementierungskosten (d. h. die Kosten für Installierung, Konfiguration, Integration und kundenspezifische Anpassung der Softwareanwendung). Während die Lizenz und die Wartungs-/Unterstützungskosten dem Anbieter von Software Einkommen generieren, schaffen Installierung und Implementierung nicht unbedingt Einkommen für den Anbieter der Software. Dies hängt davon ab, wer diese Arbeiten verrichtet.

38.Anbieter von Software verwenden unterschiedliche Lizenzmodelle. Zunächst kann grob zwischen befristeten und unbefristeten Lizenzen unterschieden werden. Eine unbefristete Lizenz wird einmal erworben und zieht dann jährliche Wartungsgebühren nach sich, während mit befristeten Lizenzen das Recht auf Verwendung der Software für einen bestimmten Zeitraum erworben wird. Über diese grobe Unterscheidung hinaus basieren Lizenzmodelle generell auf der Anzahl der angegebenen Nutzer oder der Gruppe von Nutzern („Seats“) und dem geografischen Standort dieser Nutzer.

39.Im Falle der am Verfahren beteiligten Unternehmen bietet IBM seinen Kunden die Wahl zwischen den beiden Hauptmodellen für unbefristete Lizenzen: (i) eine Lizenz für „autorisierte Nutzer“, wonach die Lizenz nur von einem einzigen Nutzer verwendet werden darf und (ii) eine „Floating-Lizenz“, wonach ein und dieselbe Lizenz von einem Team von Nutzern verwendet werden darf, die diese Lizenz unabhängig von ihrem jeweiligen Standort nutzen können, vorausgesetzt die Gesamtzahl der gleichzeitig berechtigten Nutzer überschreitet nicht die Anzahl der erworbenen Floating-Lizenzen .

40.Die Software-Lizenzmodelle von Telelogic lassen den Kunden die Wahl zwischen einer unbefristeten oder einer befristeten Lizenz mit drei Hauptoptionen: (i) einer rechnergebundenen („node-locked“) Lizenz, wonach die Software von einem nicht-spezifischen Nutzer auf einem ganz spezifischen Rechner genutzt werden kann; (ii) einer nutzergebundenen Lizenz, wonach die Software von einem spezifischen Nutzer auf jedem Rechner genutzt werden kann, der mit dem Lizenz-Server vernetzt ist, und (iii) verschiedenen Floating-Lizenzen, wonach die Software von allen Nutzern in verschiedenen geografischen Konfigurationen genutzt werden kann (ein einziger Standort („single site“), mehrere Standorte („multiple site“), kontinental und global), vorausgesetzt, die Gesamtzahl der gleichzeitig berechtigten Nutzer überschreitet nicht die Anzahl der erworbenen Floating-Lizenzen .

41.Die Wartung umfasst in der Regel auch die Updates von Versionen, die automatische Behebung von Schwachstellen (Bugfixes und Patches) sowie unterschiedliche Unterstützungsleistungen. Wartungskosten werden generell gesondert von der Lizenzgebühr in Rechnung gestellt. So macht die Wartungsgebührenstruktur von Telelogic einen Prozentsatz des Listenpreises ([…]* des Listenpreises, je nach Umfang der Unterstützung) aus. Hingegen sind in der Lizenzgebühr von IBM auch ein Jahr Standardwartung und Unterstützung für eine Gebühr enthalten, die auf […]* einer Gebühr für eine Lizenz hinausläuft, die keine Unterstützung mit einschließen würde .

42.Außerdem gibt es Subskriptionsmodelle, nach denen die Kunden das Recht auf die Nutzung von Softwareprodukten und auf Wartungs- und Unterstützungsleistungen für einen befristeten Zeitraum erwerben. Nach diesem Modell lässt sich der Wert der Lizenzgebühr nicht gesondert von Wartung und Unterstützung bestimmen .

43.Schließlich gewähren die Anbieter ihren Kunden in der Regel auch […]* oder Preisnachlässe. Diese Nachlässe können in der Softwareentwicklungswerkzeug-branche sehr hoch ausfallen. So lassen die […]* von Telelogic Preisnachlässe von bis zu […]* auf den Listenpreis bei den Lizenzgebühren und von über […]* bei den üblichen Wartungsgebühren zu. Preisnachlässe können entweder im Rahmen einer globalen Vereinbarung oder auf Einzelvertragsbasis gewährt werden.

44.Aus der eingehenden Untersuchung ergab sich, dass die Kosten einschließlich Lizenz-, Wartungs- und Unterstützungs- sowie die Deploymentkosten zu den wichtigsten Entscheidungskriterien der Kunden zählen, die in der Entwicklung von IT-Softwareanwendungen tätig sind. Für Unternehmen im industriellen/technischen Sektor sind diese Kosten weit weniger ausschlaggebend, da sie stärker auf die technischen Kriterien der Produkte (z. B. die Funktionalität des Produkts, die Einhaltung von Standards, die Skalierbarkeit, seine Verlässlichkeit/Reifegrad und die Integrierbarkeit mit anderen Werkzeugen, usw.), den Kundendienst und in manchen Fällen auch die Referenzen des Anbieters, seine Reputation und sein Engagement in Bezug auf das jeweilige Werkzeug achten. Aus vertraulichen internen Unterlagen, die einige industrielle Großkunden vorgelegt haben, ging hervor, dass kostenbezogene Kriterien in ihrem Werkzeugauswahlprozess nur zu höchstens 30 % ausschlaggebend waren, während die technologiebezogenen Kriterien mit 60 % zu Buche schlugen. […]* „der Preis ist bei der Entwicklung von IT-Anwendungen stärker ausschlaggebend als bei der Systementwicklung“ .

VI.1.2.6. Beschaffung von Softwareentwicklungswerkzeugen

45.Die Kunden schaffen Softwareentwicklungswerkzeuge im Wesentlichen zu drei Zwecken an: (i) für neue Vorhaben; (ii) im Gefolge einer Standardisierungsinitiative und (iii) für bestehende Projekte.

46.Die meisten Kunden erwerben die Werkzeuge auf Projektbasis, was bedeutet, dass die ausgewählten Werkzeuge nur für ein spezifisches Projekt verwendet werden. In diesen Fällen erfolgt die Werkzeugauswahl häufig auf unterer Ebene innerhalb einer Organisation, d. h. auf Ebene der Abteilung oder des Teams, das für das Projekt zuständig ist.

47.Einige Kunden – hauptsächlich große Organisationen, die in der Regel in den industriellen/technischen Sektoren aktiv sind – haben ihre Beschaffungsverfahren von Softwareentwicklungswerkzeugen standardisiert. Zweck der Standardisierung ist die Rationalisierung der mit der Beschaffung verbundenen Entscheidungen im Unternehmen im Hinblick auf möglichst hohe Preisnachlässe vonseiten der Anbieter und die Erleichterung der Zusammenarbeit über die verschiedenen Geschäftsbereiche oder Abteilungen im Unternehmen hinweg. Unternehmen mit einer standardisierten Beschaffungspolitik haben meistens zunächst einen eingehenden Bewertungsprozess der verschiedenen auf dem Markt verfügbaren Werkzeuge anhand der technischen Kriterien durchlaufen, die ihren Bedarf auf Unternehmensebene bestimmen. Das Ergebnis dieses Bewertungsprozesses ist eine Liste „empfohlener“ oder „bevorzugter“ Werkzeuge (in der Regel eines für jede Produktkategorie), die von den operationellen Abteilungen oder Projektteams rasch beschafft werden können. Allerdings können zuweilen auch andere Werkzeuge angeschafft werden. Standardisierung ist bei Kunden üblich, die Softwareentwicklungswerkzeuge zur Entwicklung komplexer Systeme/eingebetteter Software benötigen (z. B. Kunden aus der Luft- und Raumfahrtbranche und der Rüstungsindustrie).

48.Schließlich schaffen Kunden Softwareentwicklungswerkzeuge auch für ihre bestehenden Projekte an, entweder wenn ihre befristeten Lizenzen auslaufen (Verlängerung) oder wenn neue Mitglieder ins Team aufgenommen werden müssen, weil ein Upgrade oder eine Erweiterung (add-on) vorgenommen werden muss. In solchen Fällen erwirbt der Kunde generell (zusätzliche) Lizenzen für das Werkzeug, das bereits für das bestehende Projekt eingesetzt wird. Alternative Werkzeuge werden in diesem Fall nicht in Betracht gezogen. Daher findet bei der Beschaffung von Softwareentwicklungswerkzeugen für bestehende Projekte kein Wettbewerb statt.

49.Nimmt der Kunde ein neues Vorhaben in Angriff oder hat er eine Standardisierung des Beschaffungsprozesses beschlossen, muss er zunächst seinen internen Bedarf ermitteln. Im Fall von großen Organisationen kann daraus ein langwieriger und komplexer Prozess werden, an dem verschiedene Geschäftsabteilungen oder Tochterunternehmen, die in verschiedenen Industriebranchen angesiedelt sind, mitwirken. Danach muss er sich über die Produkte informieren, die seinem Bedarf

möglicherweise entsprechen würden. In der Regel wird der Kunde zunächst anhand der öffentlich zugänglichen Informationen der Anbieter eine längere Liste von Produkten (meistens zwischen 5 und 20) erstellen, ohne diese Produkte vorher bewertet/getestet zu haben. Im Anschluss an eine erste grundlegende interne Bewertung erfolgt dann die Erstellung einer Shortlist. Auf den Shortlists stehen meistens zwischen 2 und 5 verschiedene Produkte. Nur Produkte von der Shortlist werden dann eingehend bewertet und getestet (ausführliche Präsentation durch die Anbieter, Versuche, Vorführungen usw.). Dieser Auswahlprozess ist hauptsächlich auf die Bewertung der Produkteigenschaften ausgerichtet. Es handelt sich dabei um einen Lernprozess für den Kunden, der wegen der Heterogenität der zahlreichen verfügbaren Produkte erforderlich ist.

VI.1.2.7. Best-of-Breed-Produkte und Suiten

50.In jeder Phase des vorstehend beschriebenen Softwareentwicklungsprozesses stehen dem Entwickler unterschiedliche Werkzeuge zur Verfügung. „Best-of-Breed-Produkte“ (auch „Point-Produkte“ genannt) zeichnen sich durch individuelle Funktionalität aus und unterstützen daher den Kunden in einer spezifischen Phase des Softwareentwicklungsprozesses. Best-of-Breed-Produkte sind eigenständige (stand-alone) Produkte, die als problemgerechte Lösungen allein verkauft werden. IDC, eine Branchenanalyst, definiert Best-of-Breed-Produkte folgendermaßen: „Ein Point-Produkt ist eine Software für eine einzelne Funktion oder eine sehr begrenzte Anzahl von Funktionen, die im Gegensatz zu einer Suite einzeln verkauft wird“ .

51.Im Gegensatz dazu werden einige Werkzeuge – häufig Suiten genannt – angeboten, die den Kunden in verschiedenen Phasen des Entwicklungsprozesses unterstützen. In Produkt-Suiten werden verschiedene Softwarewerkzeuge gebündelt, die unterschiedliche und sich ergänzende Funktionalitäten im Softwareentwicklungsprozess ausführen. IDC definiert Produkt-Suiten wie folgt: „Eine Suite ist eine Kombination aus Softwareprodukten, Modulen oder Diensten, um eine vollständigere Palette von Softwarefunktionalitäten anbieten und redundante Prozesse aussparen zu können. Häufig erfolgt die Kombination im wissenschaftlichen Sinn in Form einer Integration im Rechner, doch ebenso häufig steht sie allein zu Marketingzwecken auf dem Papier“ .

52.IDC erläutert ebenfalls, dass „ein gemeinsames Phänomen in der Software-Industrie darin besteht, dass neue Technologien zunächst als Stand-alone-Produkte auf dem Markt erscheinen, d. h. als einzigartige Produkte. Im Laufe der Zeit werden diese Produkte immer mehr zu Funktionen/Merkmalen stärker integrierter Produkte oder Produkt-Suiten“ .

Unterlage „IDC's Software Taxonomy, 2007“, Seite 96, von IBM am 19. September 2007 vorgelegt.

Unterlage „IDC's Software Taxonomy, 2007“, Seite 97, von IBM am 19. September 2007 vorgelegt

Unterlage „IDC's Software Taxonomy, 2007“, Seite 104, von IBM am 19. September 2007 vorgelegt

VI.1.2.8. Interoperabilität von Softwareentwicklungswerkzeugen

53.Es gibt kein einzelnes Werkzeug, das sämtliche unterschiedlichen Funktionalitäten aufweist, die in den einzelnen Phasen des Softwareentwicklungsprozesses erforderlich sind. Da ein erheblicher Teil der Kunden zu einer Politik des „Mix-und-Match“ tendiert, also der Kombination mehrerer Best-of-Breed-Produkte, ist die Interoperabilität zwischen Softwareentwicklungswerkzeugen unterschiedlicher Herkunft ein Schlüsselthema in der Branche und eine Frage, der die Kunden große Bedeutung beimessen. Daher haben die Anbieter von Software ein Interesse daran, dass sich eine möglichst breite Palette von Software mit ihrer eigenen Software kombinieren lässt, wodurch sie […]* ein „Ökosystem von Business Partnern“ schaffen. Dadurch gewinnen sie für die Kunden an Attraktivität.

54.Interoperabilität zwischen verschiedenen Softwareprodukten und Anbietern wird entweder durch die Verwendung gemeinsamer Dateiformate (wodurch die Softwareanwendung eines Anbieters das lesen und verstehen kann, was die Softwareanwendung des anderen Anbieters geschrieben hat) oder über sog. Anwendungsprogrammierschnittstellen („API“ - Application Programming Interfaces) erreicht, mit denen die Daten einer Anwendung nach den Vorstellungen des Anwenders in strukturierter Weise zugänglich und abrufbar werden. So kann z. B. ein Anforderungsmanagementwerkzeug eine API-Schnittstelle aufweisen, wodurch andere Anwendungen das Anforderungsmanagementwerkzeug anweisen, einige Anforderungen unter bestimmten Bedingungen auszuwählen und dann sämtliche mit diesen Anforderungen verbundenen Informationen in einem bestimmten Standardformat zu exportieren. Durch eine solche API-Schnittstelle könnte sich eine andere Anwendung nahtlos in das Anforderungsmanagementwerkzeug integrieren. Für dieses Zusammenwirken beider Anwendungen wäre keinerlei menschliches Eingreifen erforderlich; d. h. sie funktionieren so, als ob sie von vornherein auf Interoperabilität ausgerichtet gewesen wären.

55.Im Sinne einer leichteren Interoperabilität können die Anbieter entweder direkten Zugang zu den interoperabilitätsbezogenen Informationen ihrer rechtlich geschützten Software gewähren oder die Entwicklung gemeinsamer Standards fördern. So bietet z. B. die von IBM 2001 geschaffene Plattform Eclipse-Technologie , die die Entwicklung von Softwareentwicklungswerkzeugen erleichtert, die miteinander interoperabel sind. Die „Object Management Group“, die von elf Software-Anbietern einschließlich IBM gegründet wurde und für die Definition und die Wartung der Universal-Modellierungssprache „UML“ zuständig ist, ist ein weiteres Beispiel für die Bemühungen der Anbieter um mehr Standardisierung.

Siehe z. B. […]*, 30. Oktober 2007, Seite 40, von IBM in Anhang 10 der Antwort vom 5. November 2007 auf das Auskunftsverlangen der Kommission vom 19. Oktober 2007 vorgelegt.

Siehe http://www.eclipse.org/

Siehe http://www.omg.org/

VI.1.2.9. Kommerzielle Software und freie Software

56.Ein weiteres Kennzeichen der Softwareentwicklungswerkzeugbranche (und der Softwarebranche insgesamt) ist das Phänomen und die rasche Entwicklung der sog. „Open-Software“, also Software mit offenem Quellcode. Bei Open-Source-Software ist nämlich der Quellcode über eine Lizenz zugänglich, die es Entwicklern gestattet, diese Software zu verwenden, zu verändern, weiter zu verbessern und in geänderter Form oder unverändert weiter zu vertreiben . Diese Zugangsberechtigung führt zur Entstehung von Entwicklungsgemeinschaften, die zusammen an der Weiterentwicklung von Softwarewerkzeugen arbeiten.

57.Open-Source-Software wird generell kostenlos angeboten, doch bieten viele Unternehmen kommerzielle Unterstützung für bestimmte Open-Source-Produkte an. Wie jedoch in der Entscheidung über die Einleitung des Verfahrens erwähnt, werden Open-Source-Werkzeuge zur Softwareentwicklung von den industriellen Großkunden noch nicht als glaubwürdige Alternative zu kommerziellen Softwarewerkzeugen betrachtet, da sie nicht genügend Garantien im Hinblick auf ihre Stabilität, Wartung und Weiterentwicklung bieten. Solche frei verfügbaren Produkte werden nämlich in der Regel nicht von den kommerziellen Händlern, sondern nur von einer Gemeinschaft privater Entwickler unterstützt .

58.Die Vor- und Nachteile von Open-Source-Software werden in […]* folgendermaßen dargestellt:

Siehe Anmeldung, Seite 37.

Siehe Anmeldung, Seite 37.

Erwägungsgrund 41 der Entscheidung der Kommission über die Einleitung des Verfahrens vom 3. Oktober 2007.

Tabelle 1: Die Hauptvor- und –nachteile von Open-Source-Software sind generell bei allen Arten von Software anzutreffen.

Hauptvorteile

Hauptnachteile

ƒ Keine Kosten oder Probleme mit Lizenzen

ƒ Empfundenes Risiko – kein Anbieter, der Unterstützung bietet, für Fehler aufkommt und für eine stabile Weiterentwicklung sorgt

ƒ Werkzeuge sind flexibel und erweiterungsfähig

ƒ Ausgezeichnete Unterstützung durch die Entwicklergemeinschaft (für Entwickler, besser als durch kommerzielle Anbieter)

ƒ Einige Werkzeuge (z. B. Eclipse) von hoher Qualität

VI.1.3. Die für die wettbewerbsrechtliche Würdigung des beabsichtigten Zusammenschlusses sachlich relevanten Märkte

59.In einer früheren Entscheidung hatte die Kommission die Frage offen gelassen, ob es einen Markt für Softwareentwicklungswerkzeuge gibt, oder ob im Bereich der Softwareentwicklungswerkzeuge verschiedene sachlich relevante Märkte voneinander abzugrenzen sind .

60.In der Entscheidung über die Einleitung des Verfahrens war die Kommission zunächst zu dem Schluss gelangt, dass die sachlich relevanten Märkte, auf denen der beabsichtigte Zusammenschluss erhebliche Auswirkungen auf den Wettbewerb haben könnte, folgendermaßen abzugrenzen sind:

• Der Markt für UML-basierte Modellierungswerkzeuge, der Gartners Kategorie „Object-Oriented Analysis & Design“ ("OOA&D") entspricht, unabhängig davon, ob dieser Markt noch weiter in Werkzeuge für IT-Anwendungen und Werkzeuge für System-Software aufgeteilt werden muss;

• Der Markt für Anforderungsmanagementwerkzeuge, der Gartners Kategorie „Requirements Management” entspricht, unabhängig davon ob dieser Markt noch weiter in Werkzeuge für IT-Anwendungen und Werkzeuge für System-Software aufgeteilt werden muss.

38Siehe Entscheidung der Kommission vom 20. Februar 2003, Sache COMP/M.3062 – IBM/Rational, Erwägungsgrund 57.

DE

DE

61.Gartner ist ein Branchen-Analyst, der Marktdaten, Research und Analysen zum Sektor Informationstechnologie einschließlich Softwareentwicklungswerkzeuge anbietet. Insbesondere legt Gartner Marktsegmente fest, anhand derer die Marktgröße und die Marktanteile der Anbieter ermittelt werden können. Zur Ermittlung der sachlich relevanten Märkte im IT-Sektor hatte sich die Kommission bereits in früheren Entscheidungen auf die Segmentabgrenzung von Gartner gestützt . In der Entscheidung über die Einleitung des Verfahrens war die Kommission vorläufig zu dem Schluss gelangt, dass Gartners Marktsegmente für Softwareentwicklungswerkzeuge einen geeigneten Rahmen für die Untersuchung der Auswirkung des beabsichtigten Zusammenschlusses auf den Wettbewerb darstellen .

62.Der Anmelder argumentiert, dass Gartners Kategorien „OOA&D“ und „Requirements Management“ keine sachlich relevanten Märkte darstellen, da dabei zwei Komponenten nicht angemessen berücksichtigt werden: (i) Open-Source-Produkte und (ii) die in Suiten integrierte Modellierungs- und Anforderungsmanagementfunktionalität. Im Hinblick auf die Modellierung würde Gartners Kategorie OOA&D außerdem die Modellierungswerkzeuge nicht angemessen berücksichtigen, die nicht auf UML-Basis konzipiert sind. Und schließlich ist IBM der Ansicht, dass die unterschiedlichen Produktmärkte nicht nach Softwarearten (IT- oder System-Software) oder nach Verwendungsbranchen voneinander abgegrenzt werden sollten.

Jede dieser Fragestellungen wird nachstehend ausführlich erörtert.

VI.1.3.1. Open-Source-Produkte

64.Generell kann man sagen, dass Open-Source-Produkte in der Software-Branche im Allgemeinen und auch in einigen Bereichen der Werkzeugindustrie für die Softwareentwicklung immer populärer werden. Doch eingehende Untersuchungen haben ergeben, dass die Kunden bei den Modellierungs- und Anforderungsmanagementwerkzeugen eher davon ausgehen, dass Open-Source-Produkte vor allem bei kleinen Softwareentwicklungsprojekten, nicht jedoch bei größeren und komplexen Projekten glaubwürdige Alternativen zu kommerzieller Software bilden. Als Hauptgründe für den Verzicht auf Open-Source-Werkzeuge für große Projekte nennen die Kunden: (i) Mangel an Wartung und Unterstützung, (ii) nicht genügend Funktionalitäten, (iii) mangelnde Reife, (iv) Befürchtungen hinsichtlich der Dauerhaftigkeit der Werkzeuge, (v) mangelnde Schnittstellen/Interoperabilität mit anderen Werkzeugen und (vi) mangelnde Politik oder Strategie im Unternehmen zur Verwendung von Open-Source-Software.

39Siehe Entscheidung der Kommission vom 22. Dezember 2005 in der Sache COMP/M.3978 – Oracle/Siebel, und vom 26. Oktober 2004 in der Sache COMP/M.3216 – Oracle/Peoplesoft

40Siehe Erwägungsgrund 25 der Entscheidung der Kommission über die Einleitung des Verfahrens vom 3. Oktober 2007.

41Siehe Antworten auf die Fragen 26 (Modellierungswerkzeuge) und 60 (Anforderungsmanagementwerkzeuge) des an die Kunden gerichteten Auskunftsverlangens der Kommission.

65.Hinsichtlich der weiteren Entwicklung der Haltung der Kunden zu Open-Source-Werkzeugen zeigte sich bei der eingehenden Untersuchung, dass einige Kunden in den nächsten zwei bis drei Jahren möglicherweise mehr Werkzeuge dieser Art einsetzen wollen, hauptsächlich für kleine Projekte, für die sich der Einsatz kommerzieller Software aus Kostengründen nicht immer lohnt. Die Mehrheit der Kunden hat jedoch nicht vor, ihre Einstellung zu Open-Source-Werkzeugen maßgeblich zu ändern, da sie davon ausgehen, dass sich die derzeitigen Beschränkungen im Einsatz solcher Werkzeuge, insbesondere ihre unzureichenden Funktionalitäten und ihr Mangel an Wartung und Unterstützung innerhalb eines solchen Zeitraums nicht effektiv beheben lassen. Ein im Energiesektor tätiger Großkunde erklärt dazu: „Wir haben uns nach Open-Source-Werkzeugen umgeschaut, gehen aber nicht davon aus, dass wir diese Software einsetzen, da unsere Einsatzmöglichkeiten wegen des Mangels an berechenbarer Wartung und Unterstützung zu stark beschränkt wären“ .

66.Die eingehende Untersuchung ergab außerdem, dass die Anbieter kommerzieller Software generell davon ausgehen, dass ihre kommerzielle Software kaum im Wettbewerb mit Open-Source-Anforderungsmanagement- und Modellierungswerkzeugen bei großen Projekten steht. Dazu ein Anbieter von Modellierungswerkzeugen: “Artisan konkurriert nicht mit Open-Source-Produkten auf unseren Märkten, da diese Werkzeuge kaum zu großen Modellen und für große Teams skalierbar sind und diese sich daher kaum damit auskennen“ .

67.Das Ergebnis der eingehenden Untersuchung stimmt mit einer […]* Unterlage jüngeren Datums […]* überein, worin die Vorteile („drivers“) und Nachteile („inhibitors“) der Einführung von Open-Source-Software aufgeführt sind:

42Siehe Antworten auf die Fragen 27 (Modellierungswerkzeuge) und 61 (Anforderungsmanagementwerkzeuge) des an die Kunden gerichteten Auskunftsverlangens der Kommission.

43Siehe Antwort von Areva vom 16. November 2007 auf Frage 27 des an die Kunden gerichteten Auskunftsverlangens der Kommission.

http://www.topcased.org/

45Siehe Antworten auf Frage 29 (Modellierungswerkzeuge) und 61 (Anforderungsmanagementwerkzeuge) des an die Mitbewerber gerichteten Auskunftsersuchens der Kommission.

46Siehe die Antwort von Artisan vom 2. November 2007 auf Frage 29 des an die Mitbewerber gerichteten Auskunftsverlangens der Kommission.

"Drivers • Niedrige Einstiegspreise • Modularität, Unabhängigkeit und Flexibilität • Open-Source-Gemeinschaft erleichtert Innovation • Begeisterung bei Entwicklern, die an ihren Universitäten mit OSS programmieren lernten • Innovation; Rad braucht nicht neu erfunden zu werden, wenn es auf die Anwendung passt

Inhibitors • Qualität (Treiber installieren und konfigurieren) • Mangel an Zuverlässigkeit und Unterstützung)

68.Der Anmelder bestreitet eigentlich nicht, dass der Wettbewerbsdruck, der von Open-Source-Software auf die kommerziellen Softwareentwicklungswerkzeuge ausgeübt wird, bei den Anforderungsmanagementwerkzeugen immer noch begrenzt ist, wenngleich er langsam zunimmt, denn […]* erklärte dazu: „Open-Source-Lösungen werden zunehmend am unteren Ende des Spektrums konkurrenzfähig“ , woraus zu schließen ist, dass es im oberen Marktsegment wesentlich weniger Wettbewerb zwischen Open-Source- und kommerzieller Software gibt.

69.Wie vorstehend erwähnt bestätigte sich im Laufe der eingehenden Untersuchung deutlich, dass die Kunden in der Open-Source-Software keine glaubwürdige Alternative zu kommerziellen Anforderungsmanagementwerkzeugen sehen. Die meisten Kunden kennen nämlich gar keine Open-Source-Software mit Anforderungsmanagementfunktionalitäten, und wenn sie davon gehört haben, gehen sie davon aus, dass diese Software für ihre technischen Anforderungen nicht geeignet ist.

70.Hinsichtlich der Modellierungswerkzeuge erklärte […]*, dass „Open-Source-Produkte zwar noch nicht die gleiche Bedeutung wie kommerzielle Produkte haben, aber dennoch insbesondere in Europa einen spürbaren Wettbewerbsdruck auf diese Produkte ausüben“. Außerdem gab […]* zu bedenken, dass „[…]* zwar einsehen, dass die kommerzielle Unterstützung derzeit eher begrenzt sein mag, es aber Anzeichen dafür gibt, dass sich dies in Zukunft ändern wird. Zum Beispiel bieten […]* und […]* kommerzielle Unterstützung für ihre Open-Source-Modellierungswerkzeuge“ .

71.Wie vorstehend erwähnt zeigte sich bei der eingehenden Untersuchung, dass einer der Hauptgründe, warum Kunden die Open-Source-Software (zumindest bei komplexen Projekten) nicht als glaubwürdige Alternative zu kommerzieller Modellierungssoftware betrachten, vor allem im Mangel an Wartung und Unterstützung liegt. […]*.

72.Ein weiterer Grund für den beschränkten Einsatz von Open-Source-Modellierungswerkzeugen bei komplexen Software-Entwicklungsprojekten ist nach Ansicht der Kunden, dass die Funktionalitäten dieser Produkte begrenzt sind und sie daher nicht ihrem Bedarf entsprechen. Dazu erklärt Qinetiq, ein in der Rüstungsindustrie tätiger Kunde: „Die Open-Source-Modellierungswerkzeuge sind für kleine dynamische Forschungsprojekte geeignet, nicht jedoch für Projektunterstützung in Echtzeit und für die Unterstützung von großen Projekten, die sich auf mehrere Standorte verteilen. Wir verlangen außerdem, dass unsere Standardwerkzeuge vom Hersteller unterstützt werden, sowie eine klare Produktentwicklungsstrategie. Dies ist bei Open-Source-Produkten nicht immer gegeben“ .

73.Die Einschätzung der Einsetzbarkeit von Open-Source-Produkten durch die Kunden deckt sich mit der der Hersteller. Dazu ein kleiner Hersteller: „In letzter Zeit hat es einige Initiativen im Bereich Open-Source-UML insbesondere von Airbus (TopCased) und CEA (Papyrus) gegeben. Sie befinden sich noch in einem Anfangsstadium und sind in dieser Phase noch sehr vertraulich. Airbus und CEA sind aber nicht gleichzeitig Anbieter von Modellierungswerkzeugen, weshalb die Auswirkungen auf den Markt bisher kaum spürbar waren. Andere Initiativen sind Star UML, Gentleware und viele andere, doch gehen wir weiterhin davon aus, dass sich keine dieser Initiativen als glaubwürdige Alternative abzeichnet“ .

74.Interessanterweise erklärte dazu ein Anbieter von kommerzieller Unterstützung für Open-Source-Modellierungswerkzeuge: „Die Open-Source-Projekte, die wir mitverfolgen und bei denen es um die Entwicklung eines vollständigen Werkzeugs (und nicht um eine Infrastruktur für Bausteine) geht sind: ArgoUML, gestützt auf UML 1.3, weitgehend UML-kompatible mit Standard UML 1.3, und Papyrus, gestützt auf UML 2, weitgehend UML-kompatible mit Standard UML 2.0. Keine ist kommerziell verfügbar oder bei einem Anbieter erhältlich. Sie eignen sich zum Erlernen von UML und für Projekte für Studenten. Sie machen den professionellen Werkzeugen – noch - keine echte Konkurrenz“ .

75.Abschließend sei darauf hingewiesen, dass nach Gartner „Open-Source-Modellierungswerkzeuge, die auf die UML-Spezifikationen gestützt sind, immer noch nicht hinreichend ausgereift sind, um in einer verteilten oder heterogenen Entwicklungsumgebung eingesetzt werden zu können, aber für kleine am gleichen Ort arbeitende Teams interessant sein müssten“ .

76.Insgesamt lässt sich sagen, dass kommerzielle und Open-Source-Modellierungs- und Anforderungsmanagementwerkzeuge zum gegenwärtigen Zeitpunkt nur im unteren Marktsegment in direktem Wettbewerb zueinander stehen, d. h. bei kleinen Softwareentwicklungsprojekten. Obwohl man nicht ausschließen kann, dass der Wettbewerb in nächster Zukunft im Hinblick auf das mittlere Marktsegment, also für komplexere Softwareentwicklungsprojekte, zunimmt, ist es doch sehr unwahrscheinlich, dass von den Open-Source-Produkten in den nächsten zwei bis drei Jahren im oberen Marktsegment, also bei komplexen Softwareentwicklungsprojekten, ein spürbarer Wettbewerbsdruck auf die kommerziellen Werkzeuge ausgeht.

VI.1.3.2. Best-of-Breed-Produkte und Produkt-Suiten

77.In der Softwareentwicklungswerkzeugbranche gehen die Anbieter wie in vielen anderen Softwarebereichen zunehmend dazu über, ihre Best-of-Breed-Produkte mit zusätzlichen Funktionalitäten auszustatten, um sie als integrierte Produkt-Suiten anbieten zu können.

78.Insbesondere bieten immer mehr Werkzeuge integrierte Modellierungs- und Codegenerierungsfunktionalitäten, so dass der Quellcode der Softwareanwendung automatisch von den Modellen aus generiert wird. Dazu Forrester: „Durch bessere Sprachen, Frameworks, Factories, DSL und Text- und Visualisierungsmodelle wird es immer schwieriger, genau abzugrenzen, wo ein Softwaremodellierungswerkzeug aufhört und eine Programmiersprache beginnt“ . Microsoft Visual Studio, Oracle JDeveloper, Sun Netbeans, IBM RSA, Telelogic Rhapsody, Computer Associates AllFusion sind u.a. Beispiele für Werkzeuge, die mehr oder weniger umfassende Modellierungsfunktionalitäten zusammen mit Codegenerierungsfunktionalitäten bündeln .

Desgleichen werden immer mehr Anforderungsmanagementfunktionalitäten in Software integriert, die ursprünglich auf Test- sowie Änderungs- und Konfigurationsmanagementfunktionalitäten beschränkt war, wie HP QualityCenter, MKS Integrity, Rally Software Development, Kovair Global Lifecycle. Solche Produkte werden vielfach als „ALM-Tools“ (Application Lifecycle Management)

55„Open-Source Modelling Tools Maturing, but Need Time to Reach Full Potentia“, 20. April 2007. Abrufbar unter http://www.gartner.com/DisplayDocument?id=503940&ref=g_sitelink.

56„DSL“ steht für Domain Specific Languages (siehe unten)

57Unterlage „Balancing The Costs and Benefits Of Software Modelling“, 8. März 2007, Seite 11, von IBM in Anhang 15 der Antwort vom 5. November 2007 auf das Auskunftsverlangen der Kommission vom 19. Oktober 2007 vorgelegt.

58Siehe „Microsoft Sees The Future of Software in Modelling“, InformationWeek, 30. Oktober 2007. Unterlage vom Anmelder am 30. Oktober 2007 vorgelegt.

59Siehe Unterlage „Magic Quadrant for OOA&D Tools, 2h06 to 1H07“, Gartner, 30. Mai 2006, Seiten 6 und 11, von IBM in Anhang 3 der Bemerkungen „Comments on feedback from the market test relating to Object-Oriented analysis and design tools“ vom 25. September 2007 vorgelegt.

bezeichnet, da sie auf eine End-to-End-Lösung zum Management des gesamten Lebenszyklus von Softwareanwendungen abzielen .

80Darüber hinaus beinhalten immer mehr „PLM-Tools“ (Product Lifecycle Management) wie insbesondere Siemens UGS TeamCenter, Oracle Agile Product Data Management, und Dassault MatrixOne auch Anforderungsmanagementfunktionalitäten. Mit PLM-Werkzeugen lassen sich die Beschreibungen und Eigenschaften eines Produkts während seiner Entwicklung und seiner Einsatzzeit besser steuern, insbesondere aus geschäftlicher/ingenieurtechnischer Sicht . Aus diesem Grund stehen PLM-Werkzeuge mit integrierten Anforderungsmanagementfunktionalitäten hauptsächlich im Segment Systeme/eingebettete Software mit traditionellen Anforderungsmanagement-Best-of-Breed-Produkten im Wettbewerb (siehe unten).

81Aufgrund der vorstehend beschriebenen Entwicklung haben die Abnehmer von Softwareentwicklungswerkzeugen zunehmend die Wahl zwischen Produkt-Suiten und Best-of-Breed-Produkten. Grundsätzlich sind Produkt-Suiten nicht ganz perfekte oder annähernde Ersatzlösungen für Best-of-Breed-Produkte, da sie nicht dasselbe Funktionalitätsniveau wie Best-of-Breed-Produkte aufweisen. In der Regel bilden Produkt-Suiten attraktive Lösungen hauptsächlich für die Kunden, die nach Lösungen suchen, mit denen sich die Interoperabilitätsprobleme in Grenzen halten, die sich aus der Kombination von Werkzeugen von verschiedenen Anbietern ergeben, oder für diejenigen, die die Anschaffungskosten für Softwareentwicklungswerkzeuge gering halten wollen. Hingegen wählen die Großkunden, die in der Regel eine Mix-und-Match-Politik betreiben, gewöhnlich die Best-of-Breed-Produkte, die in jeder einzelnen Phase des Softwareentwicklungsprozesses ihrem spezifischen Bedarf am besten entsprechen, und kombinieren diese dann entweder mit ihren eigenen internen Möglichkeiten oder mit Hilfe eines Systemintegrators oder externen Beraters .

82Wie in der Entscheidung über die Einleitung des Verfahrens erwähnt schätzen die Kunden die Modellierungsfunktionalitäten von Integrierten Entwicklungsumgebungen (IDE) gegenüber denen von Point-Modellierungsprodukten grundsätzlich als schwach ein . Dennoch hat die eingehende Untersuchung ergeben, dass einige Werkzeuge, insbesondere die der

60Siehe Unterlage „Selecting The Right Requirements Management Tool – Or Maybe None Whatsoever“, Forrester, 28. September 2007, Seiten 5-8, in Anhang 15 der Antwort von IBM vom 5. November 2007 auf das Auskunftsverlangen der Kommission vom 19. Oktober 2007 vorgelegt.

61Siehe Entscheidung der Kommission vom 27. April 2007, Sache COMP/M.4608 – Siemens/UGS, Erwägungsgrund 8.

62Siehe Antworten auf Frage 28 des an die Kunden gerichteten Auskunftsverlangens der Kommission. Siehe auch die Entscheidung der Kommission in der Sache COMP/M.3062 – IBM/Rational, Erwägungsgrund 76.

63Entscheidung der Kommission über die Einleitung des Verfahrens vom 3. Oktober 2007, Erwägungsgrund 43.

64beteiligten Unternehmen (Telelogic Rhapsody und IBM RSA) sowie etwa Mathworks Matlab/Simulink, Borland Together, Kennedy Carter iUML und Artisan Studio zwar nicht unbedingt als IDE einzustufen sind, aber von den Kunden doch als modellgetriebene Entwicklungssoftware sowohl mit starken Modellierungsfähigkeiten als auch Codegenerierungsfähigkeiten betrachtet werden. Dies wurde auch von den Anbietern bestätigt und ging aus internen Unterlagen von Telelogic hervor, in denen die jeweiligen Modellierungs- und Codegenerierungsmöglichkeiten von Rhapsody und RSA im Einzelnen miteinander verglichen werden .

65Hinsichtlich des Anforderungsmanagements hat sich aus der eingehenden Untersuchung ergeben, dass einige ALM- und PLM-Werkzeuge einschließlich Siemens UGS TeamCenter und HP QualityCenter von den Kunden als glaubwürdige Alternativen zu traditionellen Anforderungsmanagement-Best-of-Breed-Produkten betrachtet werden, insbesondere für die System-Softwareentwicklung und Systementwicklung. Diese Feststellung wurde auch von den Anbietern bestätigt .

66Darüber hinaus geht aus […]* Unterlagen […]* hervor, dass Telelogic einige ALM- und PLM-Werkzeuge (MKS Integrity, HP QualityCenter und Siemens UGS TeamCenter) als direkte Konkurrenten für sein […]* Best-of-Breed-Produkt für Anforderungsmanagement ([…]*) betrachtet. Allerdings geht aus […]* Unterlagen […]* hervor, dass PLM-Produkte in zunehmendem Maße mit traditionellen Best-of-Breed-Produkten für Anforderungsmanagement im Systembereich konkurrieren. So heißt es z. B. in einer internen Unterlage von IBM, dass „multiple Marktkonvergenz zu neuen vertikal geschichteten Konkurrenzfeldern führt. PLM und Software konvergieren im industriellen Segment. SAP/Dassault/Oracle erhalten einen erweiterten Brennpunkt“ .

67Forrester fasst die Konvergenz zwischen traditionellen Anforderungsmanagement-Best-of-Breed-Produkten und ALM-Werkzeugen wie folgt zusammen: „Anforderungsmanagementfunktionen innerhalb von ALM-Lösungen haben das größte Potenzial. Anforderungsmanagementwerkzeuge haben so viel mit anderen Lebenszykluswerkzeugen gemein, dass es keinen Sinn macht, sie als Stand-alone-Lösungen anzubieten. Da die Anbieter die Anforderungsmanagementfunktionen in ihren ALM-Plattformen ständig weiter ausbauen, wird diese Option immer plausibler“ .

68Des Weiteren zeigte sich bei der eingehenden Untersuchung, dass ein großer Teil der Kunden in den kommenden zwei bis drei Jahren mehr Produkt-Suiten mit integrierten Modellierungs- oder Anforderungsmanagementfunktionalitäten einzusetzen gedenkt, und dies auch für große und komplexe Projekte. So bestätigten Kunden, dass sie davon ausgehen, dass diese beiden Funktionalitäten in nächster Zeit in Produkt-Suiten besser integriert sein dürften . Ein in der Luft- und Raumfahrt aktiver Kunde erklärt dazu: „Wir werden mehr Produkt-Suiten für Projektunterstützung in Echtzeit und Unterstützung für groß angelegte komplexe Projekte mit mehreren Standorten einsetzen, um die Vorteile einer End-to-End-Softwareentwicklung nutzen zu können (d .h. Vorteil dergestalt, dass das Management von Anforderungen, Design, Implementierung, Testen und Konfiguration und Fertigstellung innerhalb ein und derselben Produkt-Suite erfolgt. Produkt-Suiten werden in den nächsten 2 bis 3 Jahren wahrscheinlich besser integriert, so dass der Einsatz von Produkt-Suiten mit größeren Vorteilen verbunden sein wird“ .

69Abschließend kann festgestellt werden, dass der Wettbewerb zwischen Best-of-Breed-Produkten in der Regel intensiver ist als zwischen Point- und Produkt-Suiten (insbesondere bezogen auf große Kunden mit komplexen Anforderungen), dass aber einige Produkt-Suiten glaubwürdige Alternativen zu Best-of-Breed-Produkten für Modellierungs- und Anforderungsmanagement darstellen, hauptsächlich für die Bereiche Systemsoftwareentwicklung und Systementwicklung. Es ist damit zu rechnen, dass der Wettbewerb zwischen Best-of-Breed-Produkten und Produkt-Suiten, die Modellierungs- und Anforderungsmanagementfunktionalitäten bieten, in den nächsten Jahren zunehmen wird.

VI.1.3.3. UML- und Nicht-UML-Modellierungswerkzeuge

70Eine in der Entscheidung über die Einleitung des Verfahrens geprüfte Frage lautete, ob es einen gesonderten sachlich relevanten Markt für Modellierungswerkzeuge auf UML-Basis gibt. Die vorläufige Schlussfolgerung in der Entscheidung lautete, dass die Modellierungswerkzeuge auf UML-Basis in der Tat einen gesonderten Produktmarkt darstellen. Diese vorläufige Feststellung basierte auf Antworten von

74Unterlage „Selecting The Right Requirements Management Tool – Or Maybe None Whatsoever“, 28. September 2007, Seite 7, von IBM in Anhang 15 der Antwort vom 5. November 2007 auf das Auskunftsverlangen der Kommission vom 19. Oktober 2007 vorgelegt

75Siehe Antworten auf Frage 29 (Modellierung) und 63 Anforderungsmanagement in dem an die Kunden gerichteten Auskunftsverlangen der Kommission.

76Siehe Antwort von Qinetiq vom 2. November 2007 auf die Fragen 28 und 29 des an die Kunden gerichteten Auskunftsverlangens der Kommission.

77Kunden und Anbietern auf die im Auskunftsverlangen im Rahmen der vorläufigen Untersuchung gestellten Fragen, die die Definition der Kategorie OOA&D von Gartner erhärten .

78UML lässt sich am besten als allgemeine, offene, standardisierte Modellierungssprache beschreiben. Sie wird offiziell durch eine unabhängige Instanz (die Object Management Group) definiert. Seit dem Start der ersten Version im Jahr 1997 hat UML großen Anklang gefunden und wurde laut Gartner de facto der Standard für objektorientierte Modellierung. Objektorientierte Modellierung ist ein Modellierungsparadigma, das die Zerlegung (Dekomposition) eines Problems in erster Linie als eine bestimmte Anzahl von miteinander verbundenen interagierenden „Objekten“ unterstützt.

79Als Universalsprache mit generischen Komponenten ist UML nicht spezifisch auf die besonderen Probleme ausgerichtet, die sich in jeder einzelnen Branche ergeben. Aus diesem Grund hat sie einen erheblichen Nachteil gegenüber Domain Specific Modelling Languages („DSML“), die auf spezifische Branchen ausgerichtet sind .

80Andererseits wird UML von einer größeren Gemeinschaft von Entwicklern und Software-Ingenieuren verwendet und von einer größeren Anzahl von Anbietern unterstützt als jede DSML-Sprache. Mit UML können Modelle, die mit einem Werkzeug entwickelt wurden, in ein anderes Werkzeug eines Anbieters importiert werden. Aus diesen Gründen ist UML besonders für die Kunden attraktiv, die nicht von einen bestimmten Anbieter oder eine Gruppe von Anbietern abhängig werden wollen, sowie für Großunternehmen, die die Zusammenarbeit über die verschiedenen Geschäftsbereiche und Abteilungen hinweg erleichtern wollen.

92Der Anmelder argumentiert, dass „hinsichtlich der Abgrenzung des Marktes ein kontinuierlicher Prozess abläuft, in dem sich Modellierungswerkzeuge auf UML-Basis und Nicht-UML-Basis mit unterschiedlichen Funktionalitäten gegenseitig ablösen“. Insbesondere erläutert IBM, dass „UML eine allgemeine Modellierungssprache ist, die einen sehr weiten Anwendungsbereich abdeckt, von

77Siehe Antworten auf Frage 10.b) auf das an die Kunden gerichtete Auskunftsverlangen der Kommission vom 30. August 2007 und auf Frage 10.b) des an die Mitbewerber gerichteten Auskunftsverlangens der Kommission vom 30. August 2007.

78Die Kategorie OOA&D von Gartner enthält praktisch nur Modellierungswerkzeuge, die UML-basiert oder kompatibel sind. Siehe Unterlage "Dataquest Guide: Software Market Research Definitions", Gartner, 15. März 2007, Seite 8. von IBM am 26. Oktober 2007 vorgelegt.

79Z. B. SDL (Specification and Description Language) die in der Telekom-Industrie verwendet wird, UPDM, die in der Luft- und Raumfahrt und in der Rüstungsindustrie verwendet wird, AADL (Architecture and Analysis Design Language), die in der Automobilindustrie verwendet wird, BPMN (Business Process Modelling Notation) und BRL (Business Rules Management), die zur Entwicklung von IT-Software verwendet werden.

80Siehe Antwort von IBM vom 5. November 2007 auf Frage 33 des Auskunftsverlangens der Kommission vom 19. Oktober 2007.

82der Analyse (funktionelle Modellierung) über Design (Architekturmodellierung) bis hin zu Implementierung (Verhaltensmodellierung). Während andere Modellierungssprachen einen ähnlichen Anwendungsbereich aufweisen (z. B. SysML, SDL, IDEF, und AADL), sind die meisten Nicht-UML-Sprachen nur auf einen Aspekt der Modellierung ausgerichtet (Funktion, Architektur oder Verhalten).

83Die eingehende Untersuchung zeigte, dass Modellierungswerkzeuge auf UML-Basis von der großen Mehrheit der industriellen/technischen Kunden nicht als vollständig austauschbar gegen Nicht-UML-Werkzeugen (d. h. hauptsächlich DSLM-Werkzeugen) betrachtet werden. Als Hauptgrund dafür führen sie an, dass jeder Werkzeugtyp seine Vorteile hat und daher für jeweils andere Projekte oder zu anderen Zwecken verwendet wird. Daher gaben die meisten industriellen/technischen Kunden an, dass sie auch dann nicht auf Nicht-UML- Werkzeuge umstellen würden, wenn die Preise für UML-Werkzeuge permanent um 10 % steigen würden .

85Dagegen sind die Ansichten der Kunden, die Modellierungswerkzeuge für die Entwicklung von IT-Software einsetzen, und die hauptsächlich in der IT-Branche sowie im Bereich Banken/Finanzinstitutionen/Versicherungen aktiv sind, wesentlich ausgewogener, denn rund ein Drittel dieser Kunden geht davon aus, dass UML- und andere Modellierungsstandards austauschbar sind .

86Die überwiegende Mehrheit der Anbieter von Modellierungswerkzeugen gab ferner an, dass UML- und Nicht-UML-Werkzeuge aus der Sicht der Kunden hauptsächlich deshalb nicht voll austauschbar sind, weil sie auf unterschiedliche Funktionen ausgerichtet sind. So erklärte insbesondere die breite Mehrheit der Anbieter von Nicht-UML-Werkzeugen, dass sie ihre Produkte nicht als starke Konkurrenten von UML-Werkzeugen verstehen .

82Z. B. SDL (Specification and Description Language) die in der Telekom-Industrie verwendet wird, UPDM, die in der Luft- und Raumfahrt und in der Rüstungsindustrie verwendet wird, AADL (Architecture and Analysis Design Language), die in der Automobilindustrie verwendet wird, BPMN (Business Process Modelling Notation) und BRL (Business Rules Management), die zur Entwicklung von IT-Software verwendet werden.

83Siehe Antworten auf Frage 20 des an die Kunden gerichteten Auskunftsverlangens der Kommission vom 18. Oktober 2007.

84Siehe Antworten auf Frage 22 des an die Kunden gerichteten Auskunftsverlangens der Kommission.

88In dieser Hinsicht ergab die eingehende Untersuchung, dass Modellierungswerkzeuge, die auf rechtlich geschützten mathematischen Sprachen basieren, wie Mathworks Simulink, Esterel Studio, und dSpace TargetLink, keine Alternative, sondern eher eine Ergänzung zu UML-Werkzeugen darstellen. Letztere sind als allgemein einsetzbare Modellierungswerkzeuge einzustufen, während die andere Gruppe am besten als Simulations- und Design-Werkzeuge beschrieben werden könnte. Diese Erkenntnis stimmt mit der Einschätzung des Branchenanalysten Venture Development Corporations („VDC“) überein, der zwischen UML-Modellierungswerkzeugen, die für eingebettete Software- und Systementwicklung verwendet werden, und „rechtlich geschützten sprachbasierten dynamischen Systemdesignwerkzeugen unterscheidet, mit denen der Prozess des Designs und der Simulation dynamischer Systeme automatisiert werden soll, die mit komplexen Algorithmendesigns versehen sind, die das Verhalten komplexer physischer Phänomene abbilden“ .

89Des Weiteren hat die eingehende Untersuchung ergeben, dass UML-Werkzeuge keine Alternative zu Nicht-UML-Werkzeugen darstellen, die für die Entwicklung von Softwaresystemen verwendet werden, bei denen bestimmte industrielle Standards eingehalten werden müssen .

90Dennoch sei darauf hingewiesen, dass die Unterscheidung zwischen UML- und Nicht-UML-Modellierungswerkzeugen etwas stark vereinfacht erscheint, da dabei nicht mit berücksichtigt wird, dass einige Werkzeuge - wenn auch nicht UML-Werkzeuge strictu sensu - dennoch UML-kompatibel sind. Dies trifft vor allem auf die Werkzeuge zu, die auf UML-Profilen basieren, wie SysML, Executable UML und UPDM oder Business Profile Modelling Notation („BPMN“). ULM 2.0 und die nachfolgenden Fassungen bieten Mechanismen zur Kundenanpassung, auf deren Grundlage auf spezifische Bereiche angepasste UML-Derivate (auch „Profiles“ oder „Stereotypes“ genannt) entwickelt wurden .

88Unterlage „The Embedded Software Market Intelligence Program – 2007 Service Year – Band 5: Embedded software and system Modelling tools“, VDC, November 2007, Seite 6, von IBM am 11. September 2007 vorgelegt.

89Ascet von Etas z. B. ist für Softwareentwicklung zertifiziert, die Autosar-konform ist (Autosar ist ein Architektur-Framework, der in der Automobilindustrie verwendet wird). Scade von Esterel ist für die Entwicklung sicherheitskritischer eingebetteter Software von technischen Überwachungsbehörden wie EASA, FAA und dem TÜV zertifiziert.

94Die derzeitige Version von UML ist die Version UML 2.1.1 (Update vom August 2007) .

99Des Weiteren sind einige auf rechtlich geschützter DSML basierende Werkzeuge dennoch UML-kompatibel, da sie offene Schnittstellen haben, wodurch sie mit UML interoperabel werden (z. B. Esterel Studio).

100Daher ist festzuhalten, dass UML- und Nicht-UML-Werkzeuge zwar grundsätzlich von den Marktteilnehmern nicht als glaubwürdige Alternativen betrachtet werden, einige Nicht-UML-Werkzeuge aber dennoch UML-kompatibel sind. Diese Werkzeuge können daher für bestimmte Endanwendungen oder für bestimmte Kundengruppen als eher mit UML-Werkzeugen austauschbar betrachtet werden als reine Nicht-UML-Werkzeuge. Wie vorstehend erwähnt gilt dies besonders für Kunden, die Modellierungswerkzeuge für die IT-Softwareentwicklung einsetzen, für die Werkzeuge auf BPMN-Basis eine glaubwürdige Alternative zu UML-Werkzeugen bilden. Dazu Gartner: „UML lässt sich für Geschäftsprozessmodellierung verwenden, doch ist der Business Process Modelling Notation (BPMN)-Standard der Object Management Group (OMG) für die Analyse von Geschäftsprozessen besser geeignet“ .

101Allerdings braucht für den vorliegenden Fall keine Schlussfolgerung zum Vorliegen eines gesonderten Marktes für UML-Modellierungswerkzeuge gezogen zu werden. Dennoch sollten die vorstehend genannten Elemente zur Frage, inwieweit UML- und Nicht-UML-Werkzeuge auf dem Markt zueinander im Wettbewerb stehen, bei der wettbewerbsrechtlichen Würdigung des beabsichtigten Zusammenschlusses mit berücksichtigt werden.

VI.1.3.4. IT- und Systemkunden

102Der Anmelder geht nicht davon aus, dass es gesonderte Märkte für Werkzeuge gibt, die von den Entwicklern von eingebetteter Software verwendet werden. In seiner Anmeldung erklärte IBM: „Während einige Anbieter Werkzeuge speziell für die Entwicklung von eingebetteter Software vermarkten, verwendet die große Mehrheit der Entwickler von eingebetteter Software letztlich die gleichen Werkzeuge, die sowohl in der Entwicklung von allgemeiner IT-Software als auch von eingebetteter Software verwendet werden (wie dies u.a. auch bei Microsoft üblich ist). Bei den meisten Produkten bestehen kaum funktionale Unterschiede zwischen allgemeinen IT-Werkzeugen und Werkzeugen speziell für die Entwicklung von eingebetteter Software, und die Kunden finden, dass generische IT-Werkzeuge auch für diejenigen Produkte geeignet sind, die sich an die Entwickler von eingebetteter Software richten“ .

94Siehe die Antwort von IBM vom 5. November 2007 auf Frage 26 des Auskunftsverlangens der Kommission vom 19. Oktober 2007.

95Unterlage „Unified Modelling Language Is Still Going Strong“, Gartner, 2. Juni 2006, Seite 1, von Microsoft am 12. November 2007 vorgelegt.

96Anmeldung vom 29. August 2007, Seite 34.

104Die Unterschiede in der Entwicklung von IT-Software und Systemsoftware/eingebetteter Software spiegeln den unterschiedlichen Bedarf der Kunden hinsichtlich der Funktionalitäten und Eigenschaften der Softwareentwicklungswerkzeuge wider. Dieser Aspekt wurde von IBM bezogen auf Modellierungswerkzeuge als auch auf Anforderungsmanagementwerkzeuge anerkannt. In einer im Rahmen der eingehenden Untersuchung vorgelegten Unterlage erklärte IBM, dass nur […]* der Kriterien, die IBM selbst als relevant für den Vergleich von Modellierungswerkzeugen erachtet, in gleichem Maße für Softwareentwicklung für IT-Anwendungen und für Systemsoftware wichtig sind, während bei Anforderungsmanagementwerkzeugen […]* der Kriterien für beide Kategorien gleich wichtig wären .

97So gibt z. B. VDC einen Bericht heraus, der speziell auf „Embedded Software and System Modelling Tools“ (Modellierungswerkzeuge für eingebettete Software und Systeme) ausgerichtet ist. Auch Gartner gibt einen Bericht speziell zu „Embedded Software Development Tools and RTOS“ (Entwicklungswerkzeuge für Eingebettete Software und RTOS) heraus.

98Anmeldung, Seite 14.

Unterlage „Functional Substitution Analysis – Methodology“, Seite 6 und 7, von IBM am 20. November 2007 vorgelegt. In dieser Unterlage (Seite 6) erläutert IBM in Bezug auf Modellierungswerkzeuge: „• Ein Kernbestand von Kriterien ist in gleichem Maße für die Softwareentwicklung für IT-Anwendungen und für Systemsoftware relevant. Diese Kriterien machen […]* der Gesamtzahl der Kriterien aus. • Eine Reihe von Kriterien bezieht sich ausschließlich auf die Softwareentwicklung für IT-Anwendungen. Diese Kriterien machen etwa […]* der Gesamtzahl der Kriterien aus. • Eine Reihe von Kriterien bezieht sich lediglich auf Systemsoftwareentwicklung. Diese Kriterien machen ca. […]* der Gesamtzahl der Kriterien aus. • Etwa […]* der Kriterien beziehen sich sowohl auf Softwareentwicklung für IT-Anwendungen als auch auf Systemsoftware, wenn auch in unterschiedlichem Maße. Die Anzahl der Kriterien, die eher für Systementwicklung maßgeblich sind, ist geringfügig höher als die Anzahl der Kriterien, die eher für die Softwareentwicklung für IT-Anwendungen maßgeblich sind“. In derselben Unterlage (Seite 7) erklärte IBM im Hinblick auf Anforderungsmanagementwerkzeuge: „• Ein Kernbestand von Kriterien ist in gleichem Maße für die Softwareentwicklung für IT-Anwendungen und für Systemsoftware relevant Diese Kriterien machen etwa […]* der Gesamtzahl der Kriterien aus. • Eine Reihe von Kriterien bezieht sich ausschließlich auf die Softwareentwicklung für IT-Anwendungen. Diese Kriterien machen etwa […]* der Gesamtzahl der Kriterien aus. • Eine Reihe von Kriterien bezieht sich lediglich auf Systemsoftwareentwicklung. Diese Kriterien machen ca. […]* der Gesamtzahl der Kriterien aus.

105Darüber hinaus sei darauf hingewiesen, dass IBM in derselben Unterlage […]* Produkteigenschaften als unverzichtbar für IT-Software für Anforderungsmanagementwerkzeuge („IT-specific must haves“) ([…]*) und […]* verschiedene Produkteigenschaften als unverzichtbar für Systemsoftware („system specific must-haves“) bezeichnet ([…]*) .

106Hinsichtlich der Modellierungswerkzeuge verweist IBM in derselben Unterlage auf die folgenden […]* Produkteigenschaften als die „highest-ranking attributes for IT development“: […]*.

107Im Gegensatz dazu hat IBM die folgenden […]* Produktmerkmale als die „highest-ranking attributes for system development“ bezeichnet: […]* .

108Ein Vergleich dieser beiden Listen zeigt, dass IT-Entwicklung und System-Entwicklung nur […]* der „Attribute mit dem höchsten Stellenwert“ hinsichtlich der Modellierungstools gemeinsam aufweisen ([…]*).

109Bei einigen Anforderungsmanagement- und Modellierungswerkzeugen kommen diese Unterschiede zwischen dem Bedarf der IT- und der System-Kunden deutlich zum Ausdruck, weshalb sie eindeutig besser für die Softwareentwicklung von IT-Anwendungen oder für System-/eingebettete Softwareanwendungen geeignet sind. Wie vorstehend (in Erwägungsgrund 33) bereits erwähnt, hatte IBM erklärt, dass das Anforderungsmanagementwerkzeug von Telelogic, Doors, „eindeutig besser für Systemingenieure geeignet ist“, während das IBM-eigene Anforderungsmanagementwerkzeug, RequisitePro, ein typisches „IT-fokussiertes Tool“ ist. Des Weiteren hat Telelogic in letzter Zeit eine neue „Light“-Version seines Anforderungsmanagement-Tools, Doors FastTrack, eingeführt, das speziell auf das IT-Segment abzielt. Auf der anderen Seite hat IBM eine Unterversion seines neuen Modellierungstools RSA (RSD genannt) auf den Markt gebracht, die auf das Segment Systemsoftware/eingebettete Software abzielt .

110Allerdings braucht im vorliegenden Fall nicht ermittelt zu werden, ob es jeweils einen gesonderten Produktmarkt für Softwareentwicklungswerkzeuge für IT-Anwendungen und für Systemsoftware gibt. Dennoch weisen die vorstehend aufgeführten Elemente darauf hin, dass diese Unterscheidung ein wichtiges Element bei der wettbewerbsrechtlichen Würdigung des beabsichtigten Zusammenschlusses ist.

104Anmeldung, Seiten 34-35.

105[…]*, Seite 4, von IBM am 20. November 2007 vorgelegt.

106[…]*, Anhang 1, Seiten 2 und 4, von IBM am 20. November 2007 vorgelegt.

VI.1.3.5.Kundengruppen

111Abgesehen von der groben Unterscheidung zwischen IT-Software und System-/technischer Software machte der Anmelder in der Anmeldung geltend, dass eine Unterscheidung der Softwareentwicklungswerkzeuge nach unterschiedlichen Gruppen von Nachfragern nicht sinnvoll sei, und zwar nach dem Dafürhalten von IBM deshalb, weil „unterschiedliche Kundengruppen (unabhängige Softwareanbieter (ISV) und Systemintegratoren (SI) und unternehmensinterne Softwareentwickler) die gleichen Softwareentwicklungswerkzeuge verwenden. […]*. Gleichzeitig versuchen die Kunden, den Wert ihrer Investitionen in Werkzeuge durch deren Einsatz in all ihren Entwicklungsprojekten zu maximieren, unabhängig davon, ob es sich dabei um „High-end-“ oder „Low-end-Projekte“ handelt. Häufig können die gleichen Werkzeuge für unterschiedliche Projekte verwendet werden, selbst wenn die Funktionalität des Werkzeugs nicht voll ausgenutzt wird“ .

94Siehe die Antwort von IBM vom 5. November 2007 auf Frage 26 des Auskunftsverlangens der Kommission vom 19. Oktober 2007.

95Unterlage „Unified Modelling Language Is Still Going Strong“, Gartner, 2. Juni 2006, Seite 1, von Microsoft am 12. November 2007 vorgelegt.

96Anmeldung vom 29. August 2007, Seite 34.

112Trotz der vorstehenden Erklärung in der Anmeldung bestreitet IBM in einer im Rahmen der eingehenden Untersuchung vorgelegten Unterlage nicht, dass man verschiedene vertikale Industriestrukturen anhand ihres spezifischen Bedarfs an Modellierungs- und Anforderungswerkzeugen unterscheiden kann.

113In einer Unterlage, […]*, erklärte IBM […]*: „Es wurde ein anderes Ranking erstellt, um das relative Gewicht zu ermitteln, das die einzelnen Kriterien für die […]* wichtigsten Kategorien von industriellen Abnehmern haben: […]*. Als Beispiel für den unterschiedlichen Bedarf der verschiedenen Branchen sei angeführt, dass Unterstützung der ADA-Programmiersprache für den Sektor […]*, nicht hingegen für andere Industriesektoren wünschenswert ist“ .

114In derselben Unterlage beschreibt IBM im Einzelnen die Unterschiede zwischen den […]* Hauptkundengruppen für Modellierungs- und Anforderungsmanagementwerkzeuge ([…]*) im Hinblick auf den relativen Stellenwert verschiedener Produkteigenschaften .

115Allerdings braucht im vorliegenden Fall nicht ermittelt zu werden, ob es je nach Kundengruppe oder vertikaler Industriestruktur gesonderte Produktmärkte für Softwareentwicklungswerkzeuge gibt. Dennoch weisen die vorstehend aufgeführten Elemente darauf hin, dass diese Unterscheidung nach Kundengruppen ein wichtiges Element bei der wettbewerbsrechtlichen Würdigung des beabsichtigten Zusammenschlusses ist.

104Anmeldung, Seiten 34-35.

105[…]*, Seite 4, von IBM am 20. November 2007 vorgelegt.

106[…]*, Anhang 1, Seiten 8-12, von IBM am 20. November 2007 vorgelegt.

VI.1.3.6.Verschiedenartigkeit der Produkte und der Bedarf der Kunden

116Obwohl Anforderungsmanagement und Modellierung eindeutig als verschiedene Phasen im Softwareentwicklungsprozess erkennbar sind und die in diesem Prozess eingesetzten Best-of-Breed-Tools ganz spezifische Funktionalitäten aufweisen, lassen sich die sachlich relevanten Märkte für diese beiden Kategorien von Werkzeugen nur schwer abgrenzen. Dafür gibt es im Wesentlichen vier Gründe.

117Zunächst werden Anforderungsmanagement- und Modellierungsfähigkeiten zunehmend mit anderen in integrierten Produkt-Suiten mitgelieferten Funktionalitäten gebündelt. Wie vorstehend erwähnt ergab die eingehende Untersuchung, dass einige (jedoch nicht alle) dieser Produkt-Suiten für einige Kundenkategorien glaubwürdige Alternativen zu traditionellen Anforderungsmanagement- und Modellierungs-Best-of-Breed-Produkten darstellen. Zweitens stellen Open-Source-Anforderungsmanagement- und Modellierungswerkzeuge am unteren Ende des Marktes, nicht jedoch am oberen Marktende, Alternativen zu kommerzieller Software dar. Drittens machen UML-Tools den Nicht-UML-Tools bei der Modellierung bei einigen Endanwendungen und im Falle bestimmter – wenn auch nicht aller – Kunden Konkurrenz. Viertens gibt es selbst innerhalb eng abgegrenzter Produktkategorien eine Vielfalt von Werkzeugen, wie dies an den großen Preisunterschieden zwischen den verschiedenen Werkzeugen deutlich wird, die von praktisch 0 bei Open-Source-Tools bis zu mehreren Tausend EUR für die Lizenz für ein fortschrittliches Tool reichen. Außerdem bestehen auch erhebliche Preisunterschiede zwischen den kommerziellen Werkzeugen.

118So erklärte z. B. […]* in Bezug auf Modellierungswerkzeuge, dass „eine Lizenz für Rhapsody bis zu […]* kosten kann, während ein gleichwertiges Produkt bei Artisan für etwa […]* und bei Borland für rund […]* erhältlich ist. […] NoMagic bietet ein Konkurrenzprodukt für rund […]* an. Die Poseidon Community Edition von Gentleware ist bereits für […]* erhältlich, und Sparx Systems, […]*, […] bieten die gesamte Palette an Funktionalitäten für rund […]* an“ .

119Zu den Anforderungsmanagementwerkzeugen erklärte […]*: „MKS bietet seine Floating-Lizenz für Integrity für rund […]* an, und die Floating-Lizenz von IRaQs kostet rund […]*. Im Vergleich dazu kann die Floating-Lizenz für DOORS zwischen […]* und […]* kosten. Die Listenpreise für VersionOne beginnen bei […]* und das Unternehmen behauptet von sich, 30 Unternehmen der Fortune-100 zu beliefern. Collab.NET bietet hoch entwickelte Produkte ab […]* an“ .

An der großen Vielfalt der Anforderungsmanagement- und Modellierungswerkzeuge zeigt sich, wie heterogen der Bedarf der verschiedenen Kundengruppen im Hinblick auf diese beiden Tool-Kategorien ist. Zwischen dem Bedarf eines kleinen Unternehmens, das eine neue IT-Anwendung für

107[…]*.

108[…]*.

Geschäftsprozesse entwickelt, und dem Bedarf großer Unternehmen im Luft- und Raumfahrtsektor, die eine hochkomplizierte eingebettete Softwareanwendung für ein neues Militärflugzeug entwickeln wollen, bestehen nur wenige Gemeinsamkeiten. Während die Kunden der ersten Gruppe in der Regel ein Werkzeug benötigen, das „rasch zu erlernen und einfach einsetzbar ist“, würde das Großunternehmen nach einem fortschrittlichen Werkzeug Ausschau halten, das eine große Funktionalitätstiefe gekoppelt mit hochgradigen Wartungs- und Unterstützungsleistungen bietet. Obwohl die von diesen beiden Unternehmenstypen eingesetzten Modellierungs- oder Anforderungsmanagementtools einen Kern an gemeinsamen Eigenschaften hätten, und daher als Modellierungs- und Anforderungsmanagementtools bezeichnet werden könnten, können sie dennoch kaum als leicht gegeneinander austauschbar betrachtet werden.

121Wie ebenfalls vorstehend bereits erwähnt, haben die verschiedenen Kundengruppen zwischen diesen beiden Enden des Spektrums eine höchst unterschiedliche Anzahl von Anforderungen an die Produkteigenschaften, wobei diese weitgehend von der Branche abhängen, in der sie tätig sind.

VI.1.4.Schlussfolgerung zur Abgrenzung des sachlich relevanten Markts

122Obwohl sich die in der Entscheidung über die Einleitung des Verfahrens enthaltene Darstellung der Anforderungsmanagement- und Modellierungswerkzeuge als zwei gesonderte Produktmärkte in der eingehenden Untersuchung bestätigt zu haben scheint, lassen sich die sachlich relevanten Märkte (d. h. welche Produkte von den Nachfragern als austauschbar betrachtet werden) nur schwer voneinander abgrenzen. Dies liegt in erster Linie an der großen Vielfalt der auf dem Markt angebotenen Anforderungsmanagement- und Modellierungswerkzeuge, was wiederum auf die heterogenen Anforderungen der Kunden an diese Werkzeuge zurückzuführen ist.

123Angesichts dieser Feststellung kann die Abgrenzung des sachlich relevanten Markts in diesem Fall lediglich einen breiten Rahmen für die wettbewerbsrechtliche Würdigung des beabsichtigten Zusammenschlusses bieten. Denn unterschiedliche Softwareprodukte, die ein und derselben Produktkategorie angehören, können in den Augen der Kunden nicht wirklich gegeneinander austauschbar sein. Darüber hinaus müssen im Rahmen der wettbewerbsrechtlichen Würdigung auch andere Elemente mit berücksichtigt werden, die nicht unbedingt auf die Existenz von zwei separaten sachlich relevanten Märkten hindeuten. Dabei handelt es sich insbesondere um Elemente wie die Heterogenität von Produkten und die Unterschiede in den Anforderungen der Kunden.

VI.2.Der räumlich relevante Markt

124Der Anmelder gibt zu bedenken, dass die räumlich relevanten Märkte im vorliegenden Fall weltweite Dimension haben. In einer früheren Entscheidung über Softwareentwicklungswerkzeuge hatte die Kommission festgestellt, dass der

109räumliche Umfang der relevanten Märkte zumindest den gesamten EWR umfasst .

125Aus der eingehenden Untersuchung ging hervor, dass die Anbieter abgesehen von sprachspezifischen Kundenanpassungen weltweit die gleichen Modellierungs- und Anforderungsmanagementtools anbieten. Außerdem kaufen die Kunden für ihre verschiedenen Abteilungen oder Geschäftsbereiche ungeachtet ihres geografischen Standorts die gleichen Produkte. Obwohl es zwischen der EU und den anderen Hauptregionen der Welt gewisse Preisunterschiede zu geben scheint, spiegeln diese im Wesentlichen Wechselkursunterschiede wider, was insbesondere erklärt, warum die Preise in den USA etwas niedriger als in der EU sind .

126Die präzise Abgrenzung der räumlich relevanten Märkte kann im vorliegenden Fall jedoch offen bleiben, da die wettbewerbsrechtliche Würdigung sowohl bei einem weltweiten Markt als auch bei einem EU-weiten Markt stets zur gleichen Schlussfolgerung führt.

VII.VEREINBARKEIT MIT DEM GEMEINSAMEN MARKT UND DEM EWR-ABKOMMEN

127In der Entscheidung über die Einleitung des Verfahrens wurden die folgenden drei Gefahren aufgeführt:

A. einseitige Preiserhöhungen

B. geringerer Innovationsanreiz

C. geringere Interoperabilität von Softwarewerkzeugen.

VII.1.1.Marktanteile

Nach der Markteinteilung von Gartner wird das aus dem Zusammenschluss hervorgehende Unternehmen sowohl bei Modellierungs- als auch bei Anforderungsmanagementwerkzeugen einen hohen gemeinsamen Marktanteil aufweisen.

VII.1.1.1.Modellierung

129In der Kategorie OOA&D läge der von Gartner ermittelte kombinierte „Marktanteil“ der neuen Einheit weltweit bei 68 % (IBM: 48 % und Telelogic: 20 %), und in Europa bei 69 % (IBM: 45 % und Telelogic: 25 %). Nach Einschätzung von Gartner wären Borland, Sybase und Computer Associates die Hauptkonkurrenten.

130IBM argumentiert, dass die von Gartner ermittelten Marktanteile die Marktmacht der fusionierten Einheit nicht präzise widerspiegeln. Daher haben die beteiligten Unternehmen ihre Marktanteile sowie die ihrer Konkurrenten neu berechnet. Nach den von IBM vorgelegten berichtigten Daten zu den Marktanteilen käme die fusionierte Einheit bei Modellierungswerkzeugen auf einen weltweiten Marktanteil von wertmäßigen [30-40]* % und von volumenmäßigen [10-20]* % . Für die schwerwiegenden Mängel an den Zahlen von Gartner gibt es nach Ansicht der beteiligten Unternehmen folgende Gründe:

131Zunächst nimmt Gartner die Gesamterträge (einschließlich Erträge aus Wartungs- und Unterstützungsdiensten) anstatt der Lizenzeinnahmen und überschätzt damit die Wettbewerbsposition der beteiligten Unternehmen (da es sich bei den Rational Rose Produkten von IBM um Legacy-Produkte handelt). Gleichzeitig unterschätzt er die Wettbewerbsstellung verschiedener wichtiger Anbieter.

132Aus den von den beteiligten Unternehmen vorgelegten Zahlen geht in diesem Zusammenhang hervor, dass der von Gartner IBM zugeordnete Marktanteil von 48 % zu rund [20-30]* % durch die Legacy-Produkte von IBM bedingt wird. Aus der nachfolgenden Tabellegeht hervor, dass die aus Legacy-Produkten stammenden Lizenzeinnahmen von IBM in den letzten Jahren […]* zurückgegangen sind (siehe insbesondere […]*).

Tabelle 1

Lizenzen

2004

2005

2006 20072006/2004 (Jan/Sept.)

Rose Enterprise

Rose Modeler

[…]* […]* […]* […]*

Rose TD

[…]* […]* […]* […]*

Rose XDE

[…]* […]* […]* […]*

Bundles/ Suites

[…]* […]* […]* […]*

Eingestellt

[…]* […]* […]* […]*

Legacy-Produkte insgesamt

[…]* […]* […]* […]* -[…]* %

Zahlen in Mio. USD im weltweiten Absatz

Des Weiteren geht aus der nachstehenden Tabelle hervor, dass der größte Teil des Umsatzes von IBM mit Rational Rose derzeit aus Wartungs- und Unterstützungsleistungen für laufende Projekte stammt.

Tabelle 2

Erträge IBM Legacy-Produkte

2004

2005

2006

Lizenzen

[…]*

[…]*

[…]*

insgesamt

[…]*

[…]*

[…]*

Lizenzen /[50-60]* % [30-40]* % [20-30]* %

insgesamt Zahlen in Millionen USD im weltweiten Absatz

134Zweitens argumentiert IBM, dass sich Gartner zu sehr auf einkommensbasierte Marktanteile und weniger auf volumenbasierte Marktanteile stützt (d. h. die Anzahl der Lizenznehmer, die die tatsächliche Verwendung der Werkzeuge widerspiegelt) und damit die Bedeutung der Billiganbieter wie Sparx Systems nicht angemessen zum Ausdruck bringt.

135Obwohl sich bei der eingehenden Untersuchung bestätigte, dass einige Billiganbieter bei Modellierungswerkzeugen glaubwürdige Alternativen zu bieten haben und damit bei der Berechnung der Marktanteile mit zu berücksichtigen sind, scheinen die wertmäßigen Marktanteile die Marktmacht immer noch besser widerzuspiegeln als die volumenmäßigen Marktanteile. Bei differenzierten Produkten wird gewöhnlich davon ausgegangen, dass der Wert der Verkäufe und der entsprechende Marktanteil die relative Position und Stärke der einzelnen Anbieter besser widerspiegelt .

136Drittens macht IBM geltend, dass die Kategorie OOA&D von Gartner einige wichtige Werkzeuge für Systemmodellierung unberücksichtigt lässt (z. B. Artisan Studio oder The Mathworks Simulink).

137Viertens argumentiert IBM, dass die Daten von Gartner nicht die zunehmende Wirkung von Open-Source-Werkzeugen wie […]*, die auf Linux und Eclipse basieren, berücksichtigen.

138Fünftens gibt IBM zu bedenken, dass selbst die berichtigten Daten zu den vorgelegten Marktanteilen (kombinierter weltweiter Marktanteil bei Modellierungswerkzeugen von wertmäßig [30-40]* % und von volumenmäßig [10-20]* %) die Marktmacht der fusionierten Einheit überhöht, da dabei mehrere maßgebliche konkurrierende Produkte nicht mit berücksichtigt sind (z. B. Visiovon Microsoft und Produkte von Visual Studio).

139Die von Gartner ermittelten Marktanteile übertreffen offensichtlich die Marktmacht der aus dem Zusammenschluss hervorgehenden Einheit, doch auch die von IBM in seiner Neuberechnung berichtigten Marktanteile scheinen nicht vollständig korrekt zu sein. Nach den von den beteiligten Unternehmen vorgelegten Daten werden die Anteile des über Lizenzen erwirtschafteten Einkommens der Mitbewerber zu hoch ausgewiesen. Zweitens hat IBM auch Anbieter mit einbezogen, die von den Teilnehmern der eingehenden Untersuchung der Kommission nicht als Mitbewerber

118Einige Kunden (z. B. Infineon) verwenden ein neues Modellierungstool, das von einem neuen Marktteilnehmer oder von einem kleinen Anbieter entwickelt wurde. Andere Kunden bestätigten ebenfalls die Verwendung dieses Tools (z. B. The Boeing Company, AT&T, CSC oder RBS). Siehe Antworten von Infineon, AT&T und RBS vom 2. November 2007, Antwort von CSC vom 5. November 2007 und Antwort von The Boeing Company vom 7. November 2007

119Siehe Bekanntmachung der Kommission über die Definition des relevanten Markts im Sinne des Wettbewerbsrechts der Gemeinschaft, Absatz 55 (Amtsblatt C 372 vom 9.12.1997, S.5 –-13). Siehe auch Entscheidung der Kommission vom 21. Juni 1994 in der Sache IV/M.430 - Procter & Gamble/VP Schickedanz (II), Erwägungsgründe 112 bis 117 (Amtsblatt L 354 vom 31.12.1994, S. 32-65).

120Im Rahmen einer Wettbewerbserhebung von VDC im Jahr 2005 über den Einsatz von Software-Modellierungswerkzeugen gaben 36% aller Teilnehmer an, Visio (Microsoft) zu verwenden, obwohl VDC Visio bei eingebetteten Modellierungswerkzeugen nur einen Marktanteil von 2% beimisst ("The Embedded Market Software Intelligence Program" – Band IV, 2006, von IBM am 11. September 2007 vorgelegt).

121So schätzte IBM z. B. , dass im Falle von 5 Mitbewerbern die über Lizenzen erwirtschafteten Einnahmen 100% der Gesamterträge ausmachen (Omondo, Gentelware Poseidon, NoMagic MagicDraw, Visual Paradigm und Sparx Systems). Siehe Ausführungen von IBM vom 4. Dezember 2007, in der berichtigten und neu berechneten Version, die von IBM am 21. Dezember 2007 vorgelegt wurde.

122Drittens scheint IBM die Marktanteile in der Kategorie „Other vendors of Software Modelling“ ([10-20]* %) durch die Annahme zu hoch anzusetzen, dass ihr gesamter Umsatz über Lizenzeinnahmen erwirtschaftet wird. Und schließlich hat IBM seine eigenen Marktanteile möglicherweise unterschätzt .

140Würden die Zahlen der beteiligten Unternehmen nach Maßgabe der von den Kunden und Mitbewerbern vorgelegten Daten zu ihren eigenen Umsätzen sowie nach den Ergebnissen der eingehenden Untersuchung berichtigt, so würde sich - wie aus der nachstehenden Tabelle hervorgeht - der geschätzte weltweite Marktanteil der beteiligten Unternehmen auf [30-40]* % belaufen. Die wichtigsten Mitbewerber sind The Mathworks, Borland und Mentor Graphics mit einem Marktanteil von [30-40]* %, [0-10]* % bzw. [0-10]* %.

Tabelle 3 Anbieter/Tool

UMLWertmäßiger konformMarktanteil der Lizenzen

IBM RSA & RSD IBM Rose, Rose Tech Developer IBM RSM

Ja Ja Ja

[10-20]* % [0-10]* % [0-10]* %

IBM insgesamt

[20-30]* %

Telelogic SDL Suite Telelogic Tau Telelogic Rhapsody Telelogic Statemate

Nein Ja Ja Nein

[0-10]* % [0-10]* % [0-10]* % [0-10]* %

Telelogic insgesamt

[10-20]* %

Marktanteil der beteiligten Unternehmen

[30-40]* %

Mathworks Simulink

Nein

[30-40]* %

122Z. B. Computer Associates, Embarcadero Technologies, IAR visualSTATE und Foresight. Mehrere andere Mitbewerber, die von den Kunden, die an der eingehenden Untersuchung der Kommission teilnahmen, als Mitbewerber genannt wurden, wurden von IBM allerdings nicht in die Neuberechnung Marktanteile mit einbezogen (z. B. Core (Vitech/Sodius), IDS Scheer (ARIS), Casewise Corporate Modeller oder Allfusion Data Modeller).

123Daher wird in der Berechnung der Marktanteile nur der Teil des RSA- und RSD-Einkommens berücksichtigt, der nach Ansicht von IBM eindeutig den […]* Modellierungsfunktionalitäten zugeschrieben werden kann. Für RSA und RSD wurden nur 27% der Erträge von IBM berücksichtigt ([…]*). Desgleichen wurde Visio von Microsoft nicht mit in die Berechnungen einbezogen, da es darüber keine verlässlichen Daten gibt. Siehe Ausführungen von IBM vom 4. Dezember 2007 ("Market share calculation – limitations of Gartner data").

124Diese Tabelle basiert auf den von IBM vorgelegten Absatzzahlen, die anhand der Absatzzahlen korrigiert wurden, die im Rahmen der eingehenden Untersuchung von den Mitbewerbern eingeholt wurden. Während die beteiligten Unternehmen davon ausgehen, dass der gesamte Absatz von […]* sowie der Absatz […]* als Lizenzeinnahmen betrachtet werden sollte, wird in der Tabelle davon ausgegangen, dass 50% des Gesamtabsatzes ein realistischerer Wert wäre. Ferner sind in der Tabelle die gesamten Lizenzeinnahmen aus den Produkten RSA und RSD von IBM mit berücksichtigt […]* (IBM selbst berücksichtigt diese Einnahmen nur zu 27 %). Die Tabelle enthält keine Werkzeuge von Microsoft (wegen des Mangels an verlässlichen Umsatzzahlen) oder Open-Source-Tools.

Borland

Ja

[0-10]* %

Mentor Graphics’ BridgePoint Builder

Ja

[0-10]* %

Esterel Scade

Ja (*)

[0-10]* %

ETAS Ascet

Nein

[0-10]* %

dSpace SystemDesk

Nein

[0-10]* %

Visual Paradigm

Ja

[0-10]* %

NoMagic MagicDraw

Ja

[0-10]* %

Applied Dynamics International Beacon

Nein

[0-10]* %

ARTiSAN Studio

Ja

[0-10]* %

Sparx Systems

Ja

[0-10]* %

National Instruments Matrixx LabView

Ja

[0-10]* %

Omondo

Ja

[0-10]* %

Gentleware Poseidon

Ja

[0-10]* %

Sybase

Ja

[0-10]* %

Kennedy Carter iUML

Ja

[0-10]* %

Andere Anbieter von Software-Modellierungswerkzeugen Insgesamt

-

[0-10]* %

100 %

(*) Obwohl Esterel auf einer anderen Sprache basiert, ist die UML-Kompatibilität gewährleistet.

141Würden alle nicht UML-konformen Werkzeuge ausgeschlossen, ergäbe sich ein kombinierter Marktanteil von [50-60]* %. Die Hauptkonkurrenten wären dann Borland und Mentor Graphics mit Marktanteilen von [10-20]* % bzw. [0-10]* %.

142Im Bereich Anforderungsmanagement haben die beteiligten Unternehmen laut Gartner weltweit einen kombinierten Marktanteil von 62 % (IBM: 25 % und Telelogic: 37 %) und europaweit von 65 % (IBM: 22 % und Telelogic: 43 %). Zu den Mitbewerbern gehören Borland und Serena Software.

143Bezogen auf Modellierung argumentiert IBM, dass die Daten von Gartner erhebliche Mängel aufweisen und die Marktmacht der fusionierten Einheit nicht präzise widerspiegeln. Daher haben die beteiligten Unternehmen ihre eigenen Marktanteile und die ihrer Mitbewerber neu berechnet. Nach den von IBM vorgelegten berichtigten Marktanteilen hätte die fusionierte Einheit bei Anforderungsmanagementwerkzeugen einen kombinierten weltweiten Marktanteil von wertmäßig [20-30]* % und volumenmäßig [10-20]* %. IBM nennt

144folgende Gründe für die seiner Ansicht nach erheblichen Mängel an den Zahlen von Gartner:

145Erstens wird durch die ertragsbasierten Marktanteile von Gartner die Bedeutung der Anbieter unterschätzt, deren Geschäftsmodelle auf den Absatz einer großen Anzahl von Lizenzen zu geringen Stückkosten ausgerichtet sind wie RallyDev oder VersionOne. Außerdem werden freie Open-Source-Anforderungsmanagementtools (wie z. B. Use Case Maker, Xplanner, Open Source Requirements Management Tool, myRMS) nicht mit berücksichtigt.

146Wie im Zusammenhang mit Modellierung bereits erläutert wird bei differenzierten Produkten davon ausgegangen, dass der Wert der Verkäufe und der entsprechende Marktanteil die relative Position und Stärke der einzelnen Anbieter besser widerspiegelt.

147Zweitens macht IBM geltend, dass bei den Marktanteilen laut Gartner einige der maßgeblichen Anbieter von Anforderungsmanagementtools (z. B. Compuware) nicht mit erfasst sind.

148Drittens lässt Gartner auch Werkzeuge, die im „Produkt Lifecycle Management“ (PLM) eingesetzt werden, wie Siemens UGS TeamCenter unberücksichtigt, die auf dem Markt für Anforderungsmanagementwerkzeuge eindeutig Konkurrenzprodukte darstellen.

149Und schließlich gibt IBM zu bedenken, dass der tatsächliche Marktanteil der fusionierten Einheit sogar noch geringer wäre als der von IBM geschätzte (kombinierter weltweiter Marktanteil bei Anforderungsmanagementwerkzeugen von wertmäßig [20-30]* % und volumenmäßig [10-20]* %), da die Verkaufszahlen von Universal-Office-Tools (z. B. Microsoft Word, Excel oder Power Point), die von einigen Kunden auch für Anforderungsmanagementaufgaben verwendet werden, nicht mit berücksichtigt sind.

150Desgleichen wird in den Marktanteilsberechnungen von Gartner wie bereits bezogen auf Modellierung erläutert die Marktmacht der fusionierten Einheit zu hoch veranschlagt, während die Marktmacht der fusionierten Einheit nach den unteren Schätzungen von IBM zu gering veranschlagt wird .

129IBM hat dabei die Anbieter mit einbezogen, die von den Teilnehmern der eingehenden Untersuchung der Kommission nicht als Mitbewerber eingeschätzt werden (z. B. Microsoft Visual Studio Team System, Oracle/Agile, RallyDev, CollabNET und Atlassian JIRA). Mehrere andere Werkzeuge von Mitbewerbern, die von den an der eingehenden Untersuchung der Kommission teilnehmenden Kunden genannt wurden, wurden in der von IBM vorgenommenen Neuberechnung der Marktanteile nicht mit berücksichtigt (z. B. Axosoft On Time, Mantis, EPDM Enovia MatrixOne, OmniTracker OmniNet oder FORCE Ontopia). Darüber hinaus scheint auch der Marktanteil der Kategorie „Andere Anbieter von PLM-Tools“ ([20-30]* %) zu hoch veranschlagt.

130Ergebnisse der eingehenden Untersuchung berichtigt, so würde sich - wie aus der nachstehenden Tabelle hervorgeht - der geschätzte weltweite kombinierte Marktanteil der beteiligten Unternehmen auf [20-30]* % belaufen. Die Hauptmitbewerber wären Borland und UGS TeamCenter mit Marktanteilen von [0-10]* % bzw. [0-10]* %.

Tabelle 4

Anbieter/Tool

Wertmäßiger Marktanteil der Lizenzen

IBM Requisite Pro allein IBM Requisite Pro gebündelt

[0-10]* % [0-10]* %

IBM insgesamt

[0-10]* %

Telelogic DOORS

[10-20]* %

Telelogic insgesamt

[10-20]* %

Marktanteil der beteiligten Unternehmen [20-30]* %

Borland

[0-10]* %

Serena Software

[0-10]* %

Compuware OptimalTrace

[0-10]* %

MKS

[0-10]* %

Sonstige Anbieter von RM-Point-Podukten [10-20]* %

HP Quality Center

[0-10]* %

TNI Reqtify

[0-10]* %

3SL Cradle

[0-10]* %

UGS TeamCenter

[0-10]* %

Sonstige Anbieter von PLM-Werkzeugen [20-30]* %

VersionOne

[0-10]* %

Atlassian JIRA

[0-10]* %

Sonstige Anbieter von gebündelten RM-Tools Insgesamt

-

[0-10]* %

100 %

VII.1.1.3. Schlussfolgerung

151Bei der eingehenden Untersuchung zeigte sich, dass unabhängig von der Richtigkeit des von Gartner gewählten Ansatzes zur Marktabgrenzung Vorsicht geboten ist, wenn man aus den Marktanteilen unmittelbar Schlüsse auf die Marktmacht bei Modellierungs- und Anforderungsmanagementwerkzeugen zu ziehen versucht. Durch die ausgeprägte Verschiedenartigkeit dieser Produkte ist bei den einzelnen Modellierungs- und Anforderungsmanagementwerkzeugen eine geringere Austauschbarkeit festzustellen. Ferner hat die eingehende Untersuchung bestätigt,

130Diese Tabelle basiert auf den von IBM vorgelegten Absatzzahlen, die anhand der Absatzzahlen korrigiert wurden, die im Rahmen der eingehenden Untersuchung von den Mitbewerbern eingeholt wurden. Allerdings ist dabei zu beachten, dass der hohe Marktanteil der anderen PLM-Anbieter nicht berichtigt wurde, da diesbezüglich aus der eingehenden Untersuchung keine aussagekräftigen Ergebnisse hervorgingen.

152dass Modellierungs- und Anforderungsmanagement-Tools, die heute Branchenstandard sind, bereits in weniger als fünf Jahren Legacy-Produkte sine können. Wettbewerber, die an ihren Produkten nicht regelmäßig Upgrades vornehmen oder keine neuen Produkte einführen, die die zunehmenden Anforderungen der Kunden erfüllen, werden rasch vom Markt verdrängt. Der Rückgang der Absatzzahlen des Modellierungswerkzeugs von IBM – Rational Rose – ist dafür ein gutes Beispiel.

VII.1.2. Substitutionsgrad

153Da Marktanteile im vorliegenden Fall keine präzisen Indikatoren für Marktmacht sein dürften, wurden die potenziellen wettbewerbswidrigen Auswirkungen des Zusammenschlusses hauptsächlich auf der Grundlage einer Analyse des Grads der Austauschbarkeit beurteilt.

154Der Anmelder führte aus, dass die Modellierungs- und Anforderungsmanagementwerkzeuge von IBM und Telelogic keineswegs austauschbar sind, da sie stark differenziert sind, hinsichtlich der Hauptfunktionalitäten stark voneinander abweichen und auf unterschiedliche Kundenanforderungen ausgerichtet sind. Insbesondere wird auf die Unterschiede im Bedarf der Kunden hingewiesen. So verwenden die einen Kunden Modellierungs- und Anforderungsmanagementwerkzeuge für IT-Anwendungen, während andere diese Werkzeuge in der Systementwicklung verwenden. Während die Werkzeuge von IBM stärker auf IT-Anwendungen ausgerichtet sind, sind die Werkzeuge von Telelogic besser für Systementwicklung geeignet.

155Der Grad der Austauschbarkeit lässt sich anhand von Analysen und der Ableitung von Schlussfolgerungen aus der Auswahl der Produktgruppe ermitteln, die ein Kunde vor der Kaufentscheidung in die engere Wahl zieht. Sämtliche Produkte, die der Kunde im Beschaffungsprozess in Erwägung zieht, sind potenziell mit dem letztendlich ausgewählten Produkt austauschbar. Allerdings bedeutet die Auflistung eines bestimmten Modellierungs- oder Anforderungsmanagementwerkzeugs auf einer langen Liste oder einer „Shortlist“ nicht unbedingt, dass es tatsächlich eine nahe liegende Alternative zu allen anderen aufgelisteten Werkzeugen oder dem letztendlich vom Kunden gewählten Produkt darstellt. Angesichts der ausgeprägten Verschiedenartigkeit der einzelnen Werkzeuge und der - insbesondere zu Beginn des Beurteilungsprozesses - begrenzten Kenntnisse der Kunden über die Eigenschaften des Werkzeugs und seine praktische Leistungsfähigkeit ist Vorsicht geboten, wenn man Schlussfolgerungen allein aus der Tatsache ziehen möchte, dass ein spezifisches Werkzeug auf einer langen Liste oder sogar einer „Shortlist“ aufgeführt ist. Wie im Kapitel über den Beschaffungsprozess ausgeführt werden

131Viele Kunden schalten die Dienste von Analytikern von Geschäftsprozessen und Beratern wie Gartner oder Ovum ein, um sich bei der Ermittlung potenziell geeigneter Werkzeuge beraten zu lassen. Siehe z. B. die Antwort der niederländischen Steuerbehörde vom 1. November 2007 auf Frage 2 des Auskunftsverlangens der Kommission. Darüber hinaus dürften sich die Kunden bei Anforderungsmanagementwerkzeugen mit der neuen Produktgeneration nicht gut auskennen, da

132die Kunden in den meisten Fällen erst gegen Ende des Beschaffungsprozesses wissen, ob die Produkte auf der langen Liste oder der Shortlist tatsächlich mit dem letztendlich gewählten Werkzeug austauschbar waren. Dafür hat die eingehende Untersuchung klare Beispiele geliefert .

156Im Rahmen der eingehenden Untersuchung wurde eine qualitative Analyse der Austauschbarkeit vorgenommen. Diese Analyse wurde durch eine quantitative Analyse ergänzt, soweit die Qualität der zugrunde liegenden Daten eine solche Analyse zuließ. Die qualitative Analyse basierte auf den Antworten der Kunden und Mitbewerber auf die drei Fragerunden im Auskunftsverlangen der Kommission. Eine ausgewählte Gruppe von wichtigen Kunden und Mitbewerbern wurde im Hinblick auf zusätzliche Klarstellungen befragt . Die anschließende quantitative Analyse basierte auf einer Analyse von Gewinn/Verlust-Daten.

157Eine dritte Partei (Microsoft) legte eine alternative qualitative Marktanalyse vor. Diese führt zu der Schlussfolgerung, dass der Zusammenschluss wirksamen Wettbewerb im Gemeinsamen Markt erheblich beeinträchtigen würde. Allerdings scheint die Erhebungsmethodik, auf der diese Analyse basiert, mit gravierenden Mängeln behaftet zu sein . Angesichts dieser Feststellung und unter

Berücksichtigung der Tatsache, dass die dem Bericht zugrunde liegende Erhebung nicht in vollem Umfang die im Bericht gezogenen Schlussfolgerungen untermauert, verlässt sich die Kommission in erster Linie auf die Ergebnissen ihrer eigenen eingehenden Untersuchung.

VII.1.2.1. Modellierungswerkzeuge

158Wie im Kapitel über die Anbieter von Softwareentwicklungswerkzeugen erläutert bietet IBM mehrere Modellierungswerkzeuge an. RSA ist insbesondere auf alle Entwicklungsanforderungen bei IT-Anwendungen ausgerichtet. RSM von IBM ist spezifisch für IT-Analytiker gedacht und weist die entsprechende Untergruppe der Funktionalitäten von RSA zu einem geringeren Preis auf. RSD von IBM bietet ähnliche Funktionalitäten wie RSA, ist jedoch weniger gut für die Entwicklung allgemeiner IT-Anwendungen geeignet, da die meisten gängigen IT-Programmierungen mit Hilfe von J2EE, C# und VisualBasic.NET vorgenommen werden. Obwohl sämtliche Modellierungswerkzeuge von IBM, die noch nicht Legacy-Tools sind, mit UML 2.0 konform sind, unterstützen sie nicht SysML und generieren auch keinen C-Code. Neben diesen Modellierungswerkzeugen, die noch nicht zu den Legacy-Tools gehören, hat IBM eine Reihe von Legacy-Modellierungswerkzeugen, die zur Produktlinie Rational Rose gehören. Entsprechend ihrem Legacy-Status unterstützen sie weder UML 2.0 noch SysML.

Telelogic bietet im Wesentlichen zwei Modellierungswerkzeuge an: Rhapsody und TAU . Beide Werkzeuge sind auf komplexe (eingebettete) Systeme ausgerichtet. Außerdem werden sie zur Aufschlüsselung der Analyse großer

scheinen die zitierten Aussagen eher die Unterschiede zwischen dem Anforderungsmanagement- Tool von Telelogic – DOORS – und RequisitePro von IBM als deren ähnliche Merkmale zu hervorzuheben. Die Erhebung geht nicht auf den Aspekt Modellierungswerkzeuge von IBM und von Telelogic ein. Zum Thema der Umstellungskosten kommt die Studie zu widersprüchlichen Ergebnissen. Und selbst beim Thema der „Auswirkungen des Zusammenschlusses auf die Kunden“ kommt die Studie nicht zu einheitlichen Ergebnissen, da sich mehrere Kunden dahingehend geäußert hatten, dass sich der Zusammenschluss positiv für sie auswirken würde. Auf jeden Fall kann die Studie nicht als überzeugende Untermauerung der grundsätzlichen Schlussfolgerung herangezogen werden, dass der Zusammenschluss wirksamen Wettbewerb erheblich behindern beeinträchtigen würde.

DE

DE

Systeme in verschiedene Subsystemebenen und zur Formalisierung/Modellierung der zwischen ihnen ablaufenden Interaktionen verwendet. Rhapsody und TAU sind UML-konforme Produkte. Insbesondere unterstützen Rhapsody und TAU die jüngsten in UML 2.1 ausführbaren Modelle und ermöglichen Roundtrip- Engineering zwischen Modell und Codegenerierung .

Eine Analyse der Funktionalitäten der jeweiligen Modellierungswerkzeuge von Telelogic und IBM bestätigt, dass es zwischen den Modellierungswerkzeugen beider Unternehmen deutliche Unterschiede gibt. Die meisten wichtigen Unterschiede zwischen den Modellierungswerkzeugen von Telelogic und den Nicht-Legacy-Werkzeugen von IBM liegen darin, dass die Tools von Telelogic die Modellierungssprache SysML unterstützen, dass sie vollständig konform mit den DoDAF/MoDAF-Anforderungensind, Modelle überprüfen und validieren können, die Programmiersprachen C und Ada unterstützen, bei der Codegenerierung überlegen sind und eingebettete Applikationen unterstützen (die häufig auf Echtzeit-Betriebssystemen (RTOS) laufen). Diese Funktionalitäten sind von besonderem Interesse für Systemkunden, und da die Modellierungswerkzeuge von IBM einige dieser Funktionalitäten nicht aufweisen, sind sie für den Einsatz durch Systemkunden deutlich weniger geeignet. Und letztendlich zeigt ein Preisvergleich, dass die Preise für die Modellierungswerkzeuge von Telelogic wesentlich höher als die für die Modellierungswerkzeuge von IBM sind .

DE

DE

Andererseits zeigt ein Vergleich der Funktionalitäten, die von besonderem Interesse für IT-Entwickler sind, dass insbesondere RSA von IBM besser ausgestattet ist als die Modellierungswerkzeuge von Telelogic. Dies gilt z. B. im Hinblick auf […]* .

Diese Unterschiede in den Funktionalitäten und in der kommerziellen Schwerpunktsetzung zwischen den Modellierungswerkzeugen von Telelogic und IBM spiegeln sich auch in den Kundenkategorien wider, die diese beiden Unternehmen beliefern. Die Modellierungskunden von Telelogic sind vorrangig in den Branchen tätig, die Modellierungswerkzeuge zur Entwicklung komplexer (insbesondere eingebetteter) Systeme verwenden, d. h. Luft- und Raumfahrt und Rüstungsindustrie (45 % des Umsatzes von Telelogic) und in geringerem Maße in der Kommunikationsbranche (11 %) und im Automobilsektor (5 %) . Zu den Großkunden von Telelogic zählen Lockheed Martin, Ericsson, Thales, Nokia, Raytheon, Boeing, General Dynamics, Northrop Grumman, Siemens und EADS. Die Kunden von IBM im Bereich Modellierungswerkzeuge konzentrieren sich mehr auf den Sektor Entwicklung von IT-Anwendungen, den Finanzsektor und die öffentliche Verwaltung. Mit öffentlichen Verwaltungen werden [40-50]* % der Umsätze von IBM erzielt, während auf Kunden im IT-Sektor [10-20]* % der Umsätze entfallen. Auf Kunden in der Luft- und Raumfahrt und in der Rüstungsindustrie entfallen [0-10]* % des Umsatzes. IBM erzielt den größten Teil seines Umsatzes im Sektor Luft- und Raumfahrt und in der Rüstungsindustrie sowie in anderen Sektoren der Systementwicklung mit seinen […]* Modellierungswerkzeugen .

Die Analyse der […]* von IBM ergab, […]*dass ihre Modellierungswerkzeuge für den Einsatz in Marktsegment Systementwicklung und insbesondere im Segment der komplexen (insbesondere eingebetteten) Systeme nur begrenzt geeignet sind. Dieses Segment umfasst im Wesentlichen den Luft- und Raumfahrtsektor und die Rüstungsindustrie .

Bei der Analyse der Produkt-Roadmap von IBM wurde deutlich, dass bei dem […]* Werkzeug von IBM – […]* – ein umfassendes Upgrade geplant war. Ein solches Upgrade wurde für nötig gehalten, um die Präsenz von IBM im (finanziell wichtigen) Systemsegment aufrecht zu erhalten oder zu verstärken.

Aus der Roadmap geht jedoch hervor, dass dem Tool von IBM auch nach dem Upgrade im Vergleich zu den aktuellen Versionen der Modellierungswerkzeuge von Telelogic immer noch einige Schlüsselfunktionalitäten fehlen würden ([…]*) .

Damit die Modellierungswerkzeuge von IBM mit denen von Telelogic austauschbar werden, bedarf es möglicherweise nicht nur der reinen Erweiterung der Anzahl der Funktionalitäten. Die Ergebnisse der eingehenden Untersuchung bestätigten, dass für die Kunden die Qualität der verfügbaren Modellierungsfunktionalitäten ebenso wichtig ist wie deren Anzahl. Kunden im Systemsegment gehen generell davon aus, dass die Tools von Telelogic denen von IBM sowohl quantitativ als auch qualitativ bzw. von der Tiefe her überlegen sind .

Des Weiteren bestätigte die eingehende Untersuchung, dass alle Anbieter von Modellierungswerkzeugen ständig Upgrades an ihren Werkzeugen vornehmen. Dieser Prozess wird durch die Nachfrage der Kunden nach besseren und fortschrittlicheren Modellierungswerkzeugen angeregt. So sieht Telelogic zum Beispiel für 2007 und 2008 wesentliche Upgrades seiner […]* Werkzeuge vor .

Doch selbst für den Fall, dass sich die Kluft zwischen den Modellierungswerkzeugen von Telelogic und denen von IBM etwas schließen sollte, würde dennoch weiterhin ein gewisser Abstand bestehen bleiben, der die Kaufentscheidung der Kunden im Systemsegment entscheidend beeinflussen könnte. Aus der eingehenden Untersuchung ging hervor, dass die Kunden im Systemsegment, insbesondere im Segment Luft- und Raumfahrt und Rüstungsindustrie, generell nach dem besten verfügbaren Modellierungswerkzeug Ausschau halten, da ihr quantitativer und qualitativer Bedarf an Funktionalitäten grundsätzlich den Umfang an Funktionalitäten überschreitet, den die derzeit verfügbaren Produkte zu bieten haben .

DE

DE

Letztendlich sind sich die Marketing-Abteilungen von IBM bewusst, dass ihre Produkte durch ein Upgrade kaum mit den Modellierungswerkzeugen von Telelogic austauschbar werden: „[…]* fehlt es an einer attraktiven End-to-End-Lösung für Systemkunden“ und „Erweiterungsinvestitionen werden nicht ausreichen, um den Rückstand hinsichtlich der Erwartungen der Kunden aufzuholen“ .

Branchenanalyse

169.Die eingehende Untersuchung hat bestätigt, dass Kunden unterschiedlicher Wirtschaftszweige auch einen unterschiedlichen Bedarf an Modellierungssoftware aufweisen. Generell lässt sich unterscheiden zwischen Kunden, die Modellierungswerkzeuge für die Systementwicklung verwenden, denen, die sie für IT-Anwendungen verwenden, und schließlich denjenigen, die sowohl für die Systementwicklung als auch für IT-Anwendung eine Nachfrage entfalten. Die letztgenannte Kundengruppe tendiert in der Regel zum Kauf von Modellierungswerkzeugen, die sich für verschiedene Bedürfnisse eigenen.

170.Eine Gemeinsamkeit der Kunden in der Systementwicklungsbranche besteht darin, dass sie komplexe Anforderungen haben, doch können die Anforderungen der einzelnen Kundengruppen dieses Marktsegments im Einzelnen durchaus unterschiedlich ausfallen und ihre Wahl des für sie geeigneten Modellierungswerkzeugs beeinflussen (z. B. große/kleine Systeme, kontinuierlich/reaktiv, Echtzeit, sicherheitskritisch, hardwareabhängig usw.).

Modellierungswerkzeuge können für die Erstellung von Systemspezifikationen eingesetzt werden, die (bisweilen organisationsübergreifend) von Teams bei der Zielfestlegung verwendet werden. Dadurch wird sich der Bedarf der Kunden stärker

152Siehe dazu das Protokoll des Interviews mit Lockheed Martin vom 27. November 2007: „Obwohl an erster Stelle eingestuft, ist [VERTRAULICH] bei weitem nicht das „perfekte“ Tool für Lockheed Martin, da es nur 92,6 Punkte von insgesamt maximal 200 Punkten erhielt. Dies zeigt, dass der letztendliche Bedarf von Lockheed Martin bei Weitem die Performance der Modellierungswerkzeuge übersteigt, die derzeit auf dem Markt angeboten werden, was genügend Spielraum für zukünftige Upgrades von Produkten lässt“.

DE

DE

Systeme in verschiedene Subsystemebenen und zur Formalisierung/Modellierung der zwischen ihnen ablaufenden Interaktionen verwendet. Rhapsody und TAU sind UML-konforme Produkte. Insbesondere unterstützen Rhapsody und TAU die jüngsten in UML 2.1 ausführbaren Modelle und ermöglichen Roundtrip- Engineering zwischen Modell und Codegenerierung .

178.Die eingehende Untersuchung hat bestätigt, dass die Kunden im Automobil- und Kommunikationssektor – auf den mit dem Luft- und Raumfahrt- und dem Rüstungssektor zusammengenommen rund 80 % der Kunden für Modellierungswerkzeuge für eingebettete Systemsoftware entfallen – generell ähnliche Präferenzen für die Modellierungswerkzeuge von Telelogic wie die Unternehmen des Luft- und Raumfahrtsektors und der Rüstungsindustrie äußern.

Der Modellierungsbedarf des Kommunikationssektors ähnelt in gewisser Weise dem der Systementwicklung, doch sind auch gewisse Gemeinsamkeiten mit der Entwicklung von IT-Anwendungen festzustellen. Daher sind hier Merkmale wie J2EE- oder .NET-Unterstützung relevant. Im Unterschied zu anderen Industriezweigen, die Modellierungssoftware für Systemanwendungen einsetzen, wird hier SDL parallel zu UML als Modellierungssprache verwendet. SDL ist eine Modellierungssprache mit ETSI-Spezifikation , die speziell für den Telekommunikationssektor konzipiert wurde. Telelogic ist der wichtigste Anbieter von Tools, die ETSI/ITU-Standards (d. h. die Telelogic SDL Suite) unterstützen .

Der Modellierungsbedarf für die Automobilindustrie ist als Teilbereich der Systementwicklung zu sehen. Dieser Sektor zeichnet sich durch eine Kundenstruktur aus, die in der Regel weniger komplexe Anforderungen an die

DE

DE

163Unterlage „Report on the embedded software market intelligence program, 2006 service year”, VDC, Seite 33, von IBM am 11. September 2007 vorgelegt.

164Siehe Ausführungen von IBM vom 20. November 2007.

165Das European Telecommunications Standards Institute (ETSI) ist eine unabhängige, nicht gewinnorientierte Normungsorganisation der Telekommunikationsindustrie (Ausrüstungshersteller und Netzbetreiber) in Europa mit weltweiter Ausrichtung. Als besondere Erfolge des Instituts sind die Entwicklung der GSM-Norm für das Mobilfunksystem und des TETRA-Standards für digitale Behördenfunknetze zu nennen.

166Siehe Antwort von Alcatel/Lucent vom 7. November 2007 auf Frage 15 des Auskunftsverlangens der Kommission: „UML-Werkzeuge eigenen sich besser für alle Endanwendungen mit Ausnahme von Protokollen, für die SDL besser geeignet sind“.

52

DE

DE

Softwareentwicklung stellt. Ihre Systeme sind meist nicht so umfangreich wie in der Luft- und Raumfahrtbranche oder im Telekommunikationssektor, in denen Software und Hardware eng miteinander verknüpft sind. Dementsprechend sind die Systemspezifikationen oder die strukturelle Modellierung in diesem Bereich weniger komplex. Stattdessen legen die Automobilkunden größeren Wert auf die Möglichkeit, Hardware und Software bis in kleinste Detail modellieren und Simulationsmechanismen einsetzen zu können, mit denen sich die Funktionalität, Leistungsfähigkeit und Sicherheit des Systems bereits überprüfen lässt, bevor die entsprechende Hardware zur Verfügung steht. Im Gegensatz zum allgemeinen Trend bei der Systementwicklung verwenden die Kunden der Automobilbranche (aufgrund von Leistungszwängen) zumeist C als Programmiersprache. Die anderen Programmiersprachen sind folglich weniger relevant. Dieser Umstand an sich reduziert den Einsatz der IBM-Modellierungswerkzeuge in der Automobilbranche ganz erheblich, da diese nicht zur C-Code-Generierung geeignet sind.

181.Zur Erfüllung ihrer verschiedenen Ansprüche verwenden die Kunden des Kommunikations- und des Automobilsektors für die einzelnen Modellierungsaufgaben unterschiedliche Werkzeuge. Für ihren IT-Bedarf oder weniger anspruchsvolle Systementwicklungsaufgaben wählen die Kunden in der Regel aus einer breiten Palette alternativer Modellierungswerkzeuge, die sowohl die IBM-Modellierungswerkzeuge als auch andere wie Borland, Sparx, Microsoft Visio, Artisan und Mentor Graphics umfassen. Gelegentlich greifen die Kunden für diese Aufgaben auch auf Modellierungswerkzeuge von Telelogic zurück. Da diese jedoch teurer als die weniger fortschrittlichen Modellierungswerkzeuge anderer Anbieter und komplizierter in der Anwendung sind, dürften die Kunden dieser Sektoren die Verwendung von Telelogic-Tools in ihrem Unternehmen auf die Modellierung komplexer eingebetteter Systeme beschränken. Für diese Anwendungen sind die IBM-Modellierungswerkzeuge keine nahe liegende Alternative zu den Telelogic-Tools.

IT-Anwendungen

Am anderen Ende des Spektrums sind die Kunden angesiedelt, die Modellierungswerkzeuge für IT-Anwendungen nutzen. Zu diesen Kunden zählen nicht nur IT-Unternehmen, sondern auch Finanzinstitutionen und öffentliche Verwaltungen. Der Modellierungsbedarf für die Entwicklung von IT-Anwendungen richtet sich nach den Zielvorgaben für die Runtime-Plattformen und den entsprechenden Programmiersprachen. IT-Anwendungen können auf Betriebssystemen wie Microsoft Windows oder Linux laufen, doch sind moderne Unternehmensanwendungen vielfach so konzipiert, dass sie oberhalb der

167

Middleware liegen, wie J2EE oder .NET-Anwendungsserver (z. B. IBM Websphere, BEA Weblogic, Microsoft IIS) oder Web-Server (z. B. Apache) oder Engines für das Geschäftsprozessmanagement. Für die Entwickler von IT-Applikationen ist demnach die Unterstützung der Modellierung von Webservices, von J2EE domänenspezifischen Aspekten, der Generierung von Quellcode-Frames oder Reverse-Engineering von Programmierungscodes, die auf Middleware wie J2EE (in Java geschrieben) und .NET (z. B. in C# oder VB.NET geschrieben) laufen, besonders relevant .

Der Modellierungsbedarf von Finanzdienstleistern entspricht in etwa dem der IT-Anwendungsentwicklung. Da die Anwendungen von Banken/ Finanzinstitutionen/Versicherungen meist datenbankorientiert sind, stehen eher Kriterien wie Datenmodellierung oder DDL („Data Design Language“) Codegenerierung im Vordergrund. Verschiedene Bank-, Finanz-/Versicherungsanwendungen basieren noch auf Desktop-Anwendungen in Java oder unter Einsatz von Technologien wie Corba (Client/Server-Kommunikation), weshalb diesen Merkmalen in diesem Marktsegment eine etwas höhere Bedeutung beigemessen wird.

Die eingehende Untersuchung hat bestätigt, dass die Kunden in diesen Sektoren die Modellierungsprodukte von Telelogic nur selten als nahe liegende Alternative zum IBM-Produktangebot betrachten, da sie weniger auf den spezifischen IT-Bedarf dieser Kunden zugeschnitten sind. Im Gegensatz zu vielen Kunden im Segment Systementwicklung (insbesondere in der Luft- und Raumfahrt- sowie der Rüstungsindustrie) achten die Kunden in diesen Sektoren stärker auf den Preis der Tools. Der höhere Preis und die Ausgefeiltheit von Produkten wie Rhapsody von Telelogic wären an sich schon ein Hindernis für einen breiten Einsatz in diesem Sektor. Hinzu kommt, dass die Komplexität der Telelogic-Tools im IT-Sektor generell wenig nützlich ist. Die eingehende Untersuchung hat gezeigt, dass nur wenige Kunden dieses Sektors Modellierungswerkzeuge von Telelogic in Betracht ziehen würden. Stattdessen verwenden sie IBM-Tools und eine breite Palette anderer Modellierungswerkzeuge (z. B. Oracle JDeveloper und Computer Associates).

Gewinn/Verlust-Analyse

In Ergänzung zu den Unterlagen und Stellungnahmen der Marktteilnehmer forderte die Kommission die beteiligten Unternehmen auf, eine vollständige Aufstellung

170

ihrer „Gewinn/Verlust-Daten“ für den Bereich Modellierungs- und Anforderungsmanagementwerkzeuge ab Dezember 2005 vorzulegen.

Unter „Gewinn/Verlust-Daten“ sind alle Fälle zu erfassen, in denen ein beteiligtes Unternehmen einen neuen Auftrag (Auftrag eines Unternehmens, das bisher nicht Kunde war, oder neues Projekt eines bestehenden Kunden) erhalten bzw. einen potenziellen Auftrag (Verlängerung eines bestehenden Vertrags, Ausweitung des Vertragsgegenstands eines bestehenden Auftrags, potenzieller Geschäftsabschluss) verloren hat. Zweck einer solchen quantitativen Analyse ist die Bestimmung des Substitutionsgrads zwischen den Produkten der beteiligten Unternehmen, beispielsweise durch Messung, wie häufig die Produkte der beteiligten Unternehmen in den Beschaffungsprozessen der Kunden „aufeinandertreffen“, und ob die Präsenz des Angebots der einzelnen beteiligten Unternehmen das Ergebnis des Beschaffungsprozesses der Kunden beeinflusst.

Im vorliegenden Fall wurden von den beteiligten Unternehmen erstens Angaben zum Kunden: Name des Kunden, (gegebenenfalls) Name der Gruppe, der der Kunde angehört, Land, in dem der Kunde niedergelassen ist, und Branche, in der er tätig ist; zweitens Angaben zum Projekt: Jahr, Erfassungsbereich, neues oder bereits laufendes Projekt, Hauptmerkmale des Bedarfs des Kunden/des Projekts, Gesamtwert, Anzahl der Projektlizenzen; und drittens Angaben zu den tatsächlichen bzw. vermeintlichen Lieferanten verlangt: (gegebenenfalls) Name früherer Produkte und ihrer Lieferanten, (gegebenenfalls) Namen der tatsächlichen oder vermeintlichen Konkurrenzprodukte und ihrer Lieferanten, die auf der Shortlist des Kunden enthalten sind, und (gegebenenfalls) Name des in Auftrag gegebenen Produkts.

173

[…]*. Daher stützte sich die Kommission im Wesentlichen auf die Analyse der Antwort von Telelogic. Telelogic unterhält eine Datenbank, in der in der Regel „Business Opportunities“ erfasst werden, wenn die Wahrscheinlichkeit eines Geschäftsabschlusses höher als […]* % ist .

Die Kommission hat die Gewinn/Verlust-Datensätze von Telelogic zum Produktbereich Modellierungswerkzeuge teilweise korrigiert, indem sie die

173

Genauigkeit der von Telelogic vorgelegten Informationen mit verschiedenen Kunden überprüft hat. Ein besonderes Augenmerk wurde dabei auf die Anzahl und Art der Konkurrenzprodukte gerichtet, mit denen Telelogic konfrontiert war .

Für die Jahre 2006 und 2007 enthalten die endgültigen Datensätze Angaben zu […]* Gewinn/Verlustfällen ([…]* gewonnene und […]* verlorene Geschäftsabschlüsse). Der Gesamtwert dieser (bereits unterzeichneten oder erwarteten) Abschlüsse beläuft sich auf rund […]* Mio. USD ([…]* Mio. USD für gewonnene Abschlüsse und […]* Mio. USD für verlorene Abschlüsse) .

191.In […]* der erfassten Geschäftschancen wird ein tatsächlicher oder vermuteter Konkurrent erwähnt ([…]* Gewinne und […]* Verluste). Theoretisch handelt es sich bei Geschäftschancen, für die kein tatsächlicher oder vermeintlicher Konkurrent erwähnt wird, um Anschlussaufträge oder Auftragsverlängerungen, oder aber um neue Projekte. Im ersten Fall ist der etablierte Vertragspartner (Telelogic) in der Regel keinem Wettbewerb ausgesetzt. Der einzige Unsicherheitsfaktor ist die Frage, ob der Kunde bereit ist, weitere Lizenzen für Telelogic-Produkte zu erwerben. Diese Entscheidung wird durch das Angebot der Konkurrenz jedoch praktisch nicht beeinflusst. Diese Geschäftschancen geben keinen Aufschluss über das Wechselspiel zwischen den beteiligten Unternehmen. Im anderen Fall wird der Kunde wahrscheinlich mehrere Anbieter konsultieren, um dann ein Produkt auszuwählen. In diesem Fall würde die Stichprobe die Zahl der Geschäftschancen, bei denen Telelogic mit alternativen Anbietern konfrontiert war, zu niedrig ansetzen. Damit würde die Gewinn/Verlust-Datenbank die Interaktion zwischen den Wettbewerbern nicht völlig korrekt wiedergeben.

192.Zur Bewertung der Repräsentativität des Gewinn/Verlust-Datensatzes hat die Kommission mehrere Tests durchgeführt . Trotz einiger Ungenauigkeiten

175Diese Überprüfung fand in Form von Interviews mit verschiedenen Kunden statt. Aus Zeitmangel wurde die Kundenliste auf diejenigen Kunden beschränkt, für die Telelogic als Konkurrenzprodukte entweder IBM-Legacy-Produkte oder IBM-Produkte ohne nähere Einzelheiten angegeben hatte.

176Aufgrund der Beschaffenheit der „Opportunity-Datenbank“ von Telelogic ist es möglich, dass darin nicht alle Ausschreibungsverfahren erfasst sind, an denen sich Telelogic beteiligt hat. Insbesondere stellt Telelogic klar, dass „[…]*“. Siehe Bericht von LECG mit dem Titel „Telelogic's win/loss data: description and limitations“ vom 27. November 2007.

Anhand der von den beteiligten Unternehmen vorgelegten Daten beliefen sich im Zeitraum 2006-3. Quartal 2007 die Lizenzeinnahmen von Telelogic aus Modellierungsprodukten, die für diesen Zeitraum in der Opportunity-Datenbank erfasst waren, nämlich Rhapsody, TAU und SDL, auf […]* Mio. USD. Die entsprechenden Gesamteinnahmen von Telelogic (Lizenzen, Wartung und Dienstleistungen) beliefen sich auf […]* Mio. USD. In der Gewinn/Verlust-Datenbank sind gewonnene Abschlüsse im Betrag von […]* Mio. USD ausgewiesen. Das entspricht […]* der Lizenzeinnahmen von Telelogic für den Zeitraum 2006-3. Quartal 2007 und […]* der Gesamteinnahmen für denselben Zeitraum. Der Abgleich dieser Werte ist jedoch nicht ganz einfach, da sich die in der Gewinn/Verlust-Datenbank erfassten erwarteten Werte über mehrere Jahreseinnahmen erstrecken können, während die Einnahmendaten Mittelzuflüsse aus verschiedenen Aufträgen und Elemente enthalten können, die in den ursprünglichen Aufträgen nicht vorgesehen waren (z. B. unplanmäßige Wartungsarbeiten oder Dienstleistungen).

173

scheinen die in der Gewinn/Verlust-Datenbank erfassten Informationen umfangreich genug, um eine gewisse Analyse zuzulassen.

193.Darüber hinaus hat LECG die Einnahmenverteilung nach Branchen aus beiden Quellen (gewonnene Abschlüsse aus der Gewinn/Verlust-Datenbank einerseits und Einnahmenzahlen andererseits) abgeglichen und für stimmig befunden. Dies stärkt die Glaubwürdigkeit der Analyse der Gewinn/Verlust-Daten.

194.Wie nachstehend aus Tabelle 1 hervorgeht, gibt es nur wenige Geschäftschancen, bei denen nicht in den Legacy-Bereich fallende IBM-Produkte mit Telelogic-Produkten konkurrieren: zwischen […]* und […]* von insgesamt […]* Fällen, in denen ein Konkurrent ermittelt wurde (d. h. […]*-[…]*). Ein ähnlich hoher Anteil ([…]*-[…]*) entfällt auf den Gesamtwert der Geschäftschancen, bei denen nicht in den Legacy-Bereich fallende IBM-Produkte mit Produkten von Telelogic konkurrieren und den Gesamtwert der Geschäftschancen, bei denen ein Wettbewerber ermittelt wurde.

178

Tabelle 6: Häufigkeit der Interaktion zwischen Modellierungsprodukten von Telelogic und IBM (Anzahl der Geschäftschancen, aufgeschlüsselt nach Gewinn/Verlust)

Rhapsody

SDL

TAU

Wurden IBM-Produkte als Konkurrenz in Betracht gezogen? Gewinn Verlust Gewinn Verlust Gewinn Verlust Insges.

IBM-Produkt (ohne nähere Angaben) wurde als einzige Konkurrenz in Betracht gezogen

IBM-Produkt (ohne nähere Angaben) wurde zusammen mit 2 weiteren Konkurrenzprodukten in Betracht gezogen

IBM-Legacy-Produkt wurde in Betracht gezogen

IBM-Produkt (nicht Legacy) wurde als einzige Konkurrenz in Betracht gezogen

IBM-Produkt (nicht Legacy) wurde zusammen mit 1 weiteren Konkurrenzprodukt in Betracht gezogen

IBM-Produkt wurde nicht in Betracht gezogen

Es wurde kein Wettbewerber ermittelt

Insges.

Quelle: Marktuntersuchung und Analyse der Kommission

Hinweis: (1) Zu den IBM-Legacy-Produkten zählen die Rose Produkte, d. h. Rose Enterprise, Rose Modeler, Rose RT und Rose XDE

(2) Zu den nicht in den Legacy-Bereich fallenden IBM-Produkten zählen RSA, RSD und RSM Produkte

(3) Bei IBM Produkten ohne nähere Angaben kann es sich um IBM-Legacy-Produkte oder um nicht in den Legacy-Bereich fallenden IBM-Produkte handeln

(4) In einzelnen Fällen kann mehr als ein Konkurrent präsent gewesen sein; daher beläuft sich die Gesamtzahl der hier dargestellten Interaktionen zwischen Anbieterpaaren auf 187, obwohl in der Gewinn/Verlust-Datenbank nur 181 Geschäftschancen erfasst sind, bei denen Konkurrenz festgestellt wurde

196.Abschließend ist demnach festzuhalten, dass trotz der vorstehend beschriebenen unvermeidlichen Vorbehalte die Gewinn/Verlust-Analyse zu bestätigen scheint, dass auf dem Markt für Modellierungswerkzeuge kein hoher Substitutionsgrad zwischen den beteiligten Unternehmen besteht.

Schlussfolgerung zum Substitutionsgrad zwischen den beteiligten Unternehmen

197.Auf der Grundlage der vorstehenden qualitativen und quantitativen Bewertung hat es den Anschein, dass die Modellierungswerkzeuge von Telelogic kein gleichwertiger Ersatz für die Modellierungswerkzeuge von IBM sind. Bei der Entwicklung der meisten komplexen Systeme im Luft- und Raumfahrtsektor und in der Rüstungsindustrie bietet sich als einzige echte Alternative zu den Modellierungswerkzeugen von Telelogic offenbar das UML-Tool Artisan Studio an, obwohl es in der Praxis nur in begrenztem Umfang zum Einsatz kommt. Die anderen Systemkunden im Automobil- und Telekommunikationssektor weisen eine ähnliche starke Präferenz zugunsten von Telelogic-Produkten für die Entwicklung komplexer Systeme auf.

198.Zur Deckung ihres sonstigen Modellierungsbedarfs (z. B. kleine, weniger komplexe Projekte im Bereich Systementwicklung und IT-Entwicklungsprojekte) verwenden die Kunden des Geschäftsbereichs Systementwicklung alternative Modellierungswerkzeuge (z. B. Borland, Sparx and NoMagic). Der Anteil dieser „anderen” Projekte scheint in der Automobil- und Kommunikationsbranche höher zu sein als im Luft- und Raumfahrt- und im Rüstungssektor.

199.Im IT-Bereich, in der öffentlichen Verwaltung und im Finanzsektor kommen Modellierungswerkzeuge von Telelogic nur in sehr begrenztem Umfang zum Einsatz, wohingegen IBM eine stärkere Präsenz aufweist. Diese Erkenntnis steht in Einklang mit den beschriebenen Unterschieden in den Funktionalitäten zwischen den Modellierungswerkzeugen von IBM und von Telelogic. In diesen Bereichen steht den Verwendern von IBM-Modellierungswerkzeugen eine Vielzahl alternativer Modellierungswerkzeuge zur Verfügung.

200.Wenngleich einige Kunden das Angebot von Telelogic und IBM für bestimmte Zwecke als annähernd gleichwertig ansehen, ist die Austauschbarkeit insgesamt nur in so wenigen Situationen gegeben, dass das Unternehmen nach dem Zusammenschluss die Preise nicht erhöhen könnte. Ferner gibt es eine ausreichend große Zahl an Anbietern von Modellierungs- und Anforderungsmanagementwerkzeugen, deren Funktionen ungefähr denen der Produkte von IBM und Telelogic entsprechen, so dass eine derartige Preiserhöhung unrentabel wäre. Da Beschaffungsentscheidungen (insbesondere bei Großbestellungen) oftmals auf der Grundlage eines ausschreibungsähnlichen Verfahrens getroffen werden, sind die Marktanteile von IBM und Telelogic in solchen Fällen weniger relevant.

VII.1.2.2 Anforderungsmanagementwerkzeuge

201.IBM bietet ein Anforderungsmanagementwerkzeug an. Es trägt die Bezeichnung RequisitePro und zielt in erster Linie auf betriebswirtschaftlich ausgerichtete Analytiker ab, die IT-Anwendungen für Geschäftsprozesse (z. B. Sales Tracking, Fakturierung) entwickeln.

202.Telelogic bietet im Wesentlichen drei Anforderungsmanagementwerkzeuge an, DOORS, Focal Point und DOORS Fastrak. DOORS ist zur Deckung der Managementanforderungen von Systemingenieuren bei der Systementwicklung konzipiert. Focal Point ist im Grunde eher ein Portfoliomanagementwerkzeug als ein Anforderungsmanagementwerkzeug. DOORS Fastrak ist eine anwenderfreundliche „Light“-Version von Focal Point, die im April 2007 auf den Markt gebracht wurde. Sie gilt als „Out-of-the-Box“-Lösung für das

180Siehe Ausführungen von IBM vom 21. November 2007, wo dieses Anforderungsmanagementwerkzeug näher beschrieben wird.

181Siehe Ausführungen von IBM vom 21. November 2007.

182Die Lizenz von DOORS Fastrak begrenzt die Funktionalitäten, die in Focal Point genutzt werden können; siehe Ausführungen von IBM vom 12. Dezember 2007.

203.Anforderungsmanagement bei Softwareentwicklungsprojekten mit hohem Tempo. Sowohl DOORS Fastrak als auch Focal Point erzielen nur sehr moderate Umsatzzahlen im Vergleich zu DOORS, dem meistverkauften Anforderungsmanagementwerkzeug auf dem Markt.

204.Eine Analyse der Funktionalitäten der Anforderungsmanagementwerkzeuge von Telelogic und IBM bestätigt, dass zwischen diesen Werkzeugen deutliche funktionale Unterschiede bestehen. RequisitePro von IBM ist ein dokumentzentriertes, leichtes, im Wesentlichen auf IT ausgerichtetes Werkzeug, das in der Regel von betriebswirtschaftlich ausgerichteten Analytikern verwendet wird. Es ist für die Verwendung mit Microsoft Word konzipiert, um dem Anwender einen vertrauten Umgang zu erleichtern. Die Anforderungsdefinition in RequisitePro ist einfach: informelle Sprachebene, Priorität (hoch, mittel, gering), Kosten (hoch, mittel, gering). Die Verwender von RequisitePro nutzen im Durchschnitt 500-1000 Anforderungen, doch hat das Werkzeug eine Kapazität von bis zu 50 000 Anforderungen.

205.DOORS von Telelogic ist ein datenbankzentriertes fortschrittliches Werkzeug für komplexe Projekte mit ausgereiften stark strukturierten Prozessen, die eine große Anzahl von Anforderungen mit einem intensiven Prozess zur Anforderungsanalyse beinhalten. Es ist für anspruchsvolle Verwender konzipiert und hat eine komplexe Benutzerschnittstelle. Es beinhaltet umfassende Reporting- und Analyse-Tools zur Bestimmung von Mängeln und Änderung der Wirkungswerte und Metriken. Verwender von DOORS nutzen im Durchschnitt etwa 100 000 Anforderungen oder mehr, wobei maximal bis zu 10 Millionen Anforderungen möglich sind.

206.Ein Vergleich beider Werkzeuge zeigt, dass DOORS das leistungsstärkere und ausgefeiltere von beiden ist. Dies ist vor allem im Systementwicklungsbereich von Vorteil. Im Vergleich zu DOORS fehlt es RequisitePro an folgenden für Systementwicklungskunden maßgeblichen Attributen: […]* .

207.Auf der anderen Seite weist DOORS in einigen für die IT-Entwicklung maßgeblichen Attributen Schwächen auf: Es mangelt an […]* . Telelogic hat vor kurzem mit DOORS Fastrak eine „Light“-Version von Focal Point eingeführt.

183Der Begriff „Out-of-the-Box“ wird in der Software-Industrie normalerweise für eine Software verwendet, die leicht zu installieren ist, keine besondere Einarbeitung erfordert und einfach funktioniert.

184Siehe Ausführungen von IBM vom 12. Dezember 2007.

208.Obwohl DOORS Fastrak kostengünstiger und einfacher in der Anwendung als DOORS ist, mangelt es nach wie vor an […]*. Telelogic Focal Point ist für IT-Kunden ein eher unattraktives Produkt. Es ist eher als Produktportfolio-Managementwerkzeug als als Anforderungsmanagementwerkzeug positioniert und schneidet hinsichtlich […]* relativ schlecht ab.

207.Die internen Unterlagen von IBM bestätigen die Überlegenheit des Telelogic-Produkts DOORS im Segment Systementwicklung. Der Anmelder geht davon aus, dass DOORS eine Lücke im IBM-Produktportfolio füllen und dem Unternehmen Zugang zu Kunden (z. B. in der […]*-Industrie) erschließen wird, die es andernfalls nicht erreichen könnte.

209.Die Unterschiede in den Funktionalitäten und Schwerpunkten zwischen DOORS von Telelogic und RequisitePro von IBM spiegeln sich auch im jeweiligen Kundenprofil wider. Zu den Kunden von IBM-RequisitePro zählen im Wesentlichen öffentliche Verwaltungen ([…]*) und Finanzinstitutionen ([…]*) und nur in begrenztem Umfang die typischen Systemsektoren wie Luft- und Raumfahrtindustrie und Verteidigungssektor ([…]*), Automobilbranche ([…]*) und der Kommunikationssektor ([…]*). Die Anforderungsmanagement-Kunden von Telelogic dagegen sind vor allem in den Bereichen Luft- und Raumfahrt und Rüstungsindustrie ([…]*), der Automobilbranche ([…]*) und im Kommunikationssektor ([…]*) zu finden.

210.Eine Untersuchung der Produkt-Roadmap von IBM bestätigt, dass verschiedene Funktionalitäten von RequisitePro aktualisiert werden sollen (z. B. […]*). Allerdings betreffen die geplanten Upgrades nicht die „Kernattribute“, die den Abstand zwischen den Anforderungsmanagement-Tools von IBM und Telelogic aufheben oder verringern würden. Wie im Zusammenhang mit den Modellierungswerkzeugen bereits erläutert erkennt IBM selbst an, dass es unwahrscheinlich ist, dass seine Werkzeuge (d. h. sowohl die Modellierungs- als auch die Anforderungsmanagementwerkzeuge) durch die Modernisierung zu einem gleichwertigen Ersatz für die Modellierungswerkzeuge von Telelogic werden: […]* und „Erweiterungsinvestitionen werden nicht ausreichen, um den Rückstand hinsichtlich der Erwartungen der Kunden aufzuholen“ .

189Siehe […]* Ausführungen von IBM vom 21. November 2007.

190Siehe […]* Ausführungen von IBM vom 21. November 2007.

191[…]

192Siehe Ausführungen von IBM vom 4. Dezember 2007 einschließlich einer LECG-Untersuchung über die Einkommensverteilung der beteiligten Unternehmen aufgeschlüsselt nach Wirtschaftszweigen.

193Siehe Ausführungen von IBM vom 23. August 2007 betreffend die Erörterung und Untersuchung der Produkt-Roadmap für […]*.

194[…] vom 7. August 2006, S.12, von IBM in Anhang 8 der Antwort vom 5. November 2007 auf das Auskunftsverlangen der Kommission vorgelegt.

Branchenanalyse

210.Ähnlich wie bei den Modellierungswerkzeugen bestätigte die eingehende Untersuchung auch in Bezug auf die Anforderungsmanagement-Tools, dass Kunden in verschiedenen Wirtschaftszweigen einen unterschiedlichen Produktbedarf aufweisen. Die Unterscheidung zwischen Systementwicklungskunden und IT-Anwendungskunden ist auch bei den Anforderungsmanagementwerkzeugen relevant.

211.Der Anforderungsmanagementbedarf im Bereich Systementwicklung ist in der Tatsache begründet, dass die Projekte einen zunehmend längeren Lebenszyklus aufweisen, während die Teams gleichzeitig umfangreicher werden und sich stärker verteilen (innerhalb der Organisation oder organisationsübergreifend). Aus diesen Gründen sind hier verschiedene Merkmale im Zusammenhang mit der Skalierbarkeit der Anzahl der Benutzer (z. B. Change Proposal System, Workflow-Unterstützung, Prüfpfade, Sicherheits-/Zugriffskontrolle) und der Skalierbarkeit der Anforderungen (z. B. Wirkungsanalyse, Orphan-Analyse) relevanter als bei anderen Anwendungen. Da die Systementwicklung sowohl Hardware- als auch Softwareanforderungen beinhaltet, ist hier außerdem die Integration mit Werkzeugen für das Produktlebenszyklus-Management wie CAD (Computer Aided Design) oder EDA (Electronic Design Automation) besonders relevant.

Auch innerhalb der Gruppe der Systemkunden sind Unterschiede festzustellen. Sie sind Ausdruck der Besonderheiten der einzelnen Marktsegmente und der damit zusammenhängenden Präferenzen zugunsten von bestimmten Anforderungsmanagementwerkzeugen.

Luft- und Raumfahrt- und Rüstungsindustrie

213.Der Bedarf des Luft- und Raumfahrtsektors und der Rüstungsindustrie an Anforderungsmanagement deckt sich weitgehend mit dem der Systementwickler allgemein. Eine Besonderheit dieses Sektors sind langfristige Projekte und komplexe Hauptauftragnehmer- und Unterauftragnehmerbeziehungen. Aufgrund des Umfangs der Projekte sind Kriterien im Zusammenhang mit der Planung und Schätzung in der Regel nicht relevant, da diese von dazu besser geeigneten Spezial-Tools (z. B. Primavera) abgedeckt werden. Umgekehrt wird Kriterien im Zusammenhang mit den Benutzen und der Skalierbarkeit ihrer Anforderungen mehr Gewicht beigemessen (z. B. Workflow-Unterstützung, Change Proposal System, Versionierung von Anforderungen, Orphan/Vollständigkeitsanalyse).

215.Die Ergebnisse der eingehenden Untersuchung bestätigen, dass die Anforderungsmanagementsysteme von IBM und Telelogic nicht in direktem Wettbewerb zueinander stehen. Kunden im Luft- und Raumfahrtsektor und in der Rüstungsindustrie, die Anforderungsmanagementwerkzeuge im Wesentlichen für umfangreiche Systeme benötigen, haben eine eindeutige Präferenz zugunsten von DOORS von Telelogic. Einige Kunden in dieser Kategorie sind der Meinung, dass es beim Umgang mit komplexen Systemen keine Alternative zu DOORS gibt.

Allerdings gibt es in dieser Kategorie auch Kunden, die sowohl DOORS von Telelogic als auch RequisitePro von IBM benutzen. In vielen dieser Fälle hat es jedoch den Anschein, dass jedes dieser Werkzeuge für unterschiedliche Zwecke eingesetzt wird, d. h. DOORS wird zur Deckung des Systembedarfs des Unternehmens verwendet, und RequisitePro kommt bei Projekten zum Einsatz, die schwerpunktmäßig auf Softwareentwicklung ausgerichtet sind.

Automobil- und Kommunikationssektor

Der Anforderungsmanagementbedarf der Automobilbranche deckt sich weitgehend mit dem der Systementwickler allgemein. Der Automobilsektor zeichnet sich durch Kunden aus, die hinsichtlich der Softwareentwicklung weniger anspruchsvoll sind, jedoch eher sensibel auf Preise und die Komplexität der Werkzeuge reagieren. Ihre Entwicklungsteams sind in der Regel kleiner als in der Luft- und Raumfahrtindustrie, im Rüstungs- oder Kommunikationssektor und in der Entwicklungsbranche. Aus diesen Gründen sind Merkmale im Zusammenhang mit der Skalierbarkeit der Teams wie Webzugang, Sicherheits- und Zugriffskontrolle weniger relevant, wohingegen auf Preise, Benutzerfreundlichkeit, Integration mit PLM-Werkzeugen oder Planungsunterstützung größerer Wert gelegt wird.

195Siehe Antwort von Safran vom 31. Oktober 2007 auf Frage 59 des Auskunftsverlangens der Kommission. Safran vertritt die Ansicht, dass “Doors ein einzigartiges Werkzeug für die Luft- und Raumfahrtindustrie ist”. Siehe auch Antwort von Elbit vom 2. November 2007 auf Frage 59 des Auskunftsverlangens der Kommission: „Für einige unserer Legacy-Projekte verwenden wir RequisitePro. Allerdings fanden wir dieses Werkzeug für Großprojekte ungeeignet, und bis heute ist Doors ein Standardwerkzeug für das Anforderungsmanagement. Ich sehe im Moment keine echte Alternative zu Doors”.

196Siehe z. B. Antwort von Thales vom 8. November 2007 auf Frage 57 des Auskunftsverlangens der Kommission. Thales äußert sich wie folgt zu Telelogic Doors: „Es gibt alternative Anbieter (IBM, Borland, Serena …). Aber ihre Produkte weisen nicht das gleiche Niveau in Bezug auf Funktionalitäten und Leistungsfähigkeit auf wie Doors.“

197Siehe z. B. Antwort von Safran vom 31. Oktober 2007 auf Frage 54 des Auskunftsverlangens der Kommission. Safran verwendet Doors für das System- und Produkt-Anforderungsmanagement, während RequisitePro für das Software-Anforderungsmanagement eingesetzt wird. Siehe auch Antwort von Northrop Grumman vom 15. Januar 2008 auf Frage 59 des Auskunftsverlangens der Kommission: „Die Entscheidung zwischen den beiden Anforderungsmanagementwerkzeugen hängt von der Art des Entwicklungsprojekts ab. Im Zusammenhang mit einer Suite und für den Fall, dass das Projekt weitgehend auf Softwareentwicklung ausgerichtet ist, wird vielfach die IBM-Rational Tool-Suite zur Integration mit anderen Software-Managementwerkzeugen aus dem Rational-Suite-Programm „Computer Aided Software Engineering“ (CASE) gewählt […]. Wenn es bei dem Projekt dagegen um eine Kombination aus System- und Softwareentwicklung oder vorrangig um System- / Komponentenentwicklung geht, wird vielfach auf Telelogic DOORS zur Integration mit Telelogic System Architect und Telelogic TAU zurückgegriffen.”

64

217.Die eingehende Untersuchung hat gezeigt, dass DOORS in der Automobilbranche generell als Standard für das Anforderungsmanagement gilt. Die Kunden entscheiden sich entweder für DOORS, weil sie es für das Werkzeug mit den besten Eigenschaften halten, oder weil es ihnen den Austausch mit Lieferanten, Unterauftragnehmern usw. erleichtert. In einigen Fällen sind die Kunden sogar vertraglich verpflichtet, mit DOORS zu arbeiten. Die an der eingehenden Untersuchung mitwirkenden Unternehmen nennen einige potenzielle Alternativen zu DOORS, beispielsweise MKS, Borland Caliber, IRQA, Polarion ALM, Reqtify und Siemens UGS TeamCenter. RequisitePro von IBM wird jedoch generell nicht als potenzieller Ersatz genannt.

Der Anforderungsmanagementbedarf des Kommunikationssektors deckt sich weitgehend mit dem der Systementwickler allgemein, doch gibt es auch einige Gemeinsamkeiten mit der IT-Anwendungsentwicklung. Es ist üblich, dass Kommunikationssysteme IT-Anwendungen beinhalten oder an sie angeschlossen sind. Entsprechend sind hier auch Merkmale wie Ablaufplanung (Storyboard) gefragt. Ähnlich wie in der Automobilbrache und im Kommunikationssektor weist die Systementwicklung auch hier kürzere Entwicklungszyklen auf, allerdings sind die Entwicklungsteams größer. Daher sind Planungs- und Schätzungsmerkmale sowie die Skalierbarkeit der Anzahl der Benutzer hier stärker gefragt. Schließlich sind die Entwicklungsteams im Kommunikationssektor in der Regel auch Benutzer verschiedener PLM-Werkzeuge wie Produktdatenmanagement- (Trackingfunktion für Materialliste von Hardware-Komponenten) und Konfigurationsmanagement-Werkzeuge (Trackingfunktion für Versionen von Software- und Hardwarekomponenten). Folglich ist die Integration mit PLM-Werkzeugen von größerer Relevanz.

198 Siehe Antwort von Audi vom 8. November 2007 auf Frage 55 des Auskunftsverlangens der Kommission. Hier heißt es, dass DOORS de facto das Standard-Anforderungsmanagementwerkzeug für die Automobilbranche ist. Siehe auch Antwort von Daimler vom 8. November 2007 auf Frage 55 des Auskunftsverlangens der Kommission: „Telelogic Doors ist die wichtigste Werkzeug-Suite für das Anforderungsmanagement. Da Doors bei so vielen Projekten zum Einsatz kommt, werden sich zahlreiche andere Projekte diesem Quasi-Standard anschließen“.

199 Siehe z. B. Antwort von Conti vom 22. November 2007 auf Frage 59 des Auskunftsverlangens der Kommission. „Wir verwenden Doors, weil unsere Kunden Doors verwenden. Außerdem gibt es auf dem Markt derzeit nur sehr schwache Alternativen“. Siehe auch Antwort von HD Leopold Kostal vom 31. Oktober 2007 auf Frage 59 des Auskunftsverlangens der Kommission: „Einige Anforderungsmanagementwerkzeuge könnten eine Alternative zu Telelogic Doors darstellen, wäre da nicht die Tatsache, dass viele Kfz-Hersteller Doors verwenden, und der Datenaustausch dadurch komplizierter würde“.

200 Siehe z. B. die Antwort von Conti vom 22. November 2007 auf Frage 56 des Auskunftsverlangens der Kommission. Conti nennt die Anforderungsmanagementwerkzeuge von Borland Caliber und MKS RM (IBM-Werkzeuge werden nicht erwähnt).

201 Siehe z. B. die Antwort von Daimler vom 8. November 2007 auf Frage 59 des Auskunftsverlangens der Kommission, in der es um die Austauschbarkeit der Anforderungsmanagementwerkzeuge von IBM und Telelogic geht: „Wir haben bisher keine Konkurrenz zwischen den Werkzeugen von IBM und Telelogic festgestellt. […] Die IBM-Werkzeug-Suiten werden für andere Zwecke eingesetzt“. Siehe auch die in den vorangegangenen drei Fußnoten erwähnten Antworten von Conti und Audi sowie die Antworten von Porsche vom 30. Oktober 2007 und von HD Leopold Kostal vom 31. Oktober 2007 auf Frage 54 des Auskunftsverlangens der Kommission.

202 Storyboards sind grafische Ordnungsmittel wie eine sequenzielle Abfolge von Illustrationen oder Bildern, die zum Zwecke der Vorabvisualisierung einer Bewegungsgrafik oder einer interaktiven Mediensequenz einschließlich einer interaktiven Website verwendet werden.

65

Die eingehende Untersuchung bestätigte, dass die Kunden des Telekom-Sektors in der Regel aus einer Vielzahl verschiedener Anbieter auswählen, darunter DOORS, Requisite Pro, Borland Caliber, Serena RTM, 3SL Cradle, Siemens UGS TeamCenter Systems Engineering, IRQA, Speedreq, Ontopia Force, Omninet Omni Tracker, Enovia Matrix One, oder aber (in Abhängigkeit von dem jeweiligen Projekt) für das Anforderungsmanagement relativ einfache Werkzeuge wie Microsoft Word und Excel verwenden. Die eingehende Untersuchung zeigte jedoch auch, dass für viele Kunden DOORS nach wie vor das bevorzugte Werkzeug ist.

IT-Anwendungen

Der Anforderungsmanagementbedarf für IT-Anwendungen ist durch die Notwendigkeit der Erfassung, Priorisierung und des Tracking von Merkmalen geprägt, die Teil der Anwendungsfunktionalität und Benutzerschnittstelle des IT-Systems werden. Da Anforderungsmanagementwerkzeuge für IT-Anwendungen im Wesentlichen von geschäftlich ausgerichteten Anwendern verwendet werden, sind Benutzerfreundlichkeit, Integration mit den Microsoft Office Tools und der Preis ausschlaggebende Kriterien. Ebenfalls wichtig sind die Unterstützung von visuellen Storyboards (die die Möglichkeit zur Erzeugung von Anschauungsmodellen (Screen-Mockups) bieten, auf denen Inhalt und Leistung der Benutzerschnittstelle dargestellt werden können) und Storyboard-Simulation.

Der Anforderungsmanagementbedarf des Finanzsektors ähnelt dem der IT-Entwicklung. Im Vergleich zur IT-Entwicklung in anderen vertikalen Unternehmensstrukturen zeichnet sich der Finanzsektor durch eine hohe Anzahl kleiner, kurzfristiger Projekte aus. Daher sind hier die Skalierbarkeit der Anzahl der Benutzer oder Anforderungen oder fortgeschrittene Merkmale wie Versionierung der Anforderungen oder Wirkungsanalyse von untergeordneter Bedeutung. Wichtiger sind dagegen Möglichkeiten wie Storyboarding, da die Kunden vielfach bestrebt sind, die geplanten neuen Merkmale von den Endbenutzern validieren zu lassen, bevor sie mit der eigentlichen Entwicklung beginnen.

203 Siehe z. B. Antwort von AT&T vom 2. November auf Frage 60 des Auskunftsverlangens der Kommission. „Die meisten unserer Entwicklungsgruppen verwenden MS/Excel oder MS/Word für ihren Dokumentations-, Track- und Trace-Bedarf.

204 Siehe z. B. Antwort von Motorola vom 8. November 2007 auf die Fragen 59 und 62 des Auskunftsverlangens der Kommission: „Doors von Telelogic ist unser bevorzugtes RM-Werkzeug. Bei Motorola kommt überwiegend Doors zum Einsatz“. In gewissem Umfang wird jedoch auch RequisitePro von IBM verwendet: „RequisitePro wurde von Übernahmeunternehmen […] in Fällen ausgewählt, in denen es als Legacy-Produkt im Einsatz war und die Umstellung eine Unterbrechung der Geschäftsabläufe bedeutet hätte. In der Regel entscheiden sich die Benutzer nur dann für RequisitePro, wenn sie von den Suite-Möglichkeiten mit anderen Rational-Produkten Gebrauch machen wollen. Als Einzelprodukt ist Doors überlegen und damit die von uns empfohlene AM-Lösung“.

205 Siehe Ausführungen von IBM vom 20. November 2007.

66

der Anforderungen oder Wirkungsanalyse von untergeordneter Bedeutung. Wichtiger sind dagegen Möglichkeiten wie Storyboarding, da die Kunden vielfach bestrebt sind, die geplanten neuen Merkmale von den Endbenutzern validieren zu lassen, bevor sie mit der eigentlichen Entwicklung beginnen.

222.In Einklang mit den besonderen Merkmalen der vorstehend beschriebenen Marktsegmente ergab die eingehende Untersuchung eine andere Produktpräferenz, als sie im Systemsegment ermittelt wurde. Die Kunden bevorzugen in der Regel das IBM-Produkt RequisitePro, wobei sie vielfach parallel dazu andere Alternativen einsetzen. In diesen Alternativen sind die Anforderungsmanagementwerkzeuge von Telelogic oft nicht enthalten. Die eingehende Untersuchung ergab, dass selbst die Verwendung relativ einfacher Werkzeuge wie Microsoft Excel und Word durchaus üblich ist. Wenn die Anforderungsmanagementwerkzeuge von IBM und Telelogic parallel eingesetzt werden, dann in aller Regel für unterschiedliche Zwecke.

In Anbetracht der vorstehenden Ausführungen kann der Schluss gezogen werden, dass die eingehende Untersuchung weitgehend eine geringe Austauschbarkeit der Anforderungsmanagementwerkzeuge von IBM und Telelogic bestätigt hat. Auf jeden Fall hat die eingehende Untersuchung gezeigt, dass selbst in Fällen, in denen der eine oder andere Kunde Werkzeuge beider Anbieter in Betracht zieht, nur ein geringes Risiko besteht, dass die fusionierte Einheit nach dem Zusammenschluss die Preise erhöht, da es eine ausreichend große Zahl an Anbietern von Anforderungsmanagementwerkzeugen auf dem Markt gibt, deren Funktionen ungefähr denen von RequisitePro entsprechen, so dass eine derartige Preiserhöhung unrentabel wäre.

Gewinn/Verlust-Analyse für Anforderungsmanagementwerkzeuge

224.Die beteiligten Unternehmen haben darüber hinaus Gewinn/Verlustdaten für die Lieferung von Anforderungsmanagementwerkzeugen vorgelegt. […]*. Daher stützte sich die Kommission im Wesentlichen auf die Auskünfte über Telelogic.

206 Siehe z. B. die Antwort von ABNAMRO vom 2. November 2007 auf die Fragen 54 und 59 des Auskunftsverlangens der Kommission und die Antwort der niederländischen Steuerverwaltung vom 1. November 2007 auf die Fragen 17, 54 und 56 des Auskunftsverlangens der Kommission.

207 Siehe die Antwort der niederländischen Steuerverwaltung vom 1. November 2007 auf Frage 17 des Auskunftsverlangens der Kommission. „Bei vielen Projekten erfolgt die Erfassung der Anforderungen noch mit Word oder Excel“.

208 Siehe Antwort von Unisys vom 7. November 2007 auf Frage 58 des Auskunftsverlangens der Kommission: „Rational RequisitePro als Teil der Rational-Suite kommt bei Vorhaben im Bereich Anwendungsentwicklung zum Einsatz, die von einem Team an einem einzigen Standort durchgeführt werden. […] Doors von Telelogic wird für die gleichen Projekte wie RequisitePro verwendet, an denen jedoch große, auf verschiedene Standorte verteilte Teams mitwirken. In der Entwicklungsumgebung wird Doors von Telelogic ausschließlich für Anforderungsmanagementaufgaben eingesetzt, die sich über ein Portfolio von Software-, Hardware- und Systemprodukten erstrecken, die von auf verschiedene Standorte verteilten Teams entwickelt werden“.

67

225.Bedauerlicherweise sind die in der Datenbank erfassten Geschäftschancen von Telelogic im Bereich Anforderungsmanagement mit so vielen Vorbehalten behaftet, dass eine aussagekräftige Analyse nicht möglich ist. Erstens liegen nur für […]* von insgesamt […]* Geschäftschancen (d. h. […]*) Angaben zu tatsächlichen oder vermeintlichen Konkurrenten vor. Außerdem hat LECG die Einkommensverteilung nach Branchen für die in der Gewinn/Verlust-Datenbank von Telelogic erfassten gewonnenen Fälle mit der Verteilung der Gesamteinnahmen von Telelogic in der Sparte Anforderungsmanagement abgeglichen. Die beiden Datensätze weisen enorme Unterschiede auf.

226.Folglich lassen sich aus der Gewinn/Verlust-Datenbank für Anforderungsmanagementwerkzeuge keine stichhaltigen Schlüsse über den Wettbewerbsdruck ziehen, den die beteiligten Unternehmen aufeinander ausüben.

Schlussfolgerung zum Substitutionsgrad

227.Nach der vorstehenden vorwiegend qualitativen Analyse hat es den Anschein, dass die Anforderungsmanagementwerkzeuge von Telelogic kein gleichwertiger Ersatz für das IBM-Anforderungsmanagementwerkzeug RequisitePro ist. Für viele systementwicklungsorientierte Branchen kommt DOORS von Telelogic fast einem Industriestandard gleich (z. B. Luft- und Raumfahrtindustrie, Rüstungssektor und Automobilbranche), für den es hinsichtlich der Funktionalitäten und der Gesamtleistungsfähigkeit keine realistische Alternative gibt. Die anderen Anforderungsmanagementwerkzeuge von Telelogic sind entweder keine reinen Anforderungsmanagementwerkzeuge (Focal Point), oder es fehlt ihnen an Funktionalitäten (DOORS Fastrak). Folglich sind auch sie kein gleichwertiger Ersatz.

228.In den Fällen, in denen Systemkunden der Ansicht sind, dass es realistische Alternativen zu DOORS von Telelogic gibt, wird nicht nur auf IBM-RequisitePro, sondern auf eine ganze Reihe verschiedener Werkzeuge verwiesen (z. B. Borland Together, Serena RTM, Siemens UGS TeamCenter), darunter auch auf grundlegende Universal-Produktivitätswerkzeuge wie Microsoft Word und Excel sowie auf Werkzeuge relativ kleiner Anbieter. Die Verwendung von Microsoft-Produkten und sonstigen verhältnismäßig einfachen Werkzeugen ist bei den Benutzern von Anforderungsmanagementwerkzeugen üblicher als bei Benutzern von Modellierungswerkzeugen.

229.Im IT- und im Finanzsektor kommen die Anforderungsmanagementwerkzeuge von Telelogic nur in sehr begrenztem Umfang zum Einsatz, insbesondere weil DOORS als zu komplex und zu teuer erachtet wird. In diesen Sektoren spielt der Preis eine wesentlich größere Rolle als im Systemsektor. Die Kunden des IT- und des Finanzsektors haben eine ausgeprägte Vorliebe für IBM-RequisitePro und eine Vielzahl anderer Anbieter von Anforderungsmanagementwerkzeugen.

Selbst in den Fällen, in denen der eine oder andere Kunde die Anforderungsmanagementwerkzeuge von Telelogic und IBM für austauschbar hält, hätte die fusionierte Einheit nicht die Möglichkeit, nach dem Zusammenschluss die Preise zu erhöhen.

VII.2 Geringerer Innovationsanreiz

231.In der Entscheidung über die Einleitung des Verfahrens wurde festgestellt, dass einige Kunden die Besorgnis geäußert hatten, dass der geplante Zusammenschluss wirksamen Wettbewerb im Bereich der Modellierungs- und Anforderungsmanagementwerkzeuge insofern beeinträchtigen würde, als er einen Rückgang der Innovationstätigkeit zur Folge hätte. Daher ging die Kommission in ihrer eingehenden Untersuchung der Frage nach, ob das Unternehmen IBM/Telelogic einen geringeren Innovationsanreiz hätte als die beiden Unternehmen IBM und Telelogic für sich genommen (d. h. wenn es nicht zu dem geplanten Zusammenschluss käme).

Der Anmelder weist in diesem Zusammenhang darauf hin, dass die Innovation in der Softwareentwicklungsbranche weniger durch den Wettbewerb zwischen IBM und Telelogic als vielmehr durch die von den Kunden gestellten Anforderungen angetrieben wurde, und dass dies auch in Zukunft so bleiben wird.

Dazu erklärt der Anmelder, dass IBM und Telelogic bei der Entwicklung ihrer Werkzeuge in den letzten Jahren unterschiedliche Wege eingeschlagen haben. Während IBM den Schwerpunkt seiner Investitionstätigkeit auf die Entwicklung von Modellierungswerkzeugen für die IT-Softwareentwicklung gelegt hat (d. h. […]*), konzentrierte Telelogic seine Investitionen im Modellierungsbereich schwerpunktmäßig auf die Entwicklung von Werkzeugen für die Systemsoftwareentwicklung (z. B. […]*). IBM führt ferner aus, dass die wichtigsten Innovationen, die Telelogic in den letzten Jahren eingeführt hat, auf Konsultationen mit den Kunden zurückgehen.

Daher erklärte der Anmelder, dass er für die kommenden Jahre voraussichtlich eher einen Ausbau seiner Innovationsanstrengungen plane. In diesem Zusammenhang weist IBM darauf hin, dass das Unternehmen „bereits unmittelbar nach der Übernahme eine Erhöhung der FuE-Ausgaben für die Produkte von Telelogic geplant hat. 2006 beliefen sich die FuE-Aufwendungen von Telelogic auf rund […]* Mio. USD, während im Business Case für die Übernahme eine Erhöhung der FuE-Ausgaben auf […]* Mio. USD im Jahr 2008 und auf […]* Mio. USD bis 2012 veranschlagt wurde“ .

Außerdem führt IBM an, dass Open-Source-Tools (wie z. B. CVS, Subversion, Bugzilla, JIRA oder Trac) in zunehmendem Maße von Entwicklungsteams in kleinen und mittleren Unternehmen einschließlich kleiner unabhängiger Teams in Großunternehmen verwendet werden.

Schließlich bringt IBM vor, dass Innovation für das Überleben in dem sich ständig verändernden Software-Sektor unverzichtbar ist, und dass sich daran auch nach dem Zusammenschluss nichts ändern werde. Das Beispiel der IBM-Rose-Produkte zeigt, dass selbst bei führenden Werkzeugen der Absatz innerhalb relativ kurzer Zeit […]* einbrechen kann, wenn ein Produkt den neuen Anforderungen der Kunden nicht gerecht wird.

Die eingehende Untersuchung hat zunächst gezeigt, dass der Wettbewerb zwischen IBM und Telelogic in der jüngsten Vergangenheit die Innovation nicht wesentlich vorangetrieben hat. Zwar erwähnten einige Kunden, dass sich der Wettbewerb zwischen IBM und Telelogic positiv auf die Innovation ausgewirkt habe, doch erklärte die überwiegende Mehrheit der an der Marktuntersuchung beteiligten Unternehmen, dass die Innovation in der Softwareentwicklungsbranche durch die Entwicklung der Modellierungssprachen (insbesondere die Einführung der standardisierten UML-Sprache) und die ständig steigenden Anforderungen der Kunden - insbesondere derer mit Geschäftsschwerpunkt Systemsoftwareentwicklung - angespornt wird.

In diesem Zusammenhang bestätigten Kunden, die sowohl auf IT-Software als auch auf Systemsoftware spezialisiert sind, dass der Wettbewerb in erster Linie durch die Anforderungen der Kunden angetrieben wird. Boeing, dessen Schwerpunkt in der Systemsoftwareentwicklung liegt, führte aus, dass man „nicht glaube, dass der Wettbewerb zwischen diesen Unternehmen zwangsläufig die Innovation in Bezug auf die Modellierung angetrieben hat. Der Wettbewerb wurde sowohl durch die Anforderungen der Kunden als auch durch bessere Standards für UML geschürt“. In Bezug auf die Anforderungsmanagementwerkzeuge wies Boeing ferner darauf hin, dass der Wettbewerb zwischen den beteiligten Unternehmen keine nennenswerten Impulse auf den Wettbewerb insgesamt ausgelöst hat .

CSC, dessen Schwerpunkt in der IT-Softwareentwicklung liegt, erklärte in Bezug auf Modellierungswerkzeuge, dass „weder IBM noch Telelogic auf dem Markt für Modellierungswerkzeuge eine marktbeherrschende Stellung hatten, und dass beide aufgrund des Wettbewerbs durch andere Anbieter unter Innovationsdruck standen. Soweit CSC bekannt deutet gegenwärtig nichts darauf hin, dass die Innovation auf dem Markt durch die Übernahme von Telelogic durch IBM beeinträchtigt wird, da es eine Vielzahl weiterer Anbieter gibt“ . Im Hinblick auf Anforderungsmanagementwerkzeuge äußerte sich CSC ähnlich. Weitere in den Bereichen Telekom, Elektronik, Energie, Bankwesen und IT-Beratung tätige Kunden bestätigten ebenfalls, dass der Wettbewerb zwischen IBM und Telelogic in der Vergangenheit keine wesentliche Antriebskraft für Innovation entfaltet hat.

Die eingehende Untersuchung hat ferner gezeigt, dass Open-Source-Produkte zwar offenbar nicht in direktem Wettbewerb zu den Modellierungs- und Anforderungsmanagement-Tools von IBM und Telelogic stehen, aber dennoch in

213 Siehe z. B. Antwort von Boeing vom 7. November 2007 auf Frage 49 des Auskunftsverlangens der Kommission.

214 „Boeing hat in diesem Wettbewerb keinen wesentlichen Innovationsantrieb für die Anforderungsmanagementprodukte dieser Anbieter gesehen“ (Antwort von Boeing vom 7. November 2007 auf Frage 83 des an die Kunden gerichteten Auskunftsverlangens der Kommission).

215 Siehe z. B. Antwort von CSC Computer Sciences vom 5. November 2007 auf Frage 49 des an die Kunden gerichteten Auskunftsverlangens der Kommission.

216 Siehe z. B. Siemens, Infineon (Antwort vom 2. November auf die Fragen 49 und 83 des an die Kunden gerichteten Auskunftsverlangens der Kommission).

217 So erklärte z. B. Texas Instruments, dass ihm „aus den letzten drei Jahren keine Fälle oder Beispiele dafür bekannt sind, dass der Wettbewerb zwischen IBM und Telelogic die Innovation bei Anforderungsmanagementwerkzeugen spürbar vorangetrieben hat” (Antwort vom 8. November auf Frage 83 des an die Kunden gerichteten Auskunftsverlangens der Kommission).

218 So antwortete z. B. AREVA T&D: „Ich glaube, dass IBM im Bereich Modellierungswerkzeuge seine Wettbewerbsposition verschlechtert hat, und Telelogic wurde durch andere Anbieter zu einer Verbesserung seiner Produkte angetrieben“ (Antwort vom 16. November auf Frage 49 des an die Kunden gerichteten Auskunftsverlangens der Kommission).

219 RBS z. B. gab sowohl mit Blick auf die Modellierungswerkzeuge als auch auf das Anforderungsmanagement an, „wir haben keinen Grund zu der Annahme, dass der Wettbewerb zwischen IBM und Telelogic wesentliche Impulse auf die Innovation ausgelöst hat“ (Antwort vom 2. November auf die Fragen 49 und 83 des an die Kunden gerichteten Auskunftsverlangens der Kommission).

220 UNYSIS Corp. z. B. führte aus, „wir glauben nicht, dass dieser Wettbewerb der Innovation in irgendeiner Weise förderlich war“ (Modellierung) und „uns ist nicht bewusst, dass dieser Wettbewerb einen Innovationsanspor darstellte“ (Anforderungsmanagement). Antwort vom 7. November auf die Fragen 49 und 83 des an die Kunden gerichteten Auskunftsverlangens der Kommission.

240.naher Zukunft eine Weiterentwicklung des Open-Source-Angebots für diese beiden Werkzeugkategorien zu erwarten ist. Dies dürfte in den nächsten Jahren einen direkten Beitrag zu mehr Innovation leisten, da die Anbieter kommerzieller Software ihre Produkte um neue Merkmale ergänzen müssen, um den Preisunterschied zwischen ihren Produkten und den Open-Source-Produkten zu rechtfertigen.

241.Laut einer von der Europäischen Kommission in Auftrag gegebenen Studie können durch Open-Source-Software „potenziell 36 % der FuE-Investitionen der Industrie im Softwarebereich eingespart werden. Diese Gelder können sich in Form höherer Gewinne niederschlagen oder sinnvoller für zusätzliche Innovationen ausgegeben werden“. Die Studie zeigt auf, dass es deutliche Hinweise auf den Zusammenhang zwischen der Entwicklung von Open-Source-Software, Innovation und der IKT-Branche gibt, und kommt zu dem Schluss, dass Open-Source-Software „einen Einsatz der Technologie auf wesentlich breiterer Front als urheberrechtlich geschützte (proprietäre) Software gewährleistet, insbesondere für potenzielle künftige Innovatoren, die auf diese Weise die Kosten für die Auffindung neuer Innovationsquellen einsparen, die sich innerhalb der geschützten Software verbergen.

242.Schließlich sind die Produkte von IBM und Telelogic wie vorstehend nachgewiesen auch im Hinblick auf Modellierungs- und Anforderungsmanagementwerkzeuge unter dem Aspekt ihrer Funktionalitäten und der Kundengruppen, für die sie bestimmt sind, kaum gegeneinander austauschbar. Dies ist insbesondere darauf zurückzuführen, dass sich IBM schwerpunktmäßig auf Kunden mit IT-Anwendungsbedarf und Telelogic auf Kunden mit Entwicklungsbedarf im Bereich Systemsoftware ausgerichtet hat. Daher sind die Produkte von IBM und von Telelogic grundsätzlich auf unterschiedliche Kundengruppen bzw. unterschiedliche Bedarfskategorien ausgerichtet.

243.Angesichts dieser Feststellungen kann die Schlussfolgerung gezogen werden, dass der beabsichtigte Zusammenschluss das Innovationstempo auf den Märkten für Anforderungsmanagement- und Modellierungswerkzeuge in nächster Zeit nicht beeinträchtigen dürfte.

VII.3 Verringerung des Interoperabilitätsgrads von Softwarewerkzeugen

VII.3.1 Nicht-horizontale nicht-koordinierte Auswirkungen: Marktabschottung durch Verringerung des Interoperabilitätsgrads von Softwarewerkzeugen

244.In der Entscheidung über die Einleitung des Verfahrens war die Kommission zunächst zu dem Schluss gelangt, dass der beabsichtigte Zusammenschluss gravierende Zweifel hinsichtlich seiner Vereinbarkeit mit dem Gemeinsamen Markt aufwarf, insbesondere weil das Unternehmen nach dem Zusammenschluss einen geringeren Anreiz hätte, offene Schnittstellen für die Interoperabilität mit den Softwareentwicklungswerkzeugen anderer Unternehmen zu schaffen. IBM würde es weniger für notwendig halten, sein eigenes Angebot an Softwareentwicklungstools so zu „ergänzen“, dass sie mit Angeboten dritter Softwareanbieter kompatible wären, und hätte demnach weniger Anreize, dritten Softwareanbietern Zugang zu seinen Softwareschnittstellen zu gewähren.

245.Insbesondere ein Mitbewerber der beteiligten Unternehmen (Microsoft) führte das Argument an, dass das Unternehmen nach dem Zusammenschluss die Möglichkeit und den Anreiz hätte, seine Mitbewerber von den Märkten (bzw. Marktsegmenten) für Integrierte Entwicklungsumgebungs-Software (Integrated Development Environments – IDE), Software Change and Configuration Management-Werkzeuge (SCCM) und Anwendungsserversoftware-Plattformen (Application Server Software Platforms -ASSP) auszuschließen .

246.Im Einzelnen argumentierte Microsoft, dass die fusionierte Einheit die Möglichkeit hätte, konkurrierenden Anbietern von SCCM-, IDE- und ASSP-Produkten Informationen zur Interoperabilität seiner Anforderungsmanagement- und Modellierungswerkzeuge vorzuenthalten. Dies würde auf eine technische Kopplung der SCCM-, IDE- und ASSP-Produkte der beteiligten Unternehmen an ihre Anforderungsmanagement- und Modellierungswerkzeuge hinauslaufen. Nach Ansicht von Microsoft bestünde dazu für die fusionierte Einheit ein Anreiz, da sie damit ihre durch den Zusammenschluss auf den Märkten für Modellierungs- und Anforderungsmanagementwerkzeuge entstehende Marktmacht auf die daran angrenzenden Märkte für SCCM-, IDE- und ASSP-Software projizieren könnte.

247.In Einklang mit den Leitlinien zur Beurteilung nicht-horizontaler Zusammenschlüsse hat die Kommission daher zunächst geprüft, ob die fusionierte Einheit nach dem Zusammenschluss die Möglichkeit hätte, den Zugang zu den Werkzeugen der beteiligten Unternehmen abzuschotten, indem sie den konkurrierenden Anbietern von SCCM-, IDE- und ASSP-Softwareprodukten Informationen zur Interoperabilität ihrer Anforderungsmanagement- und Modellierungswerkzeuge vorenthält. Zweitens hat die Kommission geprüft, ob dazu für die beteiligten Unternehmen ein Anreiz bestünde, und drittens, ob eine Strategie der Behinderung des Marktzugangs den Wettbewerb in erheblichem Maße behindern würde.

VII.3.1.1

Fähigkeit zur Marktabschottung

Technische Kopplung

248.IDE werden zur Generierung eines Codes in einer Programmiersprache verwendet, der später für die angepeilte Runtime-Plattform übersetzt werden kann, d. h. in eine Form gebracht wird, die auf dem Ziel-Computersystem ausgeführt werden kann. Im Zusammenhang mit dem Lebenszyklus von Softwareentwicklung kommen IDE dann ins Spiel, wenn die Anforderungen festgelegt sind und die Zielsoftware modelliert ist. In gewisser Weise besteht die Programmierung aus der inhaltlichen Ausgestaltung der Modelle, die von den Modellierungswerkzeugen erstellt wurden.

249.Generell können auf einer ASSP Applikationen angesiedelt werden, die bestimmte Dienste über Netzwerke bereitstellen. So müssen beispielsweise Online-Banking-Anwendungen oder Anwendungen im Bereich Elektronischer Handel auf Spezial-Anwendungsservern untergebracht werden. In der Regel interagiert ein solcher Server mit dem Anwender über Komponenten, die Web-Servern sehr ähnlich sind. Diese verwenden Internet-Technologie (wie das Hypertext Transfer Protocol, HTTP), um dem Anwender eine Grafikschnittsstelle der Anwendung anzubieten und von ihm Inputs entgegenzunehmen. Bekannte Beispiele für Anwendungssoftware-Serverplattformen sind WebSphere von IBM und Java Enterprise Edition von Sun. ASSP werden gegen Ende des Software-Entwicklungslebenszyklus wichtig. Wenn für den netzgebundenen Einsatz bestimmte Anwendungssoftware in einer Integrierten Entwicklungsumgebung kodiert ist und alle Tests zur Überprüfung ihrer Konformität mit allen gestellten Anforderungen erfolgreich abgeschlossen sind, muss sie installiert werden, d. h. auf einer ASSP in Betrieb genommen werden. Wichtig ist in diesem Zusammenhang, dass nur ein kleiner Teil aller entwickelten Software für den Betrieb auf einer ASSP angewiesen ist. Ein großer Teil der Software ist für den direkten Einsatz auf dem Rechner des Anwenders bestimmt, bedarf also keiner Netzwerkverbindung zwischen Anwender und Applikation. Andere Software wird direkt auf Spezial-Hardware eingesetzt und ist nicht erst über ein Universal-Netzwerk wie das Internet zugänglich. Dies gilt beispielsweise für Software in Raketen, Satelliten, Bordcomputern von Autos, usw.

250.Über SCCM-Server können Entwicklerteams gleichzeitig an verschiedenen Phasen des Software-Entwicklungslebenszyklus zusammen arbeiten. So wird zum Beispiel der in einer IDE produzierte Programmierkode in eine Datenbank „eingecheckt“, die die verschiedenen Versionen kennzeichnet und mitverfolgt (Tracking), so dass der Programmierer, der an einem spezifischen Teil des Codes arbeiten will, die aktuellste Version für diesen Teil abrufen kann. Der Server stellt auch sicher, dass verschiedene Entwickler nicht unterschiedliche Versionen desselben Abschnitts des Softwarecodes, die im Widerspruch zueinander stehen, in die Datenbank eingeben. SCCM-Server können auch zur Speicherung von Modellen verwendet werden, die mit Modellierungswerkzeugen erstellt wurden. Damit können die verschiedenen Mitglieder des Entwicklungsteams zusammen an den Modellen arbeiten, ohne dass die Gefahr besteht, dass voneinander abweichende Versionen entstehen. Desgleichen können SCCM-Server unter dem Aspekt des Zusammenwirkens Vorteile für den Einsatz anderer Tools im Software-Entwicklungslebenszyklus bieten.

251.Softwareentwicklung wird dadurch erleichtert, dass IDE direkten Zugriff auf Modelle haben, die mit Modellierungswerkzeugen erstellt wurden und daraus Informationen abrufen können. ASSP sind natürlich nur sinnvoll, wenn sie den Code unterstützen, der in einer IDE generiert wurde. Damit SCCM von Nutzen sind, muss der Server in der Lage sein, die unterschiedlichen Arten von Informationen zu erkennen, und eine gewisse „Vorstellung“ von ihrem Inhalt haben. Mit Anforderungsmanagement lässt sich viel mehr erreichen, wenn eine Anforderung direkt mit einem spezifischen Teil eines Modells und mit einem spezifischen Abschnitt im Softwarecode verknüpft werden kann, als wenn keine ständige technische Verbindung zwischen beiden hergestellt werden kann. Alle diese Beispiele zeigen, dass ein (unterschiedliches) Maß an Interoperabilität zwischen den verschiedenen Werkzeugen, die während des Software-Entwicklungslebenszyklus zum Einsatz kommen, für die Entwickler viele Vorteile hat und daher auf dem Markt für diese Werkzeuge sehr begehrt ist.

252.Die fusionierte Einheit wird in allen wichtigen Marktsegmenten der Vorleistungen für die Softwareentwicklung Produkte anbieten. Microsoft gibt zu bedenken, dass die fusionierte Einheit die Fähigkeit hätte, ihren Mitbewerbern den Marktzugang zu verwehren, indem sie eine technische Kopplung dadurch erreicht, dass sie ihren Mitbewerbern die für die Interoperabilität erforderlichen Informationen vorenthält. So würde die fusionierte Einheit den konkurrierenden Anbietern von SCCM-, ASSP-, und IDE-Tools nicht offen legen, wie ihre Produkte mit den angebotenen Produkten der fusionierten Einheit im Bereich Anforderungsmanagement- und Modellierungswerkzeuge interagieren könnten.

253.In diesem Zusammenhang ist zunächst darauf hinzuweisen, dass das für Modellierungs- und Anforderungsmanagementwerkzeuge benötigte Maß an Interoperabilität von der Art des Werkzeugs abhängt, mit dem die Interaktion erfolgen soll. So benötigt man praktisch keine Interoperabilität zwischen Modellierungs- und Anforderungsmanagementwerkzeugen und ASSP. Allenfalls könnte die fusionierte Einheit eine indirekte Wirkung auf ASSP-Konkurrenten erzielen, wenn es ihr gelingen würde, die Interoperabilität zwischen Modellierungs- und Anforderungsmanagementwerkzeugen und den im Informationsfluss normalerweise zwischen ihnen liegenden SCCM und IDE weitgehend zu verhindern.

Interoperabilität besteht dann, wenn für alle technischen Möglichkeiten, die zum Austausch von Informationen zwischen verschiedenen Softwareprodukten und zur gegenseitigen Nutzung der ausgetauschten Informationen verwendet werden, vollständige und präzise Spezifikationen verfügbar sind. Dieses Konzept kann sowohl für Kommunikationsprotokolle (zur Beantwortung der Frage: „Wie wird eine bestimmte Information zwischen verschiedenen Instanzen von Softwareprodukten übermittelt?“) als auch für Dateiformate gelten (zur Beantwortung der Frage: „Wie wird eine spezifische Information in einer Computerdatei aufgezeichnet?“).

254.Je nachdem, wie ausgefeilt die eingesetzten Werkzeuge sind, kann sich die erforderliche Interoperabilität zwischen IDE und SCCM auf der einen Seite und Modellierungs- und Anforderungsmanagementwerkzeugen auf der anderen Seite auf sehr grundlegende Elemente beschränken. So kann es z. B. ausreichen, dass SCCM-Server Dateien mit Informationen über Modelle lediglich speichern, verwalten und weiterverteilen, ohne dass sie erkennen müssten, worin sie inhaltlich bestehen. Das gleiche kann für IDE gelten, da jeder einzelne Programmierer nur einen sehr kleinen Teil des Gesamtmodells zu kennen braucht und daher nicht auf automatische Extraktion von Informationen aus Modellen angewiesen ist, da seine eigenen Fähigkeiten zur Einsichtnahme in ein Modell ausreichen. In der Regel werden Anforderungsmanagementwerkzeuge mit eigenem Server und eigener Datenbank geliefert und sind daher im Hinblick auf eine Zusammenarbeit an Projekten nicht auf SCCM-Server angewiesen. Außerdem gibt es keine Anzeichen dafür, dass die direkte Verknüpfung von Anforderungen mit dem Softwarecode oder Teilen des Modells über ein einfaches Mapping der Anforderungen mit Prozedurname und Dateiname hinaus in der Softwarebranche weit verbreitet ist. Da die zugrunde liegende Datenbanktechnologie weitgehend standardisiert ist, gibt es nicht viele Informationen zur Interoperabilität, die den Mitbewerbern eventuell vorenthalten werden könnten.

255.Auch wenn diese Erwägungen mit berücksichtigt werden, kann man dennoch schlussfolgern, dass die fusionierte Einheit doch in der Lage wäre, den konkurrierenden Anbietern von SCCM-, ASSP- und IDE-Produkten Informationen zur Interoperabilität seiner Modellierungs- und Anforderungsmanagementwerkzeuge vorzuenthalten. Doch ist dies lediglich eine sachliche Feststellung, da sich die fusionierte Einheit z. B. für eine urheberrechtlich geschützte, nicht-standardisierte und nicht offen gelegte Methode der Speicherung von Modellen in Dateien oder der Speicherung von Daten in Datenbanken entscheiden könnte. Diese Möglichkeit hat im Prinzip jeder Anbieter von Software, dessen Produkte Outputs generieren, die für andere Softwareprodukte wiederum als Inputs fungieren.

256.Dennoch weisen die betreffenden Produkte bestimmte Eigenschaften auf, die sich auf die Folgen einer derartigen Vorenthaltung von Informationen zur Interoperabilität auswirken würden. Wie vorstehend dargestellt werden Modellierungs- und Anforderungsmanagementwerkzeuge häufig auf Projektbasis eingesetzt. Das heißt, während der Durchführung eines Projekts ist eine Umstellung auf ein anderes Werkzeug höchst unwahrscheinlich. Veränderungen hinsichtlich der Interoperabilitätseigenschaften dieser Modellierungs- und Anforderungsmanagementwerkzeuge können folglich nur zukünftige Versionen dieser Software und damit neue Projekte betreffen. In der Regel sind die Kunden am Interoperabilitätsaspekt gerade deshalb stark interessiert, weil in der Softwareentwicklung unterschiedliche Tools zusammen zum Einsatz kommen.

vorstehend nachgewiesen gibt es für die meisten Wirtschaftssektoren eine große Anzahl von konkurrierenden Modellierungs- und Anforderungsmanagementwerkzeugen. Daher würde sich die technische Fähigkeit der Vorenthaltung von interoperabilitätsbezogenen Informationen nur auf neue Projekte beschränken.

VII.3.1.2 Anreize zur Marktabschottung

Märkte für Kopplungsprodukte

257.Die Schadenstheorie von Microsoft könnte nur für den Fall zutreffen, dass die fusionierte Einheit Marktmacht im Hinblick auf eine technische Kopplung von Produkten hat, d. h. in diesem Fall die Modellierungs- und Anforderungswerkzeuge. Wie vorstehend bereits erläutert würde der Zusammenschluss die Marktmacht von IBM aufgrund der besonderen Merkmale des Wettbewerbs auf den betreffenden Märkten nicht erhöhen. Selbst wenn die fusionierte Einheit bei diesen Produkten Marktmacht hätte, was jedoch nicht der Fall ist, würde dies auch auf IBM allein genommen zutreffen. Selbst wenn die fusionierte Einheit also einen Anreiz für eine Strategie der Marktabschottung hätte, würde dieser Anreiz nicht erst durch den Zusammenschluss entstehen.

258.Wie vorstehend festgestellt treffen die beteiligten Unternehmen in vielen Marktsegmenten auf verschiedene leistungsstarke Mitbewerber. In anderen Marktsegmenten bilden die Tools von Telelogic eher eine Klasse für sich, konkurrieren also nicht mit dem Angebot von IBM. Deshalb werden durch den Zusammenschluss die Erfolgschancen für die von Microsoft vermutete Marktabschottungsstrategie nicht dadurch größer, dass zwei Modellierungswerkzeuge (Rhapsody und TAU) und ein Anforderungsmanagementwerkzeug (Doors) wegen mangelnder Interoperabilität als potenzielle Alternative für die Kunden wegfallen.

259.Telelogic ist zwar ein relativ kleines Unternehmen, verfügt aber im Marktsegment der Modellierungs- und Anforderungsmanagementwerkzeuge über einen erheblichen Marktanteil. Daher besteht kein Grund zur Annahme, dass große gewinnstarke Unternehmen wie Microsoft selbst nicht in der Lage wären, Marktersatz für die Werkzeuge der fusionierten Einheit zu schaffen, sofern diese versuchen sollte, ihre Kunden zum Verzicht auf Produkte konkurrierender Anbieter in angrenzenden Marktsegmenten zu zwingen. Dies würde die Struktur dieser Märkte grundlegend verändern. Die eingehende Untersuchung hat nicht gezeigt, dass es bei Modellierungs- und Anforderungsmanagementwerkzeugen besondere technische Marktzutrittsschranken gibt. Dies zeigt, dass eine Inangriffnahme einer solchen Marktabschottungsstrategie für die fusionierte Einheit ein eher gefährliches Unterfangen wäre, da dadurch neue Mitbewerber veranlasst werden könnten, in Märkte vorzudringen, auf denen die fusionierte Einheit selbst aktiv ist.

Allerdings gibt es einige spezifische und hochspezialisierte Bereiche, insbesondere in der Automobilindustrie, im Luft- und Raumfahrtsektor und in der Rüstungsindustrie, in denen es nur eine geringere Zahl leistungsstarker Konkurrenten gibt. In der Regel sind die Projekte in diesen Sektoren sehr umfangreich, so dass die Kosten der Software nur eine untergeordnete Rolle spielen. Meistens erfordern diese Projekte über mehrere Jahrzehnte hinweg Softwareunterstützung. Die Manager dieser Projekte wählen die von ihnen benötigten Software-Tools daher sehr sorgfältig aus. Bei ihnen handelt es sich auch um die anspruchsvollsten Kunden, die häufig auch eine kundenspezifische Anpassung der Software an ihren spezifischen Bedarf verlangen. Es ist schwer vorstellbar, dass die fusionierte Einheit unter diesen Umständen hoffen könnte, ein Modellierungs- oder Anforderungsmanagementwerkzeug zu verkaufen, dessen Interoperabilität sich lediglich auf ihr eigenes Produktportfolio beschränken würde. Selbst wenn die Hauptfunktionalität dieser Werkzeuge zur vollen Zufriedenheit des Anwenders ausfiele, könnte die gezielte und erzwungene Behinderung (und potenziell die Verweigerung) der Interoperabilität als Mangel an kritischer Funktionalität betrachtet werden.

Märkte für gekoppelte Produkte

261.Des Weiteren gilt es zu bedenken, dass die fusionierte Einheit auf den Märkten für IDE- und ASSP-Produkte einen Marktanteil von weniger als 30 % hätte. Auf beiden Märkten gibt es Mitbewerber ähnlicher Größe. Bei den SCCM-Produkten liegt der Marktanteil von IBM allein bei 45 %, während durch Telelogic ein weiterer Marktanteil von nicht einmal 5 % hinzukäme. Zwei weitere Mitbewerber verfügen über Marktanteile von rund 20 %. Daher stehen den Kunden in diesen Segmenten genügend Anbieter zur Auswahl, und es deutet nichts darauf hin, dass sie bereit sein könnten, in strategischen Kategorien wie ASSP von ihren bis dato bevorzugten Produkten auf andere umzustellen, nur weil sie ein spezifisches Modellierungswerkzeug oder ein spezifisches Anforderungsmanagementwerkzeug verwenden möchten.

262.Ein weiterer Faktor zur Untermauerung dieser Erkenntnis ist die Tatsache, dass zumindest die Märkte für ASSP und IDE wesentlich größer als die Märkte für Modellierungs- und Anforderungsmanagementwerkzeuge sind. Die Modellierungs- und Anforderungsmanagementwerkzeuge der fusionierten Einheit müssten daher selbst auf mittlere Sicht vollständig unverzichtbar und nicht substituierbar sein, um Kunden in anderen Segmenten zum Umstieg auf andere Produkte zu zwingen. Allerdings wäre es nach den meisten Szenarios z. B. wesentlich billiger, die bestehenden Schnittstellen so umzuschreiben, dass die Interoperabilität mit den Produkten der fusionierten Einheit wieder hergestellt würde (in der Annahme, dass eine derartige Interoperabilität nach der Theorie von Microsoft zuvor verweigert worden war), als eine sehr kostspielige Umstellung vorzunehmen. Schließlich ist solch eine Umstellung z. B. in der ASSP-Kategorie nicht nur kostspielig, weil neue Softwareprodukte geschaffen werden müssten, sondern auch, weil zusätzliche Kosten für neue Schulungen, durch Dienstunterbrechung und Inkompatibilitäten mit den bestehenden Softwareanwendungen usw. entstehen würden. Hingegen würde die Anpassung der Schnittstellen - wenn überhaupt möglich - allenfalls den Einsatz einer kleinen Gruppe von Ingenieuren erfordern und keine Auswirkungen auf die Arbeit von anderen haben.

Ferner ist darauf hinzuweisen, dass ASSP-Produkte und in geringerem Ausmaß auch IDE-Produkte im Marktsegment Entwicklung von (insbesondere eingebetteten) Systemen eine wesentlich geringere Rolle als im Segment der Entwicklung von IT-Anwendungen spielen. Bei ASSP-Produkten liegt dies daran, dass ein eingebettetes System mit seiner eigenen Plattform angeboten wird und daher keine Universalplattform wie WebSphere von IBM oder Microsoft- oder Oracle-Plattform zum Einsatz benötigt. Bei IDE ist dies darauf zurückzuführen, dass eingebettete Systeme in der Regel keine Benutzerschnittstelle aufweisen und auf zweckgebundener Hardware installiert sind, so dass die Softwaremodellierung viel stärker ins Detail gehen kann. Folglich brauchen automatisch generierte Codes nur in begrenztem Umfang bearbeitet zu werden, weshalb IDE hierfür in wesentlich geringerem Umfang - wenn überhaupt - benötigt werden. Da die Produkte von Telelogic auf dieses Marktsegment für Systementwicklung abstellen, würde der beabsichtigte Zusammenschluss die derzeitige Fähigkeit von IBM zur Projizierung seiner Marktmacht im Bereich Modellierung und Anforderungsmanagement auf die Märkte für ASSP- und IDE-Produkte nicht wesentlich verändern.

Bisheriges Verhalten

264.Da die IDE von IBM – Eclipse – eine Open-Source-Lösung darstellt, ist schwer vorstellbar, wie IBM in der Lage sein sollte, die Verwendung seiner eigenen Modellierungs- und Anforderungsmanagementwerkzeuge nur mit Eclipse, aber nicht mit Visual Studio von Microsoft oder anderen IDE zu erzwingen. Es würde der Grundidee einer für Dritte offenen Open-Source-Entwicklungsplattform zur Erweiterung ihrer Funktionalität über „Plug-Ins“ völlig zuwider laufen, wenn ihre Benutzung technisch an urheberrechtlich geschützte kommerzielle Softwareprodukte gekoppelt wäre. Eclipse und das ASSP-Produkt von IBM – WebSphere – basieren gegenwärtig auf offenen Standards, weitestgehend Java, für die es für alle Phasen des Software-Entwicklungszyklus eine Fülle von Tools von anderen Anbietern gibt. Würden die Kunden der fusionierten Einheit neuen Zwängen oder Beschränkungen vonseiten der beteiligten Unternehmen ausgesetzt, könnten sie durchaus auf andere Anbieter ausweichen. Jede Hoffnung auf eine erfolgreiche Durchsetzung einer Marktabschottungsstrategie würde eine grundlegende Kehrtwende im Geschäftsmodell von IBM bei diesen Werkzeugen voraussetzen. In den internen Unterlagen der beteiligten Unternehmen deutet nichts darauf hin, dass IBM eine derartige Strategie auch nur im Entferntesten als Beweggrund für die Übernahme von Telelogic in Betracht gezogen hätte.

265.Microsoft weist ferner darauf hin, dass das Unternehmen selbst vorhatte, Interoperabilität zwischen dem Anforderungsmanagementprodukt von Telelogic – Doors – und dem eigenen SCCM-Produkt anzubieten, dass Telelogic die einschlägigen Gespräche jedoch kurz vor der Ankündigung des Übernahmeangebots durch IBM abgebrochen habe. Microsoft stellt dies als ersten Hinweis darauf dar, dass IBM damit bereits de facto in eine Strategie der Marktabschottung eingestiegen ist.

266.Auf das SCCM-Angebot von Microsoft entfällt jedoch nur ein sehr kleiner Anteil des Marktes für SCCM-Server. Daher ist klar, dass es weder Telelogic und erst recht nicht der fusionierten Einheit in erster Linie darum gehen kann, dass Doors auch mit dem SCCM-Produkt von Microsoft kompatibel wird. In dieser Hinsicht sei daran erinnert, dass Microsoft die Interoperabilität von Doors mit dem wesentlich umfangreicheren Angebot von Dritten auf dem SCCM-Markt wie z. B. dem von Computer Associates oder Serena nicht bestreitet.

VII.3.1.3 Kosten und Nutzen

267.Die Kosten des Einstiegs in eine solche Strategie umfassen (a) die Kosten für entgangenen Absatz bei den Kopplungsprodukten, wenn die Kunden eine Bindung an solche Produkte ablehnen; (b) die Kosten für entgangenen Absatz bei den Kopplungsprodukten, wenn die Mitbewerber beschließen, in diesen Markt vorzudringen, um die Nachfrage nach interoperablen Werkzeugen im oberen Marktsegment zu befriedigen; (c) die Kosten für entgangenen Absatz bei den gekoppelten Produkten (IDE, ASSP, SCCM), wenn die Kunden beschließen, aus Angst vor einer noch stärkeren Produktbindung auf Produkte der fusionierten Einheit zu verzichten; (d) dem allgemeinen Verlust an Goodwill, insbesondere angesichts des bisherigen Verhaltens von IBM auf den betreffenden Märkten, wo man recht offen für Interoperabilität und offene Standards war. Jede einzelne dieser vier Kostenkategorien ist potenziell ausschlaggebend, und keine kann von vornherein ausgeschlossen werden.

268.Der potenzielle Nutzen dagegen liegt in höheren Absatzzahlen für die gekoppelten Produkte. Diese würden sich ergeben, wenn die Marktabschottungsstrategie wirksam wäre und Kunden, die ansonsten die IDE-, ASSP- und SCCM-Angebote anderer Unternehmen genutzt hätten, auf die Produkte der beteiligten Unternehmen in diesen Kategorien umsteigen, um (weiterhin) die Modellierungs- und Anforderungsmanagementwerkzeuge der beteiligten Unternehmen verwenden zu können. Wie vorstehend ausgeführt besteht die Kundengruppe, die vielleicht am ehesten darauf angewiesen wäre, Doors und Rhapsody weiter verwenden zu können (als auf die Modellierungs- und Anforderungswerkzeuge der Konkurrenz umzustellen), aus den größten Kunden, die ganz spezielle Anforderungen haben und lange Service-Zeiten benötigen. Für sie ist der Preis der erworbenen Software weniger wichtig als ihre Funktionalität und Einsetzbarkeit. Diese Kunden wären daher aber auch am ehesten in der Lage, eine gegenläufige Nachfragemacht auf die fusionierte Einheit auszuüben. In der Regel sind diese Kunden, die im Wesentlichen im Bereich der Systementwicklung angesiedelt sind, aber auch am wenigsten bereit, Universal-Entwicklungsumgebungen (wie Eclipse) einzusetzen, und sie benötigen wohl auch kaum ein ASSP-Produkt. Folglich wäre der potenzielle Nutzen einer Marktabschottungsstrategie eher begrenzt, wobei es vollkommen ungewiss ist, ob sich ein solcher Nutzen überhaupt erzielen ließe.

VII.3.1.4 Schlussfolgerungen zur Interoperabilität

269.Angesichts der vorstehend aufgeführten Argumente führt eine Gesamtbewertung der wahrscheinlichen Auswirkungen einer von den beteiligten Unternehmen verfolgten hypothetischen Marktabschottungsstrategie auf die Preise und die Wahl des Angebots zu einer eindeutigen Schlussfolgerung. Die Märkte für Modellierungs- und Anforderungsmanagementwerkzeuge sind, insbesondere im oberen Marktsegment, so beschaffen, dass ausgeschlossen ist, dass eine solche Strategie zum Erfolg führt. Zwar wäre es technisch kein Problem, Kommunikationsprotokolle und Dateiformate zu verschleiern und zu verändern, um die Interoperabilität zu behindern, doch gäbe es für das Unternehmen nach dem Zusammenschluss dafür keinen Anreiz, da die damit verbundenen Kosten die potenziellen Vorteile bei weitem überwiegen würden.

VIII. SCHLUSSFOLGERUNG

270.Aus den vorstehend dargelegten Gründen kommt die Kommission zu dem Schluss, dass das Zusammenschlussvorhaben den wirksamen Wettbewerb im Gemeinsamen Markt oder in einem wesentlichen Teil desselben nicht erheblich behindern dürfte. Daher sollte der Zusammenschluss für mit dem Gemeinsamen Markt und dem EWR-Abkommen vereinbar erklärt werden -

HAT FOLGENDE ENTSCHEIDUNG ERLASSEN:

Artikel 1

Der angemeldete Zusammenschluss, wonach International Business Machines Corporation die alleinige Kontrolle im Sinne von Artikel 3 Absatz 1 Buchstabe b der Verordnung (EG) Nr. 139/2004 über das Unternehmen Telelogic AB erwirbt, wird für mit dem Gemeinsamen Markt und dem EWR-Abkommen vereinbar erklärt.

Artikel 2

Diese Entscheidung ist gerichtet an:

International Business Machines Corporation 1 New Orchard Road Armonk, NY 10504-1722 United States of America

Brüssel, den 5. März 2008

Für die Kommission (Unterzeichnet) Neelie KROES Mitglied der Kommission

82