Ist langfristige Zusammenarbeit in Softwareprojekten mit dem Vergaberecht vereinbar?

Ausgangssituation

Die webfactory ist in vielen Projekten für öffentliche Auftraggeber tätig, teilweise seit über 20 Jahren. Öffentliche Auftraggeber sind verpflichtet, bei der Erteilung von Aufträgen das Vergaberecht zu beachten. Dieses sieht vor, dass Aufträge grundsätzlich öffentlich oder zumindest wettbewerblich ausgeschrieben werden müssen und dass Rahmenvereinbarungen auf 4 Jahre begrenzt sein müssen (§21 Abs. 6 VgV). Immer wieder stellt sich daher die Frage, inwiefern unsere Art und Weise der langfristigen Zusammenarbeit vom Vergaberecht gedeckt ist. Müssen Aufträge für Betrieb und Weiterentwicklung zeitlich begrenzt sein, mit der Möglichkeit, dass das System alle paar Jahre in die Hände eines anderen Auftragnehmers gegeben wird? Muss ein System gar alle paar Jahre neu programmiert werden?

Softwareentwicklung als Theoriebildung

Um diese Frage zu beantworten, sollte man sich zuerst bewusst machen, worum es bei Softwareentwicklung geht: ein Modell der Realität zur Lösung einer bestimmten Aufgabe.

Peter Naur hat bereits 1985 in seinem Aufsatz "Programming as Theory Building" dargelegt, wie eng eine Software an die Menschen gebunden ist, die sie entwickelt haben. Der Aufsatz wurde im 2006 erschienenen Buch "Agile Software Development: A Cooperative Game" von Alistair Cockburn nachgedruckt und ist auch heute noch aktuell – z. B. in einem aktuellen Blogbeitrag zu der Frage, inwieweit Softwareentwicklung durch künstliche Intelligenz erfolgsversprechend ist.

Naur legt dar, dass Softwareentwicklung als eine Tätigkeit gesehen werden sollte, bei der die Programmierer Erkenntnisse gewinnen und eine Theorie des relevanten Ausschnitts der Welt entwickeln. Er stellt dies in Kontrast zu der Wahrnehmung, bei Softwareentwicklung ginge es in erster Linie um die Produktion eines Programms und weiterer begleitender Textdokumente. Die Theorie, die bei dieser Tätigkeit entsteht und auf der die Software basiert, ist untrennbar an Personen gebunden, es handelt sich um implizites Wissen.

Folgende Gründe nennt Naur dafür, dass das Wissen, das der Entwickler über die Software hat, über das in Form von Code und Dokumentation niedergeschriebene Wissen hinausgeht:

1. Der Entwickler, der die Theorie hinter der Software kennt, kann erklären, wie sich die Lösung zu dem Ausschnitt der Realität verhält, den sie zu handhaben hilft. Diese Erklärung erstreckt sich auch darauf, welche Dinge der realen Welt in welchem Detailgrad in der Software abgebildet sind. Er kann für jeden Teil der Software erklären, welchen Aspekt der Welt sie abdeckt, und umgekehrt für jeden Aspekt der Welt sagen, ob und wie er in der Software berücksichtigt ist. Die Frage, welche Aspekte der Welt in der Software abgebildet werden müssen, setzt eine fundierte Kenntnis dieser relevanten (Fach-) Welt voraus.
2. Der Entwickler, der die Theorie hinter der Software kennt, kann erklären, warum jeder Teil des Programms so geschrieben ist, wie er ist. Er kann also den Programmcode begründen.
3. Der Entwickler, der die Theorie hinter der Software kennt, kann konstruktiv auf Änderungsbedarfe reagieren. Die Entscheidung, wie eine Änderung am besten vorgenommen werden kann, und die Gestaltung dieser Änderung hängen davon ab, wie ähnlich der neue Bedarf zu den bereits in der Software vorhandenen Fähigkeiten ist. Die Beurteilung dieser Ähnlichkeit setzt das oben beschriebene Wissen sowohl über die Software als auch über die von ihr abgebildete Realität voraus, das nur der Entwickler hat.

Wird eine Software von Entwicklern ohne angemessenes Verständnis ihrer Theorie angepasst, degeneriert sie mit der Zeit. Denn es kommen stets verschiedene technische Lösungen für die Umsetzung neuer Anforderungen in Frage, die alle technisch korrekt funktionieren. Aber nur, wenn sie der Theorie entsprechen, entwickelt sich die Software in einem stimmigen Gesamtbild weiter. Wenn sie dagegen der Theorie widersprechen, wirkt die Software zunehmend wie ein Flickwerk, dessen Zerfaserung nur mit groben Nähten aufgehalten wird. All diese Nähte können das Verständnis der Software und damit ihren Betrieb und künftige Weiterentwicklungen erschweren. Nur Entwickler, die die Theorie hinter der Software kennen, sind in der Lage, die Lösungen dahingehend zu bewerten, ob sie dieser Theorie entsprechen oder widersprechen.

Daraus folgert Naur, dass eine Software nur als lebendig angesehen werden kann, solange ein Team, das die Theorie der Software besitzt, mit ihrer Weiterentwicklung betraut ist und die Kontrolle über alle Modifikationen hat. Eine Software stirbt demnach, wenn das Entwicklerteam, das die Theorie besitzt, aufgelöst wird. Eine solche tote Software kann zunächst weiter genutzt werden, aber der Tod wird sichtbar, wenn Weiterentwicklungsbedarfe nicht mehr intelligent umgesetzt werden können.

Die Theorie hinter der Software kann neuen Entwicklern vermittelt werden, indem diese intensiv und über längere Zeit mit den ursprünglichen Entwicklern zusammenarbeiten. Dadurch werden die neuen Entwickler vertraut mit dem Stellenwert der Software im Kontext verschiedener Situationen der realen Welt und bauen das Wissen auf, wie die Software funktioniert und wie außergewöhnliche Situationen und Änderungsanforderungen in ihrer Theorie abgebildet werden. Die Vermittlung einer solchen existierenden Theorie an neue Entwickler ist sehr ähnlich zur Vermittlung anderer Fähigkeiten, bei denen es mehr darum geht, zu lernen, wie etwas getan wird, als darum, sich Faktenwissen anzueignen. Solche Tätigkeiten sind zum Beispiel das Schreiben oder das Spielen eines Instruments. Naur hält fest, dass die wichtigste Lernaktivität bei solchen Fähigkeiten darin besteht, dass der Schüler relevante Tätigkeiten unter der Beobachtung und Anleitung seines Lehrers ausübt. Im Falle der Softwareentwicklung sollte diese Anleitung Diskussionen über das Verhältnis zwischen der Software und den relevanten Aspekten und Aktivitäten der realen Welt beinhalten, ebenso wie über die Grenzen der in der Software vorgenommenen Abbildung der Realität.

Eine tote Software könnte laut Naur theoretisch wiederbelebt werden, indem ein neues Team die Theorie zur existierenden Software erneut entwickelt. Das ist allerdings ohne Kontakt zu Personen, die die Theorie noch besitzen, aus seiner Sicht praktisch unmöglich und wird jedenfalls teurer sein, als die Software neu zu entwickeln.

Neuentwicklung statt Weiterentwicklung?

Man könnte nun versucht sein, zu fordern, dass Software folglich regelmäßig neu entwickelt werden müsste, wenn die Weiterentwicklung der Software ausgeschrieben werden muss und eine Arbeit mit dem existierenden Quellcode ohne die zugrundeliegende Theorie nicht möglich ist.

Das würde zum einen bedeuten, dass die komplette Investition, die in die Entwicklung der Software geflossen ist, erneut getätigt werden müsste. Es ist aus meiner Sicht zumindest fraglich, ob das mit dem Wirtschaftlichkeitsgebot aus dem Haushaltsrecht vereinbar ist (siehe hierzu Softwareentwicklung für öffentliche Auftraggeber).

Zum anderen würde das aber auch voraussetzen, dass es überhaupt möglich ist, die existierende Software neu zu entwickeln. Dies ist mit einem erheblichen Projektrisiko und einem hohen Zeitaufwand verbunden, der benötigt wird, um überhaupt nur den aktuellen Status Quo wiederherzustellen – ohne dass die benötigte Weiterentwicklung damit auch nur begonnen wäre. In den meisten Fällen wird die Weiterentwicklung schneller benötigt werden als eine komplette Neuentwicklung des Systems abgeschlossen werden könnte. Eine solche Neuentwicklung bringt zudem auch das Problem der Datenmigration von der alten in die neue Struktur mit sich.

Hinzu kommt, dass eine Neuentwicklung bestehender Lösungen knappe volkswirtschaftliche Ressourcen – Softwareentwickler – binden würde, die dann nicht für die Entwicklung innovativer Lösungen für noch ungelöste Probleme zur Verfügung stehen.

Die Neuentwicklung bestehender Systeme sollte daher die Ausnahme und nicht die Regel sein.

Das passende Vergabeverfahren

Wie oben gezeigt, ist es für die langfristige erfolgreiche Weiterentwicklung komplexer Systeme existenziell, dass ein Entwicklerteam, das die Theorie hinter der Software besitzt, diese Weiterentwicklung vornimmt. Das Team hat damit einzigartiges technisches Wissen über die Software.

Und hierfür wiederum kennt das Vergaberecht einen entsprechenden Tatbestand: Gemäß §14 Abs. 4 Nr. 2 der Vergabeverordnung kann der öffentliche Auftraggeber Aufträge im Verhandlungsverfahren ohne Teilnahmewettbewerb vergeben, wenn der Auftrag nur von einem bestimmten Unternehmen erbracht werden kann, weil aus technischen Gründen kein Wettbewerb vorhanden ist.

In jurisPK-Vergaberecht heißt es dazu:

Führt eine rechtmäßige Leistungsbestimmung dazu, dass die Leistung nur noch von einem Unternehmen zu erbringen ist, erfüllt dies zunächst den Tatbestand des technischen Alleinstellungsmerkmals. Es besteht daher ein von der deutschen Rechtsprechung geprägter direkter Zusammenhang zwischen dem Leistungsbestimmungsrecht des öffentlichen Auftraggebers und dem Verhandlungsverfahren ohne Teilnahmewettbewerb aufgrund technischen Alleinstellungsmerkmals. OLG Düsseldorf: „Sind die vergaberechtlichen Grenzen der Bestimmungsfreiheit des öffentlichen Auftraggebers indes eingehalten, sofern die Bestimmung durch den Auftragsgegenstand sachlich gerechtfertigt ist, vom Auftraggeber dafür nachvollziehbare objektive und auftragsbezogene Gründe angegeben worden sind und die Bestimmung folglich willkürfrei getroffen worden ist, solche Gründe tatsächlich vorhanden (festzustellen und notfalls erwiesen) sind und die Bestimmung andere Wirtschaftsteilnehmer nicht diskriminiert. Bewegt sich die Bestimmung in diesen Grenzen, gilt der Grundsatz der Wettbewerbsoffenheit der Beschaffung nicht mehr uneingeschränkt." (OLG Düsseldorf v. 01.08.2012 - Verg 10/12 und im Anschluss OLG Düsseldorf v. 12.02.2014 - VII-Verg 29/13, Verg 29/13 - juris.)Ortner in: Heiermann/Zeiss/Summa, jurisPK-Vergaberecht, 6. Aufl., § 14 VgV (Stand: 15.09.2022)

Der Kommentar zur VgV/UVgO von Malte Müller-Wrede konkretisiert:

Dem Rückgriff auf § 14 Abs. 4 Nr. 2 VgV steht grundsätzlich nicht entgegen, dass das Vorliegen der Tatbestandsvoraussetzungen dem öffentlichen Auftraggeber zuzuschreiben ist. Im Falle des § 14 Abs. 4 Nr. 2 VgV übt der öffentliche Auftraggeber stets einen gewissen Einfluss auf das Vorliegen der Tatbestandsvoraussetzungen aus, denn er gibt die Leistungsanforderungen vor, die dann nur von einem Unternehmen erfüllt werden können. Aber auch das Zutun des öffentlichen Auftraggebers zum Erwerb der Monopolstellung durch ein Unternehmen ist im Rahmen des § 14 Abs. 4 Nr. 2 VgV unbeachtlich. So sind singuläre technische Fähigkeiten infolge einer vorangegangenen Beauftragung durch den öffentlichen Auftraggeber gerade typische Folge des Leistungswettbewerbs. Anderes könnte allenfalls dann diskutiert werden, wenn die vorangegangene Beauftragung und die hieraus folgende Monopolstellung unter Missachtung des Vergaberechts erlangt wurden. Jedoch kann die Rechtswidrigkeit der vorangegangenen Beauftragung nach hier vertretener Auffassung nicht auf das neue Vergabeverfahren durchwirken. Sie muss im jeweiligen Vergabeverfahren angegriffen werden.Müller-Wrede in: Müller-Wrede, VgV / UVgO - Kommentar, 5. Aufl. 2017,§ 14 VgV Wahl der Verfahrensart

Mit dem Verständnis von Softwareentwicklung als Theoriebildung und im Hinblick auf die große Bedeutung impliziten Wissens für die erfolgreiche Weiterentwicklung scheint es eindeutig, dass § 14 Abs. 4 Nr. 2 VgV hier zum Tragen kommen muss.

Müller-Wrede betont auch, dass der öffentliche Auftraggeber darlegen muss, dass einer oder mehrere der in §14 Abs. 4 Nr. 2 VgV genannten Gründe zwingend die Vergabe an ein bestimmtes Unternehmen erfordern. Er weist des Weiteren darauf hin:

Gelingt dies, so ist ein Wettbewerb um den öffentlichen Auftrag tatsächlich unmöglich und die Durchführung eines wettbewerblichen Vergabeverfahrens obsolet. Eine dennoch erfolgende Bekanntmachung oder Aufforderung von Unternehmen zur Angebotsabgabe würde eine tatsächlich nicht bestehende Zuschlagschance suggerieren.

Gilt das für alle Unternehmen?

Wichtig scheint mir noch die Feststellung, dass die oben dargestellte Situation nicht in jedem Projekt und jedem Unternehmen gegeben sein muss – denn sie setzt voraus, dass das Team, das die Theorie hinter der weiterzuentwickelnden Software besitzt, auch für die Arbeit an dem Projekt zur Verfügung steht.

Bei uns in der webfactory ist das typischerweise der Fall. Da wir uns auf langlebige Softwareprodukte spezialisiert haben, legen wir großen Wert auf Kontinuität im Team und eine geringe Fluktuation. Neue Teammitglieder werden bei uns Schritt für Schritt in Weiterentwicklungsprojekte eingebunden und mit der Theorie hinter den Softwaresystemen vertraut gemacht.

Bei größeren Unternehmen ist hingegen nicht unbedingt gesagt, dass eine Folgevergabe an das gleiche Unternehmen überhaupt dazu führt, dass die Entwicklung von einem Team durchgeführt wird, das die Theorie hinter dem System kennt. Wenn das aber nicht garantiert ist, ist eine Vergabe an ein solches Unternehmen auch nicht durch die obige Argumentation gerechtfertigt.

Und wenn alle Stricke reißen?

Natürlich kann es Situationen geben, in denen die Weiterentwicklung eines Systems durch das ursprüngliche Team nicht möglich ist und die Betreuung des Systems daher neu vergeben werden muss. In diesem Fall sollte aber, wenn die Software nicht komplett neu entwickelt werden soll, das ursprüngliche Team wenn möglich beratend bei der Entwicklung zur Seite stehen, damit das neue Team die Theorie hinter der Software lernen kann. Parallel zur Vergabe an den neuen Dienstleister sollte also der alte Dienstleister mit der Vermittlung des Wissens beauftragt werden. Die dadurch entstehenden Kosten sind durch die dadurch erreichte bessere Einarbeitung des neuen Teams, höhere Qualität der Weiterentwicklung und daraus resultierend ein längeres Leben der Software gerechtfertigt.