Onderwerp 4.0 — Technische architectuur, cloud en legacy

In gezondheid en zorg is technische architectuur een beslissing over klinische veiligheid, beveiliging en publiek geld die jaren vooruit wordt genomen: de platforms die u optuigt en de legacy die u laat staan bepalen stilletjes of zorg veilig, samenhangend en betaalbaar kan zijn lang nadat de mensen die ze kozen zijn doorgegaan.

Waarom dit ertoe doet in gezondheid en zorg#

Architectuur is de set langlevende structurele keuzes onder uw digitale diensten: wat waar draait, hoe componenten verbinden, wat u bouwt versus koopt en wat u uit het verleden in leven houdt. Deze keuzes zijn zelden zichtbaar voor patiënten of clinici en zelden opwindend voor besturen. Toch vormen ze alles wat erbovenop zit. Een goed gearchitectureerd bestand laat u snel een nieuwe dienst toevoegen, data veilig delen en snel herstellen wanneer iets breekt. Een slecht gearchitectureerd bestand maakt elke wijziging traag, elke integratie broos en elk incident erger.

In gezondheid en zorg is de inzet hoog omdat de systemen ingrijpend zijn. Wanneer een verouderd patiëntenadministratiesysteem omvalt, worden ambulances omgeleid en klinieken afgelast. Wanneer een niet-ondersteund besturingssysteem wordt misbruikt, worden vertrouwelijke dossiers blootgelegd en stoppen diensten — zoals de NHS in 2017 leerde toen de WannaCry-ransomwareaanval zich verspreidde via machines met software die niet meer kon worden gepatcht. Die verstoring was geen slimme, gerichte aanval; het was het voorspelbare gevolg van opgehoopte technische schuld in kritieke systemen. Architectuurbeslissingen zijn daarom veiligheidsbeslissingen, of iemand ze zo kadert of niet.

Het zijn ook beslissingen over billijkheid en vertrouwen. Legacysystemen die geen data kunnen delen laten de meest complexe patiënten — die van veel diensten gebruikmaken — met de meest gefragmenteerde dossiers. Gesloten platforms die u aan één leverancier binden onttrekken geld dat zorg kon financieren. En het publiek verwacht terecht dat de NHS draait op moderne, veilige, goed onderhouden technologie; de kloof tussen die verwachting en het werkelijke bestand is zelf een risico voor het vertrouwen.

Ten slotte is dit waar veel publiek geld voor zeer lange tijd wordt vastgelegd. Het duurste deel van een systeem is zelden de aanschaf; het is het decennium aan hosting, licenties, onderhoud en uiteindelijke vervanging dat volgt. Leiders die architectuur behandelen als “iets wat het technische team regelt” delegeren enkele van de grootste en langstdurende financiële toezeggingen die de organisatie doet. Dit onderwerp is geschreven zodat u die beslissingen ter verantwoording kunt roepen zonder engineer te zijn.

Kernbegrippen#

Enterprise-architectuur is de discipline van het afstemmen van bedrijfsprocessen, informatie, applicaties en technologie van een organisatie zodat ze samenhangend strategie ondersteunen in plaats van bij toeval te groeien. Zij neemt het gezichtspunt van de hele organisatie: welke capaciteiten u nodig hebt, welke systemen ze leveren en waar de hiaten en duplicaties liggen. Oplossingsarchitectuur is de smallere discipline op projectniveau van het ontwerpen hoe een specifieke dienst zal worden gebouwd en in het bredere bestand past. Beide vallen binnen het bredere idee van systeemarchitectuur — het structurele model van hoe componenten, interfaces en gedrag zich tot een werkend geheel verbinden. Leiders hoeven deze disciplines niet te beoefenen, maar moeten erop staan dat ze bestaan, want hun afwezigheid is hoe bestanden onbeheersbaar worden.

Architectuur wordt geleid door architectuurprincipes: een korte, afgesproken set uitspraken — zoals “hergebruik voor koop, koop voor bouw” of “bouw naar open normen” — die consistente beslissingen mogelijk maken zonder dat elke keuze wordt geëscaleerd. Principes worden, licht, afgedwongen door een design authority: een kleine groep die significante technische beslissingen toetst. De gezonde versie van een design authority maakt mogelijk in plaats van te blokkeren; zij bestaat om vermijdbare schade en duplicatie te voorkomen, niet om teams te vertragen of uit zichzelf poortwachter te spelen.

Cloud computing is het leveren van rekenkracht — servers, opslag, databases, netwerken — als dienst op aanvraag via het internet, in plaats van vanaf hardware die u bezit in uw eigen gebouw. Een publieke cloud wordt gerund door een externe aanbieder en gedeeld door veel klanten; een private cloud is gewijd aan één organisatie; een hybride cloud combineert de twee en houdt vaak sommige werklasten op bestaande infrastructuur terwijl andere naar buiten gaan. Veel overheden, waaronder die van het VK, hebben een beleid van “cloud-first” aangenomen, wat betekent dat teams publieke cloud moeten overwegen vóór andere opties en moeten rechtvaardigen waarom niet. Omdat cloud op verbruik wordt gefactureerd in plaats van eenmaal gekocht, is het beheersen van die uitgaven een eigen discipline geworden — FinOps, de praktijk om engineering en financiën samen te brengen zodat teams zicht hebben op, en verantwoording dragen voor, wat hun cloudgebruik werkelijk kost. Op de laag van de applicatie levert software as a service (SaaS) een afgewerkte applicatie via het web die de leverancier host en onderhoudt, zodat u configureert in plaats van runt. Infrastructuur en hosting — waar en hoe uw systemen fysiek draaien — liggen onder dit alles en dragen steeds vaker een koolstofkost die in de beslissing thuishoort (zie Onderwerp 8.5 — Duurzaamheid en netto nul).

Een legacysysteem is een verouderd maar nog steeds gebruikt systeem dat moeilijk te wijzigen is en vaak niet-ondersteunde software draait waarvoor geen beveiligingspatches meer worden uitgegeven. Legacy stapelt zich op als technische schuld — de toekomstige kosten van opportune keuzes uit het verleden. Een beetje schuld is normaal en zelfs verstandig; onbeheerde schuld op schaal wordt een aansprakelijkheid voor veiligheid en beveiliging, omdat de systemen waarvan de meeste mensen afhangen de systemen worden die niemand durft aan te raken. Dit beheren is de taak van applicatieportfoliomanagement: een duidelijke inventaris bijhouden van elke applicatie, haar kosten, staat en bedrijfswaarde, zodat u het bestand kunt rationaliseren — systemen uitfaseren, vervangen of consolideren — en veilig uitfaseren in plaats van het oude ding stilletjes te laten draaien.

Moderne bestanden worden bijeengehouden door application programming interfaces (API’s): omschreven interfaces waarlangs het ene systeem een capaciteit aan het andere aanbiedt. Goed ontworpen API’s laten u platforms samenstellen — herbruikbare diensten waarop veel teams bouwen — terwijl componenten los gekoppeld en vervangbaar blijven. Een nuttige discipline hier is het “dunste levensvatbare platform”: bouw alleen de gedeelde capaciteit die werkelijk het werk van anderen vermindert, en niet meer. Onder veilig ontwerp ligt secure by design, het beginsel dat beveiliging vanaf het begin wordt ingebouwd in plaats van achteraf erop te worden geschroefd. En het financiële kader voor dit alles zijn de total cost of ownership (TCO): de volledige kosten van een systeem over haar leven, niet haar aankoopprijs — de lens waardoor de keuze bouwen/kopen/configureren, en het risico van vendor lock-in, moet worden beoordeeld.

Beste praktijken#

1. Spreek een korte set architectuurprincipes af en gebruik ze om te beslissen. Schrijf een handvol duidelijke, gedenkwaardige principes op — hergebruik voor koop voor bouw, bouw naar open normen, cloud waar het zinvol is, secure by design, ontwerp voor het hele zorgtraject — en laat teams de meeste beslissingen zelf nemen door ze toe te passen. Principes werken alleen als ze werkelijk worden gebruikt om ja en nee te zeggen, en alleen als er weinig genoeg zijn om te onthouden. Dit sluit rechtstreeks aan bij Onderwerp 1.1 — Het operationele model en Onderwerp 1.2 — Digitale strategie en roadmapping, die de richting bepalen die de principes dienen.

2. Run een design authority die mogelijk maakt in plaats van blokkeert. Richt een kleine, senior, multidisciplinaire groep op om significante technische beslissingen te toetsen — die welke duur, moeilijk terug te draaien zijn, veel diensten raken of risico voor veiligheid en beveiliging dragen. Geef haar een snelle, lichtgewicht route zodat routinekeuzes er niet doorheen worden gesleept en houd haar aan een dienstnorm: zij moet teams helpen een goed antwoord te vinden, niet eenvoudig weigeren. Een design authority die een knelpunt wordt zal worden omzeild, en schaduwarchitectuur is erger dan geen.

3. Neem cloud bewust over, werklast voor werklast, niet als slogan. Behandel “cloud-first” als standaard om over na te denken, niet als instructie om alles te verplaatsen. Beoordeel elke werklast op geschiktheid, dataresidentie, weerbaarheid, kosten op schaal en de moeite om te migreren, en wees eerlijk dat lift-and-shift van een ongewijzigde legacyapplicatie het probleem vaak slechts tegen hogere kosten verplaatst. Weeg de koolstofdimensie expliciet, omdat waar en hoe u host emissies beïnvloedt (zie Onderwerp 8.5 — Duurzaamheid en netto nul), en ontwerp voor overdraagbaarheid zodat een toekomstige verhuizing tussen aanbieders mogelijk blijft.

4. Onderhoud een levend applicatieportfolio en beheer technische schuld als benoemd risico. Houd een accurate inventaris bij van elke applicatie, haar bedrijfseigenaar, kosten, ondersteunbaarheid en het risico dat zij draagt, en toets die regelmatig. Zet technische schuld en niet-ondersteunde software op het risicoregister van de organisatie met dezelfde ernst als klinisch of financieel risico, want dat is wat het is. Wat u niet kunt zien, kunt u niet financieren, prioriteren of veilig uitfaseren, en bestanden die nooit worden geïnventariseerd zijn precies degene die zonder waarschuwing falen.

5. Rationaliseer het bestand en fase veilig uit. Fase actief gedupliceerde, verouderde en end-of-life systemen uit in plaats van ze “voor het geval dat” te laten hangen, omdat elk live systeem een aanvalsoppervlak, een licentiekost en een onderhoudslast is. Uitfaseren is een project op zich: migreer of archiveer de data onder duidelijke bewaarregels, bevestig dat niets nog van het systeem afhangt, communiceer met gebruikers en verifieer voordat u uitschakelt. Goed gedaan maakt rationalisatie geld vrij en vermindert risico; onzorgvuldig gedaan vernietigt het dossiers of breekt een afhankelijkheid die niemand documenteerde.

6. Geef de voorkeur aan open normen, API’s en los gekoppelde componenten. Ontwerp zo dat capaciteiten worden blootgesteld via gedocumenteerde, versioneerde API’s, zodat één component kan worden vervangen zonder alles eromheen te herbouwen. Dit is het architecturele fundament voor de interoperabiliteit besproken in Onderwerp 4.3 — Interoperabiliteit en datastandaarden en uw belangrijkste verdediging tegen lock-in. Het kost vooraf iets meer dan een directe, vast bedrade verbinding en betaalt dat vele malen terug de eerste keer dat u een leverancier moet wisselen of een dienst moet toevoegen.

7. Bouw het dunste levensvatbare platform, en niet meer. Wanneer u een gedeeld platform creëert waarop anderen bouwen, weersta de drang het vanaf dag één compleet te maken. Bied de kleinste herbruikbare capaciteit die werkelijk werk wegneemt voor teams, bewijs dat zij wordt gebruikt en laat haar groeien als reactie op echte vraag. Te veel gebouwde platforms worden hun eigen legacy — duur, rigide en gehaat — terwijl een dun, goed gerund platform adoptie verdient en meegroeit met de behoefte.

8. Maak beveiligingsarchitectuur en secure-by-design niet onderhandelbaar. Breng beveiligingsdenken vanaf de eerste schets in het ontwerp, niet als poort vóór de lancering: minimaliseer het aanvalsoppervlak, pas minimale rechten toe, segmenteer netwerken en ga ervan uit dat componenten zullen worden afgetast. In gezondheid en zorg is dit onlosmakelijk van klinische veiligheid en informatiebeheer (Onderwerp 1.6 — Klinische veiligheid en risicobeheer; Onderwerp 1.7 — Informatiebeheer, gegevensbescherming en cyberbeveiliging), omdat een lek zowel dataschade is als, wanneer het systemen stopt, een gebeurtenis van patiëntveiligheid. Niet-ondersteunde, niet te patchen software is een beveiligingsbeslissing die u bij verstek neemt — neem haar dus bewust, met beperkende maatregelen, of helemaal niet.

9. Besluit bouwen, kopen of configureren op total cost of ownership, niet op de prijs op het etiket. Vergelijk voor elke capaciteit maatwerk bouwen, een product kopen en een bestaand platform configureren op hun volledige levenskosten — hosting, licenties, integratie, ondersteuning, upgrades en uiteindelijke uitstap — niet de aanvankelijke prijs. Geef de voorkeur aan kopen of configureren voor gemeengoedbehoeften en bewaar bouwen voor echte onderscheiding, en weeg de lock-in die elke optie creëert. Werk dit uit met commerciële collega’s (Onderwerp 6.3 — Inkoop en commercie), want het goedkoopste moment om open interfaces en uitstaprechten te verzekeren is vóór u tekent.

10. Behandel cloudkosten als gedeelde discipline van engineering en financiën (FinOps). Geef teams duidelijk zicht op wat hun diensten kosten door cloudmiddelen aan eigenaren te taggen, instanties op maat te maken tegen echt gebruik en ongebruikte of te ruim ingerichte middelen uit te zetten in plaats van er maand na maand voor te betalen. Maak de teams die een dienst runnen verantwoordelijk voor haar lopende kosten, zodat de mensen die het best geplaatst zijn om verspilling te verminderen degenen zijn die de rekening zien. Pay-as-you-go cloud zonder deze discipline verbruikt stilletjes budget dat zorg zou moeten financieren, en de afwijking wordt zelden opgemerkt totdat een factuur de vraag afdwingt.

11. Architectureer voor kosten als eersteklas niet-functionele eis, afgewogen tegen koolstof en weerbaarheid. Behandel kosten zoals u prestaties, beveiliging en beschikbaarheid behandelt: een eigenschap waarvoor u bewust ontwerpt, voor het bouwen schat en toetst naarmate gebruik groeit. Weeg ze expliciet tegen koolstof (zie Onderwerp 8.5 — Duurzaamheid en netto nul) en tegen weerbaarheid, omdat de drie vaak samen bewegen — maar jaag nooit de laagste rekening na ten koste van veiligheid, herstelbaarheid of patiëntuitkomsten. Het juiste antwoord zijn de laagste kosten die nog aan uw verplichtingen voor klinische veiligheid en weerbaarheid voldoen, niet de goedkoopste optie op zichzelf.

Vragen om met uw team te bespreken#

1. Welke van onze kritieke systemen zijn vandaag niet-ondersteund of niet te patchen, en wat is onze werkelijke blootstelling als er een wordt aangevallen of faalt? Begin bij de systemen waarzonder klinische en operationele diensten werkelijk niet kunnen functioneren en stel concreet vast welke software draaien die geen beveiligingsupdates of leveranciersondersteuning meer krijgt. Vraag wat er zou gebeuren — met patiënten, personeel, data — als elk door ransomware werd getroffen of simpelweg stopte, en hoe lang herstel zou duren. Onderscheid systemen waarvan u bewust risico hebt aanvaard, met beperkende maatregelen op hun plaats, van die waarvan niemand de kwetsbaarheid heeft beoordeeld. Overweeg of deze blootstelling zichtbaar is op het risicoregister van de organisatie of begraven in een spreadsheet die geen bestuur heeft gezien. Denk na over WannaCry: de schade kwam niet van verfijning maar van bekende, onbehandelde schuld in kritieke systemen. Als u dit niet met bewijs kunt beantwoorden, is die kloof zelf uw meest urgente bevinding, omdat u een risico dat u niet hebt benoemd niet kunt financieren.

2. Waar zitten wij vast, en wat zou het ons werkelijk kosten ons grootste platform te verlaten? Veel organisaties ontdekken de echte prijs van een gesloten systeem pas wanneer zij proberen het te wijzigen. Werk door wat het werkelijk zou vergen van uw grootste klinische of bedrijfsplatform af te stappen: of u uw data in bruikbare, standaardvorm kunt exporteren, welke bedrijfseigen interfaces zouden moeten worden ontward en wat uw contract zegt over eigendom en uitstap. Overweeg of “cloud” stilletjes een andere soort lock-in is geworden, met data en gereedschap zo verstrengeld in één aanbieder dat vertrek onpraktisch is. Weeg dit af tegen de openheid van alternatieven en eventuele nationale platforms die u in plaats daarvan zou kunnen hergebruiken. Dit is geen pleidooi om leveranciers te wisselen; het gaat erom uw hefboom te begrijpen voor u opnieuw onderhandelt, en de roadmap van één leverancier niet stilletjes uw enige optie te laten worden.

3. Investeren wij genoeg in het onderhouden en rationaliseren van wat wij al hebben, of alleen in het nieuwe en zichtbare? Nieuwe systemen trekken financiering en aandacht; het onglamoureuze werk van patchen, upgraden, consolideren en veilig uitfaseren zelden, en zo stapelt schuld zich op. Vraag welk deel van uw digitale budget werkelijk gaat naar het veilig en actueel houden van het bestaande bestand versus het bouwen van nieuwe dingen, en of iemand die balans bewust bezit. Bespreek of uitfaseren ooit behoorlijk van middelen wordt voorzien, of dat oude systemen simpelweg blijven hangen omdat uitzetten niemands taak is. Overweeg de gedupliceerde applicaties die over de organisatie hetzelfde doen en wat nodig zou zijn om ze te consolideren. Denk na over wie op bestuursniveau verantwoordelijk is voor de gezondheid van het bestand als geheel in plaats van voor afzonderlijke projecten. Een organisatie die alleen het nieuwe financiert leent tegen haar eigen toekomstige veiligheid, en de aflossing komt altijd op het slechtst denkbare moment.

4. Weten wij werkelijk wat onze cloud kost, wie de rekening bezit en of de uitgaven onder controle zijn? Pay-as-you-go cloud kan stilletjes budget verbruiken dat zorg zou moeten financieren, en de afwijking wordt zelden opgemerkt tot een factuur de vraag afdwingt. Vraag of cloudmiddelen zijn getagd aan de teams en diensten die ze bezitten, of iemand instanties op maat maakt tegen echt gebruik en of ongebruikte of te ruim ingerichte middelen ooit worden uitgezet. Bespreek of de mensen die een dienst runnen haar lopende kosten zien en erop worden aangesproken, of dat cloudkosten landen als één onverklaarde regel in een centraal budget dat niemand kan ontleden. Overweeg of kosten worden behandeld als eersteklas niet-functionele eis — voor het bouwen geschat en naarmate gebruik groeit getoetst — of pas achteraf ontdekt. Wees eerlijk over de spanning tussen autonomie van engineering en financiële controle, en over het afwegen van kosten tegen koolstof en weerbaarheid in plaats van louter de laagste rekening na te jagen. Een eerlijk antwoord noemt wie de FinOps-discipline bezit en toont het bewijs dat zij werkt, in plaats van aan te nemen dat cloud goedkoper is omdat zij modern is.

5. Wanneer wij een nieuwe capaciteit nodig hebben, hoe beslissen wij tussen bouwen, kopen en configureren van iets wat wij al hebben — en op welke grondslag? Het instinct om maatwerk te bouwen, of het product met de beste demo te kopen, wint vaak voordat iemand de volledige levenskosten heeft vergeleken. Werk door hoe uw laatste enkele significante keuzes werkelijk zijn gemaakt: of hosting, licenties, integratie, ondersteuning, upgrades en uiteindelijke uitstap zijn gewogen, of alleen de aanvankelijke prijs. Vraag of u bouwen bewaart voor echte onderscheiding en standaard kiest voor kopen of configureren voor gemeengoedbehoeften, of dat maatwerk stilletjes woekert omdat een team het verkoos. Overweeg wie er bij deze beslissingen in de kamer zit — commerciële en klinische collega’s naast engineers — en of de lock-in die elke optie creëert wordt beoordeeld voor het tekenen in plaats van later ontdekt. Denk na of uw architectuurprincipes (“hergebruik voor koop, koop voor bouw”) deze keuzes werkelijk binden of stilletjes worden genegeerd. Een eerlijk antwoord kan wijzen op echte beslissingen waarin total cost of ownership, niet de prijs op het etiket, de uitkomst veranderde.

6. Hebben wij de interne architectuurcapaciteit om onze eigen beslissingen te dragen, of zijn wij afhankelijk van de leveranciers die wij ter verantwoording zouden moeten roepen? Architectuur is waar de grootste en langstdurende toezeggingen worden gedaan, maar veel organisaties hebben juist de capaciteit uitgehold die nodig is om ze goed te nemen, en vertrouwen op de leveranciers van wie de producten worden geëvalueerd om hun te vertellen hoe goed eruitziet. Vraag of u geloofwaardige vaardigheid in enterprise- en oplossingsarchitectuur aan uw eigen kant hebt en of uw design authority is bemand om teams mogelijk te maken of slechts om af te stempelen. Bespreek of significante, moeilijk terug te draaien beslissingen werkelijk worden getoetst aan afgesproken principes, of in feite worden gedelegeerd aan de leverancier die het dichtst bij het probleem zit. Overweeg hoe u een slechte architectuuraanbeveling zelfs zou herkennen als u geen onafhankelijke deskundigheid had om haar uit te dagen. Weeg de kosten van het opbouwen en behouden van deze capaciteit af tegen de veel grotere kosten van lock-in en herwerk die haar afwezigheid oplevert. Een eerlijk antwoord onderscheidt de beslissingen die u werkelijk kunt bezitten van die welke u nu op vertrouwen neemt.

In de praktijk: een voorbeeld uit gezondheid en zorg#

Het technische bestand van een algemeen ziekenhuis is twee decennia organisch gegroeid. In het hart zit een patiëntenadministratiesysteem op een besturingssysteem dat de leverancier achttien maanden geleden niet meer ondersteunt; eromheen zijn meer dan tweehonderd applicaties, veel afdelingsgewijs gekocht, verscheidene met overlappende taken, en niemand heeft een volledige lijst. Een bijna-ongeval — een ransomwarepoging geblokkeerd eerder door geluk dan door ontwerp — zet het bestuur ertoe een vraag te stellen die het nooit eerder stelde: wat draaien wij precies, en hoe blootgesteld zijn wij?

De chief digital information officer weerstaat de neiging één heroïsch programma “vervang alles” te lanceren en doet eerst het saaie werk. De organisatie bouwt een levend applicatieportfolio: elk systeem, haar bedrijfseigenaar, haar ondersteunbaarheid, haar kosten en haar risico. Het beeld is ontnuchterend — een vijfde van de applicaties draait op niet-ondersteunde software en een dozijn dupliceert capaciteiten die elders al beschikbaar zijn — maar voor het eerst is het zichtbaar, en de ergste blootstellingen gaan rechtstreeks op het risicoregister van de organisatie waar het bestuur ze kan zien.

Uit die inventaris maakt de organisatie bewuste keuzes geleid door een handvol afgesproken architectuurprincipes. Het niet-ondersteunde patiëntenadministratiesysteem krijgt voorrang voor vervanging, ingekocht als configureerbaar product met contractuele rechten op open API en data-export zodat de organisatie niet opnieuw wordt vastgezet. Geschikte werklasten verhuizen naar publieke cloud, één voor één beoordeeld in plaats van volgens slogan, met koolstof en overdraagbaarheid naast kosten gewogen. Een kleine design authority toetst de significante beslissingen en keurt de routinematige snel goed. Twaalf overlappende afdelingsapplicaties worden geconsolideerd tot drie, en de uitgefaseerde systemen worden behoorlijk uitgeschakeld — data gemigreerd onder duidelijke bewaarregels, afhankelijkheden gecontroleerd, gebruikers geïnformeerd en pas dan uitgezet.

Niets hiervan haalt een krantenkop. Maar achttien maanden later weet de organisatie wat zij draait, wordt haar gevaarlijkste schuld afgelost volgens een gefinancierd plan in plaats van weggehoopt en wordt een nieuwe integratie met een gedeeld zorgdossier in weken opgeleverd omdat de vervangende systemen open API’s blootstellen. Het bijna-ongeval werd het moment waarop de organisatie haar architectuur begon te beheren in plaats van erdoor te worden beheerd.

Sectorperspectieven#

Startup#

Een startup in digitale gezondheid heeft de luxe van weinig legacy en moet die fel beschermen. Bouw vanaf het begin cloud-native, stel open API’s bloot en behandel secure-by-design als kernfunctie in plaats van latere kost, omdat voorzichtige NHS-kopers uw beveiligingsarchitectuur en voorwaarden voor data-export nauwgezet zullen toetsen. Houd uw eigen dunste levensvatbare platform werkelijk dun en weersta de verleiding te over-engineeren voor schaal die u nog niet hebt. Uw snelste route naar verlammende technische schuld is opportune code uitleveren onder druk van investeerders en haar nooit terugbetalen, dus maak bewuste, zichtbare keuzes over welke schuld u aangaat. Paradoxaal is ontwerpen zodat een klant zijn data kan exporteren en vertrekken wat het vertrouwen verdient dat hem behoudt.

Klein bedrijf#

Een gevestigde kleine aanbieder — een huisartsenpraktijk, een gemeenschapsapotheek, een verzorgingshuis, een kliniek met één vestiging of een kleine leverancier van gezondheidstechnologie voorbij het startupstadium — draagt dezelfde plichten als een groot ziekenhuis maar met een fractie van de middelen en zelden enige toegewijde IT-capaciteit. Hier is architectuur vooral de discipline van goed inkopen: geef de voorkeur aan gerenommeerde software as a service zodat de leverancier de hosting, patching en beveiliging draagt die u niet kunt bemensen, en lees het contract op rechten voor data-export en uitstap voor u tekent, omdat lock-in het hardst bijt wanneer u geen hefboom hebt. Houd een eenvoudige inventaris bij van de handvol systemen waarvan u afhangt en weet welke nog worden ondersteund, omdat zelfs een klein bestand een niet-gepatchte machine kan verbergen die de praktijk stopt. Sta erop dat leveranciers voldoen aan erkende normen als de Data Security and Protection Toolkit in plaats van beveiliging van nul te proberen beoordelen. Wanneer geld krap is, is de verleiding een oud, niet-ondersteund systeem aan te houden om een rekening te vermijden, maar dat is een veiligheidsbeslissing die u bewust moet nemen, niet door drift.

Grote onderneming#

Een groot ziekenhuis of grote leverancier draagt decennia aan opgehoopte systemen en kan niet simpelweg opnieuw beginnen. De realistische strategie is gedisciplineerde evolutie: onderhoud een levend portfolio, zet open, op API gebaseerde lagen voor wat moet blijven en los de gevaarlijkste schuld af volgens een gefinancierd, geprioriteerd plan in plaats van in af en toe paniek. Run een design authority die wordt gerespecteerd omdat zij levering mogelijk maakt, niet gevreesd omdat zij haar blokkeert, en maak technische schuld een blijvend risico op bestuursniveau met een benoemde eigenaar. Waak bij elke verlenging tegen lock-in en behandel uitfaseren als echt, van middelen voorzien werk in plaats van een bijzaak. Dit is dezelfde discipline van hergebruik en open interfaces die de operationele kernplatforms bestuurt in Onderwerp 5.4 — Enterprise resource planning (ERP).

Overheid#

Nationale en regionale organen stellen de voorwaarden vast waaronder de hele sector werkt, en hun architectuurkeuzes rimpelen naar buiten. De waardevolste dingen die de overheid kan doen zijn open normen verplicht stellen, herbruikbare nationale platforms bieden zodat lokale organisaties eenmaal bouwen en verwachtingen voor cloud, beveiliging en duurzaamheid vaststellen die de vloer overal verhogen. Cruciaal is dat de overheid het onglamoureuze nationale werk moet financieren — legacyherstel, onderhoud van terminologie, ondersteuning bij uitfaseren — dat geen enkele organisatie alleen zal financieren maar waarvan iedereen afhangt. Een strikt gehandhaafde, goed-genoege norm die breed wordt hergebruikt verslaat een theoretisch superieure die inconsistent wordt geïmplementeerd. Deze rentmeesterrol sluit aan bij Onderwerp 9.1 — Werken met lokale en nationale overheden en bij hoe partners samenwerken in Onderwerp 9.0 — Samenwerken met partnerorganisaties.

Veelvoorkomende faalpatronen#

• Onzichtbaar bestand. Honderden applicaties draaien zonder accurate inventaris, zodat blootstelling onbekend is, duplicatie onopgemerkt blijft en het eerste teken van kwetsbaarheid een uitval of een lek is.
• Schuld verborgen voor het bestuur. Niet-ondersteunde software en technische schuld als technische voetnoot houden in plaats van als benoemd risico van de organisatie, zodat ze nooit worden gefinancierd totdat ze falen.
• Cloud als slogan. Ongewijzigde legacy op principe in publieke cloud tillen, wat het probleem tegen hogere kosten verplaatst, of data en gereedschap zo verstrengelen in één aanbieder dat het een nieuwe lock-in wordt.
• Design authority als knelpunt. Architectuurbestuur een trage poort laten worden die teams omzeilen, wat ongedocumenteerde schaduwarchitectuur voortbrengt die erger is dan geen.
• Bouwen waar u zou moeten configureren. Maatwerkbouw kiezen voor gemeengoedbehoeften, op de prijs op het etiket in plaats van total cost of ownership, en een decennium aan onderhoud erven dat u niet begrootte.
• Nooit uitfaseren. Verouderde systemen “voor het geval dat” laten draaien, elk een aanvalsoppervlak, een licentiekost en een onderhoudslast die niemand bezit.
• Beveiliging erop geschroefd. Beveiliging behandelen als poort vóór de lancering in plaats van ontwerpinput, zodat het aanvalsoppervlak is vastgelegd lang voordat iemand het beoordeelt.
• Lock-in bij verstek. Platforms tekenen zonder open interfaces of rechten op data-export en de kosten van de val pas ontdekken wanneer u probeert te vertrekken.

Volwassenheidsmodel#

Checklist#

• Een levend applicatieportfolio legt van elk systeem eigenaar, kosten, ondersteunbaarheid en risico vast en wordt regelmatig getoetst.
• Niet-ondersteunde en niet te patchen kritieke systemen zijn geïdentificeerd en staan op het risicoregister van de organisatie, niet in een technische spreadsheet.
• Een korte, afgesproken set architectuurprincipes wordt werkelijk gebruikt om beslissingen te nemen en te rechtvaardigen.
• Een design authority toetst significante, moeilijk terug te draaien beslissingen en keurt routinematige snel goed, mogelijk makend in plaats van blokkerend.
• Adoptie van cloud wordt per werklast beoordeeld, met dataresidentie, weerbaarheid, kosten, overdraagbaarheid en koolstof gewogen.
• Technische schuld heeft een benoemde eigenaar en een gefinancierd herstelplan, niet slechts af en toe brandjes blussen.
• Gedupliceerde en verouderde systemen worden gerationaliseerd, en uitfaseren is van middelen voorzien met datamigratie, bewaring en controles op afhankelijkheden.
• Nieuwe capaciteiten stellen open, versioneerde API’s bloot zodat componenten kunnen worden vervangen zonder eromheen te herbouwen.
• Beveiliging wordt vanaf het begin ingebouwd — minimaal aanvalsoppervlak, minimale rechten, segmentatie — niet vóór de lancering erop geschroefd.
• Beslissingen over bouwen/kopen/configureren worden genomen op total cost of ownership en lock-in, met uitstap- en data-exportrechten verzekerd voor het tekenen.

Belangrijkste bronnen#

• NHS England — cloudstrategie, technologienormen en de Data Security and Protection Toolkit.
• National Cyber Security Centre (NCSC) — principes voor veilig ontwerp en richtlijnen voor cloudbeveiliging.
• Britse overheid (GDS/CDDO) — de Technology Code of Practice en het cloud-first-beleid.
• National Audit Office — rapporten over NHS-legacysystemen, de WannaCry-aanval en door IT mogelijk gemaakte programma’s.
• The Open Group — TOGAF, het kader voor enterprise-architectuur.
• Government Digital Service — het concept “dunste levensvatbare platform” in de GOV.UK service manual en de ontwerpgemeenschap.

Referenties#

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