Thema 4.0 — Technische Architektur, Cloud und Altsysteme

In Gesundheit und Pflege ist technische Architektur eine Entscheidung über klinische Sicherheit, Sicherheit und öffentliches Geld, die Jahre im Voraus getroffen wird: Die Plattformen, die Sie aufsetzen, und die Altlasten, die Sie bestehen lassen, entscheiden still darüber, ob Versorgung sicher, verzahnt und bezahlbar sein kann – lange nachdem die Menschen, die sie gewählt haben, weitergezogen sind.

Warum das in Gesundheit und Pflege wichtig ist#

Architektur ist die Menge langlebiger struktureller Entscheidungen unter Ihren digitalen Services: was wo läuft, wie Komponenten verbunden sind, was Sie bauen versus kaufen und was Sie aus der Vergangenheit am Leben halten. Diese Entscheidungen sind für Patientinnen, Patienten und Klinikpersonal selten sichtbar und für Vorstände selten aufregend. Doch sie prägen alles, was darauf sitzt. Eine gut architekturierte Landschaft lässt Sie schnell einen neuen Service hinzufügen, Daten sicher teilen und sich schnell erholen, wenn etwas bricht. Eine schlecht architekturierte macht jede Änderung langsam, jede Integration brüchig und jeden Vorfall schlimmer.

In Gesundheit und Pflege ist der Einsatz hoch, weil die Systeme folgenreich sind. Wenn ein alterndes Patientenverwaltungssystem umfällt, werden Rettungswagen umgeleitet und Kliniken abgesagt. Wenn ein nicht unterstütztes Betriebssystem ausgenutzt wird, werden vertrauliche Akten offengelegt und Services stehen still – wie der NHS 2017 lernte, als sich der WannaCry-Ransomware-Angriff über Rechner ausbreitete, die Software liefen, die sich nicht mehr patchen ließ. Diese Störung war kein raffinierter, gezielter Angriff; sie war die vorhersehbare Folge angesammelter technischer Schulden in kritischen Systemen. Architekturentscheidungen sind daher Sicherheitsentscheidungen, ob es jemand so rahmt oder nicht.

Sie sind auch Gerechtigkeits- und Vertrauensentscheidungen. Altsysteme, die keine Daten teilen können, hinterlassen die komplexesten Patientinnen und Patienten – jene, die viele Services berühren – mit den fragmentiertesten Akten. Geschlossene Plattformen, die Sie an einen einzigen Lieferanten binden, entziehen Geld, das Versorgung finanzieren könnte. Und die Öffentlichkeit erwartet zu Recht, dass der NHS auf moderner, sicherer, gut gewarteter Technologie läuft; die Lücke zwischen dieser Erwartung und dem tatsächlichen Bestand ist selbst ein Risiko für das Vertrauen.

Schließlich werden hier sehr lange sehr viele öffentliche Gelder gebunden. Der teuerste Teil eines Systems ist selten sein Kauf; es ist das Jahrzehnt aus Hosting, Lizenzierung, Wartung und schließlichem Ersatz, das folgt. Führungskräfte, die Architektur als „etwas, um das sich das technische Team kümmert“ behandeln, delegieren einige der größten und langlebigsten finanziellen Verpflichtungen, die die Organisation eingeht. Dieses Thema ist so geschrieben, dass Sie diese Entscheidungen zur Rechenschaft ziehen können, ohne Ingenieur zu sein.

Kernkonzepte#

Unternehmensarchitektur (Enterprise Architecture) ist die Disziplin, Geschäftsprozesse, Informationen, Anwendungen und Technologie einer Organisation so aufeinander abzustimmen, dass sie Strategie kohärent unterstützen, statt zufällig zu wachsen. Sie nimmt die Sicht der ganzen Organisation ein: welche Fähigkeiten Sie brauchen, welche Systeme sie liefern und wo die Lücken und Duplizierungen liegen. Lösungsarchitektur (Solution Architecture) ist die engere Disziplin auf Projektebene, zu entwerfen, wie ein bestimmter Service gebaut und in die weitere Landschaft eingepasst wird. Beide liegen innerhalb der breiteren Idee der Systemarchitektur – des strukturellen Modells, wie Komponenten, Schnittstellen und Verhalten sich zu einem funktionierenden Ganzen verbinden. Führungskräfte müssen diese Disziplinen nicht selbst ausüben, sollten aber darauf bestehen, dass sie existieren, denn ihr Fehlen ist, wie Landschaften unbeherrschbar werden.

Architektur wird von Architekturprinzipien geleitet: einer kurzen, vereinbarten Menge von Aussagen – etwa „Wiederverwenden vor Kaufen, Kaufen vor Bauen“ oder „nach offenen Standards bauen“ –, die konsistente Entscheidungen ermöglichen, ohne dass jede Wahl eskaliert werden muss. Prinzipien werden leicht von einer Design Authority durchgesetzt: einer kleinen Gruppe, die wesentliche technische Entscheidungen prüft. Die gesunde Version einer Design Authority ermöglicht, statt zu blockieren; sie existiert, um vermeidbaren Schaden und Duplizierung zu verhindern, nicht um Teams zu bremsen oder um ihrer selbst willen Torwächter zu spielen.

Cloud Computing ist die Bereitstellung von Rechenleistung – Server, Speicher, Datenbanken, Netzwerk – als bedarfsgerechter Service über das Internet, statt von Hardware, die Ihnen im eigenen Gebäude gehört. Eine öffentliche Cloud wird von einem Drittanbieter betrieben und unter vielen Kunden geteilt; eine private Cloud ist einer Organisation gewidmet; eine Hybrid-Cloud kombiniert beide und hält oft manche Workloads auf bestehender Infrastruktur, während andere ausgelagert werden. Viele Regierungen, darunter die des Vereinigten Königreichs, haben eine „Cloud-first“-Politik übernommen, das heißt, Teams sollen öffentliche Cloud vor anderen Optionen erwägen und rechtfertigen, sie nicht zu nutzen. Weil Cloud nach Verbrauch statt einmalig gekauft abgerechnet wird, ist die Kontrolle dieser Ausgaben zu einer eigenen Disziplin geworden – FinOps, die Praxis, Engineering und Finanzen zusammenzubringen, damit Teams Sicht auf und Verantwortung für das haben, was ihre Cloud-Nutzung tatsächlich kostet. Auf der Anwendungsebene liefert Software as a Service (SaaS) eine fertige Anwendung über das Web, die der Lieferant hostet und wartet, sodass Sie sie konfigurieren statt betreiben. Infrastruktur und Hosting – wo und wie Ihre Systeme physisch laufen – liegen unter all dem und tragen zunehmend Kohlenstoffkosten, die in die Entscheidung gehören (siehe Thema 8.5 — Nachhaltigkeit und Netto-Null).

Ein Altsystem (Legacy System) ist ein alterndes, aber weiter benötigtes System, das schwer zu ändern ist und oft nicht unterstützte Software betreibt, für die keine Sicherheitspatches mehr ausgegeben werden. Altlasten sammeln sich als technische Schuld an – die künftigen Kosten zweckmäßiger Entscheidungen der Vergangenheit. Etwas Schuld ist normal und sogar sinnvoll; ungesteuerte Schuld im großen Maßstab wird zur Sicherheits- und Security-Haftung, weil die Systeme, von denen die meisten abhängen, zu den Systemen werden, die niemand anzufassen wagt. Das zu steuern ist die Aufgabe des Anwendungsportfoliomanagements (Application Portfolio Management): ein klares Inventar jeder Anwendung, ihrer Kosten, ihres Zustands und ihres Geschäftswerts zu führen, damit Sie die Landschaft rationalisieren können – Systeme stilllegen, ersetzen oder konsolidieren – und sicher außer Betrieb nehmen, statt das Alte still weiterlaufen zu lassen.

Moderne Landschaften werden von Anwendungsprogrammierschnittstellen (APIs) zusammengehalten: definierten Schnittstellen, über die ein System einem anderen eine Fähigkeit anbietet. Gut gestaltete APIs lassen Sie Plattformen zusammensetzen – wiederverwendbare Services, auf denen viele Teams aufbauen – und halten Komponenten lose gekoppelt und austauschbar. Eine nützliche Disziplin hierbei ist die „dünnste tragfähige Plattform“: Bauen Sie nur die gemeinsame Fähigkeit, die die Arbeit anderer wirklich verringert, und nicht mehr. Dem sicheren Design liegt Secure by Design zugrunde, das Prinzip, dass Sicherheit von Anfang an eingebaut statt nachträglich angeflanscht wird. Und der finanzielle Rahmen für all das sind die Gesamtbetriebskosten (Total Cost of Ownership, TCO): die vollen Lebenszeitkosten eines Systems, nicht sein Kaufpreis – die Linse, durch die die Wahl zwischen Bauen/Kaufen/Konfigurieren und das Risiko von Vendor Lock-in beurteilt werden sollten.

Bewährte Praktiken#

1. Vereinbaren Sie eine kurze Menge an Architekturprinzipien und nutzen Sie sie zum Entscheiden. Schreiben Sie eine Handvoll klarer, einprägsamer Prinzipien nieder – Wiederverwenden vor Kaufen vor Bauen, nach offenen Standards bauen, Cloud, wo sinnvoll, Secure by Design, für den ganzen Versorgungspfad gestalten – und lassen Sie Teams die meisten Entscheidungen selbst treffen, indem sie sie anwenden. Prinzipien funktionieren nur, wenn sie tatsächlich dazu genutzt werden, Ja und Nein zu sagen, und nur, wenn es wenige genug sind, um sie sich zu merken. Das hängt direkt mit Thema 1.1 — Das Betriebsmodell und Thema 1.2 — Digitalstrategie und Roadmapping zusammen, die die Richtung vorgeben, der die Prinzipien dienen.

2. Betreiben Sie eine Design Authority, die ermöglicht statt blockiert. Richten Sie eine kleine, erfahrene, funktionsübergreifende Gruppe ein, die wesentliche technische Entscheidungen prüft – jene, die teuer, schwer umkehrbar sind, viele Services betreffen oder Sicherheits- und Security-Risiko tragen. Geben Sie ihr einen schnellen, schlanken Weg, damit Routinewahlen nicht hindurchgeschleift werden, und messen Sie sie an einem Servicestandard: Sie sollte Teams helfen, eine gute Antwort zu finden, nicht einfach ablehnen. Eine Design Authority, die zum Engpass wird, wird umgangen, und Schattenarchitektur ist schlimmer als keine.

3. Übernehmen Sie Cloud bewusst, Workload für Workload, nicht als Parole. Behandeln Sie „Cloud-first“ als Voreinstellung, über die nachzudenken ist, nicht als Anweisung, alles zu verlagern. Bewerten Sie jeden Workload auf Eignung, Datenresidenz, Resilienz, Kosten im großen Maßstab und den Migrationsaufwand und seien Sie ehrlich, dass Lift-and-Shift einer unveränderten Altanwendung das Problem oft nur zu höheren Kosten verlagert. Wägen Sie die Kohlenstoffdimension ausdrücklich ab, da sich Ort und Art des Hostings auf Emissionen auswirken (siehe Thema 8.5 — Nachhaltigkeit und Netto-Null), und gestalten Sie für Portabilität, damit ein künftiger Wechsel zwischen Anbietern möglich bleibt.

4. Pflegen Sie ein lebendiges Anwendungsportfolio und steuern Sie technische Schuld als benanntes Risiko. Führen Sie ein genaues Inventar jeder Anwendung, ihrer fachlichen Verantwortlichen, Kosten, Unterstützbarkeit und des Risikos, das sie trägt, und prüfen Sie es regelmäßig. Nehmen Sie technische Schuld und nicht unterstützte Software mit demselben Ernst wie klinisches oder finanzielles Risiko in das Unternehmensrisikoregister auf, denn das ist, was sie ist. Was Sie nicht sehen können, können Sie nicht finanzieren, priorisieren oder sicher stilllegen, und Landschaften, die nie inventarisiert werden, sind genau die, die ohne Vorwarnung versagen.

5. Rationalisieren Sie die Landschaft und nehmen Sie sicher außer Betrieb. Legen Sie duplizierte, veraltete und am Lebensende stehende Systeme aktiv still, statt sie „für alle Fälle“ weiterlaufen zu lassen, denn jedes Live-System ist eine Angriffsfläche, ein Lizenzkostenposten und eine Wartungslast. Außerbetriebnahme ist ein eigenes Projekt: Daten unter klaren Aufbewahrungsregeln migrieren oder archivieren, bestätigen, dass nichts mehr von dem System abhängt, Nutzende informieren und verifizieren, bevor Sie abschalten. Gut gemacht, setzt Rationalisierung Geld frei und senkt Risiko; nachlässig gemacht, zerstört sie Akten oder bricht eine Abhängigkeit, die niemand dokumentiert hat.

6. Bevorzugen Sie offene Standards, APIs und lose gekoppelte Komponenten. Gestalten Sie so, dass Fähigkeiten über dokumentierte, versionierte APIs bereitgestellt werden, damit eine Komponente ersetzt werden kann, ohne alles darum herum neu zu bauen. Das ist das architektonische Fundament der in Thema 4.3 — Interoperabilität und Datenstandards besprochenen Interoperabilität und Ihre wichtigste Verteidigung gegen Lock-in. Es kostet vorab etwas mehr als eine direkte, festverdrahtete Verbindung und zahlt sich vielfach aus, wenn Sie erstmals einen Lieferanten wechseln oder einen Service hinzufügen müssen.

7. Bauen Sie die dünnste tragfähige Plattform und nicht mehr. Wenn Sie eine gemeinsame Plattform für andere zum Aufbauen schaffen, widerstehen Sie dem Drang, sie von Tag eins an umfassend zu machen. Bieten Sie die kleinste wiederverwendbare Fähigkeit, die Teams wirklich Arbeit abnimmt, beweisen Sie, dass sie genutzt wird, und lassen Sie sie als Antwort auf realen Bedarf wachsen. Überbaute Plattformen werden zu ihrem eigenen Altsystem – teuer, starr und übelgenommen –, während eine dünne, gut betriebene Plattform Annahme verdient und sich mit dem Bedarf entwickelt.

8. Machen Sie Sicherheitsarchitektur und Secure by Design nicht verhandelbar. Bringen Sie Sicherheitsdenken von der ersten Skizze an in das Design, nicht als Tor vor dem Start: Minimieren Sie die Angriffsfläche, wenden Sie geringste Rechte an, segmentieren Sie Netzwerke und nehmen Sie an, dass Komponenten abgetastet werden. In Gesundheit und Pflege ist das untrennbar von klinischer Sicherheit und Informationsgovernance (Thema 1.6 — Klinische Sicherheit und Risikomanagement; Thema 1.7 — Informationsgovernance, Datenschutz und Cybersicherheit), denn eine Panne ist sowohl ein Datenschaden als auch, wenn sie Systeme stoppt, ein Ereignis der Patientensicherheit. Nicht unterstützte, nicht patchbare Software ist eine Sicherheitsentscheidung, die Sie per Voreinstellung treffen – treffen Sie sie also bewusst, mit Milderungen, oder gar nicht.

9. Entscheiden Sie Bauen, Kaufen oder Konfigurieren nach Gesamtbetriebskosten, nicht nach Listenpreis. Vergleichen Sie für jede Fähigkeit Maßanfertigung, Produktkauf und Konfiguration einer bestehenden Plattform nach ihren vollen Lebenszeitkosten – Hosting, Lizenzierung, Integration, Support, Upgrades und schließlicher Ausstieg –, nicht nach dem Anfangspreis. Bevorzugen Sie Kaufen oder Konfigurieren für Standardbedarf und reservieren Sie Bauen für echte Differenzierung und wägen Sie den Lock-in ab, den jede Option erzeugt. Arbeiten Sie das mit kommerziellen Kolleginnen und Kollegen durch (Thema 6.3 — Beschaffung und Vertragsgestaltung), denn die billigste Zeit, offene Schnittstellen und Ausstiegsrechte zu sichern, ist vor der Unterschrift.

10. Behandeln Sie Cloud-Ausgaben als gemeinsame Disziplin von Engineering und Finanzen (FinOps). Geben Sie Teams klare Sicht darauf, was ihre Services kosten, indem Sie Cloud-Ressourcen ihren Verantwortlichen zuordnen (Tagging), Instanzen an der realen Nutzung ausrichten und ungenutzte oder überprovisionierte Ressourcen abschalten, statt Monat für Monat dafür zu zahlen. Machen Sie die Teams, die einen Service betreiben, für seine Betriebskosten rechenschaftspflichtig, damit die Menschen, die Verschwendung am besten verringern können, die sind, die die Rechnung sehen. Pay-as-you-go-Cloud ohne diese Disziplin verbraucht still Budget, das Versorgung finanzieren sollte, und die Drift wird selten bemerkt, bis eine Rechnung die Frage erzwingt.

11. Architekturieren Sie Kosten als erstklassige nichtfunktionale Anforderung, abgewogen gegen Kohlenstoff und Resilienz. Behandeln Sie Kosten, wie Sie Leistung, Sicherheit und Verfügbarkeit behandeln: eine Eigenschaft, für die Sie bewusst gestalten, vor dem Bau schätzen und mit wachsender Nutzung überprüfen. Wägen Sie sie ausdrücklich gegen Kohlenstoff (siehe Thema 8.5 — Nachhaltigkeit und Netto-Null) und gegen Resilienz ab, denn die drei bewegen sich oft gemeinsam – doch jagen Sie nie der niedrigsten Rechnung auf Kosten von Sicherheit, Wiederherstellbarkeit oder Patientenergebnissen nach. Die richtige Antwort sind die niedrigsten Kosten, die Ihre Pflichten zu klinischer Sicherheit und Resilienz noch erfüllen, nicht die billigste Option isoliert.

Fragen zur Diskussion im Team#

1. Welche unserer kritischen Systeme sind heute nicht unterstützt oder nicht patchbar, und wie groß ist unsere tatsächliche Exposition, wenn eines angegriffen wird oder ausfällt? Beginnen Sie bei den Systemen, ohne die klinische und operative Services wirklich nicht funktionieren können, und stellen Sie konkret fest, welche Software betreiben, die keine Sicherheitsupdates oder Herstellerunterstützung mehr erhält. Fragen Sie, was geschähe – mit Patientinnen und Patienten, mit Personal, mit Daten –, wenn jedes von Ransomware getroffen würde oder schlicht stoppte, und wie lange die Wiederherstellung dauerte. Unterscheiden Sie Systeme, bei denen Sie bewusst Risiko akzeptiert haben, mit vorhandenen Milderungen, von jenen, deren Fragilität niemand bewertet hat. Überlegen Sie, ob diese Exposition im Unternehmensrisikoregister sichtbar ist oder in einer Tabelle vergraben, die kein Vorstand gesehen hat. Denken Sie an WannaCry: Der Schaden kam nicht von Raffinesse, sondern von bekannter, unbehandelter Schuld in kritischen Systemen. Können Sie dies nicht mit Evidenz beantworten, ist diese Lücke selbst Ihr dringendster Befund, denn Sie können kein Risiko finanzieren, das Sie nicht benannt haben.

2. Wo sind wir gebunden, und was würde es uns wirklich kosten, unsere größte Plattform zu verlassen? Viele Organisationen entdecken den wahren Preis eines geschlossenen Systems erst, wenn sie versuchen, es zu ändern. Gehen Sie durch, was es tatsächlich bräuchte, Ihre größte klinische oder Unternehmensplattform zu verlassen: ob Sie Ihre Daten in nutzbarer, Standardform herausziehen können, welche proprietären Schnittstellen entwirrt werden müssten und was Ihr Vertrag zu Eigentum und Ausstieg sagt. Überlegen Sie, ob „Cloud“ still zu einem Lock-in anderer Art geworden ist, mit Daten und Werkzeugen so in einem Anbieter verflochten, dass das Verlassen unpraktikabel ist. Wägen Sie das gegen die Offenheit von Alternativen und jede nationale Plattform ab, die Sie stattdessen wiederverwenden könnten. Das ist kein Plädoyer für ständigen Lieferantenwechsel; es geht darum, Ihren Hebel zu verstehen, bevor Sie das nächste Mal verhandeln, und nicht zuzulassen, dass die Roadmap eines Lieferanten still Ihre einzige Option wird.

3. Investieren wir genug in Pflege und Rationalisierung dessen, was wir schon haben, oder nur in das Neue und Sichtbare? Neue Systeme ziehen Finanzierung und Aufmerksamkeit an; die unglamouröse Arbeit von Patchen, Upgraden, Konsolidieren und sicherem Stilllegen selten, und genau so sammelt sich Schuld an. Fragen Sie, welcher Anteil Ihres Digitalbudgets tatsächlich dafür aufgewendet wird, den bestehenden Bestand sicher und aktuell zu halten, gegenüber dem Bauen neuer Dinge, und ob jemand diese Balance bewusst verantwortet. Besprechen Sie, ob Außerbetriebnahme je ordentlich ausgestattet ist oder alte Systeme einfach fortbestehen, weil das Abschalten niemandes Aufgabe ist. Bedenken Sie die duplizierten Anwendungen, die in der Organisation dasselbe tun, und was es bräuchte, sie zu konsolidieren. Überlegen Sie, wer auf Vorstandsebene für die Gesundheit der Landschaft als Ganzes statt für einzelne Projekte rechenschaftspflichtig ist. Eine Organisation, die nur das Neue finanziert, leiht sich gegen ihre eigene künftige Sicherheit, und die Rückzahlung wird immer im schlechtestmöglichen Moment fällig.

4. Wissen wir tatsächlich, was unsere Cloud kostet, wer diese Rechnung verantwortet und ob die Ausgaben unter Kontrolle sind? Pay-as-you-go-Cloud kann still Budget verbrauchen, das Versorgung finanzieren sollte, und die Drift wird selten bemerkt, bis eine Rechnung die Frage erzwingt. Fragen Sie, ob Cloud-Ressourcen den Teams und Services zugeordnet sind, denen sie gehören, ob jemand Instanzen an der realen Nutzung ausrichtet und ob ungenutzte oder überprovisionierte Ressourcen je abgeschaltet werden. Besprechen Sie, ob die Menschen, die einen Service betreiben, seine Betriebskosten sehen und dafür einstehen, oder ob Cloud-Ausgaben als eine einzige unerklärte Zeile in einem zentralen Budget landen, die niemand zerlegen kann. Überlegen Sie, ob Kosten als erstklassige nichtfunktionale Anforderung behandelt werden – vor dem Bau geschätzt und mit wachsender Nutzung überprüft – oder erst im Nachhinein entdeckt werden. Seien Sie ehrlich zur Spannung zwischen Autonomie des Engineerings und finanzieller Kontrolle und dazu, Kosten gegen Kohlenstoff und Resilienz abzuwägen, statt einfach der niedrigsten Rechnung nachzujagen. Eine ehrliche Antwort benennt, wer die FinOps-Disziplin hält, und zeigt die Evidenz, dass sie funktioniert, statt anzunehmen, die Cloud sei billiger, weil sie modern ist.

5. Wenn wir eine neue Fähigkeit brauchen, wie entscheiden wir zwischen Bauen, Kaufen und Konfigurieren von etwas, das wir schon haben – und auf welcher Grundlage? Der Instinkt, maßgeschneidert zu bauen oder das Produkt mit der besten Demo zu kaufen, gewinnt oft, bevor jemand die vollen Lebenszeitkosten verglichen hat. Gehen Sie durch, wie Ihre letzten wesentlichen Wahlen tatsächlich getroffen wurden: ob Hosting, Lizenzierung, Integration, Support, Upgrades und schließlicher Ausstieg abgewogen wurden oder nur der Anfangspreis. Fragen Sie, ob Sie Bauen für echte Differenzierung reservieren und für Standardbedarf standardmäßig kaufen oder konfigurieren, oder ob sich Eigenbauten still vermehren, weil ein Team sie bevorzugte. Überlegen Sie, wer bei diesen Entscheidungen im Raum ist – kommerzielle und klinische Kolleginnen und Kollegen ebenso wie Ingenieure – und ob der Lock-in, den jede Option erzeugt, vor der Unterschrift bewertet statt später entdeckt wird. Bedenken Sie, ob Ihre Architekturprinzipien („Wiederverwenden vor Kaufen, Kaufen vor Bauen“) diese Wahlen wirklich binden oder still ignoriert werden. Eine ehrliche Antwort kann auf reale Entscheidungen verweisen, in denen die Gesamtbetriebskosten, nicht der Listenpreis, das Ergebnis veränderten.

6. Haben wir die interne Architekturfähigkeit, unsere eigenen Entscheidungen zu halten, oder hängen wir von den Lieferanten ab, die wir zur Rechenschaft ziehen sollen? Architektur ist der Ort, an dem die größten und langlebigsten Verpflichtungen eingegangen werden, doch viele Organisationen haben gerade die Fähigkeit ausgehöhlt, die man braucht, sie gut zu treffen, und verlassen sich auf die Anbieter, deren Produkte bewertet werden, dass sie ihnen sagen, wie Gutes aussieht. Fragen Sie, ob Sie glaubwürdige Fähigkeit in Unternehmens- und Lösungsarchitektur auf Ihrer eigenen Seite haben und ob Ihre Design Authority besetzt ist, Teams zu befähigen, oder nur abzustempeln. Besprechen Sie, ob wesentliche, schwer umkehrbare Entscheidungen wirklich an vereinbarten Prinzipien getestet oder faktisch an den Lieferanten delegiert werden, der dem Problem am nächsten ist. Überlegen Sie, wie Sie eine schlechte Architekturempfehlung überhaupt erkennen würden, hätten Sie keine unabhängige Expertise, sie anzufechten. Wägen Sie die Kosten, diese Fähigkeit aufzubauen und zu halten, gegen die weit größeren Kosten von Lock-in und Nacharbeit ab, die ihr Fehlen erzeugt. Eine ehrliche Antwort unterscheidet die Entscheidungen, die Sie wirklich verantworten können, von jenen, die Sie derzeit auf Vertrauen hinnehmen.

In der Praxis: ein Beispiel aus Gesundheit und Pflege#

Die technische Landschaft eines akuten Krankenhaus-Trusts ist zwei Jahrzehnte lang organisch gewachsen. In ihrem Herzen sitzt ein Patientenverwaltungssystem auf einem Betriebssystem, dessen Unterstützung der Hersteller vor achtzehn Monaten eingestellt hat; darum herum sind mehr als zweihundert Anwendungen, viele abteilungsweise gekauft, mehrere mit überlappenden Aufgaben, und niemand hält eine vollständige Liste. Ein Beinahe-Vorfall – ein Ransomware-Versuch, der eher durch Glück als durch Design abgewehrt wurde – veranlasst den Vorstand, eine Frage zu stellen, die er nie zuvor gestellt hat: Was genau betreiben wir, und wie exponiert sind wir?

Der Chief Digital Information Officer widersteht dem Instinkt, ein einziges, heroisches „alles ersetzen“-Programm zu starten, und leistet zuerst die langweilige Arbeit. Der Trust baut ein lebendiges Anwendungsportfolio: jedes System, seine fachliche Verantwortliche, seine Unterstützbarkeit, seine Kosten und sein Risiko. Das Bild ist ernüchternd – ein Fünftel der Anwendungen läuft auf nicht unterstützter Software, und ein Dutzend dupliziert Fähigkeiten, die anderswo bereits verfügbar sind –, aber erstmals ist es sichtbar, und die schlimmsten Expositionen gehen direkt auf das Unternehmensrisikoregister, wo der Vorstand sie sehen kann.

Aus diesem Inventar trifft der Trust bewusste Entscheidungen, geleitet von einer Handvoll vereinbarter Architekturprinzipien. Das nicht unterstützte Patientenverwaltungssystem wird zum Ersatz priorisiert, als konfigurierbares Produkt mit vertraglichen Rechten auf offene APIs und Datenextraktion beschafft, damit der Trust nicht erneut gebunden ist. Geeignete Workloads wandern in die öffentliche Cloud, einzeln bewertet statt per Parole, wobei Kohlenstoff und Portabilität neben den Kosten abgewogen werden. Eine kleine Design Authority prüft die wesentlichen Entscheidungen und gibt die routinemäßigen schnell frei. Zwölf überlappende Abteilungsanwendungen werden auf drei konsolidiert, und die stillgelegten Systeme werden ordentlich außer Betrieb genommen – Daten unter klaren Aufbewahrungsregeln migriert, Abhängigkeiten geprüft, Nutzende informiert und erst dann abgeschaltet.

Nichts davon macht Schlagzeilen. Doch achtzehn Monate später weiß der Trust, was er betreibt, seine gefährlichste Schuld wird nach einem finanzierten Plan abgebaut, statt weggehofft zu werden, und eine neue Integration der gemeinsamen Patientenakte ist in Wochen geliefert, weil die Ersatzsysteme offene APIs bereitstellen. Der Beinahe-Vorfall wurde zu dem Moment, in dem der Trust begann, seine Architektur zu steuern, statt von ihr gesteuert zu werden.

Sektorperspektiven#

Startup#

Ein Startup der digitalen Gesundheit hat den Luxus wenig Altlasten und sollte sie erbittert schützen. Bauen Sie von Anfang an Cloud-nativ, stellen Sie offene APIs bereit und behandeln Sie Secure by Design als Kernmerkmal statt späterer Kosten, denn vorsichtige NHS-Käufer werden Ihre Sicherheitsarchitektur und Datenextraktionsbedingungen genau prüfen. Halten Sie Ihre eigene dünnste tragfähige Plattform wirklich dünn und widerstehen Sie der Versuchung, für Skalierung überzukonstruieren, die Sie noch nicht haben. Ihr schnellster Weg, lähmende technische Schuld anzuhäufen, ist, unter Investorendruck zweckmäßigen Code auszuliefern und nie zurückzuzahlen; treffen Sie daher bewusste, sichtbare Entscheidungen, welche Schuld Sie eingehen. Paradoxerweise ist es das Gestalten, damit ein Kunde seine Daten herausziehen und gehen könnte, was das Vertrauen verdient, das ihn hält.

Kleines Unternehmen#

Ein etablierter kleiner Anbieter – eine Hausarztpraxis, eine Gemeindeapotheke, ein Pflegeheim, eine Einzelstandort-Klinik oder ein kleiner Health-Tech-Lieferant jenseits der Startup-Phase – trägt dieselben Pflichten wie ein großer Trust, aber mit einem Bruchteil der Ressourcen und selten mit eigener IT-Kapazität. Architektur ist hier überwiegend die Disziplin, gut zu kaufen: Bevorzugen Sie seriöses Software as a Service, damit der Lieferant Hosting, Patching und Sicherheit trägt, die Sie nicht besetzen können, und lesen Sie den Vertrag auf Datenextraktions- und Ausstiegsrechte, bevor Sie unterschreiben, denn Lock-in beißt am härtesten, wenn Sie keinen Hebel haben. Führen Sie ein einfaches Inventar der Handvoll Systeme, von denen Sie abhängen, und wissen Sie, welche noch unterstützt sind, denn selbst eine kleine Landschaft kann einen ungepatchten Rechner verbergen, der die Praxis stoppt. Bestehen Sie darauf, dass Lieferanten anerkannte Standards wie das Data Security and Protection Toolkit erfüllen, statt zu versuchen, Sicherheit von Grund auf zu bewerten. Bei knappem Geld ist die Versuchung, ein altes, nicht unterstütztes System weiterlaufen zu lassen, um eine Rechnung zu vermeiden, doch das ist eine Sicherheitsentscheidung, die Sie bewusst treffen sollten, nicht per Drift.

Großunternehmen#

Ein großer Trust oder Lieferant trägt Jahrzehnte angesammelter Systeme und kann nicht einfach neu beginnen. Die realistische Strategie ist diszipliniertes Weiterentwickeln: ein lebendiges Portfolio pflegen, offene, API-basierte Schichten vor das legen, was bleiben muss, und die gefährlichste Schuld nach einem finanzierten, priorisierten Plan abbauen statt in gelegentlichen Paniken. Betreiben Sie eine Design Authority, die respektiert wird, weil sie Lieferung ermöglicht, nicht gefürchtet, weil sie sie blockiert, und machen Sie technische Schuld zu einem ständigen Risiko auf Vorstandsebene mit benannter Verantwortlicher. Hüten Sie sich bei jeder Verlängerung vor Lock-in und behandeln Sie Außerbetriebnahme als echte, ausgestattete Arbeit statt als Nachgedanken. Das ist dieselbe Disziplin aus Wiederverwendung und offenen Schnittstellen, die zentrale operative Plattformen in Thema 5.4 — Enterprise Resource Planning (ERP) steuert.

Regierung#

Nationale und regionale Stellen setzen die Bedingungen, unter denen der ganze Sektor arbeitet, und ihre Architekturentscheidungen wirken nach außen. Das Wertvollste, was die Regierung tun kann, ist, offene Standards vorzuschreiben, wiederverwendbare nationale Plattformen bereitzustellen, damit lokale Organisationen einmal bauen, und Erwartungen an Cloud, Sicherheit und Nachhaltigkeit zu setzen, die die Untergrenze überall heben. Entscheidend ist, dass die Regierung die unglamouröse nationale Arbeit finanzieren muss – Altsystem-Sanierung, Terminologiepflege, Unterstützung der Außerbetriebnahme –, die keine einzelne Organisation allein finanziert, von der aber alle abhängen. Ein fest durchgesetzter, gut genug Standard, breit wiederverwendet, schlägt einen theoretisch überlegenen, uneinheitlich umgesetzten. Diese Verwalterrolle hängt mit Thema 9.1 — Zusammenarbeit mit lokalen und nationalen Regierungen und damit zusammen, wie Partner in Thema 9.0 — Zusammenarbeit mit Partnerorganisationen kooperieren.

Häufige Fehlermuster#

• Unsichtbare Landschaft. Hunderte Anwendungen ohne genaues Inventar betreiben, sodass die Exposition unbekannt ist, Duplizierung unbemerkt bleibt und das erste Zeichen von Fragilität ein Ausfall oder eine Panne ist.
• Vor dem Vorstand verborgene Schuld. Nicht unterstützte Software und technische Schuld als technische Fußnote statt als benanntes Unternehmensrisiko halten, sodass sie nie finanziert wird, bis sie versagt.
• Cloud als Parole. Unveränderte Altsysteme aus Prinzip in die öffentliche Cloud heben und schieben, das Problem zu höheren Kosten verlagern, oder Daten und Werkzeuge so tief in einem Anbieter verflechten, dass es ein neuer Lock-in wird.
• Design Authority als Engpass. Architektur-Governance zu einem langsamen Tor werden lassen, das Teams umgehen, und undokumentierte Schattenarchitektur erzeugen, die schlimmer ist als keine.
• Bauen, wo man konfigurieren sollte. Maßanfertigungen für Standardbedarf wählen, nach Listenpreis statt nach Gesamtbetriebskosten, und ein Jahrzehnt Wartung erben, das man nicht budgetiert hat.
• Nie außer Betrieb nehmen. Veraltete Systeme „für alle Fälle“ weiterlaufen lassen, jedes eine Angriffsfläche, ein Lizenzkostenposten und eine Wartungslast, die niemand verantwortet.
• Sicherheit angeflanscht. Sicherheit als Tor vor dem Start statt als Designeingabe behandeln, sodass die Angriffsfläche lange festgelegt ist, bevor sie jemand bewertet.
• Lock-in per Voreinstellung. Plattformen ohne offene Schnittstellen oder Datenextraktionsrechte unterzeichnen und die Kosten der Falle erst entdecken, wenn man zu gehen versucht.

Reifegradmodell#

Checkliste#

• Ein lebendiges Anwendungsportfolio hält Verantwortliche, Kosten, Unterstützbarkeit und Risiko jedes Systems fest und wird regelmäßig überprüft.
• Nicht unterstützte und nicht patchbare kritische Systeme sind identifiziert und stehen im Unternehmensrisikoregister, nicht in einer technischen Tabelle.
• Eine kurze, vereinbarte Menge an Architekturprinzipien wird tatsächlich genutzt, um Entscheidungen zu treffen und zu rechtfertigen.
• Eine Design Authority prüft wesentliche, schwer umkehrbare Entscheidungen und gibt Routinen schnell frei, ermöglichend statt blockierend.
• Cloud-Übernahme wird Workload für Workload bewertet, mit Abwägung von Residenz, Resilienz, Kosten, Portabilität und Kohlenstoff.
• Technische Schuld hat eine benannte Verantwortliche und einen finanzierten Sanierungsplan, nicht nur gelegentliches Brandlöschen.
• Duplizierte und veraltete Systeme werden rationalisiert, und die Außerbetriebnahme ist mit Datenmigration, Aufbewahrung und Abhängigkeitsprüfungen ausgestattet.
• Neue Fähigkeiten stellen offene, versionierte APIs bereit, damit Komponenten ersetzt werden können, ohne darum herum neu zu bauen.
• Sicherheit ist von Anfang an eingeplant – minimale Angriffsfläche, geringste Rechte, Segmentierung – nicht vor dem Start angeflanscht.
• Entscheidungen zu Bauen/Kaufen/Konfigurieren werden nach Gesamtbetriebskosten und Lock-in getroffen, mit vor der Unterschrift gesicherten Ausstiegs- und Datenextraktionsrechten.

Zentrale Quellen#

• NHS England — Cloud-Strategie, Technologiestandards und das Data Security and Protection Toolkit.
• National Cyber Security Centre (NCSC) — Prinzipien des sicheren Designs und Leitlinien zur Cloud-Sicherheit.
• Britische Regierung (GDS/CDDO) — der Technology Code of Practice und die Cloud-first-Politik.
• National Audit Office — Berichte zu NHS-Altsystemen, dem WannaCry-Angriff und IT-gestützten Programmen.
• The Open Group — TOGAF, das Rahmenwerk für Unternehmensarchitektur.
• Government Digital Service — das Konzept der „dünnsten tragfähigen Plattform“ im GOV.UK Service Manual und der Design-Community.

Referenzen#

1. Enterprise architecture — Wikipedia — https://en.wikipedia.org/wiki/Enterprise_architecture
2. Solution architecture — Wikipedia — https://en.wikipedia.org/wiki/Solution_architecture
3. Systems architecture — Wikipedia — https://en.wikipedia.org/wiki/Systems_architecture
4. Cloud computing — Wikipedia — https://en.wikipedia.org/wiki/Cloud_computing
5. Software as a service — Wikipedia — https://en.wikipedia.org/wiki/Software_as_a_service
6. Legacy system — Wikipedia — https://en.wikipedia.org/wiki/Legacy_system
7. Technical debt — Wikipedia — https://en.wikipedia.org/wiki/Technical_debt
8. Application portfolio management — Wikipedia — https://en.wikipedia.org/wiki/Application_portfolio_management
9. Application programming interface — Wikipedia — https://en.wikipedia.org/wiki/Application_programming_interface
10. Total cost of ownership — Wikipedia — https://en.wikipedia.org/wiki/Total_cost_of_ownership
11. Secure by design — Wikipedia — https://en.wikipedia.org/wiki/Secure_by_design
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. Cloud strategy — NHS England — https://www.england.nhs.uk/long-read/cloud-centre-of-excellence/
14. Secure design principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/cyber-security-design-principles
15. Technology Code of Practice — UK Government (CDDO) — https://www.gov.uk/guidance/the-technology-code-of-practice
16. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
17. TOGAF Standard — The Open Group — https://www.opengroup.org/togaf
18. Service Manual: cloud and platforms — Government Digital Service — https://www.gov.uk/service-manual