Architectuur in 2026: ontwerp voor overstappen, melden en herstellen

Managementsamenvatting

Enterprise-architectuur krijgt in 2026 een concretere opdracht. De EU Data Act maakt overstappen tussen cloud- en dataverwerkingsdiensten tot een uitvoerbaar ontwerpvraagstuk, terwijl de Cyber Resilience Act vanaf 11 september 2026 snelle melding van actief misbruikte kwetsbaarheden en ernstige incidenten vereist. Tegelijk standaardiseren organisaties hun infrastructuur via platform engineering en hybride cloud. Daardoor verschuift de kwaliteitsvraag: niet alleen of een oplossing vandaag werkt, maar ook of zij aantoonbaar te verplaatsen, te observeren en onder tijdsdruk te beheersen is. Dat raakt Business, Solution, Data, Infrastructure, Cloud en Security Architecture tegelijk.

Van “werkt het?” naar “kunnen we eruit, kunnen we het aantonen en kunnen we reageren?”

Architectuurprincipes als interoperabiliteit, portabiliteit, resilience en traceability zijn niet nieuw. Wat in 2026 verandert, is dat ze steeds minder vrijblijvend worden. De Europese Data Act is sinds 12 september 2025 van toepassing en bevat expliciete regels voor switching tussen data-processing services. Voor PaaS- en SaaS-diensten spelen open interfaces en export in gangbare machineleesbare formaten een rol; bij IaaS gaat het onder meer om het faciliteren van functionele equivalentie bij een overstap. De Commissie publiceerde in februari 2026 bovendien een studie als voorbereiding op open specificaties en geharmoniseerde standaarden voor interoperabiliteit van data-processing services. [1][2]

Daar komt een tweede tijdslijn bij. Onder de Cyber Resilience Act gaan op 11 september 2026 de rapportageverplichtingen gelden voor actief misbruikte kwetsbaarheden en ernstige incidenten die de beveiliging van producten met digitale elementen raken. De eerste waarschuwing moet in beginsel binnen 24 uur na bekendwording worden ingediend, gevolgd door een uitgebreidere melding binnen 72 uur. ENISA bouwt daarvoor het Single Reporting Platform. [3][4]

Voor architecten ontstaat daardoor één samenhangende ontwerpvraag: hoe bouw je een digitale organisatie die niet alleen efficiënt kan veranderen, maar ook aantoonbaar kan overstappen, incidenten kan reconstrueren en onder wettelijke tijdsdruk kan reageren?

1. Business Architecture: nieuwe verantwoordelijkheden horen in het operating model

Business Architecture wordt vaak geassocieerd met capabilities, value streams, organisatie-inrichting en governance. Juist daar begint het probleem. Wanneer wet- en regelgeving eisen stelt aan switching, kwetsbaarheidsafhandeling en incidentmelding, moet duidelijk zijn welke organisatorische capability daarvoor verantwoordelijk is.

Een exitplan dat alleen in een contractmap staat, is geen capability. Een meldplicht die alleen bij Legal of Security bekend is, is geen werkend operating model. Business Architecture moet daarom expliciet maken wie eigenaar is van bijvoorbeeld cloud portability, product security, vulnerability handling, leveranciersafhankelijkheden en wettelijke rapportage.

De CRA-richtsnoeren die de Europese Commissie op 27 juli 2026 publiceerde, verduidelijken onder meer scope, substantiële wijzigingen, supportperioden, rapportage en risicobeoordeling. Dat onderstreept dat compliance niet alleen een juridische controle achteraf is, maar gedurende de levenscyclus van digitale producten organisatorisch moet zijn ingericht. [5]

Voor businessarchitecten betekent dit concreet dat capability maps en verantwoordelijkheidsmodellen moeten worden aangevuld met vragen als:

• Wie kan besluiten dat een cloud- of platformdienst wordt vervangen?
• Wie bezit de informatie die nodig is voor een exit?
• Wie beoordeelt of een kwetsbaarheid actief wordt misbruikt?
• Wie kan binnen 24 uur een eerste melding laten doen?
• Welke externe partijen moeten daarvoor informatie aanleveren?

De architectuurwaarde zit hier niet in het tekenen van extra vakjes, maar in het voorkomen van een bestuurlijke leegte precies op het moment dat snel handelen nodig is.

2. Solution Architecture: substitueerbaarheid wordt een expliciet ontwerpbesluit

Solution Architecture heeft jarenlang terecht gewaarschuwd tegen onnodige vendor lock-in. Toch bleef “cloud-agnostisch” vaak een abstract ideaal. De Data Act maakt de discussie specifieker. De wet verlangt niet dat iedere oplossing volledig uitwisselbaar wordt, maar creëert wel concrete verwachtingen rond switching, open interfaces, exporteerbare data en het wegnemen van overstapbelemmeringen. [2]

Daarom is een bruikbaarder architectuurprincipe niet “vermijd alle afhankelijkheid”, maar maak afhankelijkheid bewust en meetbaar.

Een solutionarchitect kan per component onderscheid maken tussen:

1. Bewust provider-specifiek — de meerwaarde van een managed dienst is groter dan de overstapkosten.
2. Vervangbaar via contract — interfaces en gedrag zijn zodanig begrensd dat een alternatief component kan worden aangesloten.
3. Data-portable — data kan met voldoende semantiek en metadata worden geëxporteerd.
4. Runtime-portable — de workload kan technisch op een andere omgeving draaien.
5. Niet-portable — er is een expliciet geaccepteerd risico en een mitigerende strategie.

Dat maakt een exit geen theoretische exercitie aan het einde van een contract, maar een ontwerpkenmerk van de oplossing. Bij kritieke functies hoort bovendien getest te worden of de veronderstelde substitueerbaarheid werkelijk bestaat. Een architectuurdiagram waarop twee providers naast elkaar staan, bewijst nog geen portabiliteit.

3. Data Architecture: exporteerbaar is nog niet hetzelfde als bruikbaar

De Data Act is bijzonder relevant voor Data Architecture omdat interoperabiliteit meer omvat dan een bestand kunnen downloaden. Artikel 35 benoemt verschillende lagen, waaronder syntactische, semantische en beleidsmatige interoperabiliteit en portabiliteit. De verordening vraagt bovendien dat datasets, gebruiksbeperkingen, kwaliteit, onzekerheid, structuren, vocabularies en technische toegangsmiddelen voldoende worden beschreven waar dat van toepassing is. [1]

Daarmee krijgt metadata een directere strategische waarde. Een export van tabellen zonder definities, classificaties, kwaliteitsinformatie of lineage kan technisch compleet zijn en toch praktisch nauwelijks overdraagbaar.

Voor data-architecten zijn daarom ten minste vier ontwerpvragen relevant:

• Zijn kritieke dataobjecten onafhankelijk van één leveranciersintern formaat beschreven?
• Zijn definities en taxonomieën buiten het bronsysteem beschikbaar?
• Kan autorisatiebeleid worden vertaald naar een andere omgeving?
• Is duidelijk welke metadata nodig is om betekenis, kwaliteit en herkomst te behouden?

De Commissie werkt ondertussen verder aan open specificaties en geharmoniseerde standaarden voor interoperabiliteit van data-processing services. Dat betekent dat organisaties die hun semantiek nu al expliciet maken, beter voorbereid zijn dan organisaties die portabiliteit reduceren tot technische export. [1]

4. Infrastructure Architecture: standaardisatie wordt een beheersingsmechanisme

Infrastructure Architecture beweegt tegelijk in de richting van meer standaardisatie. CNCF rapporteerde in maart 2026 dat 88% van backendontwikkelaars met ten minste één vorm van infrastructuurstandaardisatie werkt. Interne developerplatformen en platform engineering zorgen ervoor dat ontwikkelaars infrastructuur steeds vaker via gestandaardiseerde capabilities consumeren in plaats van iedere onderliggende technologie rechtstreeks te beheren. [6]

Dat is niet alleen een efficiencytrend. Goed ingerichte platformen kunnen ook portability, security en observability afdwingen. Denk aan standaard logging, identity patterns, policy-as-code, deploymenttemplates, secrets management en vaste export- of backupmechanismen.

Maar er is een belangrijk risico: een intern platform kan zelf een nieuwe lock-in-laag worden. Als een organisatie alle kennis over deployment, observability en runtimegedrag in één eigen platform abstraheert, moet ook dat platform een beheerde exitstrategie hebben.

Infrastructure Architecture moet daarom twee dingen tegelijk doen: complexiteit voor teams reduceren én voldoende transparantie behouden om workloads te kunnen verplaatsen en reconstrueren. Standaardisatie is waardevol wanneer zij herhaalbaarheid oplevert, niet wanneer zij afhankelijkheden onzichtbaar maakt.

5. Cloud Architecture: “exit-ready” hoort naast “cloud-ready”

Cloud Architecture krijgt de meest directe impuls uit de Data Act. De Commissie legt uit dat providers obstakels voor overstappen en parallel gebruik moeten verwijderen. Vanaf 12 januari 2027 verdwijnen bovendien switching charges, waaronder kosten voor data egress die nodig zijn voor een overstap. [2]

Voor cloudarchitecten verandert daarmee de economische context van exitplanning. De technische kosten verdwijnen niet: migratie, refactoring, testen en tijdelijke dubbele capaciteit blijven bestaan. Maar de regelgeving verschuift de verwachting dat switching in beginsel uitvoerbaar moet zijn.

Daarom hoort bij een cloudarchitectuur een expliciete exit architecture. Niet noodzakelijk een volledig uitgewerkt migratieproject, maar ten minste:

• welke data en configuratie moeten worden geëxporteerd;
• welke services provider-specifiek zijn;
• welke identity- en key-managementafhankelijkheden bestaan;
• hoe observabilityhistorie behouden blijft;
• welke minimale functionaliteit in een alternatieve omgeving nodig is;
• hoe lang een realistische overgang duurt;
• welke test aantoont dat de exit niet alleen op papier bestaat.

De praktische consequentie is dat “cloud-first” volwassen wordt tot “cloud-with-control”: managed services gebruiken waar ze waarde bieden, maar zonder de bestuurbaarheid van de organisatie weg te ontwerpen.

6. Security Architecture: een meldplicht van 24 uur begint bij detecteerbare architectuur

Voor Security Architecture is 11 september 2026 de meest directe datum. De CRA-rapportageplicht vraagt bij relevante gebeurtenissen om een vroege waarschuwing binnen 24 uur en een verdere melding binnen 72 uur. ENISA heeft het Single Reporting Platform ingericht als centraal technisch kanaal voor deze meldingen. [3][4]

Die klok begint niet bij het moment dat een incidentmanager een dossier opent, maar bij het moment waarop de fabrikant zich bewust wordt van de relevante gebeurtenis. Daarom zijn observability, vulnerability intelligence, asset ownership en besluitvorming architectuurvoorwaarden.

Een organisatie kan alleen snel betrouwbaar melden wanneer zij kan beantwoorden:

• Welk product of welke component is geraakt?
• Welke versies en klanten zijn mogelijk getroffen?
• Is er betrouwbare aanwijzing voor actieve exploitatie?
• Wie is de fabrikant of verantwoordelijke actor in de keten?
• Welke mitigation of patch is beschikbaar?
• Welke logs en technische feiten ondersteunen de beoordeling?

ENISA rapporteerde in NIS360 2026 dat de cybersecurityvolwassenheid in kritieke EU-sectoren gemiddeld verbetert, maar ongelijk blijft. Onder meer health, railway, maritime, ICT management services, space, public administrations en watersectoren bevonden zich in de door ENISA gedefinieerde risiczone. Digitale diensten zoals telecom, cloud en datacenters behoren tegelijk tot de meest kritieke categorieën. [7]

Voor securityarchitecten bevestigt dit dat resilience niet alleen draait om preventieve controls. Detectie, herleidbaarheid, leveranciersinformatie en besluitvorming onder tijdsdruk horen evenzeer in het ontwerp.

De gezamenlijke architectuurpatronen

Wanneer de zes disciplines naast elkaar worden gelegd, ontstaan vier patronen die in 2026 steeds belangrijker worden.

1. Eigenaarschap moet machineleesbaar noch impliciet zijn, maar operationeel

Voor ieder kritiek product, datapakket, platform en cloudcontract moet duidelijk zijn wie verantwoordelijk is voor risico, exit, security en melding. Architectuur zonder eigenaarschap levert op crisismomenten vertraging op.

2. Portabiliteit moet getest worden

Een contractuele exitclausule of een theoretisch open formaat is onvoldoende. Kritieke overdrachten moeten periodiek aantoonbaar worden gemaakt: data-export, herstel, configuratiereconstructie en — waar relevant — workloadmigratie.

3. Observability wordt bewijsvoering

Logs, metadata, versies, configuratiehistorie en dependency-informatie zijn niet alleen operationele hulpmiddelen. Ze vormen het bewijs waarmee een organisatie kan reconstrueren wat gebeurde, welke producten geraakt zijn en welke actie nodig is.

4. Platform engineering is governance in code

Interne platformen kunnen architectuurprincipes vertalen naar standaard deployment-, security-, identity- en observabilitypatronen. Daarmee verschuift governance van documenten naar herhaalbare bouwblokken. De architectuurfunctie moet dan wel expliciet eigenaar blijven van de principes die in die platformen worden geautomatiseerd.

Conclusie

De relevante ontwikkeling in 2026 is niet dat regelgeving architectuur “overneemt”. Het omgekeerde gebeurt: regelgeving maakt zichtbaar waar architectuur te vaak abstract is gebleven.

De Data Act dwingt organisaties na te denken over echte interoperabiliteit en switching. De Cyber Resilience Act maakt duidelijk dat productbeveiliging, observability en incidentafhandeling binnen uren moeten kunnen functioneren. Platform engineering biedt ondertussen een technische manier om architectuurprincipes consistent in de uitvoeringslaag te brengen.

De volwassen enterprise-architectuur van 2026 vraagt daarom bij iedere belangrijke digitale capability drie aanvullende vragen: kunnen we aantoonbaar overstappen, kunnen we aantoonbaar begrijpen wat er gebeurt, en kunnen we aantoonbaar snel handelen wanneer het misgaat?

Wie die drie vragen pas bij contractbeëindiging, audit of incident stelt, is te laat. Ze horen vanaf het begin in het ontwerp.

Bronnen

[1] Europese Commissie, *Results of the study on interoperability of data processing services*, 23 februari 2026.

[2] Europese Commissie, *Data Act explained* — switching tussen data-processing services en het verdwijnen van switching charges per 12 januari 2027.

[3] Europese Commissie, *Cyber Resilience Act — Reporting obligations*, bijgewerkt 8 juni 2026.

[4] ENISA, *Frequently Asked Questions — CRA Single Reporting Platform*, bijgewerkt 3 augustus 2026.

[5] Europese Commissie, *Commission publishes new guidance to support timely Cyber Resilience Act implementation*, 27 juli 2026.

[6] CNCF / SlashData, *State of Cloud Native Development Q1 2026*, 24 maart 2026.

[7] ENISA, *NIS360: The bigger picture on maturity and criticality of NIS critical sectors*, 28 mei 2026.