Vier Wege zu Software, vier Formen von Abhängigkeit

Wer Software einführt, gibt Kontrolle ab. Das lässt sich nicht vermeiden, nur gestalten. Dieser Artikel beschreibt vier Wege und die spezifische Form von Abhängigkeit, die jeder davon erzeugt.

Inhaltsverzeichnis

Sie haben vor drei Jahren einen Cloud-Dienst eingeführt. Die Lösung war schnell verfügbar, das Team kam sofort damit zurecht. Heute entscheidet der Anbieter, welche Funktionen bleiben, wo Ihre Daten liegen und wann sich die Konditionen ändern. Sie sind abhängig. Nicht weil das Produkt schlecht wäre, sondern weil Abhängigkeit zur Struktur dieses Weges gehört.

Kaufen oder entwickeln lassen, so werden Software-Entscheidungen oft vereinfacht. In unserer Arbeit seit 2008 haben sich allerdings vier Wege herauskristallisiert, nicht zwei, und jeder erzeugt eine eigene Form von Abhängigkeit. Entscheidend ist, welche davon zur eigenen Situation passt.

SaaS mieten: Bequem, solange der Anbieter mitspielt

SaaS bedeutet, Sie mieten eine fertige Anwendung über das Internet. Sie brauchen keine eigene Infrastruktur, keinen Installationsaufwand und können sofort starten. Für Standardprozesse wie Buchhaltung, E-Mail oder Projektmanagement ist das oft der richtige Weg.

Wir haben mit Destill IT selbst ein SaaS-Unternehmen gegründet und kennen die Perspektive beider Seiten. Die Abhängigkeit liegt bei Preisgestaltung, Funktionsumfang und Datenhaltung. SaaS lohnt sich, solange der Prozess keine Differenzierung erzeugt. Wenn Ihre Buchhaltung genauso funktioniert wie die Ihres Wettbewerbers, brauchen Sie dafür keine eigene Lösung.

Open Source betreiben: Offen heißt nicht unabhängig

Bei Open-Source-Software ist der Quellcode öffentlich zugänglich. Sie können ihn einsehen, anpassen und die Software auf eigenen Servern betreiben. Sie kontrollieren Ihre Daten vollständig. Kein Anbieter kann Ihnen Funktionen wegnehmen oder die Bedingungen einseitig ändern.

Wer Open Source betreibt, tauscht Anbieterabhängigkeit gegen Betriebsverantwortung. Jemand muss den Server administrieren, Updates einspielen und bei Ausfällen reagieren. Das leistet entweder Ihr eigenes Team oder ein Dienstleister, der Installation, Updates und Betrieb komplett auf seinen Servern übernimmt. Wir selbst betreiben eine Vielzahl von Open-Source-Tools wie Zammad, GitLab oder Open WebUI für unsere internen Prozesse oder im Auftrag für Kunden. Wie gut das langfristig funktioniert, hängt jedoch immer von der Community ab. Schrumpft sie, stockt die Weiterentwicklung, Sicherheitslücken bleiben offen, Kompatibilitätsprobleme häufen sich.

Wer Open Source wählt, sollte Datenkontrolle als Priorität setzen und Betriebskompetenz mitbringen – intern oder über einen Dienstleister.

Standardsoftware anpassen lassen: Jede Änderung bindet tiefer

Standardsoftware ist marktfertig verfügbar und lässt sich an eigene Prozesse anpassen. SAP, Salesforce, Microsoft Dynamics stehen für mächtige Systeme. In der Praxis hängt an jeder Anpassung jedoch oftmals mehr, als der Projektplan anfangs vorsieht.

Jede Anpassung bindet Sie enger an den Dienstleister, der die Änderungen umgesetzt hat und sie am besten kennt. Ein Wechsel von Software oder Dienstsleister ist zwar möglich, aber mit erheblichem Aufwand verbunden. Darüber hinaus können Updates des Herstellers bestehende Anpassungen brechen. Es gilt die Devise: Je tiefer Sie anpassen, desto schwieriger wird ein Wechsel und desto aufwändiger jedes Update. WIchtig zu beachten ist auch, dass große Hersteller regelmäßig den Support älterer Versionen beenden und damit den Rhythmus für Updates und Wechsel vorgeben. Der versprochene Vorteil, auf einem fertigen Produkt aufzubauen, schwindet mit jeder Sonderanforderung.

Das gilt jedoch nicht nur für proprietäre Produkte. Unsere Typo3-Partneragentur hat ein Website-Projekt von einer anderen Agentur übernommen und über drei große Versionssprünge hinweg zahlreiche individuelle Erweiterungen durch systemnahe Lösungen ersetzen müssen. Die Erweiterungen erhöhten den Wartungsaufwand, gefährdeten die Stabilität und waren fehleranfällig, ohne ausreichend Mehrwert zu bieten. Offener Quellcode hat geholfen, das Problem zu lösen, verhindert hat er es nicht. Nicht die Lizenz bestimmt die Abhängigkeit, sondern die Tiefe der Anpassung.

Die Entscheidung für Standardsoftware geht auf, wenn die eigenen Anforderungen nah am Produkt bleiben und die Konfiguration sauber dokumentiert ist.

Individualsoftware entwickeln lassen: Freiheit mit Bedingungen

Individualsoftware ist der aufwändigste Weg, dafür gehört das Ergebnis samt Quellcode, Architektur und Entscheidungshoheit über jede Funktion vollständig Ihnen. Sie können den Dienstleister wechseln, intern weiterentwickeln oder das Projekt pausieren, ohne jemanden um Erlaubnis zu fragen. Bei jedem anderen Weg entscheidet jemand anderes mit.

Ob diese Freiheit real ist, entscheidet sich nicht im Vertrag, sondern im Code: seine Qualität, seine Dokumentation und die Verbreitung der genutzten Technologie sind wichtige Merkmale. Sauberer Code in einer weit verbreiteten Technologie hält Ihnen alle Optionen offen. Schlecht dokumentierter Code in einer exotischen Technologie bindet Sie stärker als jeder Vertrag. Wie bewährte Technologie die Wartbarkeit von Softwareprojekten über Jahre sichert und warum das für Ihr Budget wichtiger ist als immer dem neuesten Trend zu folgen, beschreibt unser Artikel über Ruby on Rails.

Individualsoftware zahlt sich aus, wo kein Standardprodukt den eigenen Prozess abbildet und wo dieser Prozess einen echten Wettbewerbsvorteil bietet. Aus unserer Praxis kennen wir Fälle, in denen sich der gewünschte Prozess mit keinem Standardprodukt abbilden ließ, ohne ihn grundlegend zu verbiegen. Ein Nachfolgeportal für die Wirtschaftsförderung, ein Webportal für kommunale Abgabenmeldungen oder andere branchenspezifische Verwaltungslösungen sind Beispiele dafür.

Was sich ändert und was bleibt

Derzeit verschieben externe Kräfte alle vier Wege an unterschiedlicher Stelle:

KI-gestützte Entwicklungswerkzeuge machen Individualsoftware wirtschaftlicher. Prototypen und erste Produktversionen, die bisher am Kosten-Nutzen-Verhältnis scheiterten, lassen sich damit erstmals realisieren. Daneben verändert sich der institutionelle Rahmen. Seit März 2026 machen die EVB-IT, die Standardvertragsvorlagen für öffentliche IT-Beschaffung, Open Source bei neuen Softwareentwicklungsprojekten zum Standard. Zugleich wächst die Marktmacht auf Anbieterseite, denn die Märkte für SaaS und Standardsoftware konsolidieren sich. Wer heute zwischen mehreren Anbietern wählen kann, hat morgen weniger Optionen. Vor diesem Hintergrund gewinnt digitale Souveränität in Europa wieder an Gewicht. Wir selbst stehen dabei nicht außen vor, denn auch als Softwareentwickler müssen wir regelmäßig entscheiden, auf welchem der vier Wege wir Software einführen und welche Abhängigkeiten wir damit eingehen wollen.

Was trotz dieser Entwicklungen konstant bleiben wird: Jede Software-Entscheidung verschiebt Kontrolle – zu einem Anbieter, zu einem Dienstleister, zu einer Community oder zum eigenen Team. Diese Kontrollverschiebung ist unvermeidlich und wer sie nicht erkennt, kann sie nicht steuern. Ist man sich dessen jedoch bewusst, fällt die Entscheidung für eine nachhaltige und langfristig erfolgreiche Softwareinvestition deutlich leichter.

Veröffentlicht
21. April 2026
Zuletzt aktualisiert
17. April 2026
Autor
Lars Schimanski
Warum wir schreiben

Software wird in Monaten gebaut und über Jahre benutzt. Wer in diesem Handwerk gut arbeiten will, muss den Hype vom Bleibenden trennen. Das geht nicht nebenbei.

Unser Werkzeug dafür ist das Schreiben. Der Soziologe Niklas Luhmann brachte es auf Zettel 9/8g auf den Punkt: „Ohne zu schreiben, kann man nicht denken.“

Das Ergebnis zeigen wir auf unserer Website. Wie wir dorthin kommen, steht hier im Blog.

MW Studio