Wie wir Architektur für zehnfaches Wachstum planen

Die meisten Plattformen werden für die Nutzer gebaut, die es heute gibt. Am ersten Tag ist das vernünftig. An Tag vierhundert wird es teuer: Das Unternehmen hat sich verdoppelt, ist in ein zweites Land gegangen und braucht eine Sprache, die niemand eingeplant hatte.

Für Wachstum planen heißt nicht, alles auf einmal zu bauen. Es heißt, die wenigen Entscheidungen früh zu treffen, die sich später nur schwer ändern lassen, und alles andere einfach zu halten. So gehen wir dabei vor.

Vom Ziel her denken

Bevor wir einen Tech-Stack wählen, schreiben wir die Zahlen auf, die das Unternehmen erreichen will: Nutzer, Regionen, Transaktionen, Sprachen. An diesem Ziel messen wir jede Architekturentscheidung. Der Traffic dieses Quartals ist dafür kein Maßstab.

Die Zahlen müssen nicht genau sein. „Etwa zehn Gesellschaften in der Gruppe, drei Länder, Französisch, Englisch und Arabisch, ein paar tausend Mitarbeitende“ reicht schon, um manche Entwürfe auszuschließen und andere zu bestätigen. Unsere Fragen sind einfach:

• Wie viele Organisationen teilen sich die Plattform, und müssen ihre Daten strikt getrennt sein?
• Welche Sprachen und Schreibrichtungen braucht die Oberfläche?
• Welche nationalen Regeln gelten (Lohnabrechnung, Steuern, Speicherort der Daten)?
• Was bedeutet es für das Geschäft, wenn die Plattform eine Stunde lang ausfällt?

Skalierung ist kein Zufall.

Aus jeder Antwort wird eine Vorgabe. Eine Gruppe mit mehreren Gesellschaften braucht Mandantenfähigkeit von Anfang an, denn wer sie später nachrüstet, muss jede Tabelle und jede Abfrage anfassen. Ein Produkt, das auch auf Arabisch genutzt wird, braucht Rechts-nach-links-Layouts im Fundament. Sonst muss später jeder einzelne Bildschirm neu gebaut werden.

Nahtstellen zuerst

Wir bestimmen, wo sich das System später aufteilen wird, etwa bei Abrechnung, Suche oder Benachrichtigungen. Dort ziehen wir schon jetzt saubere Grenzen, auch wenn anfangs alles als ein einziger Dienst ausgeliefert wird.

Eine Nahtstelle ist eine Schnittstelle, auf die sich der restliche Code verlässt. Die Implementierung dahinter bleibt austauschbar:

// a seam today, a service tomorrow
export interface Billing {
  charge(order: Order): Promise<Receipt>
}

Am ersten Tag besteht die Implementierung aus ein paar Funktionen in derselben Codebasis. Wird die Abrechnung irgendwann so komplex, dass sie ein eigenes Team, eine eigene Datenbank oder einen eigenen Release-Zyklus verdient, zieht sie hinter dieselbe Schnittstelle um. Der Rest der Plattform merkt davon nichts.

Genau hier trennt sich gute Vorbereitung von Overengineering. Wir starten nicht mit einem Dutzend Microservices, einem Message Bus und drei Datenbanken. Wir starten mit einer gut strukturierten Anwendung, deren Grenzen schon dort verlaufen, wo später die einzelnen Dienste liegen werden.

Dasselbe gilt für Integrationen. Jedes externe System, von der Buchhaltungssoftware bis zum Identity Provider, sitzt hinter einem Adapter. Wer einen Anbieter austauscht, ändert eine überschaubare Stelle im Code und muss keine große Migration stemmen.

Erst messen, dann skalieren

Jede Plattform, die wir live bringen, hat vom ersten Tag an Monitoring. Die Entscheidung zu skalieren beruht dann auf Daten und nicht auf Vermutungen.

Konkret sind drei Dinge eingerichtet, bevor sich der erste echte Nutzer anmeldet:

• Metriken zu Antwortzeiten, Fehlerraten und den Geschäftsvorgängen, auf die es ankommt (genehmigte Anträge, ausgestellte Rechnungen).
• Logs, durchsuchbar nach Organisation, Nutzer und Request, damit sich jedes Problem bis zu seiner Ursache zurückverfolgen lässt.
• Alarme, die jemanden wecken, sobald ein Schwellenwert überschritten wird. Und zwar bevor Kunden etwas merken.

So wird Skalierung zu einer Reihe kleiner, gut begründeter Entscheidungen: Diese Abfrage braucht einen Index, jener Bericht sollte im Hintergrund laufen, dieser Mandant braucht eine eigene Datenbank. Ohne Monitoring wird geraten. Und Raten kommt meistens teuer.

In der Praxis

Bei einer typischen Unternehmensplattform ist das Ergebnis bewusst unspektakulär: eine Anwendung, mandantenfähig ab der ersten Tabelle, mit Single Sign-on, serverseitigem Audit-Trail, klaren internen Grenzen, automatisierten Tests und Monitoring. Nichts Exotisches, und nichts, was man wegwerfen muss, wenn das Unternehmen wächst.

Der Ehrgeiz steckt im Plan. Die Technik bleibt so schlicht wie möglich. Sollen wir uns Ihr Ziel ansehen und Ihnen sagen, welche Entscheidungen jetzt zählen? Dann buchen Sie ein Gespräch.