Falls jemandem “Risiko beim Einsatz von Drittanbieter-Komponenten” nichts sagt dann braucht er sich eigentlich nur die aktuelle Situation bei Toyota anzuschauen: Das klemmende Gaspedal, welches gerade dabei ist, das Markenimage zu ramponieren, kommt vom Zulieferer CTS, einem Drittanbieter also.

In der Produktion Teile von Drittanbietern einzusetzen ist gang und gäbe. Ob in der Autoindustrie oder in der Softwareentwicklung. Die Motivation dahinter ist letzendlich, Zeit und Geld zu sparen. Warum sollte ich das Rad neu erfinden? Der Drittanbieter hat in der Regel bereits beträchtliche Summen in die Perfektion seiner Komponente investiert und meine eigenen Ausgaben würden höchst wahrscheinlich ähnlich hoch sein, bis ich ein vergleichbares Produkt selbst entwickelt habe.

Allerdings birgt die Abhängigkeit von einem externen Anbieter immer Risiken, auch in der Sofwareentwicklung. Beispiel aus der Praxis: Wir entwickeln in meiner Firma ein geschäftskritisches, internes Projektmanagement-System, eine Windows-Client/Server-Anwendung auf Basis von Microsoft .NET. Für die Benutzeroberfläche setzen wir stark auf die telerik RadControls for WinForms, ein (auf den ersten Blick) ziemlich beeindruckendes Framework von UI-Controls. Allerdings stoßen wir hier immer wieder auf ärgerliche Bugs. Für viele lässt sich in der Regel ein schneller Workaround finden, so dass die Investitionen in die RadControls insgesamt noch deutlich unter dem Aufwand für eine entsprechende Eigenentwicklung liegen.

Allerdings gibt es momentan ein Problem, für dass wir keinen Workaround entwickeln können: Die ganze Anwendung stürzt beim Drücken einer Akzent-Taste ab. Da wir ein Übersetzungsdienstleister sind, der u.a. auch Französisch anbietet und mit Kunden und Lieferanten in aller Welt zusammenarbeitet, ist das natürlich kritisch. Mehrmals pro Tag hört man hier im Büro die Flüche der Anwender, die gerade wieder einmal ihren Client per Akzent ins Nirvana befördert haben. Der Fehler ist nun bereits an telerik gemeldet und bestätigt worden, für dessen Behebung gibt es allerdings noch keinen Termin.

Diese Situation ist natürlich extrem unbefriedigend. Was haben wir für Alternativen? Wir könnten auf die RadControls verzichten. Das bedeutet aber entweder extrem hohen Aufwand für die Eigenentwicklung brauchbarer Alternativen oder Investitionen in eine Controlsuite eines Konkurrenzanbieters, einschließlich des Lernaufwandes der Entwickler – und wer garantiert uns, dass diese Control letztendlich fehlerfreier sind? Wir könnten auch den Sourcecode der betroffenen Controls selbst anpassen, der uns aufgrund unserer Lizenz zur Verfügung steht. Damit läuft man aber wieder in Probleme beim Update auf ein neues Release der Controls. Oder wir warten einfach, bis telerik den Fehler behoben hat, gegebenenfalls kann man versuchen, den Prozess durch regelmäßiges Nachfragen beschleunigen.

Alles in allem also nur die Wahl zwischen Pest und Cholera. Hier ist wie gesagt “nur” unser internes PM-System betroffen. Nicht auszudenken, wenn es sich um eine extern releaste Software handeln würde. Die Nutzen und Risiken sollten in dem Fall also tatsächlich gut abgewogen werden.