Langfristige Weiterentwicklung individueller Software trotz öffentlicher Vergabe

Immer wieder finden sich in entsprechenden Portalen Bekanntmachungen zur Neuentwicklung von Webanwendungen oder Websites samt fachlicher Analyse, Konzeption, Design und Betrieb über einen bestimmten Zeitraum. Oft geht es dabei um bereits existierende Systeme, die auch – zumindest von außen betrachtet – gut gemacht zu sein scheinen.

Bei themenbezogenen Websites gibt es vielleicht einen gewissen Lebenszyklus, beispielsweise für mehrjährige Förder- oder Kulturprogramme. Wir haben in der Vergangenheit aber auch schon an eigenen Projekten erlebt, wie funktionierende Lösungen komplett neu aufgerollt und anschließend ohne erkennbare Änderungen von einem anderen Anbieter wieder „neu“ ausgeliefert wurden. Und das alles nur, weil ein bestehender Vertrag ausgelaufen ist und die Betreuung neu vergeben werden musste?

Natürlich ist von Zeit zu Zeit eine konzeptionelle Neuausrichtung angebracht. Natürlich ändert sich der Zeitgeist und damit die Ansprüche an die visuelle Gestaltung. Natürlich ändern sich Anforderungen, Technik und Umfeld und machen eine Weiterentwicklung notwendig. Aber darum geht es hier nicht.

Dieser Artikel versucht, die Probleme der Neuentwicklung vorhandener Software zu erläutern. Es folgt ein Vorschlag, wie die Weiterentwicklung im Rahmen einer Ausschreibung vergeben werden könnte. Den Abschluss bilden einige Überlegungen dazu, mit welchen strategischen Vorgaben sich die Übertragbarkeit von Software zwischen verschiedenen Bietern verbessern lässt.

Ob überhaupt ein Anbieterwechsel in Erwägung gezogen werden muss, dazu haben wir inzwischen noch einen weiteren Artikel im Blog: Ist langfristige Softwareentwicklung mit dem Vergaberecht vereinbar?

Risiken und Probleme der Neuentwicklung aus IT-Sicht

Was bei (Web-)Anwendungen noch offenkundig ist, wird bei Websites schnell übersehen: Ab einem gewissen Umfang geht es immer um maßgeschneiderte Lösungen, zum Beispiel durch angebundene Fachdatenbanken, die direkte Integration in Geschäftsprozesse oder sonstige fachliche Logik. Selbst eine Website ist nicht nur ein Content Management System mit ein paar Dokumentvorlagen im Corporate Design, sondern ein kleines Stück Individualsoftware.

Dass es problematisch und riskant ist, funktionierende Software neu zu entwickeln, ist in der IT-Welt keine neue Erkenntnis. Einige der Gründe dafür sind:

• Es gibt mindestens einen Betrieb, eventuell auch eine Pflege oder sogar Weiterentwicklung des Altsystems, während ein zweites Team im Dauersprint versucht, das neue System fertigzustellen.
• Frühes und schnelles Feedback, eine der Kernideen agiler Softwareentwicklung, lässt sich bei diesem Vorgehen nicht erzielen. Eine Inbetriebnahme ist erst möglich, wenn mindestens der Feature-Stand des Altsystems erreicht ist.
• Bis es „fertig“ ist, kann das neue System keine Erlöse generieren.
• Ein Umstieg ist oft nur vollständig oder gar nicht möglich.
• Lange time-to-market, wenn neu benötigte Leistungsmerkmale erst auf der neuen Basis ausgeliefert werden können.
• Regressionsprobleme: Wie lässt sich sicherstellen, dass das neue System zumindest da, wo keine Änderungen beabsichtigt sind, genauso funktioniert wie das alte?
• Migration: Wie funktioniert die Datenübernahme während des Parallelbetriebs oder beim Übergang?

Die Regressions- und Migrationsprobleme werden noch verschärft, wenn der Auftraggeber den Ist-Stand eines Systems nur über ein Lastenheft zu spezifizieren versucht und dieses zur Grundlage der Neuentwicklung macht. Schon die Spezifikation an sich ist eine schwierige und zeitaufwändige Aufgabe. Ein reibungsloser Übergang setzt darüberhinaus noch die wohlwollende Zusammenarbeit von altem und neuem Auftragnehmer voraus.

Was will das Vergaberecht?

Das Vergaberecht fördert den Wettbewerb zwischen Anbietern, die über Preise, Leistungen und Qualität miteinander konkurrieren können. Öffentlichen Auftraggebern ermöglicht es eine regelmäßige Überprüfung der Konditionen, zu denen sie Leistungen beziehen. Damit dient es der Wirtschaftlichkeit.

Eine wirtschaftliche Lösung ergibt sich aber nicht alleine durch Auswahl des billigsten Angebots, sondern erfordert eine Gesamtbetrachtung aller damit verursachten Kosten – auch auf Seite des Auftraggebers. Dabei kann eine Weiterentwicklung, wenn sie langfristig gedacht und geplant ist, einigen Aufwand vermeiden helfen. Dazu gehört beispielsweise auch der Aufwand einer vollständigen, neuen Spezifikation, der Validierung vorhandener Dokumentation, der erneuten Implementierung oder der Lösung der Migrations- und Regressionsprobleme.

Der Begriff „Neuentwicklung“ taucht in den Gesetzen und Verordnungen natürlich nicht auf. Denn was die genaue inhaltliche Festlegung der zu vergebenden Leistungen sowie die Gestaltung des Vergabe- und Auswahlverfahrens angeht, haben Auftraggeber auch einige Gestaltungs- und Entscheidungsspielräume. Die Entscheidungen müssen dabei nur schlüssig zu begründen sein.

Einen konkreten Vorschlag, bitte.

Statt einer Neuentwicklung könnten Auftraggeber die Übernahme und Einarbeitung in die vorhandene Lösung sowie deren Betrieb, Weiterentwicklung und Pflege über einen bestimmten Zeitraum vergeben oder zumindest gleichberechtigt offenhalten.

Das könnte zum Beispiel auf Basis von Stundenkontingenten für bestimmte Leistungen (Beratung, Konzeption, Programmierung, Helpdesk…) geschehen. Vereinbarungen zu solchen Kontingenten sind schon deshalb nützlich, weil auch nach einer Neuentwicklung früher oder später Anpassungen oder Erweiterungen notwendig werden, die sich zum Zeitpunkt der Vergabe noch nicht absehen lassen. Diese Weiterentwicklungen können dann im Rahmen der z. B. quartalsweise noch verfügbaren Stunden Schritt für Schritt angegangen werden.

Zur Auswahl der Bewerber wäre es möglich, eine praktisch vorliegende, konkrete Problemstellung als Wettbewerbsaufgabe zu stellen. Anhand dieser Aufgabe könnten Bieter beispielsweise in einer Präsentation ihre Arbeitsweise, Leistungsfähigkeit und Lösungskompetenz unter Beweis stellen. Aufwandsschätzungen oder Angebote für diese Aufgabenstellung können zusammen mit den gebotenen Rahmenpreisen unter Kostenaspekten bewertet werden. Eventuell lässt sich so auch erkennen, ob ein Bieter günstigere Stundensätze anbietet, gleichzeitig aber mit mehr Stunden kalkuliert.

Natürlich wird jeder Bieter mit Anlaufschwierigkeiten zu kämpfen haben und eine Einarbeitungszeit in das vorhandene System benötigen. Die steht aber oft in keinem Verhältnis zum Gesamtaufwand einer Neuentwicklung.

Welche strategischen Vorgaben sind sinnvoll?

Darüber hinaus können Auftraggeber einige Vorgaben machen oder in ihren Entscheidungen berücksichtigen, um eine langfristige Wartbarkeit und Weiterentwicklung individueller Lösungen wahrscheinlicher zu machen und damit auch die Investitionssicherheit zu verbessern.

Zunächst einmal ist es notwendig, Vereinbarungen darüber zu treffen, dass Lösungen im Quellcode mit den notwendigen Rechten zur Weiterentwicklung und Anpassung – auch durch andere oder nachfolgende Unternehmen – zur Verfügung stehen.

Auch bei der Auswahl von Drittbibliotheken, also dem Rückgriff auf bereits vorhandene Programmteile oder –bausteine, ist die Nutzung quelloffener Software vorteilhaft. Das vereinfacht nicht nur die Vertragsgestaltung, sondern erhöht auch die Wahrscheinlichkeit, dass potenziell nachfolgende Auftragnehmer mit dem entsprechenden Baustein bereits vertraut sind.

Noch deutlicher wird dieser Vorteil bei der Entscheidung für quelloffene „Frameworks“.  Dabei handelt es sich um eine Art Grundgerüst, das den Aufbau einer bestimmten Klasse von Software-Systemen vorgibt. Weil dabei bestimmte Architekturentscheidungen bereits vorgegeben sind, erhalten Software-Lösungen eine gleichartige Struktur. Konventionen, Standards und bewährte Praktiken der können so genutzt werden. Gleichzeitig wird der Einarbeitungsaufwand in vorhandene Systeme reduziert. Die Software wird übertragbarer.

Das Paradigma des „Domain-Driven Design“

Domain-Driven Design (DDD) ist eine Herangehensweise zum Entwurf objektorientierter Softwaresysteme. Die Kernidee ist es, (relevante) Konzepte und Zusammenhänge der fachlichen Welt zu erschließen und unmittelbar im Software-Modell umzusetzen.

Das äußert sich beispielsweise darin, eine einheitliche und der Fachseite entnommene Terminologie bis in die unterste Ebene der Software (Benennung von Klassen, Methoden, Objekten) zu führen. Auch die Aufgaben und das Zusammenspiel dieser Komponenten wird so direkt wie möglich aus den Umständen des Fachbereichs übernommen.

Diese Sichtweise des DDD steht im Gegensatz zu von der Technik dominierten Lösungen, bei denen die Herleitung aus den fachlichen Problemen nicht offensichtlich wird. Der Unterschied zwischen fachlicher und technischer Sicht erschwert nicht nur die Kommunikation zwischen den Beteiligten. Es muss auch langfristig das Wissen darüber bewahrt werden, wie die technische Seite “funktioniert” und mit den fachlichen Begebenheiten zusammenhängt. Je technischer die Lösung funktioniert, umso mehr bedarf sie erläuternder Worte, Dokumentation usw. Auch für technisch versierte Außenstehende ist es schwierig, solche Systeme zu übernehmen und im Sinne der ursprünglichen Entwickler fortzuführen.

Wenn aber der Quellcode in Struktur, Terminologie und Ähnlichem die tatsächlichen Begebenheiten der Fachseite nachbildet, kommt es immer weniger auf eine schriftlich fixierte Dokumentation an. Es wird nämlich einfacher möglich, zum Verständnis auf die Fachabteilung und das dort gelebte implizite Wissen zurückzugreifen. An die Stelle ständig veralteter, schriftlicher Dokumentation tritt der Dialog mit dem Fachbereich.

Fazit

Vergaberechtlich gesehen ist es nicht notwendig, vorhandene Systeme und Lösungen immer wieder neu entwickeln zu lassen. Der Aufwand zur Erstellung eines Lastenhefts sowie die Risiken einer Umstellung werden häufig nicht betrachtet oder unterschätzt.

Das macht es allerdings erforderlich, geeignete Verfahren zur Auswahl qualifizierter Bieter zu entwickeln, die sich in vorhandene Lösungen einarbeiten und sie sinnvoll weiterentwickeln können. Auch Fragen im Hinblick auf die Vergütungsmodelle und die geforderte Angebotsgestaltung sind zu klären. Bieter werden kaum das wirtschaftliche Risiko eingehen, „unbekannte“ Systeme zu einem vorab vereinbarten Festpreis zu übernehmen und die Weiterentwicklung über einen bestimmten Zeitraum zu garantieren.

An dieser Stelle kommt die Verantwortung auf die Auftraggeber zu, individuelle oder angepasste Software als solche zu erkennen und als Teil des Anlagevermögens zu behandeln. Strategische Vorgaben an die Softwareentwicklung können dabei helfen, den Wert einmal geschaffener Lösungen langfristig zu erhalten.