Plattformen, die mit Ihrem Geschäft wachsen — statt Sie in 18 Monaten zum Refactor zu zwingen.
Ihre Plattform muss heute liefern und morgen skalieren. Sie haben aber den Eindruck, dass jeder neue Use-Case einen Architektur-Bruch auslöst, dass SAP, CRM, PIM und Identity-Systeme fragmentiert nebeneinander stehen und dass Observability nachträglich angeflanscht wird. Mein Ansatz setzt vor dem ersten Service an: klare Domain-Grenzen, integrierte Identity, Beobachtbarkeit von Beginn — damit Ihre Plattform auch in 18 Monaten noch trägt.
Der typische Verlauf: Sie investieren in Microservices, weil 'monolithisch' nicht mehr zeitgemäß klingt. Services werden geschnitten, oft entlang der Team-Struktur statt entlang Domain-Grenzen. Sechs Quartale später haben Sie sechzehn Services, die zusammen langsamer sind als der vorherige Monolith — weil jede Anfrage durch fünf Dienste tunneln muss und niemand mehr weiß, wo Datenhoheit eigentlich liegt.
Conway's Law in Aktion
Services geschnitten nach Team-Struktur statt Domain-Grenzen werden zum verteilten Monolithen — mit allen Nachteilen des Monolithen plus Netzwerk-Latenz.
Parallel werden Integrationen zu SAP, CRM, PIM und Identity-System als Adapter angebaut, einer nach dem anderen. Jeder funktioniert für sich, keine zwei sehen gleich aus, und beim ersten Compliance-Audit wird sichtbar, dass es keine zentrale Stelle gibt, an der Sie Identity-Flows nachvollziehen können. Observability war 'Phase 2' — und Phase 2 kam nie.
Observability als Phase 2
Nachgerüstete Beobachtbarkeit ist immer halb so wirksam und doppelt so teuer. Wer ohne Tracing in Produktion geht, fliegt blind durch die ersten Incidents.
Das Ergebnis ist eine Plattform, die im Architektur-Diagramm beeindruckend aussieht und in der Produktion Quartale kostet, jedes Mal wenn jemand etwas ändert. Die Frage 'Wann lohnt sich Kubernetes?' ist meistens die falsche. Die richtige Frage ist: Sind die Domain-Grenzen so geschnitten, dass die Plattform Änderungen verträgt?
Mein Ansatz: zwei Wochen länger am Service-Schnitt überlegen statt zwei Quartale später entwirren. Observability gehört in die erste Architektur-Skizze, nicht in Sprint vierzig. Integration als First-Class-Pattern, nicht als Adapter-Sammlung. Das ist die Differenz zwischen einer Plattform, die trägt, und einer, die zur Hypothek wird.
Vier Prinzipien, an denen ich Plattform-Architektur ausrichte — unabhängig davon, ob bei Greenfield oder bei Modernisierung von Bestand:
Vor jeder Greenfield-Plattform oder Modernisierungs-Initiative: ehrliche Bestandsaufnahme. Wo liegen heute Domain-Grenzen tatsächlich, wo sind sie verwischt, wo verstecken sich Architektur-Schulden? Sie wissen am Ende, was als nächstes Sinn macht und was bewusst noch nicht angefasst wird.
Service-Grenzen entlang fachlicher Bounded Contexts statt entlang Team-Strukturen. Klare Zuständigkeit für Datenhoheit, definierte Schnittstellen, asynchrone Kommunikation wo Konsistenz es erlaubt. Bewährt bei Hoffmann: Identity-, Product-, Order-Hub als drei klar abgegrenzte DataHubs.
SAP, Informatica PIM, MS Dataverse, CRM-Systeme als integrierte Bestandteile statt sechs separat gewachsene Adapter. Bei Schneider Electric: was Microsoft-Spezialisten als 'unmöglich' eingestuft hatten — geliefert. Eine kohärente Integrations-Architektur statt Punkt-zu-Punkt-Wirrwarr.
OpenTelemetry für Tracing, Prometheus für Metrics, Loki oder Elasticsearch für strukturierte Logs. Resilience-Patterns über Polly, Circuit-Breaker, Bulkhead-Isolation. Sie sehen Probleme bevor Ihre Kunden anrufen — und können sie diagnostisch zerlegen, nicht nur erahnen.
Bestehende Plattform mit Architektur-Schulden? Modernisierung über Strangler-Pattern statt Big-Bang-Rewrite. Service für Service abgespalten, parallele Betriebsphase, schrittweise Migration. Risiko bleibt klein, Wert wird kontinuierlich geliefert.
Drei zentrale DataHubs (Identity, Product, Order) für E-Commerce über 47 Länder, 135k+ Produkte. GraphQL-Federation als kohärenter API-Layer über die Domains, integriert mit SAP, Informatica PIM, MS Dataverse. Eigene shared Libraries (CakeExt.Git) und Open-Source-Beiträge (GraphQL Inspector) als Beleg, dass Plattform-Arbeit auf Enterprise-Niveau auch innovativ sein darf.
Integration diverser interner Divisionen in eine nahtlose IDE-Lösung, vorher von Microsoft-Spezialisten als nicht machbar eingestuft. Internationale Teams koordiniert, Plattform-Architektur trotz heterogener Bestandssysteme stabil ausgeliefert. Beweis dafür, dass komplexe Integrations-Architektur kein Hexenwerk ist, wenn das Domain-Modell sauber sitzt.
„Herr Daniel zeichnet sich dadurch aus aktiv auf Problemstellungen oder Lücken in Konzepten hinzuweisen und im Team eine optimale Lösung für solche Fälle zu erarbeiten. Ich bin Herr Daniel persönlich sehr dankbar für die stets offene, zielführende und angenehme Zusammenarbeit. Er ist kommunikationsstark, verlässlich, hat hohe Ansprüche an guten Code und die Zusammenarbeit mit ihm hat wirklich Spaß gemacht."
Microservices lohnen sich, wenn unabhängige Deployment-Zyklen, unabhängige Skalierung pro Domain oder organisatorische Team-Autonomie konkret gebraucht werden — nicht weil das Architektur-Vokabular sie nahelegt. Bei vielen mittelständischen Plattformen ist ein gut geschnittener Modulith (klare Domain-Grenzen im Code, ein Deployment) die ehrlichere Antwort. Das entscheidet die fachliche Analyse, nicht das Buzzword.
Ja — Modernisierung läuft seit Jahren genau so. Bestandsaufnahme, Strangler-Pattern, Service-für-Service-Migration, parallele Betriebsphasen. Bewährt bei Hoffmann mit gewachsenem .NET-Bestand, der über Jahre kontinuierlich auf moderne Versionen, Central Package Management und Container-natives Deployment gehoben wurde.
Eine substanzielle Plattform-Modernisierung läuft typisch über Quartale, nicht Wochen. Schrittweise: Bestandsaufnahme, erster Pilot-Service nach Strangler-Pattern (4–8 Wochen), dann sukzessive Migration. Sie sehen Wert pro Quartal — keine 12-Monats-Black-Box-Phase, an deren Ende ein Big-Bang-Release steht.
Bestehende SAP-, CRM- oder PIM-Integrationen werden nicht pauschal weggeworfen. Stattdessen: Schritt-für-Schritt-Konsolidierung in eine kohärente Integrations-Schicht, mit klarem Cut-over pro Integration. Während der Migration laufen alt und neu parallel — kein Stillstand, kein Risiko-Wochenende.
Tagessatz im Marktbereich für Senior-Cloud-Architekten in DACH — transparent, abhängig vom Engagement-Modell (Architektur-Lead, Team-Integration, beratend). Eine erste Architektur-Bewertung (1–2 Wochen) ist klein und planbar; danach gibt es ein konkretes Migrations-Konzept mit Quartals-Meilensteinen statt Open-End-T&M. Greenfield-Plattformen werden in klaren Phasen mit definierten Lieferzuständen geplant — keine 6-Monats-Discovery-ohne-Ergebnis.
Ein paar gezielte Fragen statt starres Formular — ich verstehe in 2–3 Minuten, worum es geht, und melde mich persönlich.