Build, Buy oder Configure — wann Individualsoftware sich rechnet

Es ist eine ungewöhnliche Art, ein Dokument zu beginnen: Der beste Rat, den ein Softwarehaus manchmal geben kann, lautet, keine Software bauen zu lassen. Das klingt gegen das eigene Interesse und ist genau deshalb glaubwürdig. Denn die teuersten Projekte sind nicht die, die scheitern, sondern die, die nie hätten beginnen dürfen — Individualsoftware, gebaut für ein Problem, das ein fertiges Produkt besser und billiger gelöst hätte.

Dieses Dokument behandelt die Frage, die vor allen technischen Fragen steht: bauen, kaufen oder konfigurieren. Es ist ehrlich auch dann, wenn die Antwort „kaufen" lautet, weil eine Empfehlung nur so viel wert ist wie die Bereitschaft, gegen das eigene Geschäft zu raten, wenn die Sache es verlangt. Es nennt kein Produkt und keine Zahl; es beschreibt das Kriterium, an dem sich die Entscheidung ehrlich treffen lässt.

1. Die eigentliche Frage

Die Frage ist nicht „sollen wir Software bauen?", sondern „rechtfertigt dieses Problem eigene Software — oder löst es ein anderer besser?". Fast jedes betriebliche Problem ist schon einmal gelöst worden, oft von vielen, oft in Form eines fertigen Produkts. Die Wahrscheinlichkeit, dass ausgerechnet das eigene Problem so besonders ist, dass es eigene Software verlangt, ist geringer, als es sich im eigenen Haus anfühlt.

Deshalb steht am Anfang nicht der Entwurf, sondern die Prüfung: Gibt es das schon? Und wenn ja, warum sollte das eigene Gebaute besser sein als das Vorhandene? Wer diese Frage überspringt, entscheidet sich nicht bewusst für das Bauen, sondern verpasst nur die Chance, es zu lassen. Die erste Ingenieursleistung besteht manchmal darin, nicht zu bauen.

Trade-off. Die Frage ernst zu nehmen bedeutet, den Reiz des Eigenen zurückzustellen und die Möglichkeit auszuhalten, dass die richtige Antwort weniger Arbeit für uns ist.

Kosten. Die ehrliche Prüfung kostet Zeit vor dem Projekt und die Bereitschaft, ein Vorhaben zu verkleinern oder abzusagen, bevor es begonnen hat.

Wann wir anders entscheiden. Wo offensichtlich kein fertiges Produkt das Problem berührt — ein Prozess, den es nur in diesem Unternehmen gibt —, ist die lange Prüfung überflüssig, und man geht zügig zum Bauen über.

Warum überspringen so viele diese Frage? Weil das Bauen dem eigenen Empfinden schmeichelt. „Niemand versteht unser Geschäft so wie wir" fühlt sich richtig an, und der Wunsch nach voller Kontrolle ist verständlich. Beides führt jedoch leicht dazu, das eigene Problem für besonderer zu halten, als es ist — und Gewöhnliches teuer selbst zu bauen, im Glauben, es sei einzigartig. Die nüchterne Prüfung ist deshalb auch eine Prüfung der eigenen Betriebsblindheit: Ist dieser Ablauf wirklich unser Unterschied — oder nur unser gewohnter Weg, etwas Verbreitetes zu tun?

2. Was Build, Buy und Configure bedeuten

Die drei Wege sind keine scharfen Kategorien, sondern Punkte auf einem Band. Am einen Ende steht Buy: ein fertiges Produkt, so genutzt, wie es ist. In der Mitte steht Configure: eine Plattform, die man an die eigenen Bedürfnisse anpasst, ohne sie zu bauen — man arbeitet innerhalb ihrer Grenzen. Am anderen Ende steht Build: eigene Software, genau auf das eigene Problem zugeschnitten. Zwischen den Punkten liegen Mischformen; die meisten realen Systeme sind eine Kombination.

Schema: Von links nach rechts wächst die Kontrolle über die Lösung — und mit ihr der Aufwand und die Verantwortung. Keine Position ist überlegen; jede passt zu einem anderen Problem.

Der Sinn dieser Einteilung ist, die Entscheidung als Wahl auf einem Band zu sehen, nicht als Ja/Nein zum Bauen. Oft ist die richtige Antwort eine Mischung: das Gemeinsame kaufen, das Besondere bauen. Wer das Band kennt, sucht nicht nach der einen Lösung, sondern nach der richtigen Verteilung.

Trade-off. Auf dem Band nach rechts zu gehen kauft Passgenauigkeit und Kontrolle mit Aufwand und dauerhafter Verantwortung — nach links spart man beides, um den Preis, sich der fremden Lösung anzupassen.

Kosten. Jede Position hat eine eigene Kostenstruktur, die man kennen muss, bevor man wählt (siehe Kapitel 6); die falsche Wahl fällt nicht sofort auf, sondern über Jahre.

Wann wir anders entscheiden. Wo ein einziges Produkt das ganze Problem sauber abdeckt, lohnt die Mischung nicht; man kauft es und spart sich die Komplexität mehrerer Bausteine.

3. Wann Buy richtig ist

Kaufen ist die richtige Wahl, wenn das Problem verbreitet und gelöst ist — wenn viele Unternehmen dasselbe brauchen und ein Markt dafür existiert. Buchhaltung, Postfächer, Kalender, die üblichen Bausteine des Betriebs: Hier ist die Wahrscheinlichkeit hoch, dass ein fertiges Produkt reifer, günstiger und verlässlicher ist als alles, was man in vertretbarer Zeit selbst bauen könnte. Der Anbieter verteilt seine Entwicklungskosten auf viele Kunden; man selbst trüge sie allein.

Der entscheidende Punkt ist, dass ein gekauftes Produkt für ein verbreitetes Problem nicht nur billiger in der Anschaffung ist, sondern die dauerhafte Last der Pflege abnimmt. Man kauft nicht nur die Funktion, sondern auch die Zukunft der Funktion — die Fehlerbehebungen, die Weiterentwicklung, die Anpassung an neue Anforderungen, die ohnehin kommen. Für alles, was das eigene Unternehmen nicht von anderen unterscheidet, ist das der klügere Weg.

Dazu kommt ein Preis, der nie auf einer Rechnung steht: die Aufmerksamkeit, die man verliert. Jede Stunde, die ein Team in den Nachbau von Gewöhnlichem steckt, fehlt an der Stelle, die das Unternehmen wirklich unterscheidet. Ingenieurskraft ist die knappste Ressource, die ein Vorhaben hat, und sie ist nicht teilbar — was in das Lösbare fließt, das andere schon gelöst haben, fließt nicht in das Eigene, das nur man selbst lösen kann. Der stärkste Grund, das Verbreitete zu kaufen, ist deshalb nicht der niedrigere Preis, sondern dass man die eigene Kraft für das aufspart, worauf es ankommt.

Trade-off. Kaufen kauft Reife und geringen Aufwand mit dem Verzicht auf Passgenauigkeit — man fügt sich in die Annahmen des Produkts, statt sie zu bestimmen.

Kosten. Ein gekauftes Produkt bringt eine Abhängigkeit mit: laufende Gebühren, die Bindung an einen Anbieter, die Grenzen seiner Vorstellung vom Problem (siehe Kapitel 6).

Wann wir anders entscheiden. Sobald das verbreitete Produkt das eigene Problem nur ungefähr trifft und die Lücke im Kern des Geschäfts liegt, reicht Kaufen nicht mehr — dann beginnt der Bereich, in dem sich Bauen rechnet.

4. Wann Configure richtig ist

Konfigurieren ist die richtige Wahl, wenn eine Plattform dem eigenen Bedarf nahe genug kommt, dass Anpassung billiger ist als Bauen — und wenn man bereit ist, mit ihren Grenzen zu leben. Viele Plattformen sind gerade dafür gemacht: ein tragfähiges Gerüst, das man ohne eigene Entwicklung an die eigenen Abläufe anpasst. Man bekommt einen großen Teil des Weges geschenkt und gestaltet nur den Rest.

Die Kunst des Konfigurierens liegt im ehrlichen Blick auf die Grenzen. Eine Plattform trägt die Annahmen ihrer Erbauer in sich; man kann sie biegen, aber nicht beliebig. Solange die eigenen Abläufe sich innerhalb dieser Annahmen bewegen, ist Konfigurieren ein guter Tausch. Sobald man beginnt, die Plattform gegen ihre Natur zu zwingen — Anpassung auf Anpassung, um etwas zu erreichen, wofür sie nicht gedacht ist —, kippt die Rechnung, und man zahlt am Ende mehr als für eigenes Bauen und bekommt weniger.

Trade-off. Konfigurieren kauft einen großen Vorsprung mit der Bindung an die Grenzen der Plattform — man erbt ihre Stärken und ihre Annahmen zugleich.

Kosten. Jede Anpassung koppelt an die Plattform und muss bei deren Weiterentwicklung mitgetragen werden; zu viele Anpassungen machen aus dem Vorsprung eine Last.

Wann wir anders entscheiden. Wo man beginnt, die Plattform systematisch gegen ihre Natur zu biegen, hat Konfigurieren seinen Vorteil verloren — dann ist das ehrliche Eingeständnis, dass man eigentlich baut, billiger als das Weiterbiegen.

5. Wann Build sich rechnet

Bauen rechnet sich in einem engen, aber realen Bereich: dort, wo die Software selbst der Unterschied ist. Wenn ein Prozess das eigene Unternehmen von anderen abhebt, wenn kein Produkt ihn abbildet, weil ihn so nur dieses Unternehmen hat, oder wenn die Grenzen des Kaufbaren im Kern mehr kosten als das Bauen — dann ist Individualsoftware die richtige Antwort. Man baut das, was einen ausmacht, und was lange tragen muss.

Der Maßstab ist nicht, ob man bauen könnte — man kann fast alles bauen —, sondern ob das Gebaute einen Wert schafft, den das Gekaufte nicht schaffen kann. Dieser Wert liegt fast immer an einer von zwei Stellen: in der Differenzierung, weil die Software eine Fähigkeit gibt, die Wettbewerber nicht von der Stange bekommen; oder in der Passung, weil ein eigener, wesentlicher Ablauf sich in kein fremdes Korsett zwängen lässt, ohne teuer zu leiden. Wo keine dieser Stellen berührt ist, ist Bauen ein teurer Weg, das zu bekommen, was man hätte kaufen können.

Trade-off. Bauen kauft volle Passung und Kontrolle mit dem höchsten Aufwand und der dauerhaften Verantwortung für Pflege und Weiterentwicklung.

Kosten. Eigene Software endet nicht mit ihrer Fertigstellung; sie muss über ihre gesamte Lebensdauer betrieben, gepflegt und angepasst werden — diese Kosten trägt man allein.

Wann wir anders entscheiden. Sobald ein fertiges Produkt das Problem gut genug trifft und der Unterschied nicht im Kern des Geschäfts liegt, ist Bauen die falsche Wahl — dann kauft man und richtet die eigene Kraft auf das, was wirklich differenziert.

Die Entscheidung muss zudem nicht für immer fallen. Oft ist der klügste Weg, mit dem Kaufen zu beginnen und erst dann zu bauen, wenn sich zeigt, dass ein fertiges Produkt den eigenen Vorteil wirklich begrenzt. Man kauft, solange man das Problem noch nicht genau kennt, und ersetzt das Gekaufte durch Eigenes, sobald die Differenzierung sichtbar und belegt ist — dieselbe Haltung wie überall: sich nicht früh festlegen, sondern die teure, schwer umkehrbare Wahl treffen, wenn man am meisten weiß. Bauen ist selten dringlich; es lässt sich fast immer nachholen, wenn der Grund dafür feststeht.

6. Die verborgenen Kosten jeder Option

Jeder der drei Wege hat Kosten, die zum Zeitpunkt der Entscheidung im Schatten liegen und erst über die Jahre sichtbar werden. Sie zu kennen ist wichtiger als der Anschaffungspreis, denn über die Lebensdauer entscheiden sie die Rechnung.

Der häufigste Fehler ist, nur die sichtbaren Kosten zu vergleichen — den Kaufpreis gegen die Entwicklungskosten — und die verborgenen zu übersehen. Kaufen sieht billig aus, bis die Anbieterbindung teuer wird; Bauen sieht teuer aus, bis man merkt, dass es das Einzige war, was den eigenen Ablauf wirklich trägt.

Bei eigener Software ist die verborgene Kostenart die größte: Der Bau ist nur die Spitze, die Pflege über die Lebensdauer ist der Rumpf darunter. Eigene Software muss betrieben, aktualisiert, an neue Anforderungen angepasst und über Jahre verstanden werden — auch von Menschen, die sie nicht gebaut haben. Wer nur die Entwicklung rechnet und die Pflege vergisst, unterschätzt die wahren Kosten des Bauens systematisch. Dieselbe Verpflichtung, die Individualsoftware so wertvoll macht — sie gehört ganz einem selbst —, macht sie auch dauerhaft teuer: Es gibt keinen Anbieter, der die Zukunft mitträgt. Die ehrliche Rechnung stellt nicht Preis gegen Preis, sondern Gesamtkosten über die Lebensdauer gegen den Wert, den die Lösung im Kern des Geschäfts schafft.

Trade-off. Die verborgenen Kosten ernst zu nehmen bedeutet, eine langsamere, unbequemere Rechnung aufzumachen, statt sich vom niedrigen Anschaffungspreis leiten zu lassen.

Kosten. Die vollständige Rechnung über die Lebensdauer verlangt Annahmen über die Zukunft, die man nicht sicher kennt — man rechnet mit Unschärfe, aber ehrlicher als mit dem bloßen Preis.

Wann wir anders entscheiden. Bei einer kleinen, kurzlebigen Anschaffung genügt der Preisvergleich; die volle Lebensdauer-Rechnung lohnt erst bei Entscheidungen, die das Unternehmen über Jahre binden.

7. Das Kriterium: Differenzierung und Lebensdauer

Am Ende laufen alle drei Wege auf ein einziges Kriterium zusammen: Baue, was dich unterscheidet und lange tragen muss; kaufe oder konfiguriere, was verbreitet und austauschbar ist. Der Kern des Geschäfts — das, was man besser kann als andere und woran das Unternehmen hängt — verdient eigene Software, weil man ihn nicht in fremde Hände und fremde Annahmen legen will. Alles Übrige, das Notwendige, aber nicht Unterscheidende, kauft man.

Schema: Zwei Fragen entscheiden — unterscheidet uns das Problem, und gibt es ein Produkt, das passt? Nur oben links, im Differenzierenden ohne fertige Antwort, rechnet sich Bauen zwingend.

Die Lebensdauer verschärft das Kriterium. Etwas, das lange tragen muss, will man ungern an einen Anbieter binden, dessen Zukunft man nicht kennt; etwas Kurzlebiges kann man bedenkenlos kaufen. Differenzierung und Lebensdauer zusammen ergeben die ehrliche Antwort: Der langlebige Kern des Geschäfts wird gebaut, das kurzlebige oder austauschbare Beiwerk gekauft — und das meiste liegt dazwischen und wird gemischt.

Trade-off. Nach diesem Kriterium zu entscheiden verlangt, ehrlich zu benennen, was einen wirklich unterscheidet — und das ist oft weniger, als man glauben möchte.

Kosten. Das Kriterium zwingt zu einer differenzierten Antwort statt einer bequemen Regel; man muss für jeden Baustein neu urteilen, statt ein für alle Mal „bauen" oder „kaufen" zu sagen.

Wann wir anders entscheiden. Wo die Differenzierung und die Lebensdauer beide gering sind, spart man sich die feine Abwägung und kauft; das volle Kriterium gilt den Bausteinen, die den Kern oder die Dauer des Geschäfts berühren.

8. Typische Fehler

Die wiederkehrenden Muster, an denen die Entscheidung scheitert — fast alle sind Varianten davon, das Kriterium zu überspringen:

• Sofort ans Bauen denken, ohne zu prüfen, ob das Problem längst gelöst und kaufbar ist.
• Das Unterscheidende kaufen und in fremde Annahmen legen — und so den eigenen Vorteil aufgeben.
• Das Austauschbare bauen — teuer selbst herstellen, was man reifer und billiger hätte kaufen können.
• Nur Anschaffungspreise vergleichen und die verborgenen Kosten über die Lebensdauer übersehen.
• Eine Plattform so lange gegen ihre Natur biegen, bis Konfigurieren teurer wird als Bauen gewesen wäre.
• Die eigene Differenzierung überschätzen und für gewöhnlich halten, was in Wahrheit verbreitet ist.
• Entscheiden, als gäbe es nur bauen oder kaufen, und die Mischung übersehen, die meist die richtige ist.
• Ein langlebiges Kernsystem an einen Anbieter binden, dessen Zukunft man nicht kennt.

9. Entscheidungs-Checkliste

Vor jeder Build-, Buy- oder Configure-Entscheidung der Reihe nach zu klären:

• Schon gelöst? Gibt es ein fertiges Produkt für dieses Problem — und wenn ja, warum wäre Eigenes besser?
• Differenzierend? Unterscheidet uns dieser Baustein von anderen — oder ist er notwendig, aber gewöhnlich?
• Lebensdauer? Muss er lange tragen, oder ist er kurzlebig und bedenkenlos ersetzbar?
• Passung? Trifft ein Produkt oder eine Plattform das Problem gut genug — oder nur ungefähr, und liegt die Lücke im Kern?
• Verborgene Kosten bedacht? Habe ich Gesamtkosten über die Lebensdauer verglichen, nicht nur Anschaffungspreise?
• Mischung geprüft? Lässt sich das Gemeinsame kaufen und nur das Besondere bauen?
• Plattform-Grenzen? Beim Konfigurieren: bleibe ich innerhalb der Annahmen der Plattform — oder biege ich sie gegen ihre Natur?
• Bindung tragbar? Beim Kaufen: ist die Abhängigkeit vom Anbieter für diesen Baustein vertretbar?

Wer diese Fragen beantworten kann, hat entschieden, ob das Problem eigene Software verdient — und nicht bloß, dass man welche bauen könnte.

FAQ

Sagt ein Softwarehaus wirklich manchmal „nicht bauen"? Ein verantwortliches ja. Die teuerste Software ist die, die nie hätte gebaut werden sollen — Individuelles für ein Problem, das ein Produkt besser gelöst hätte. Wer nur baut, dient seinem kurzfristigen Geschäft; wer auch abrät, wenn die Sache es verlangt, dient dem Kunden und verdient das Vertrauen, das langfristig mehr wert ist.

Ist Kaufen nicht immer billiger als Bauen? In der Anschaffung oft, über die Lebensdauer nicht immer. Ein gekauftes Produkt bringt Gebühren, Anbieterbindung und die Grenzen fremder Annahmen mit; passt es im Kern nicht, kann die Summe dieser Kosten das Bauen übersteigen. Die ehrliche Rechnung stellt Gesamtkosten über die Zeit gegen den geschaffenen Wert, nicht Preis gegen Preis.

Woran erkenne ich, was ich bauen sollte? An der Differenzierung. Baue, was dich von anderen unterscheidet und was lange tragen muss — den Kern, an dem das Geschäft hängt. Kaufe oder konfiguriere, was verbreitet und austauschbar ist. Der häufigste Fehler ist, den eigenen Vorteil zu kaufen und das Gewöhnliche zu bauen — genau verkehrt herum.

Was ist mit Konfigurieren als Mittelweg? Konfigurieren ist stark, wenn eine Plattform nah genug am Bedarf liegt und man mit ihren Grenzen leben kann. Es kippt, sobald man sie systematisch gegen ihre Natur biegt — dann zahlt man am Ende mehr als für eigenes Bauen und bekommt weniger. Das ehrliche Eingeständnis, dass man eigentlich baut, ist dann die billigere Wahl.

Muss ich mich für einen Weg entscheiden? Selten. Die meisten Systeme sind eine Mischung: das Gemeinsame gekauft, das Besondere gebaut, eine Plattform für den Rahmen konfiguriert. Die Frage ist nicht „welcher Weg", sondern „welche Verteilung" — welcher Baustein verdient welchen Weg.

Wie verhält sich das zur Langlebigkeit? Eng. Was lange tragen muss, legt man ungern in fremde Hände, deren Zukunft man nicht kennt; was kurzlebig ist, kauft man bedenkenlos. Lebensdauer und Differenzierung zusammen ergeben die Antwort — der langlebige Kern wird gebaut, das austauschbare Beiwerk gekauft.

Weiterführend

• Software, die in zehn Jahren noch läuft — warum die Lebensdauer auch die Build-Buy-Entscheidung bestimmt.
• Ausgereifte Technik vor Neuheit — dieselbe Nüchternheit, angewandt auf die Wahl der Technik statt der Beschaffung.
• Warum Softwareprojekte wirklich scheitern — warum das teuerste Projekt oft das ist, das nie hätte beginnen dürfen.
• Reversibilität vor Vorhersage — Bausteine so wählen, dass ein Weg später noch umkehrbar bleibt.

Grundlage ist die Batunet Engineering Method: erst prüfen, ob gebaut werden muss; das Differenzierende bauen, das Gewöhnliche kaufen, den Rest bewusst mischen.

Abschließendes Engineering-Prinzip

Die Regel, die alles zusammenhält, ist kurz: Baue deinen Kern, kaufe deine Peripherie. Das Unterscheidende, das lange tragen muss und an dem das Geschäft hängt, legt man nicht in fremde Hände — dort baut man, weil man es sich nicht nehmen lassen will. Das Gewöhnliche, das viele brauchen und das ein Markt reifer und billiger bereithält, kauft man — dort zu bauen wäre teure Eitelkeit. Die meisten Fehler in dieser Frage sind Verwechslungen dieser beiden Seiten: den Kern gekauft und damit den Vorteil verschenkt, oder die Peripherie gebaut und damit Geld und Aufmerksamkeit an das Falsche gebunden. Wer die beiden sauber trennt, richtet seine knappste Ressource — die eigene Ingenieurskraft — auf das, was wirklich zählt.

Die erste Frage ist nie, wie man etwas baut, sondern ob. Die reifste Antwort eines Ingenieurs ist manchmal, es nicht zu tun — und zu sagen, warum.