Wie groß muss eine neue Anwendung gebaut werden?

Wer eine neue Anwendung entwickeln lässt, bekommt früher oder später Vorschläge wie diese:

„Wir bauen das gleich skalierbar.“
„Am besten teilen wir das in einzelne Services auf.“
„Das neue Framework bringt das doch sowieso schon mit.“

Das klingt nach Weitsicht und sauberer Architektur. Für jemanden, der nicht selbst entwickelt, ist es aber schwer zu beurteilen. Ist das nötig? Oder wird hier mehr gebaut, als die Aufgabe verlangt?

Wann Vorausdenken richtig ist

Manche Dinge sollten von Anfang an stimmen: wie die Daten aufgebaut sind, wer worauf zugreifen darf, wie sich die Anwendung sichern und wiederherstellen lässt. Das später zu ändern, ist teuer.

Auch Wachstum kann ein guter Grund sein, größer zu bauen. Soll die Anwendung absehbar an allen Standorten laufen oder hat ein großer Kunde mit deutlich mehr Aufträgen schon unterschrieben, gehört das in die Planung. Entscheidend ist, dass das Wachstum konkret ist und nicht nur denkbar.

Warum die Technik oft vor der Begründung feststeht

Viele technische Entscheidungen stehen fest, bevor die Begründung existiert. Das hat selten mit Schlamperei zu tun. Die Gründe sind oft andere als die, die man laut ausspricht: Eine Technologie reizt. Man will so etwas endlich einmal bauen. Es wird überall als der richtige Weg dargestellt.

Die fachliche Begründung kommt danach, und sie klingt gut. Damit einzelne Teile unabhängig wachsen können. Damit man später flexibler ist. Damit nicht alles ausfällt, wenn ein Teil Probleme macht. Das können berechtigte Ziele sein. Nur beantwortet keiner dieser Sätze die eigentliche Frage: Welches konkrete Problem oder welche absehbare Anforderung löst das?

Ich nehme mich davon nicht aus. Ich habe selbst schon Lösungen gebaut und mir die Begründung erst hinterher zurechtgelegt.

Was zu viel Architektur kostet

Eine Anwendung, die für eine Größe gebaut ist, die sie nie erreicht, ist nicht nur etwas teurer in der Entwicklung. Mehr Teile bedeuten mehr Stellen, an denen eine Änderung abgestimmt, ausgeliefert und auf Nebenwirkungen geprüft werden muss. Gut gebaut lässt sich das beherrschen. Der Aufwand ist aber da, und er lohnt sich nur, wenn die Aufteilung tatsächlich etwas bringt.

Dazu kommt der Betrieb. Mehr Bestandteile heißt mehr, was überwacht, aktualisiert und verstanden werden muss. In einem Unternehmen ohne große eigene IT-Abteilung ist das eine echte Last. Und sie bleibt, auch wenn der Entwickler, der es so gebaut hat, längst weitergezogen ist.

Fragen, die Sie stellen können

Sie müssen eine Architektur nicht selbst beurteilen können, um gezielt nachzufragen:

  • Welches konkrete Problem oder welche absehbare Anforderung löst dieser Ansatz?
  • Woran würden wir merken, dass wir ihn brauchen?
  • Was spräche gegen den einfacheren Weg?
  • Was würde es kosten, das später nachzurüsten, wenn es tatsächlich nötig wird?
  • Wer betreibt das, wenn das Projekt abgeschlossen ist?

Gute Antworten darauf sind konkret. Bleiben sie allgemein, etwa bei „zukunftssicher“ oder „flexibler“, lohnt sich eine Nachfrage.

Erst ankommen, dann ausbauen

Einfach bauen heißt nicht kurzsichtig bauen. Eine Anwendung kann klein starten und trotzdem so aufgebaut sein, dass sie später wachsen kann: mit einer klaren Struktur, sauber getrennten Zuständigkeiten im Code und ohne Abkürzungen, die einen Ausbau verbauen. Wächst die Anforderung tatsächlich, wird dort ausgebaut, wo es eng wird.

Skalierbarkeit ist dann eine Anforderung, die aus der Realität kommt, und kein Ziel an sich.

Bei einer neuen Anwendung kläre ich zuerst, was sie heute leisten muss und was absehbar dazukommt. Danach richtet sich, wie groß gebaut wird: nicht größer als nötig, nicht kurzfristiger gedacht als sinnvoll. Mehr dazu unter Interne Tools und neue Anwendungen.

Projekt besprechen