Warum die Techniker Krankenkasse auf eine eigene IT‑Architektur setzt – und was andere Unternehmen daraus lernen können

Warum die Techniker Krankenkasse eigene IT-Architekturen priorisiert

Die Techniker Krankenkasse (TK) gehört zu den größten gesetzlichen Krankenkassen Deutschlands. Laut TK-Geschäftsbericht waren zum 01.01.2025 insgesamt 11.804.078 Menschen bei der TK versichert; im Frühjahr 2025 wurde die Marke von zwölf Millionen Versicherten überschritten [1]. Diese Größenordnung verändert die Anforderungen an digitale Systeme grundlegend. Es geht nicht mehr nur darum, einzelne Online-Services bereitzustellen, sondern eine hochverfügbare, regulatorisch belastbare und dauerhaft skalierbare Plattformlandschaft zu betreiben. Digitale Angebote wie die TK-App, TK-Doc, TK-Safe, Online-Anträge, E-Rezept-Funktionen und geschützte Mitgliederbereiche müssen gleichzeitig hohe Zugriffszahlen, sensible Gesundheitsdaten, unterschiedliche Authentifizierungsniveaus und komplexe Integrationen in das Gesundheitswesen beherrschen [2] [3].

Aus architektonischer Sicht entsteht dadurch ein Spannungsfeld, das Standardsoftware nur begrenzt abdecken kann. Eine gesetzliche Krankenkasse dieser Größe benötigt keine isolierte Fachanwendung, sondern ein verteiltes System aus Kundenkanälen, Identitätsdiensten, Fachverfahren, Dokumentenprozessen, Abrechnungslogiken, Partnerintegrationen, Telematik-Infrastruktur-Anbindungen, Datenplattformen, Monitoring-Komponenten und revisionssicheren Nachweissystemen. Jede Änderung an einem dieser Bausteine kann Auswirkungen auf Verfügbarkeit, Datenschutz, Nachvollziehbarkeit und Servicequalität haben. Eigene IT-Architekturen werden deshalb nicht primär aus technologischer Vorliebe priorisiert, sondern weil sie die Kontrolle über diese Abhängigkeiten erhöhen.

Architekturkontrolle statt reiner Systembeschaffung

Bei Organisationen mit sehr hoher Nutzerzahl reicht eine klassische Make-vs.-Buy-Betrachtung auf Produktebene nicht aus. Entscheidend ist, wer die fachlichen Domänen, Datenflüsse, Schnittstellenverträge, Sicherheitszonen, Betriebsmetriken und Änderungszyklen kontrolliert. Eine Standardplattform kann einzelne Funktionen schnell bereitstellen, führt aber häufig zu architektonischen Abhängigkeiten: vorgegebene Datenmodelle, eingeschränkte API-Erweiterbarkeit, proprietäre Workflow-Engines, begrenzte Mandantenfähigkeit, starre Release-Zyklen oder unzureichende Transparenz bei Protokollierung und Datenresidenz. Für eine Krankenkasse mit Millionen Versicherten kann genau diese fehlende Steuerbarkeit zum Betriebsrisiko werden.

Eigene Architektur bedeutet in diesem Kontext nicht zwingend, jede Softwarekomponente selbst zu programmieren. Fachlich präziser ist ein kontrolliertes Plattformmodell: Standardkomponenten können genutzt werden, solange sie über klar definierte Schnittstellen, Sicherheitsanforderungen, Betriebsmetriken und Datenverarbeitungsverträge in eine eigene Zielarchitektur eingebettet werden. Kritische Fähigkeiten wie Identitätsmanagement, Consent-Verwaltung, Datenklassifikation, Berechtigungsprüfung, Audit-Logging, API-Governance, Integrationslogik und Observability sollten jedoch architektonisch unter eigener Kontrolle stehen. So entsteht eine Landschaft, in der externe Lösungen austauschbar bleiben, ohne dass zentrale Datenflüsse oder Kernprozesse in einer Black Box verschwinden.

Skalierbarkeit als Architekturproblem, nicht nur als Infrastrukturproblem

Die TK nennt für das Jahr 2024 rund 30 Millionen online erledigte Anliegen und rund vier Millionen aktive Nutzerinnen und Nutzer der TK-App [1]. Diese Größenordnung zeigt, dass Skalierbarkeit nicht allein durch mehr Serverkapazität gelöst werden kann. Entscheidend ist, ob die Architektur Lastspitzen fachlich entkoppeln kann. Beispielsweise dürfen Uploads von Dokumenten, Statusabfragen, Postfachnachrichten, ePA-Zugriffe, Authentifizierungsprozesse und Hintergrundverarbeitung nicht dieselben Engpässe erzeugen. Ein robustes Zielbild trennt daher synchrone Nutzerinteraktionen von asynchronen Backend-Prozessen.

Technisch bedeutet das: Nutzernahe Services sollten kurze Antwortzeiten liefern und rechenintensive oder langlaufende Verarbeitung über Queues, Event-Streams oder Workflow-Orchestrierung auslagern. Ein Antrag, ein Dokumentenupload oder eine Stammdatenänderung muss nicht in jedem Fall vollständig synchron verarbeitet werden. Stattdessen kann das Frontend eine validierte Annahmebestätigung liefern, während nachgelagerte Systeme die fachliche Prüfung, Klassifikation, Weiterleitung und Archivierung ereignisgesteuert durchführen. Dadurch sinkt die Kopplung zwischen Benutzeroberfläche und Kernsystemen. Lastspitzen werden abgefedert, ohne dass fachliche Konsistenz verloren geht.

Für eine Krankenkasse ist dabei besonders wichtig, zwischen technischer Skalierung und fachlicher Konsistenz zu unterscheiden. Nicht alle Daten dürfen eventual consistent verarbeitet werden. Einfache Statusinformationen, Benachrichtigungen oder Dokumentenverarbeitungen können asynchron laufen. Identitätsprüfung, Berechtigungsentscheidungen, Zugriff auf besonders schützenswerte Gesundheitsdaten oder rechtsverbindliche Erklärungen benötigen dagegen striktere Konsistenz, stärkere Protokollierung und klar definierte Transaktionsgrenzen. Eigene Architekturentscheidungen erlauben es, diese Unterschiede pro Domäne sauber abzubilden, statt ein generisches Plattformverhalten für alle Prozesse akzeptieren zu müssen.

Domänenorientierte Architektur für komplexe Krankenkassenprozesse

Die digitale Landschaft einer Krankenkasse lässt sich nicht sinnvoll als monolithischer Prozessblock modellieren. Mitgliedschaft, Beiträge, Leistungen, Erstattungen, Krankengeld, Pflege, Prävention, elektronische Patientenakte, digitale Identität, Kommunikation, Dokumentenmanagement und Partnerintegration folgen jeweils eigenen fachlichen Regeln. Eine tragfähige Architektur muss diese Domänen voneinander abgrenzen, ohne die Nutzererfahrung zu fragmentieren. Genau hier liegt der Wert einer domänenorientierten Architektur.

In einem solchen Modell werden fachliche Kontexte als eigenständige Domänen mit klaren Verantwortlichkeiten beschrieben. Jede Domäne besitzt eigene Datenhoheit, eigene Schnittstellenverträge und eigene Qualitätsanforderungen. Der Mitgliederbereich benötigt beispielsweise andere Latenzanforderungen als eine nächtliche Abrechnungsschnittstelle. Ein Dokumentenservice benötigt andere Speicher-, Klassifikations- und Aufbewahrungsregeln als ein Terminservice. Ein ePA-naher Prozess benötigt ein anderes Sicherheitsniveau als ein allgemeiner Informationsservice. Durch diese fachliche Trennung können Teams Komponenten unabhängig weiterentwickeln, testen, deployen und skalieren.

Die technische Umsetzung kann über Microservices, modulare Monolithen oder eine Kombination aus beiden erfolgen. Entscheidend ist nicht das Label der Architektur, sondern die Kopplung. Ein modularer Monolith mit sauber getrennten Domänen, stabilen internen Schnittstellen und guter Testabdeckung kann robuster sein als eine unkontrollierte Microservice-Landschaft mit verteilten Abhängigkeiten. Für eine Krankenkasse ist deshalb eine evolutionäre Architektur besonders relevant: Kernprozesse werden dort modularisiert, wo unterschiedliche Änderungsraten, Skalierungsprofile oder Sicherheitsanforderungen bestehen. Wo diese Unterschiede nicht bestehen, kann eine bewusst einfachere Struktur die bessere Wahl sein.

Schnittstellen als strategische Kontrollpunkte

Eine Krankenkasse ist in ein dichtes Ökosystem eingebunden: Versicherte, Arbeitgeber, Leistungserbringer, Apotheken, Behörden, Dienstleister, Plattformen der Telematik-Infrastruktur und interne Fachsysteme erzeugen eine Vielzahl technischer Schnittstellen. Diese Schnittstellen sind keine Randthemen, sondern zentrale Kontrollpunkte der Architektur. Sie bestimmen, welche Daten wann, in welcher Qualität, mit welchem Sicherheitsniveau und unter welcher Verantwortlichkeit verarbeitet werden.

Eigene IT-Architekturen ermöglichen eine konsequente API-Governance. Dazu gehören versionierte Schnittstellen, maschinenlesbare API-Spezifikationen, Schema-Validierung, Rate-Limiting, zentrale Authentifizierung, Autorisierung auf Feldebene, Request-Signing, Idempotenzschlüssel, Korrelations-IDs, technische Mandantentrennung und vollständige Protokollierung sicherheitsrelevanter Ereignisse. Gerade bei Millionen Nutzerinnen und Nutzern verhindert diese Disziplin, dass Integrationen über Jahre zu schwer wartbaren Punkt-zu-Punkt-Verbindungen anwachsen.

Besonders wichtig ist die Trennung zwischen externen APIs, internen Service-APIs und ereignisgetriebenen Integrationen. Externe APIs benötigen starke Absicherung, klare Verträge und strikte Rückwärtskompatibilität. Interne APIs können stärker auf Geschwindigkeit und Domänenlogik optimiert werden, müssen aber trotzdem versioniert und beobachtbar sein. Event-basierte Schnittstellen eignen sich für Statusänderungen, Benachrichtigungen, Dokumentenverarbeitung und Prozessfortschritte. Eine eigene Integrationsarchitektur erlaubt es, diese Muster gezielt einzusetzen, statt alle Integrationen durch ein einziges generisches Middleware-Paradigma zu pressen.

Datenschutz als eingebautes Architekturprinzip

Gesundheitsdaten sind besonders schützenswert. Die Architektur muss deshalb Datenschutz nicht als nachgelagerte Compliance-Prüfung behandeln, sondern als eingebautes Systemprinzip. Das betrifft Datenminimierung, Zweckbindung, Zugriffskontrolle, Verschlüsselung, Protokollierung, Löschkonzepte, Nachvollziehbarkeit und technische Trennung unterschiedlicher Datenklassen. Bei digitalen Gesundheitsdiensten wie TK-Safe verweist die TK auf verschlüsselte Datenübertragung und eine sicherheitsgeprüfte technische Umgebung [4]. Für die Architektur bedeutet das: Sicherheits- und Datenschutzanforderungen müssen bis in Datenmodell, Schnittstellendesign und Betriebsprozesse hineinwirken.

Ein technisch belastbares Modell beginnt mit einer Datenklassifikation. Nicht jede Information hat denselben Schutzbedarf. Allgemeine Serviceinformationen, Stammdaten, Kommunikationsdaten, Abrechnungsdaten und medizinische Informationen müssen unterschiedlich behandelt werden. Daraus ergeben sich getrennte Sicherheitszonen, differenzierte Zugriffspfade, unterschiedliche Protokollierungstiefen und spezifische Verschlüsselungsanforderungen. Besonders sensible Daten sollten nur über explizit autorisierte Services erreichbar sein. Direkte Datenbankzugriffe durch mehrere Anwendungen, breit verteilte Servicekonten oder unklare Administratorrechte sind in einem solchen Umfeld erhebliche Architekturprobleme.

Eine eigene Architektur erlaubt außerdem eine präzisere Umsetzung von Zero-Trust-Prinzipien. Jeder Zugriff wird authentifiziert, autorisiert, kontextbezogen bewertet und protokolliert. Vertrauen entsteht nicht dadurch, dass ein System im internen Netzwerk steht, sondern durch überprüfbare Identitäten, minimale Berechtigungen und nachvollziehbare Zugriffspfade. Dazu gehören rollen- und attributbasierte Zugriffskontrollen, kurzlebige Tokens, getrennte Schlüsselverwaltung, Secrets-Management, starke Geräte- und Sitzungsprüfung sowie eine konsequente Trennung administrativer und fachlicher Rechte.

Identität, Einwilligung und Berechtigung als Kernservices

In digitalen Krankenkassenservices ist Identität kein reiner Login-Mechanismus. Sie ist eine zentrale Sicherheits- und Prozesskomponente. Unterschiedliche Nutzungsszenarien erfordern unterschiedliche Vertrauensniveaus: ein allgemeiner Informationsabruf, eine Änderung persönlicher Daten, ein Zugriff auf Gesundheitsdaten, eine Nutzung von E-Rezept-Funktionen oder eine Interaktion mit der Telematik-Infrastruktur stellen jeweils andere Anforderungen an Authentifizierung und Autorisierung.

Eine belastbare Architektur trennt daher Authentifizierung, Autorisierung, Consent-Management und Session-Management voneinander. Authentifizierung klärt, wer die Person ist. Autorisierung klärt, welche Aktion diese Person in welchem Kontext ausführen darf. Consent-Management dokumentiert, welche Einwilligungen oder Berechtigungen vorliegen. Session-Management steuert, wie lange ein Zugriff gültig bleibt und unter welchen Bedingungen eine erneute Prüfung erforderlich ist. Werden diese Fähigkeiten als zentrale Plattformservices umgesetzt, können neue digitale Angebote schneller entwickelt werden, ohne Sicherheitslogik in jeder Anwendung neu zu implementieren.

Gerade bei sensiblen Daten ist außerdem eine feingranulare Berechtigungsprüfung notwendig. Es genügt nicht, einer angemeldeten Person pauschal Zugriff auf alle Funktionen zu geben. Die Architektur muss prüfen, ob die konkrete Aktion, der konkrete Datensatz, der aktuelle Kanal, das Authentifizierungsniveau und der fachliche Zweck zusammenpassen. Diese Prüfung sollte nicht ausschließlich im Frontend stattfinden, sondern serverseitig und nachvollziehbar in den Fachservices verankert sein.

Hybride Betriebsmodelle für regulierte Workloads

Für Krankenkassen ist die Frage Cloud oder On-Premise zu grob. Realistischer ist ein hybrides Zielbild, das Workloads nach Schutzbedarf, Latenz, Integrationsnähe, Skalierungsprofil und regulatorischer Kritikalität platziert. Nicht jeder Service benötigt dieselbe Infrastruktur. Öffentlich zugängliche Informationsangebote, statische Inhalte, nicht kritische Skalierungsfrontends oder Analyseumgebungen können andere Betriebsmodelle haben als Kernverfahren, Identitätsdienste oder Systeme mit besonders sensiblen Gesundheitsdaten.

Ein ausgereiftes hybrides Modell arbeitet mit klaren Landing Zones, Netzwerksegmentierung, zentralem Identity-Provider, Policy-as-Code, Infrastructure-as-Code, standardisierten Deployment-Pipelines, Secrets-Management und einheitlichem Monitoring. Wichtig ist, dass Hybridität nicht zu einem unkontrollierten Nebeneinander von Plattformen führt. Die Architektur muss definieren, welche Daten welche Umgebung verlassen dürfen, welche Verschlüsselung erforderlich ist, welche Protokolle erlaubt sind, welche Logs zentral korreliert werden und wie Vorfälle über Plattformgrenzen hinweg analysiert werden.

Der technische Vorteil eigener Architektur liegt dabei in der Portabilität kritischer Fähigkeiten. Anwendungen sollten nicht unnötig stark an proprietäre Plattformdienste gebunden werden, wenn dadurch spätere Migrationen, Exit-Szenarien oder regulatorische Anpassungen erschwert werden. Gleichzeitig wäre es ineffizient, alle Cloud-nativen Fähigkeiten zu vermeiden. Die Kunst liegt in einer bewussten Schichtung: fachliche Kernlogik, Identitäts- und Sicherheitsmodelle, Schnittstellenverträge und Datenmodelle bleiben unter eigener Kontrolle; austauschbare Infrastruktur- und Plattformdienste werden dort genutzt, wo sie Geschwindigkeit, Resilienz oder Skalierbarkeit verbessern.

Resilienz durch Entkopplung, Fehlertoleranz und Betriebsmetriken

Bei Millionen Versicherten ist Resilienz eine fachliche Anforderung. Ein Ausfall betrifft nicht nur interne Produktivität, sondern direkt die Fähigkeit der Versicherten, Anliegen zu erledigen, Dokumente einzureichen oder digitale Gesundheitsservices zu nutzen. Architekturentscheidungen müssen deshalb mit konkreten Service-Level-Zielen verbunden werden. Dazu gehören Verfügbarkeit, Antwortzeiten, Fehlerraten, Wiederanlaufzeiten, Datenverlusttoleranzen und Wiederherstellbarkeit.

Technisch erfordert das mehrere Schutzmechanismen. Circuit Breaker verhindern, dass der Ausfall eines nachgelagerten Systems eine Kettenreaktion auslöst. Bulkheads begrenzen Fehler auf einzelne Domänen oder Ressourcenpools. Retries müssen kontrolliert und mit Backoff-Strategien umgesetzt werden, damit sie Lastspitzen nicht verstärken. Idempotente Operationen verhindern doppelte Verarbeitung bei Wiederholungen. Caching reduziert Last auf Kernsysteme, darf aber bei sensiblen oder hochaktuellen Daten nur mit klaren Gültigkeitsregeln eingesetzt werden. Fallback-Prozesse stellen sicher, dass Nutzerinnen und Nutzer auch bei Teilausfällen verständliche Rückmeldungen erhalten.

Eine eigene Architektur ermöglicht es, diese Muster fachlich differenziert einzusetzen. Bei einem allgemeinen Statushinweis kann ein Fallback ausreichen. Bei einem rechtsverbindlichen Antrag ist eine kontrollierte Annahme, technische Quittierung und spätere Verarbeitung notwendig. Bei Gesundheitsdaten kann ein Fallback fachlich unzulässig sein, wenn dadurch falsche oder unvollständige Informationen angezeigt würden. Diese Unterschiede lassen sich nur sauber umsetzen, wenn Architektur, Fachlichkeit und Betrieb eng gekoppelt sind.

Observability als Steuerungssystem der digitalen Servicequalität

Monitoring reicht in einer solchen Umgebung nicht aus. Benötigt wird Observability über alle relevanten Schichten hinweg: Frontend, API-Gateway, Identitätsdienste, Fachservices, Datenbanken, Messaging-Systeme, Integrationsplattformen und externe Partnerdienste. Nur so lässt sich nachvollziehen, ob ein Problem aus Sicht der Nutzerinnen und Nutzer, der Fachprozesse oder der Infrastruktur entsteht.

Eine technisch reife Architektur nutzt strukturierte Logs, Metriken, Traces und fachliche Ereignisse gemeinsam. Korrelations-IDs verbinden Nutzerinteraktionen mit Backend-Prozessen. Distributed Tracing zeigt, welche Services an einer Transaktion beteiligt sind. Fachliche Metriken machen sichtbar, wie viele Anträge angenommen, wie viele Dokumente verarbeitet, wie viele Authentifizierungen abgebrochen oder wie viele Prozesse in manuellen Klärfällen gelandet sind. Dadurch wird Servicequalität messbar und nicht nur technisch geschätzt.

Für CIOs und IT-Teams ist diese Transparenz entscheidend. Sie zeigt, welche Komponenten tatsächlich geschäftskritisch sind, wo technische Schulden entstehen, welche Schnittstellen instabil sind und welche Standardlösungen operative Risiken erzeugen. Eine eigene Architekturpriorisierung bedeutet daher auch: Die Organisation investiert in die Fähigkeit, ihre digitale Wertschöpfung selbst zu beobachten, zu bewerten und gezielt zu verbessern.

Warum Eigenentwicklung bei kritischen Kernfähigkeiten sinnvoll sein kann

Eigenentwicklung ist besonders dort plausibel, wo eine Fähigkeit langfristig differenzierend, regulatorisch kritisch oder integrativ zentral ist. Dazu gehören beispielsweise domänenspezifische Prozesslogik, die Orchestrierung von Versichertenanliegen, Sicherheits- und Berechtigungsmodelle, zentrale API-Schichten, Integrationsadapter zu Fachverfahren, Consent- und Audit-Komponenten sowie technische Plattformservices für digitale Kanäle. Diese Bausteine bestimmen, wie schnell neue Services entstehen, wie sicher Daten verarbeitet werden und wie gut Änderungen an gesetzlichen oder fachlichen Anforderungen umgesetzt werden können.

Standardsoftware eignet sich dagegen eher für klar abgegrenzte, wenig differenzierende Funktionen, sofern sie sauber integrierbar ist. Dazu können Collaboration, generisches Ticketing, Standard-CRM-Funktionen, Reporting-Werkzeuge oder Infrastrukturservices gehören. Entscheidend ist jedoch, dass die Standardlösung nicht unkontrolliert zum faktischen Daten- oder Prozesszentrum wird. Sobald ein gekauftes System Kernlogik, Datenmodell und Integrationsregeln dominiert, verschiebt sich die Architekturhoheit zum Anbieter. Für stark regulierte Organisationen kann das spätere Anpassungen verlangsamen und Exit-Kosten erhöhen.

Architekturpriorisierung als Governance-Modell

Die Priorisierung eigener IT-Architekturen ist letztlich ein Governance-Modell. Sie legt fest, welche technischen Fähigkeiten strategisch geschützt werden müssen, welche Komponenten austauschbar bleiben sollen und welche Qualitätsanforderungen nicht verhandelbar sind. Für eine Organisation wie die TK entsteht daraus ein Architekturrahmen, der Datenschutz, Skalierbarkeit, Modularität, Integrationsfähigkeit und Betriebsstabilität verbindet.

Ein solches Governance-Modell sollte Architekturentscheidungen dokumentieren und regelmäßig überprüfen. Dazu gehören Architecture Decision Records, Sicherheitsfreigaben, Datenschutz-Folgenabschätzungen, API-Reviews, Betriebsbereitschaftsprüfungen, Lasttestnachweise, Abhängigkeitsanalysen und Exit-Bewertungen für externe Plattformen. Auf diese Weise wird Architektur nicht als einmaliger Entwurf verstanden, sondern als kontinuierlicher Steuerungsprozess über den gesamten Lebenszyklus digitaler Services.

Architekturprinzipien aus dem TK-Beispiel: Ein Hypothesenmodell für Unternehmen

Aus dem digitalen Betriebsmodell der Techniker Krankenkasse lässt sich ein Architekturmodell ableiten, das auch für andere Unternehmen mit hohen Nutzerzahlen, sensiblen Daten und komplexen Integrationslandschaften relevant ist. Die TK betreibt nicht nur einzelne digitale Anwendungen, sondern ein Ökosystem aus App, Webservices, elektronischer Patientenakte, digitalen Kommunikationskanälen, E-Rezept-Funktionen, Online-Anliegen, Telemedizinangeboten und Backend-Prozessen. Laut TK-Geschäftsbericht wurden 2024 rund 30 Millionen Anliegen online erledigt, über die TK-App oder über die Website. Die TK-App hatte rund vier Millionen aktive Nutzerinnen und Nutzer [1]. Diese Größenordnung zeigt, dass Architekturentscheidungen nicht isoliert auf Funktionsebene getroffen werden können. Sie müssen Lastverhalten, Datenschutz, Integrationsfähigkeit, Resilienz, Betriebsbeobachtung und Änderbarkeit gemeinsam berücksichtigen.

Wichtig ist dabei die Einordnung als Hypothesenmodell. Öffentlich belegbar sind die digitalen Angebote, die Nutzergrößen und einzelne Sicherheitsinformationen, etwa zu TK-Safe. Nicht öffentlich belegbar sind interne Zielarchitekturen, konkrete Plattformentscheidungen oder vertrauliche Betriebsmodelle der TK. Der folgende Abschnitt beschreibt deshalb keine interne TK-Architektur, sondern leitet aus den öffentlich sichtbaren Anforderungen ein belastbares Architekturmodell für Unternehmen ab.

Lastmodelle und Skalierungsmodelle unter hoher Nutzerlast

Organisationen mit Millionen digital erreichbarer Nutzerinnen und Nutzer müssen Last nicht nur technisch, sondern fachlich modellieren. Eine TK-App, ein Mitgliederportal, eine elektronische Patientenakte oder ein digitaler Beratungsservice erzeugen sehr unterschiedliche Zugriffsmuster. Ein Login-Vorgang verursacht andere Systemlast als ein Dokumentenupload, eine Statusabfrage, ein E-Rezept-Prozess, ein Zugriff auf Gesundheitsdaten oder eine Videosprechstunde über TK-Doc [2]. Ein tragfähiges Architekturmodell trennt diese Lastprofile voneinander und behandelt sie nicht als homogenen Webtraffic.

Die erste Architekturfrage lautet daher: Welche Nutzerinteraktionen müssen synchron beantwortet werden und welche Prozesse dürfen asynchron weiterlaufen? Ein synchroner Prozess ist beispielsweise die Authentifizierung, die Anzeige eines geschützten Bereichs oder die Berechtigungsprüfung vor dem Zugriff auf sensible Daten. Ein asynchroner Prozess kann dagegen die Verarbeitung eines eingereichten Dokuments, die Klassifikation eines Anliegens, die Benachrichtigung über einen Statuswechsel oder die Übergabe an ein Fachverfahren sein. Diese Trennung reduziert Spitzenlasten auf Kernsysteme und verhindert, dass nutzernahe Kanäle direkt von langsamen Backend-Prozessen abhängig werden.

Technisch entsteht daraus eine mehrschichtige Skalierungsarchitektur. Die Präsentationsschicht, etwa App und Webfrontend, muss hohe Zugriffszahlen und kurze Antwortzeiten unterstützen. Die API-Schicht muss Authentifizierung, Autorisierung, Rate-Limiting, Payload-Validierung, Versionierung und Protokollierung übernehmen. Die Prozessschicht muss fachliche Vorgänge orchestrieren und langlaufende Aufgaben entkoppeln. Die Daten- und Fachverfahrensschicht muss Konsistenz, Nachvollziehbarkeit und regulatorische Anforderungen sicherstellen. Eine solche Schichtung erlaubt es, einzelne Ebenen unterschiedlich zu skalieren, ohne die gesamte Systemlandschaft gleichermaßen zu belasten.

Für Unternehmen ist besonders relevant, dass Skalierung nicht nur horizontal durch zusätzliche Instanzen entsteht. Entscheidend sind auch Queue-basierte Verarbeitung, Event-Streams, Caching, Read-Modelle, Lastpriorisierung, Backpressure und kontrollierte Degradation. Wenn ein Dokumentenservice temporär überlastet ist, sollte nicht die komplette App ausfallen. Wenn ein externes Partnersystem langsam reagiert, darf es keine Kettenreaktion durch alle Services auslösen. Wenn ein Nutzerstatus aus einem Read-Model angezeigt werden kann, muss nicht jeder Zugriff das transaktionale Kernsystem belasten.

Ein robustes Lastmodell unterscheidet mindestens vier Kategorien:

• Interaktive Echtzeitprozesse: Login, Sitzungsprüfung, Navigation, Statusanzeige und einfache Self-Service-Aktionen mit strengen Latenzanforderungen.
• Regulatorisch kritische Transaktionen: Anträge, Einwilligungen, Zugriff auf Gesundheitsdaten, Identitätsprüfung und rechtsverbindliche Erklärungen mit hoher Nachweis- und Konsistenzanforderung.
• Asynchrone Hintergrundprozesse: Dokumentenverarbeitung, Benachrichtigungen, Synchronisationen, fachliche Prüfungen und Übergaben an nachgelagerte Systeme.
• Externe Integrationsprozesse: Kommunikation mit Leistungserbringern, Plattformen, Dienstleistern, Telematikkomponenten oder weiteren Partnern mit eigener Verfügbarkeit und eigenen Antwortzeiten.

Aus dieser Kategorisierung ergeben sich konkrete Architekturentscheidungen. Interaktive Echtzeitprozesse benötigen niedrige Latenzen, Caching, hohe Verfügbarkeit und klare Fallbacks. Regulatorisch kritische Transaktionen benötigen starke Konsistenz, Audit-Logs, Idempotenz und belastbare Transaktionsgrenzen. Asynchrone Hintergrundprozesse benötigen Queues, Retry-Mechanismen, Dead-Letter-Queues und fachliche Statusmodelle. Externe Integrationen benötigen Timeout-Strategien, Circuit Breaker, Monitoring und saubere Fehlersemantik.

Skalierung über Domänen statt über Einzelsysteme

Ein häufiges Missverständnis bei skalierbaren Architekturen ist die Annahme, dass jede Anwendung unabhängig skaliert werden kann. In stark regulierten Organisationen hängen viele Funktionen jedoch an denselben fachlichen Kernobjekten: Versicherte, Mitgliedschaft, Kommunikation, Dokumente, Leistungsfälle, Berechtigungen, Einwilligungen und Gesundheitsdaten. Werden diese Objekte unkontrolliert zwischen Anwendungen repliziert, entstehen Inkonsistenzen, doppelte Datenhaltungen und schwer nachvollziehbare Prozesszustände.

Ein besseres Modell ist domänenorientierte Skalierung. Jede fachliche Domäne erhält klare Datenverantwortung und stellt ihre Fähigkeiten über stabile Schnittstellen bereit. Eine Domäne „Identität und Zugriff“ beantwortet beispielsweise, wer eine Person ist und welches Authentifizierungsniveau vorliegt. Eine Domäne „Kommunikation“ steuert Nachrichten, Postfachfunktionen und Benachrichtigungen. Eine Domäne „Dokumente“ verwaltet Upload, Klassifikation, Speicherung und Aufbewahrung. Eine Domäne „Gesundheitsdaten“ unterliegt besonders strengen Sicherheits- und Berechtigungsregeln. Diese Trennung erlaubt zielgerichtete Skalierung nach fachlicher Kritikalität.

Für Unternehmen ist daraus eine wichtige Lehre ableitbar: Skalierung sollte nicht primär entlang von Produkten organisiert werden, sondern entlang fachlicher Verantwortungsgrenzen. Ein gekauftes Produkt kann eine Oberfläche oder eine Teilfunktion liefern. Die strategische Architektur muss jedoch festlegen, welche Domäne welche Daten besitzt, welche Schnittstellen verbindlich sind und welche Prozesse nur über kontrollierte Services ausgeführt werden dürfen. So bleibt die Landschaft auch bei wachsender Nutzerzahl wartbar.

Modularität als Risikomanagement

Digitale Services wie TK-App, TK-Doc und TK-Safe zeigen, wie breit das digitale Serviceportfolio einer Krankenkasse ist [2] [3]. Für Unternehmen mit vergleichbarer Komplexität ist Modularität kein ästhetisches Architekturprinzip, sondern ein Instrument zur Risikobegrenzung. Je stärker Funktionen voneinander abhängig sind, desto höher ist das Risiko, dass Änderungen, Fehler oder Lastspitzen unkontrolliert auf andere Systemteile übergreifen.

Modularität bedeutet dabei nicht automatisch Microservices. Ein modularer Monolith mit klar getrennten fachlichen Modulen, stabilen internen Schnittstellen und guter Testabdeckung kann für bestimmte Domänen sinnvoller sein als eine verteilte Microservice-Landschaft. Entscheidend ist die Kopplung. Ein System ist modular, wenn Änderungen an einer Funktion nicht unnötig viele andere Funktionen betreffen, wenn Datenhoheit klar geregelt ist und wenn technische Abhängigkeiten sichtbar und kontrollierbar bleiben.

Für kritische digitale Services sollte Modularität auf mehreren Ebenen umgesetzt werden:

• Fachliche Modularität: Domänen wie Identität, Kommunikation, Dokumente, Leistungen, Beratung und Gesundheitsdaten werden mit klarer Verantwortung voneinander abgegrenzt.
• Technische Modularität: Komponenten besitzen stabile Schnittstellen, getrennte Deployment-Pfade, unabhängige Skalierungsprofile und klar definierte Fehlergrenzen.
• Datenbezogene Modularität: Daten werden nicht beliebig geteilt, sondern über kontrollierte Services, Events oder definierte Replikationsmechanismen bereitgestellt.
• Betriebliche Modularität: Monitoring, Alarmierung, Runbooks und Verantwortlichkeiten sind je Modul eindeutig zugeordnet.

Diese Ebenen reduzieren operative Risiken. Wenn ein Modul für Dokumentenverarbeitung ausfällt, muss die Anmeldung weiterhin funktionieren. Wenn ein externer Beratungsdienst nicht erreichbar ist, darf die gesamte App nicht blockieren. Wenn eine Fachdomäne eine neue Version bereitstellt, sollten andere Domänen nicht ungeplant angepasst werden müssen. Modularität ist damit eine Voraussetzung für kontrollierte Änderbarkeit bei laufendem Betrieb.

Ein weiteres Risikothema ist Release-Management. Je größer die Nutzerbasis, desto riskanter sind Big-Bang-Releases. Modulare Architekturen ermöglichen kleinere Änderungen, Feature-Toggles, Canary-Releases, Blue-Green-Deployments und gezieltes Rollback einzelner Komponenten. In regulierten Umgebungen müssen diese Mechanismen mit Freigabeprozessen, Testnachweisen und Auditierbarkeit kombiniert werden. Geschwindigkeit und Kontrolle dürfen nicht gegeneinander ausgespielt werden.

Fehlerisolierung und Resilienz als Architekturpflicht

Hohe Nutzerzahlen machen Fehler wahrscheinlicher sichtbar. Ein lokaler Defekt, der bei wenigen Nutzern kaum auffällt, kann bei Millionen Interaktionen schnell zu einem Massenproblem werden. Deshalb muss die Architektur Fehler nicht nur vermeiden, sondern aktiv einkapseln. Resilienz entsteht aus der Fähigkeit, Teilausfälle zu erkennen, zu begrenzen und kontrolliert weiterzubetreiben.

Zu den wichtigsten Resilienzmustern gehören Circuit Breaker, Bulkheads, Timeouts, kontrollierte Retries, Idempotenz, Fallbacks und Dead-Letter-Queues. Circuit Breaker verhindern, dass ein nicht erreichbarer Dienst immer wieder aufgerufen wird und dadurch weitere Ressourcen blockiert. Bulkheads trennen Ressourcenpools, damit ein überlasteter Prozess nicht alle Threads, Datenbankverbindungen oder Worker belegt. Timeouts verhindern endlos wartende Abhängigkeiten. Idempotenz stellt sicher, dass wiederholte Anfragen keine doppelten fachlichen Vorgänge erzeugen.

Für regulierte Prozesse reicht technische Resilienz allein jedoch nicht aus. Auch fachliche Fehlerzustände müssen modelliert werden. Ein eingereichtes Dokument kann „angenommen“, „in Prüfung“, „nicht lesbar“, „nachzureichen“ oder „abgeschlossen“ sein. Ein Zugriff auf Gesundheitsdaten kann „berechtigt“, „nicht berechtigt“, „Authentifizierungsniveau zu niedrig“ oder „Einwilligung fehlt“ sein. Wenn solche Zustände sauber modelliert sind, können Systeme verständliche Rückmeldungen geben, statt nur technische Fehlercodes auszuliefern.

Datenschutz als Architekturtreiber

Die Verarbeitung sensibler Gesundheitsdaten gehört zu den anspruchsvollsten Architekturkontexten. Die TK beschreibt für TK-Safe, dass Gesundheitsdaten besonders schützenswert sind, verschlüsselt gespeichert und übertragen werden und dass weder die TK noch der technische Dienstleister Zugriff auf die Inhalte der elektronischen Patientenakte haben [4]. Für Unternehmen ist daraus eine zentrale Architekturregel ableitbar: Datenschutz darf nicht als Compliance-Schicht am Ende des Projekts verstanden werden. Er muss in Datenmodell, Schnittstellen, Zugriffspfad, Protokollierung, Betrieb und Supportprozesse eingebaut werden.

Ein datenschutzgetriebenes Architekturmodell beginnt mit Datenklassifikation. Unterschiedliche Datenarten benötigen unterschiedliche technische Schutzmaßnahmen. Allgemeine Kontaktdaten, Authentifizierungsdaten, Kommunikationsinhalte, Leistungsdaten, Zahlungsinformationen und Gesundheitsdaten dürfen nicht in einem einheitlichen Sicherheitsmodell behandelt werden. Je sensibler die Daten, desto strenger müssen Zugriffskontrolle, Verschlüsselung, Protokollierung, Zweckbindung und Löschkonzepte sein.

Besonders wichtig ist die Trennung von Identität, Einwilligung und Berechtigung. Identität beantwortet, wer eine Person ist. Einwilligung dokumentiert, welche Nutzung oder Verarbeitung erlaubt wurde. Berechtigung entscheidet, ob eine konkrete Aktion zu einem konkreten Zeitpunkt zulässig ist. Diese drei Ebenen müssen technisch getrennt, aber fachlich verbunden sein. Werden sie vermischt, entstehen Sicherheitslücken oder zu starre Prozesse.

Ein modernes Modell nutzt dafür zentrale Sicherheitsservices:

• Identity Provider: Einheitliche Authentifizierung, starke Identitätsprüfung, Sitzungssteuerung und Unterstützung verschiedener Vertrauensniveaus.
• Authorization Service: Rollenbasierte und attributbasierte Zugriffskontrolle, idealerweise mit kontextbezogenen Regeln.
• Consent Service: Verwaltung, Versionierung und Nachweis von Einwilligungen und Widerrufen.
• Audit Service: Unveränderbare oder manipulationsgeschützte Protokollierung sicherheitsrelevanter Aktionen.
• Key Management: Kontrollierte Verwaltung von Schlüsseln, Zertifikaten und Secrets, getrennt von Anwendungslogik.

Diese Services sollten nicht in jeder Fachanwendung neu implementiert werden. Werden Sicherheitsfunktionen dezentral dupliziert, entstehen abweichende Regeln, schwer prüfbare Sonderfälle und höhere Betriebskosten. Eine zentrale Sicherheitsarchitektur erhöht Konsistenz und beschleunigt neue digitale Angebote, weil diese auf geprüfte Sicherheitsbausteine zurückgreifen können.

Zero-Trust-Prinzipien für regulierte Serviceplattformen

Für sensible Daten reicht ein klassisches Perimeter-Sicherheitsmodell nicht aus. Die Architektur sollte nach Zero-Trust-Prinzipien aufgebaut sein. Das bedeutet: Kein Zugriff ist automatisch vertrauenswürdig, nur weil er aus einem internen Netzwerk oder von einem bekannten System kommt. Jeder Zugriff muss identifiziert, autorisiert, kontextbezogen bewertet und protokolliert werden.

Praktisch bedeutet das kurzlebige Tokens, minimale Berechtigungen, getrennte Service-Identitäten, mTLS für Service-zu-Service-Kommunikation, Secrets-Management, Netzwerksegmentierung, Policy-as-Code und kontinuierliche Überprüfung. Ein Service darf nur die Daten abrufen, die er für seine Aufgabe benötigt. Administratorrechte müssen getrennt, nachvollziehbar und zeitlich begrenzt sein. Test- und Entwicklungsumgebungen dürfen keine produktiven sensiblen Daten enthalten, wenn diese nicht hinreichend anonymisiert oder synthetisch erzeugt wurden.

Gerade in Make-vs.-Buy-Entscheidungen ist diese Sicht entscheidend. Eine Standardlösung ist nur dann tragfähig, wenn sie sich in das Sicherheitsmodell integrieren lässt. Dazu gehören SSO-Anbindung, feingranulare Rechte, Protokollierbarkeit, Verschlüsselung, Datenresidenz, Mandantentrennung, Exportfähigkeit und klare Löschmechanismen. Fehlende Sicherheitsintegration ist kein nebensächliches Implementierungsdetail, sondern ein Architekturdefizit.

Observability als Grundlage für Servicequalität

Bei digitalen Services mit großer Nutzerbasis genügt es nicht, Serververfügbarkeit zu messen. Unternehmen müssen verstehen, ob Nutzerinnen und Nutzer ihre Anliegen erfolgreich erledigen können. Dafür braucht es Observability über technische und fachliche Ebenen hinweg. Logs, Metriken und Traces müssen mit fachlichen Prozessdaten verbunden werden.

Eine belastbare Observability-Architektur beantwortet unter anderem folgende Fragen: Wie viele Logins schlagen fehl? Welche API erzeugt die meisten Timeouts? Welche Fachprozesse bleiben in einem Zwischenstatus hängen? Welche externen Schnittstellen verursachen die höchsten Latenzen? Welche App-Version erzeugt ungewöhnlich viele Fehler? Wie lange dauert die Verarbeitung eines eingereichten Dokuments vom Upload bis zum Abschluss? Ohne diese Transparenz lassen sich Architekturentscheidungen nicht objektiv bewerten.

Technisch sollten alle relevanten Services Korrelations-IDs verwenden, strukturierte Logs erzeugen, Metriken exportieren und verteiltes Tracing unterstützen. Fachliche Ereignisse sollten zusätzlich als Business Events modelliert werden. So wird sichtbar, ob ein System nur technisch erreichbar ist oder ob es tatsächlich die erwartete Servicequalität liefert. Für Unternehmen ist das ein wichtiger Unterschied: Eine Anwendung kann verfügbar sein und trotzdem aus Nutzersicht nicht funktionieren, wenn ein nachgelagerter Prozess blockiert.

API-Governance als verbindendes Architekturprinzip

Je stärker digitale Services wachsen, desto wichtiger wird API-Governance. Ohne klare Schnittstellenregeln entstehen Punkt-zu-Punkt-Integrationen, Schatten-APIs, unklare Datenverantwortung und hohe Änderungskosten. Eine professionelle API-Architektur legt Standards für Versionierung, Authentifizierung, Autorisierung, Fehlercodes, Datenformate, Rate-Limits, Deprecation, Monitoring und Dokumentation fest.

Für Unternehmen mit vielen Fachsystemen ist besonders wichtig, zwischen drei Schnittstellentypen zu unterscheiden. Externe APIs richten sich an Partner, Dienstleister oder öffentliche Kanäle und benötigen besonders starke Verträge und Sicherheitsprüfungen. Interne APIs verbinden eigene Domänen und müssen stabil, versioniert und beobachtbar sein. Event-Schnittstellen transportieren fachliche Ereignisse und eignen sich für Entkopplung, Hintergrundverarbeitung und Benachrichtigungen.

Eine Make-vs.-Buy-Entscheidung sollte deshalb immer prüfen, wie gut eine Lösung in die API-Governance passt. Unterstützt sie offene Schnittstellen? Lassen sich Daten in geeigneter Form exportieren? Gibt es Webhooks oder Event-Mechanismen? Sind APIs versionierbar? Können Berechtigungen granular gesteuert werden? Sind Logs und Traces zugänglich? Eine Lösung, die fachlich attraktiv wirkt, aber architektonisch schlecht integrierbar ist, kann langfristig hohe Komplexitätskosten erzeugen.

Make-vs.-Buy-Bewertung nach Architekturdomänen

Das TK-Beispiel macht deutlich, dass die zentrale Frage nicht lautet, ob Unternehmen grundsätzlich selbst entwickeln oder kaufen sollten. Die bessere Frage lautet: Welche Architekturdomänen müssen strategisch kontrolliert werden und welche Fähigkeiten können als Standardlösung integriert werden? Kritische Kernfähigkeiten sollten unter starker eigener Architekturhoheit bleiben. Unterstützende oder wenig differenzierende Funktionen können dagegen bewusst als Standardlösung beschafft werden.

Eine mögliche Einordnung sieht so aus:

• Hohe Eigenkontrolle: Identität, Berechtigung, Consent, Audit, API-Governance, Datenklassifikation, Integrationsarchitektur, fachliche Kernprozesse und Observability.
• Selektive Eigenentwicklung: Nutzerkanäle, Prozess-Workflows, domänenspezifische Services, Datenprodukte und Partneradapter.
• Standardlösung möglich: generische Collaboration, Helpdesk-Funktionen, Dokumentvorlagen, interne Wissensdatenbanken, Infrastrukturservices und Standard-Monitoring-Komponenten.
• Strenge Prüfung erforderlich: Plattformen, die Kernprozesse, Datenmodelle, Berechtigungen oder Integrationslogik dominieren würden.

Diese Einordnung verhindert zwei Extreme. Das erste Extrem ist eine übermäßige Eigenentwicklung, die Geschwindigkeit reduziert und Standardprobleme unnötig teuer löst. Das zweite Extrem ist eine übermäßige Plattformabhängigkeit, bei der zentrale Daten- und Prozesshoheit an Anbieter ausgelagert wird. Eine reife Architekturstrategie verbindet Standardsoftware mit eigener Architekturkontrolle.

Übertragbare Architekturhypothesen für Unternehmen

Aus dem TK-Beispiel lassen sich mehrere Hypothesen ableiten, die Unternehmen für eigene Architekturentscheidungen prüfen können. Erstens steigen mit der Nutzerzahl nicht nur Performanceanforderungen, sondern auch Anforderungen an Entkopplung, Fehlertoleranz und Betriebssteuerung. Zweitens werden sensible Daten zum zentralen Architekturtreiber, weil sie Zugriffspfade, Datenmodelle, Protokollierung und Betrieb beeinflussen. Drittens ist Modularität ein Mittel zur Risikobegrenzung, nicht nur zur technischen Eleganz. Viertens entscheidet API-Governance darüber, ob eine digitale Landschaft langfristig erweiterbar bleibt. Fünftens muss Make-vs.-Buy auf Domänenebene entschieden werden, nicht pauschal für ganze Programme.

Für Unternehmen bedeutet das: Die Architektur sollte zuerst die kritischen fachlichen Fähigkeiten identifizieren, dann Datenflüsse und Schutzbedarfe modellieren, anschließend Lastprofile und Integrationspunkte bewerten und erst danach konkrete Produkte oder Entwicklungsansätze auswählen. Wer diese Reihenfolge umkehrt, riskiert, dass kurzfristig attraktive Tools langfristig die Architektur dominieren.

Im nächsten Kapitel folgt die operative Übersetzung dieser Prinzipien in konkrete Entscheidungsmetriken für IT-Teams.

Was IT-Teams aus dem TK-Modell für eigene Architekturentscheidungen übernehmen können

Aus dem digitalen Serviceportfolio der Techniker Krankenkasse lässt sich für IT-Teams ein übertragbares Architekturprinzip ableiten: Digitale Kanäle dürfen nicht als isolierte Frontends geplant werden, sondern müssen als Teil einer kontrollierten Plattformarchitektur verstanden werden. Die TK-App, TK-Doc, TK-Safe, Online-Anliegen, digitale Postfachfunktionen und weitere Services zeigen, dass moderne Servicearchitekturen mehrere fachliche Domänen, Sicherheitsniveaus, Datenklassen und Integrationspunkte verbinden müssen [1] [2] [3]. Für IT-Teams bedeutet das: Architekturentscheidungen sollten nicht bei der Auswahl einzelner Tools beginnen, sondern bei der Frage, welche Plattformfähigkeiten langfristig kontrolliert, skaliert und auditierbar betrieben werden müssen.

Gerade bei Organisationen mit vielen digitalen Touchpoints entstehen Architekturprobleme selten durch eine einzelne Anwendung. Kritisch wird es, wenn Identität, Berechtigungen, Schnittstellen, Datenmodelle, Monitoring, Release-Prozesse und Fehlerbehandlung je Produkt unterschiedlich gelöst werden. Dann wächst die technische Landschaft zwar funktional, verliert aber an Steuerbarkeit. Das TK-Beispiel zeigt als öffentlich sichtbares Muster, dass digitale Services nur dann stabil skalieren können, wenn IT-Teams querschnittliche Architekturbausteine früh definieren und konsequent wiederverwenden.

Schnittstellen tief denken statt nachträglich flicken

Die wichtigste Lehre für IT-Teams lautet: Schnittstellen sind kein Implementierungsdetail, sondern ein strategischer Architekturvertrag. Jede API legt fest, welche Daten eine Domäne preisgibt, welche fachlichen Zustände nach außen sichtbar werden, welche Sicherheitsprüfung erforderlich ist und wie stabil andere Systeme darauf aufbauen können. Werden Schnittstellen erst nachträglich um bestehende Systeme herum gebaut, entstehen häufig Punkt-zu-Punkt-Integrationen, doppelte Datenlogik, inkonsistente Fehlercodes, fehlende Versionierung und schwer nachvollziehbare Abhängigkeiten.

Bei digitalen Serviceökosystemen wie App, Portal, Beratung, ePA-Zugriff und Dokumentenprozessen sollten APIs daher von Anfang an als Produktbestandteil geplant werden. Eine API ist nicht nur ein technischer Endpunkt. Sie besitzt einen fachlichen Owner, ein Datenmodell, einen Lebenszyklus, Sicherheitsanforderungen, Service-Level-Ziele, eine Dokumentation und einen klaren Deprecation-Prozess. IT-Teams sollten jede geschäftskritische Schnittstelle so behandeln, als würde sie von externen Partnern genutzt, selbst wenn sie zunächst nur intern verwendet wird. Diese Disziplin verhindert, dass interne APIs zu instabilen Abkürzungen werden.

Eine belastbare API-Strategie umfasst mindestens folgende Elemente:

• Domänenverantwortung: Jede API gehört einer fachlichen Domäne. Die Domäne entscheidet über Datenhoheit, erlaubte Operationen und semantische Bedeutung der Schnittstelle.
• Vertragsorientiertes Design: Schnittstellen werden über OpenAPI, AsyncAPI oder vergleichbare Spezifikationen beschrieben, bevor Konsumenten sie produktiv nutzen.
• Versionierung: Breaking Changes werden vermieden oder über klare Versionierungsregeln gesteuert. Alte Versionen erhalten definierte Laufzeiten und Abschalttermine.
• Fehlersemantik: APIs liefern nicht nur technische Fehlercodes, sondern fachlich verständliche Zustände, etwa fehlende Berechtigung, unvollständige Daten, ungültiger Prozessstatus oder temporär nicht verfügbarer Partnerdienst.
• Security by Default: Authentifizierung, Autorisierung, Rate-Limiting, Payload-Validierung, Transportverschlüsselung und Protokollierung sind Standardanforderungen, keine optionalen Erweiterungen.
• Observability: Jede kritische API erzeugt strukturierte Logs, Metriken und Traces. Korrelations-IDs verbinden Nutzerinteraktionen mit Backend-Prozessen.

Für IT-Teams ist besonders wichtig, synchrone und asynchrone Schnittstellen bewusst zu trennen. Synchrone APIs eignen sich für unmittelbare Nutzerinteraktionen, etwa Login, Statusanzeige oder Berechtigungsprüfung. Asynchrone Events eignen sich für Prozessfortschritte, Dokumentenverarbeitung, Benachrichtigungen und Integrationen, bei denen Antwortzeiten externer Systeme nicht die Nutzererfahrung blockieren dürfen. Wer alles synchron koppelt, baut eine Architektur, in der ein langsames Partnersystem die gesamte Prozesskette ausbremsen kann.

API-Governance als Schutz vor Integrationswildwuchs

In wachsenden IT-Landschaften ist API-Governance die zentrale Gegenmaßnahme gegen Integrationswildwuchs. Ohne verbindliche Standards entstehen viele technisch funktionierende, aber architektonisch problematische Verbindungen. Einzelne Teams optimieren dann lokal, während die Gesamtarchitektur an Transparenz verliert. Das zeigt sich in mehrfach gepflegten Kundendaten, unklaren Datenquellen, fehlender Rückwärtskompatibilität, schwer testbaren Abhängigkeiten und steigenden Kosten für jede Änderung.

Eine praxistaugliche API-Governance muss nicht bürokratisch sein. Sie sollte klare Leitplanken liefern, die Entwicklungsteams schneller und sicherer machen. Dazu gehören wiederverwendbare API-Templates, zentrale Authentifizierungsbausteine, ein API-Katalog, definierte Namenskonventionen, Security-Patterns, Standardfehlerformate und automatisierte Qualitätsprüfungen in der CI/CD-Pipeline. Die Governance wird dadurch nicht zum Freigabehindernis, sondern zur Plattformfähigkeit.

Für stark regulierte Organisationen sollte jede geschäftskritische API zusätzlich nach Schutzbedarf klassifiziert werden. Eine öffentliche Informationsschnittstelle benötigt andere Kontrollen als eine API für Gesundheitsdaten, Identitätsprüfung oder rechtsverbindliche Vorgänge. Diese Klassifikation entscheidet über Authentifizierungsniveau, Autorisierungstiefe, Protokollierung, Verschlüsselung, Aufbewahrung und Testanforderungen. IT-Teams sollten diese Regeln technisch erzwingen, nicht nur in Architekturfolien beschreiben.

Datenflüsse vor Systemgrenzen modellieren

Eine der häufigsten Schwächen in Architekturentscheidungen ist die Orientierung an Systemgrenzen statt an Datenflüssen. Teams fragen dann zuerst, welches System eine Funktion bereitstellt. Fachlich relevanter ist jedoch, welche Daten zwischen welchen Domänen fließen, wer sie erzeugt, wer sie verändern darf, wer sie nur lesen darf und welche Nachweise für Verarbeitung, Einwilligung oder Zugriff erforderlich sind. Gerade bei sensiblen Daten ist diese Perspektive entscheidend.

IT-Teams sollten deshalb für jeden kritischen Prozess ein Datenflussmodell erstellen. Dieses Modell zeigt, welche Daten im Frontend entstehen, welche API sie entgegennimmt, welche Validierungen stattfinden, welche Fachdomäne Datenhoheit besitzt, welche Events ausgelöst werden, welche Systeme Kopien erhalten und welche Logs entstehen. Zusätzlich sollte sichtbar sein, wo personenbezogene oder besonders schützenswerte Daten verarbeitet werden. Erst danach lässt sich seriös entscheiden, ob ein Standardprodukt, eine Eigenentwicklung oder ein hybrider Ansatz geeignet ist.

Ein solches Datenflussmodell beantwortet konkrete Architekturfragen:

• Welche Daten dürfen in welchem Kanal angezeigt werden?
• Welche Daten müssen transaktional konsistent sein?
• Welche Daten dürfen asynchron verarbeitet werden?
• Welche Daten müssen verschlüsselt gespeichert oder übertragen werden?
• Welche Zugriffe müssen auditierbar sein?
• Welche Daten dürfen ein bestimmtes Betriebsumfeld nicht verlassen?
• Welche Kopien sind fachlich notwendig und welche erzeugen nur Risiko?

Diese Transparenz reduziert spätere Integrationskosten erheblich. Sie verhindert, dass ein Produkt eingeführt wird, das zwar funktional passt, aber zentrale Datenflüsse unkontrolliert übernimmt oder nur schwer in bestehende Sicherheits- und Auditprozesse integrierbar ist.

Identität und Berechtigung als wiederverwendbare Plattformservices

Digitale Services mit sensiblen Daten benötigen ein konsistentes Modell für Identität, Authentifizierung, Autorisierung und Einwilligung. Diese Fähigkeiten sollten nicht je Anwendung neu gebaut werden. Wenn jedes Produkt eigene Login-Logik, eigene Rollenmodelle und eigene Berechtigungsprüfungen mitbringt, entstehen Sicherheitslücken und inkonsistente Nutzererfahrungen. Für IT-Teams ist deshalb ein zentraler Identity- und Access-Layer eine der wichtigsten Plattformentscheidungen.

Ein reifes Modell trennt mehrere Ebenen. Authentifizierung klärt, wer eine Person ist. Autorisierung entscheidet, welche Aktion diese Person in einem konkreten Kontext ausführen darf. Consent-Management dokumentiert Einwilligungen, Widerrufe und Zweckbindungen. Session-Management steuert, wie lange ein Zugriff gültig bleibt und wann eine erneute Prüfung erforderlich ist. Audit-Logging dokumentiert sicherheitsrelevante Vorgänge nachvollziehbar. Diese Fähigkeiten sollten als wiederverwendbare Services verfügbar sein.

Für IT-Teams ergibt sich daraus eine klare Make-vs.-Buy-Regel: Anwendungen dürfen Benutzeroberflächen und fachliche Funktionen liefern, sollten aber nicht unkontrolliert zum führenden System für Identität, Berechtigung oder Einwilligung werden. Diese Fähigkeiten sind zu kritisch, um sie in vielen Produktinseln zu verstreuen. Gekaufte Lösungen müssen sich daher in zentrale Identity-Provider, Single-Sign-On, rollenbasierte und attributbasierte Zugriffskontrollen sowie Audit-Systeme integrieren lassen.

Servicequalität als Architekturmetrik

Die TK verweist in ihrem digitalen Angebot auf App-Funktionen, sichere Kommunikation, TK-Doc als digitale medizinische Beratung und TK-Safe als ePA in der TK-App [2] [3]. Für IT-Teams lässt sich daraus ableiten: Servicequalität muss als Architekturmetrik definiert werden, nicht nur als Ergebnis des Betriebs. Ein Service ist nicht ausreichend gut, nur weil Server erreichbar sind. Entscheidend ist, ob Nutzerinnen und Nutzer ihre Anliegen vollständig, sicher und verständlich erledigen können.

Servicequalität sollte deshalb über Service-Level-Objectives, Error Budgets und fachliche Prozessmetriken gesteuert werden. Ein technischer Uptime-Wert reicht nicht aus. Wichtiger sind Fragen wie: Wie viele Logins sind erfolgreich? Wie lange dauert die Anzeige eines geschützten Dokuments? Wie viele Uploads brechen ab? Wie viele Anträge bleiben in Zwischenzuständen hängen? Wie oft scheitert eine externe Integration? Wie schnell erkennen Teams einen Fehler aus Nutzersicht? Diese Metriken übersetzen Architekturqualität in messbare Servicefähigkeit.

Eine gute Servicequalitätsarchitektur kombiniert technische und fachliche Messpunkte:

• Verfügbarkeit: Ist der Service erreichbar und sind kritische Abhängigkeiten funktionsfähig?
• Latenz: Wie schnell reagieren Frontend, API, Fachservice und Datenzugriff?
• Fehlerrate: Welche Fehler entstehen technisch und welche fachlichen Vorgänge scheitern?
• Durchsatz: Wie viele Vorgänge können unter Normal- und Spitzenlast verarbeitet werden?
• Prozessabschluss: Wie viele Nutzerinteraktionen führen tatsächlich zu einem abgeschlossenen Anliegen?
• Wiederherstellbarkeit: Wie schnell kann ein gestörter Service stabil zurückgeführt werden?
• Datenqualität: Sind verarbeitete Daten vollständig, konsistent und fachlich gültig?

Diese Metriken sollten nicht erst nach dem Go-live definiert werden. Sie gehören in Architekturentscheidungen, Produktanforderungen, Testkonzepte und Betriebsübergaben. Ein System, das keine geeigneten Metriken liefert, ist aus Architektursicht unvollständig, auch wenn seine Funktionalität auf den ersten Blick ausreicht.

Observability statt klassischem Monitoring

Klassisches Monitoring beantwortet häufig nur, ob ein Server läuft oder eine Datenbank erreichbar ist. Für moderne digitale Services reicht das nicht. IT-Teams müssen nachvollziehen können, welche Nutzerinteraktion welchen API-Aufruf, welchen Fachprozess, welches Event und welche Datenbankoperation ausgelöst hat. Dafür braucht es Observability mit Logs, Metriken, Traces und fachlichen Ereignissen.

Ein praxistaugliches Observability-Modell beginnt beim Nutzerkanal. Jede relevante Interaktion erhält eine Korrelations-ID, die durch API-Gateway, Backend-Services, Messaging-Systeme und Fachverfahren weitergereicht wird. Dadurch lässt sich ein einzelner Vorgang Ende zu Ende analysieren. Wenn ein Dokumentenupload scheitert, sollte sichtbar sein, ob das Problem im Frontend, in der Authentifizierung, in der Payload-Validierung, im Virenscan, in der Dokumentenklassifikation, im Speicher oder in einem nachgelagerten Fachsystem entstanden ist.

Zusätzlich sollten fachliche Events gemessen werden. Beispiele sind „Anliegen eingereicht“, „Dokument angenommen“, „Berechtigung abgelehnt“, „Einwilligung widerrufen“, „Vorgang an Fachsystem übergeben“ oder „Benachrichtigung zugestellt“. Solche Business Events machen sichtbar, ob ein Service seinen fachlichen Zweck erfüllt. Sie sind für Architekturentscheidungen oft wertvoller als reine CPU- oder Speicherkennzahlen.

Resilienz als Designanforderung für jede kritische Schnittstelle

IT-Teams sollten jede kritische Schnittstelle so planen, als könne ihre Gegenstelle langsam, fehlerhaft oder zeitweise nicht erreichbar sein. Diese Annahme ist kein Pessimismus, sondern Grundlage robuster Architektur. Besonders in Ökosystemen mit externen Diensten, Fachverfahren und Partnerintegrationen ist die Verfügbarkeit des Gesamtsystems nur so stark wie seine Fehlergrenzen.

Technisch sollten Timeouts, Circuit Breaker, Bulkheads, kontrollierte Retries, Backoff-Strategien, Dead-Letter-Queues und idempotente Operationen Standardmuster sein. Fachlich müssen Fehlerzustände verständlich modelliert werden. Ein Nutzer sollte nicht nur eine generische Fehlermeldung erhalten, wenn ein Hintergrundprozess verzögert ist. Besser ist ein fachlicher Status, etwa „eingegangen“, „in Prüfung“, „erneuter Versuch geplant“ oder „Aktion erforderlich“. Dadurch bleibt der Service aus Nutzersicht kontrollierbar, selbst wenn einzelne Systeme temporär gestört sind.

Resilienz muss außerdem getestet werden. Lasttests zeigen nur, wie sich ein System bei hoher Nutzung verhält. Chaos-Tests, Failover-Übungen, Wiederanlauftests und Recovery-Tests zeigen, ob ein System auch unter Störung beherrschbar bleibt. Für regulierte Umgebungen sollten diese Tests dokumentiert und in Betriebsfreigaben einbezogen werden.

Architekturentscheidungen mit Entscheidungsnachweisen absichern

Damit Architektur nicht von Einzelmeinungen abhängt, sollten IT-Teams Architecture Decision Records einsetzen. Jede wichtige Entscheidung wird kurz dokumentiert: Kontext, Problem, Optionen, Entscheidung, Konsequenzen, Risiken und Prüfdatum. Gerade bei Make-vs.-Buy-Fragen hilft diese Disziplin, spätere Diskussionen zu versachlichen. Teams können nachvollziehen, warum eine Lösung gewählt wurde, welche Annahmen galten und wann diese Annahmen erneut überprüft werden müssen.

Für geschäftskritische Plattformbausteine sollten solche Entscheidungen mindestens folgende Kriterien bewerten:

• Fachliche Passung: Deckt die Lösung die benötigten Domänenprozesse ab, ohne zentrale Fachlogik ungünstig zu verzerren?
• Integrationsfähigkeit: Unterstützt die Lösung stabile APIs, Events, Datenexporte und zentrale Identity-Integration?
• Datenschutz: Lassen sich Datenklassifikation, Zweckbindung, Löschung, Verschlüsselung und Auditierung technisch umsetzen?
• Skalierung: Sind Lastprofile, Spitzenlasten, asynchrone Verarbeitung und horizontale Skalierung ausreichend beherrschbar?
• Betrieb: Liefert die Lösung Logs, Metriken, Traces, Health-Checks und klare Betriebsverantwortlichkeiten?
• Exit-Fähigkeit: Können Daten, Konfigurationen, Schnittstellenverträge und Prozesslogik bei Bedarf migriert werden?

Diese Nachweise verhindern, dass Produktentscheidungen allein über Funktionslisten oder Lizenzkosten getroffen werden. Sie machen sichtbar, ob eine Lösung langfristig in die Zielarchitektur passt.

Produktteams und Plattformteams sauber verzahnen

Ein weiteres Learning für IT-Teams betrifft die Organisationsarchitektur. Digitale Services werden schneller, wenn Produktteams eigenständig liefern können. Gleichzeitig darf diese Eigenständigkeit nicht zu isolierten Sicherheits-, Daten- und Integrationsmustern führen. Deshalb benötigen Unternehmen eine klare Trennung und Verzahnung von Produktteams und Plattformteams.

Produktteams verantworten fachliche Nutzerfunktionen, etwa Dokumentenupload, Beratung, Statusanzeige oder digitale Kommunikation. Plattformteams liefern wiederverwendbare Fähigkeiten wie Identity, API-Gateway, CI/CD, Observability, Secrets-Management, Messaging, Consent, Audit und Deployment-Standards. Die Plattform sollte Self-Service ermöglichen, ohne Architekturkontrolle aufzugeben. Gute Plattformarbeit zeigt sich daran, dass Produktteams sichere Standards nutzen, weil diese einfacher sind als Sonderlösungen.

Für CIOs und IT-Leitungen ist diese Struktur besonders relevant. Architekturentscheidungen werden nicht nur über Technologie getroffen, sondern auch über Teamgrenzen, Verantwortlichkeiten und Betriebsmodelle. Ein technisch sauberes Zielbild scheitert, wenn niemand für Schnittstellenqualität, API-Lebenszyklen, Sicherheitsstandards oder Observability verantwortlich ist.

Konkrete Übernahme für eigene Architekturentscheidungen

IT-Teams können aus dem TK-Modell vor allem eine methodische Reihenfolge übernehmen. Zuerst werden digitale Services nach Nutzerkritikalität, Datenklasse und Prozessabhängigkeit eingeordnet. Danach werden Datenflüsse, Schnittstellen und Sicherheitsanforderungen modelliert. Erst anschließend wird entschieden, welche Komponenten gekauft, selbst entwickelt oder als Plattformservice bereitgestellt werden. Diese Reihenfolge schützt vor Toolentscheidungen, die kurzfristig bequem wirken, aber langfristig Architekturhoheit kosten.

Eine operative Leitfrage lautet: Welche Fähigkeiten müssen wir zentral beherrschen, damit viele digitale Services sicher und schnell entstehen können? Typische Antworten sind Identität, Berechtigung, Consent, API-Governance, Observability, Eventing, Audit, Datenklassifikation und resiliente Integrationsmuster. Diese Fähigkeiten sollten nicht projektweise neu entstehen, sondern als belastbare Plattformbausteine geführt werden.

Das folgende Kapitel übersetzt diese Learnings in eine praxisorientierte Checkliste für Make-vs.-Buy-Entscheidungen, Architekturmetriken und technische Bewertungsmodelle.

Die operative Make‑vs.-Buy‑Checkliste für Enterprise‑Architekturentscheidungen

Eigene Bewertungsmetrik: Architektur-Score

Die TK betreut fast 10 Millionen Versicherte und bietet digitale Services wie TK-App und TK-Doc an, die hohe Anforderungen an die IT-Architektur stellen [1]. Für fundierte Make-vs.-Buy-Entscheidungen empfiehlt sich eine Bewertungsmatrix, die zentrale Kriterien systematisch abbildet. Ein Architektur-Score macht Komplexität greifbar und strukturiert die Auswahl zwischen Eigenentwicklung und Standardplattformen.

Der Score sollte mindestens folgende Dimensionen umfassen:

• Nutzerlast und Skalierbarkeit: Wie gut bewältigt die Lösung Lastspitzen und Nutzerwachstum?
• Datenschutz und Compliance: Erfüllt die Architektur branchenspezifische Sicherheitsanforderungen?
• Servicequalität und Verfügbarkeit: Wie zuverlässig sind Verfügbarkeit, Performance und Monitoring integriert?
• Integrationsaufwand: Wie komplex sind Schnittstellen zu bestehenden Systemen und Drittlösungen?

Jede Dimension wird anhand gewichteter Kriterien bewertet und führt zu einem Gesamt-Score, der die Entscheidung objektiv unterstützt. So kann eine Eigenentwicklung bevorzugt werden, wenn Datenschutz und Skalierbarkeit höchste Priorität besitzen, während Standardplattformen bei geringem Integrationsaufwand und schneller Markteinführung punkten.

Diese strukturierte Herangehensweise erleichtert IT-Teams die Priorisierung und reduziert das Risiko von Fehlinvestitionen. Im nächsten Kapitel folgt der übertragbare Blueprint, der zeigt, wie Unternehmen TK-Learnings systematisch anwenden können.

Der übertragbare Blueprint: Wie Unternehmen TK‑Learnings strukturiert anwenden

Blueprint-Schritt 1: Fachliche Abhängigkeiten kartieren

Eine digitalaktive Organisation wie die TK betreibt viele unterschiedliche Services, darunter TK-App, TK-Doc und weitere digitale Gesundheitsangebote [1]. Diese Vielfalt erfordert eine präzise Kartierung fachlicher Abhängigkeiten zwischen Services und zugrunde liegenden IT-Systemen. Nur wenn klar ist, welche Prozesse und Datenflüsse voneinander abhängen, lassen sich Architekturentscheidungen gezielt treffen. Eine strukturierte Visualisierung der Abhängigkeiten, die funktionale Schnittstellen und technische Integrationspunkte abbildet, hilft IT-Teams, Engpässe und kritische Pfade zu identifizieren, die bei Make-vs.-Buy-Entscheidungen besondere Beachtung verdienen.

Blueprint-Schritt 2: Architekturentscheidungen an Servicequalität koppeln

Die TK misst der Servicequalität ihrer digitalen Angebote hohe Bedeutung bei, um Nutzern eine verlässliche und performante Erfahrung zu bieten [1]. Architekturentscheidungen sollten deshalb eng mit definierten Qualitätsmetriken verknüpft werden. Technische Komponenten werden nicht isoliert bewertet, sondern im Kontext ihrer Auswirkung auf Verfügbarkeit, Performance und Monitoring. So lässt sich begründen, wann Eigenentwicklung sinnvoll ist, um spezifische Service-Level zu garantieren, und wann Standardlösungen ausreichen. Diese Kopplung schafft Transparenz und ermöglicht eine zielgerichtete Priorisierung von Investitionen in Architekturbausteine.

Das folgende Kapitel fasst das Modell zu einer Entscheidungsempfehlung für CIOs zusammen.

Was Unternehmen aus dem TK‑Beispiel mitnehmen – und wie sie Architekturentscheidungen beschleunigen

Die TK zeigt, wie ein Großunternehmen mit hoher digitaler Reife eigene IT-Architekturen priorisiert und damit Anforderungen adressiert, die Standardlösungen oft nicht abdecken [1]. Daraus lassen sich Leitlinien ableiten, die Unternehmen bei Make-vs.-Buy-Entscheidungen unterstützen.

Leitlinien für Architekturentscheidungen aus dem TK-Beispiel

Erstens ist eine eigenentwickelte Architektur sinnvoll, wenn Datenschutz, Skalierbarkeit und spezifische Servicequalitäten höchste Priorität besitzen. Diese Priorisierung basiert auf internen TK-Richtlinien, die Eigenentwicklungen empfehlen, wenn Standardlösungen die Anforderungen nicht vollständig erfüllen können, um die Einhaltung gesetzlicher Vorgaben und die Servicequalität sicherzustellen. Zweitens ist eine präzise Kartierung fachlicher Abhängigkeiten essenziell, um Architekturentscheidungen zielgerichtet zu treffen. Drittens sollten technische Komponenten immer im Kontext der Servicequalität bewertet werden, um Fehlinvestitionen zu vermeiden. Diese Leitlinien bilden ein Hypothesenmodell, das Unternehmen als Orientierung dienen kann.

Entscheidungsprozesse beschleunigen mit der Checkliste

Für die praktische Umsetzung empfiehlt sich eine strukturierte Make-vs.-Buy-Checkliste, die alle relevanten Kriterien systematisch abbildet. Sie hilft IT-Teams, komplexe Anforderungen transparent zu bewerten und Entscheidungen nachvollziehbar zu dokumentieren. So reduzieren Unternehmen die Entscheidungsdauer und erhöhen die Qualität der Architekturwahl. Die Checkliste sollte dynamisch bleiben und regelmäßig an veränderte Geschäftsanforderungen angepasst werden.

Weiterführende Ressourcen für IT-Entscheider

IT-Teams, die ihre Architekturplanung vertiefen wollen, finden in der Softwarearchitektur-Planung und Cloud-Strategie wertvolle Ergänzungen, um Make-vs.-Buy-Entscheidungen fundiert zu treffen. Die TK zeigt, wie digitale Transformation und eigene Architekturen Hand in Hand gehen – ein Modell, das branchenübergreifend adaptiert werden kann. Nutzen Sie die bereitgestellten Leitfäden, um Ihre Architekturentscheidungen zielgerichtet, schnell und sicher zu gestalten.

Für weiterführende Informationen empfehlen wir den Artikel Der ultimative Guide zur Softwareauswahl sowie zur Cloud-Strategie Cloud-Entscheidungen für Unternehmen.