zurück zum Artikel

In der Softwareentwicklung steht man häufig vor der Wahl, eine fertige Standardlösung von der Stange zu verwenden oder eine Eigenentwicklung durchzuführen. Was ist ratsam?

In der Softwareentwicklung steht man häufig vor der Wahl, eine fertige Standardlösung von der Stange zu verwenden oder eine Eigenentwicklung durchzuführen. Was ist ratsam?

Die im Vorspann angerissene Fragestellung ist hinlänglich unter dem Begriff "Make or Buy" bekannt. Und für viele Bereiche der Softwareentwicklung lässt sich diese Frage auch ohne großes Nachdenken beantworten: Kaum jemand dürfte in Betracht ziehen, zunächst ein eigenes Betriebssystem zu entwickeln, wenn das Kerngeschäft die Entwicklung von Webanwendungen ist.

Doch begegnet man der Frage in kleinerem Rahmen fast tagtäglich: Ist es beispielsweise sinnvoll, zum Erzeugen einer UUID eigenen Code zu schreiben, oder empfiehlt sich eher der Einsatz einer bereits vorhandenen Komponente? Ist es ratsam, eine eigene Buchhaltungssoftware zu entwickeln, oder sollte man hier auf etwas Bestehendes setzen? …?

Tatsächlich variieren die Meinungen selbst bei derartigen Fragen sehr: Während einige Unternehmen der Meinung sind, die jeweilige Aufgabenstellung sei dermaßen simpel, dass eine zusätzliche Abhängigkeit nicht lohne, argumentieren andere, dass auch die Umsetzung und Wartung einer vermeintlich einfachen Aufgabe Zeit koste und eine fertige Lösung daher vorzuziehen sei.

Was spricht für eine Komponente von der Stange?

Geht man die Frage strukturiert an, ergeben sich tatsächlich eine Reihe von Kriterien, über die man durchaus nachdenken und geteilter Meinung sein kann:

• Qualität: Die Komponente ist im Idealfall schon von vielen anderen Entwicklern eingesetzt worden und hat sich somit bewährt. Die Wahrscheinlichkeit, dass Fehler bereits entdeckt und behoben wurden, ist höher als bei einer Eigenentwicklung. Zudem ist der Code eventuell nicht nur praxiserprobt, sondern auch getestet und dokumentiert.
• Zeit: Neben der Qualität ist auch die Zeit ein wesentlicher Faktor: Eine Komponente von der Stange ist sofort verfügbar, und man bekommt mit etwas Glück sogar im Lauf der Zeit immer wieder Updates, ohne selbst etwas dafür tun zu müssen.
• Umfang: Kaum ein Problem ist so klein, wie es auf den ersten Blick zu sein scheint. Bei einer bereits etablierten Lösung besteht eine gewisse Chance, dass seltene Sonderfälle bereits berücksichtigt wurden, und dass außerdem zusätzliche praktische Features bereits enthalten sind, die über das reine Lösen des Grundproblems hinausgehen.
• Verbreitung: Zumindest wenn es sich um eine halbwegs verbreitete Komponente handelt, besteht die Möglichkeit, dass Entwickler sie bereits kennen und über Erfahrung damit verfügen.
• Kosten: Selbst wenn eine Komponente nicht Open Source, sondern kostenpflichtig ist, sind die Kosten in der Regel geringer als die für eine Eigenentwicklung.

Was spricht für eine Eigenentwicklung?

All diese Punkte sprechen stark dafür, auf bereits vorhandene Lösungen zu setzen, doch gibt es auch durchaus Gegenargumente:

• Unabhängigkeit: Mit jeder Komponente, die man einführt, macht man sich noch etwas abhängiger von externen Faktoren. Was, wenn die Komponente nicht mehr weiterentwickelt wird? Was, wenn man auf einen Fehler stößt, der nicht behoben wird? Was, wenn …? Mit einer Eigenentwicklung ist man hingegen unabhängig und frei.
• Individualität: Manche Anforderungen sind so speziell, dass sie sich kaum allgemein lösen lassen. Wer eine wirkliche maßgeschneiderte und passgenaue Lösung braucht, fährt mit einer Eigenentwicklung vermutlich besser als mit einer Komponente von der Stange.

Die Frage, die sich daraus letztlich ergibt, lautet also: Wann wiegt die Forderung nach Unabhängigkeit und Individualität so schwer, dass sie all die Vorteile einer fertigen Komponente nicht nur aufwiegen, sondern gar überwiegen?

Eine Frage des Wettbewerbsvorteils

Tatsächlich gibt es darauf eine verhältnismäßig einfache Antwort: Die Vorteile der Unabhängigkeit und Individualität einer Eigenentwicklung überwiegen genau dann, wenn das zu lösende Problem essenziell geschäftsrelevant ist und seine Lösung einen entscheidenden Wettbewerbsvorteil bietet.

Wenn das Kerngeschäft nicht gerade die Entwicklung eines UUID-Generators ist, ist eine UUID-Komponente von der Stange vermutlich gut genug, und die eingesparte Zeit und Kosten lassen sich für die Lösung anderer und wichtigerer Probleme aufwenden.

Wenn das Kerngeschäft nicht gerade eine eigene Buchhaltungssoftware ist, kommt man mit einer Lösung von der Stange vermutlich schneller und günstiger ans Ziel, als wenn man zunächst eine Lösung für die eigene Buchhaltung entwickeln muss.

Wenn man aber die Möglichkeit hat, durch eine Eigenentwicklung einen essenziellen Wettbewerbsvorteil für das Unternehmen zu erzielen – dann, ja dann sollte man eine eigene Lösung entwickeln, da man sich dadurch relevant vom Markt und den Konkurrenten absetzen kann.

Für alle Fälle, in denen das aber nicht gegeben ist, ist der "langweilige" Weg vermutlich der effizientere.

tl;dr: Für ein gegebenes Problem eine individuelle Lösung zu suchen und zu entwickeln lohnt in der Regel nur dann, wenn sich daraus ein essenzieller Wettbewerbsvorteil ergibt. Daraus folgt, dass man für all das, was nur Beiwerk zur eigentlichen Kernkompetenz ist, gut beraten ist, eher auf fertige Komponenten von der Stange zu setzen. ( [14])

URL dieses Artikels:
https://www.heise.de/-4852672

Links in diesem Artikel:
[1] https://www.heise.de/blog/Neue-Serie-Goetz-Golo-4496312.html
[2] https://www.sodgeit.de/blog.html
[3] https://www.heise.de/blog/Entdeckungsreise-in-die-eigene-Programmiersprache-4836291.html
[4] https://www.heise.de/developer/artikel/Fachlichen-Code-schreiben-Excusez-moi-do-you-sprechen-Espanol-4770714.html
[5] https://www.heise.de/developer/artikel/Wie-man-relevante-Nachrichten-aus-dem-Grundrauschen-herausfiltert-4705625.html
[6] https://www.heise.de/developer/artikel/Pfeiler-eines-guten-Arbeitsklimas-4692807.html
[7] https://www.heise.de/developer/artikel/Was-zeichnet-lesbaren-Code-aus-4671909.html
[8] https://www.heise.de/blog/Guenstigere-Software-durch-weniger-Tests-4656247.html
[9] https://www.heise.de/blog/Module-fuer-JavaScript-und-Node-js-auswaehlen-4615807.html
[10] https://www.heise.de/blog/Wie-viele-Programmiersprachen-sind-zu-viel-4600259.html
[11] https://www.heise.de/blog/Tools-fuer-Web-und-Cloud-Entwicklung-4569861.html
[12] https://www.heise.de/blog/Virtuell-vereint-4522570.html
[13] https://www.heise.de/blog/Credo-fuer-eine-offene-und-tolerante-Kommunikation-in-der-IT-Unternehmenskultur-4493541.html
[14] mailto:webmaster@goloroden.de

Copyright © 2020 Heise Medien