Bouw voor vandaag. Plan voor morgen. Plan voor falen.
Ook beschikbaar in 28 talen
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Module 5 van 7 in het hoofdstuk Denken als een data-architect, het eerste hoofdstuk van de cursus Data Architect. Elke module staat op zichzelf. Vorige: Architectuur is de kunst van het afwegen · Volgende: Ken je gereedschap: de negen vragen
De vraag die deze module beantwoordt: Hoe ontwerp je voor de eisen van vandaag terwijl je plant voor groei en voor falen?
Een van de makkelijkste fouten in architectuur is alleen ontwerpen voor de eisen die voor je liggen. We hebben een project, een backlog en eisen. We bouwen iets dat eraan voldoet. Het werkt, en we roepen de overwinning uit. Zes maanden later verandert de business, of groeit de data, of wil een andere business unit het gebruiken, of nemen we een bedrijf over, of moet een nieuw systeem koppelen, of faalt er iets waar niemand op had gerekend.
Niets daarvan zou een architect moeten verrassen. We kunnen niet alles voorspellen wat er gaat gebeuren, maar we kunnen ontwerpen in de wetenschap dat er iets gaat gebeuren. Daarom bekijk ik architectuur door drie lenzen:
Bouw voor vandaag. Plan voor morgen. Plan voor falen.
Je hebt ze alle drie nodig.
Bouw voor vandaag
Section titled “Bouw voor vandaag ”Architectuur begint bij het probleem dat we echt hebben. Dat klinkt vanzelfsprekend, maar architecten kunnen de omgekeerde fout maken van kortetermijndenken: we kunnen over-architecteren. Wat als we twaalf bedrijven overnemen, een miljard klanten krijgen, uitbreiden naar 40 landen en elk systeem realtime integratie nodig heeft? Misschien. Maar zijn dat echte mogelijkheden, of verzinnen we problemen? Architectuur gaat niet over het meest geavanceerde systeem bouwen dat we kunnen bedenken. Het gaat over het passende systeem bouwen.
Begin dus bij vandaag: wat de business nodig heeft, de echte volumes, gebruikers en transacties, hoe vaak de data verandert en hoe snel ze moet bewegen, wie toegang nodig heeft, en waar de data vandaan komt en naartoe gaat. En vooral: waarom? Die antwoorden geven ons iets concreets om te ontwerpen.
Zoek de impliciete eisen
Section titled “Zoek de impliciete eisen ”De eisen die je krijgt zijn niet per se alle eisen die je hebt. Er zijn bijna altijd impliciete eisen.
De business zegt: “We willen klantgegevens in Salesforce.” Goed. Dan moet iemand eigenaar van die gegevens zijn en beslissen hoe actueel ze moeten zijn. We moeten weten wat er gebeurt als het bronsysteem plat ligt, hoe we merken dat synchronisatie faalt, en welke kant wint als Salesforce en de bron het oneens zijn. We hebben een bewaartermijn nodig, een toegangsmodel, een beslissing over gevoelige velden en een manier om slechte data te corrigeren.
Niets daarvan stond in de user story. Het is allemaal toch architectuur. Een groot deel van architect worden is leren de vragen te herkennen die nog niet gesteld zijn.
Ken je getallen
Section titled “Ken je getallen ”Ik dring er bij architecten voortdurend op aan om te kwantificeren. Vertel me niet dat er veel data is; vertel me hoeveel. Tienduizend, tien miljoen, honderd miljoen, een miljard? Dat zijn heel verschillende architecturen. Vertel me niet dat de integratie vaak draait: elk uur, elke minuut, duizend keer per seconde? Vertel me niet dat we snel groeien. Hoe snel?
Als ik geen beter getal heb, is mijn uitgangspunt 30 procent groei per jaar. Het is geen voorspelling; het is een dwangmiddel. Als iemand me vertelt dat we vandaag 10 miljoen records hebben, wil ik niet dat de discussie bij 10 miljoen stopt. Bij 30 procent per jaar zitten we volgend jaar op ongeveer 13 miljoen, het jaar daarna op 17 miljoen en het jaar daarna rond de 22 miljoen. Laten we het nu over het ontwerp hebben. Als de business zegt dat 30 procent belachelijk is, prima: geef me het echte getal. Het gaat erom dat groei deel wordt van de architectuurdiscussie.
Ik noem dit Steve’s aantal nullen. Eén extra nul kan je architectuur volledig veranderen. Tienduizend, honderdduizend, een miljoen, tien miljoen, honderd miljoen: de functie is niet veranderd, en de eis misschien ook niet, maar de architectuur wel.
Herinner je je de afspraken uit module 1? Laten we er de echte getallen op zetten. Meer dan 1.200 locaties, 100 afspraken per locatie per dag, zes dagen per week, ongeveer 305 dagen per jaar. Dat zijn in het eerste jaar meer dan 36 miljoen afspraken. Elk bezoek maakt twee records aan, dus meer dan 73 miljoen records. Bewaar nu vijf jaar historie, met 30 procent groei per jaar, en je zit boven de 650 miljoen records. Dezelfde functie, dezelfde eis. Een paar nullen meer, en een heel andere architectuur.
Plan voor morgen
Section titled “Plan voor morgen ”Zodra ik vandaag begrijp, kijk ik vooruit: wat gaat er redelijkerwijs veranderen? Volume hoort erbij, maar morgen is niet alleen meer. Het kan ook anders betekenen: meer producten, business units en landen; andere privacyeisen; nieuwe kanalen en integraties; een fusie of overname; een nieuwe stamgegevensstrategie of een nieuw analyseplatform; een AI-agent die informatie gebruikt die alleen voor mensen ontworpen was.
Daarom vind ik het zo belangrijk of de architectuur kan groeien door toevoeging in plaats van voortdurende wijziging. Als de business een product toevoegt, kan het model dat aan? Als een ander systeem de data nodig heeft, kunnen we die netjes beschikbaar stellen? Als het volume een sprong maakt, kunnen we ergens heen? Als de bedrijfsstructuur verandert, moeten we het datamodel dan uit elkaar trekken? We proberen de toekomst niet perfect te voorspellen. We proberen ons niet klem te zetten.
Bouw morgen niet vandaag
Section titled “Bouw morgen niet vandaag ”Er zit een balans in. Plannen voor morgen betekent niet het systeem van morgen vandaag bouwen. Als we 100.000 records hebben en er over vijf jaar misschien 100 miljoen hebben, betekent dat niet dat we nu de architectuur voor 100 miljoen records bouwen. Die kan kosten en complexiteit meebrengen die we nog niet nodig hebben.
De vraag waarop ik een antwoord wil, is: kan de architectuur van vandaag uitgroeien tot die van morgen? Als we eenvoudig kunnen beginnen met een duidelijke weg vooruit, is dat vaak beter dan jaren te vroeg de prijs van complexiteit betalen. Het gevaar is niet klein beginnen. Het gevaar is ergens beginnen waar je nergens heen kunt.
Plan voor falen
Section titled “Plan voor falen ”Nu het deel waar niemand graag over praat: dingen falen. Ik heb nog nooit een systeem ontworpen waarin elk onderdeel altijd beschikbaar bleef, elke integratie slaagde, elke gebruiker perfecte data invoerde en elk extern systeem zich precies gedroeg zoals gedocumenteerd. Ontwerp dat systeem dus ook niet.
Vraag wat er kan falen, en vraag dan wat er gebeurt als het faalt. Een integratie krijgt een time-out. Een API weigert een verzoek. Een nachtelijke load verwerkt 800.000 records en faalt op 200.000. Een bronsysteem ligt plat. Een gebruiker voert ongeldige data in. Een externe identificator duikt twee keer op. Een systeem stroomopwaarts verandert het formaat van een waarde zonder de veldnaam te veranderen. Een proces slaagt in het ene systeem en faalt in het andere. Dat zijn geen ongewone randgevallen. Zo ziet productie eruit.
Gedeeltelijk succes is nog steeds falen dat je moet begrijpen
Section titled “Gedeeltelijk succes is nog steeds falen dat je moet begrijpen ”Gedeeltelijke mislukkingen zijn extra gevaarlijk in data-architectuur. Stel je voor dat je een miljoen records verplaatst, en het proces meldt dat het voltooid is. Mooi. Maar zijn er een miljoen aangekomen, of 999.997, en welke drie ontbreken? Misschien zijn er 200.000 mislukt, sommige twee keer aangemaakt, of is alles aangekomen en zijn sommige velden niet goed getransformeerd.
“Job voltooid” is niet hetzelfde als de data klopt. Een data-architect denkt aan reconciliatie: hoe weten we wat er had moeten gebeuren, wat er echt gebeurd is en wat het verschil is? En wat doen we eraan?
Dit doe ik als de systemen complex worden. Records gaan van A naar B, van links naar rechts. Dan stuurt B iets terug: een bevestiging voor elk record dat het heeft ontvangen en opgeslagen. Nu kan A vergelijken wat het verstuurde met wat bevestigd is. Heeft elk record zijn bevestiging, dan is de run geslaagd. Ontbreken er bevestigingen, dan niet, wat de jobstatus ook zegt, en weten we precies achter welke records we aan moeten: opnieuw proberen, naar een mens doorsturen of een melding geven.
Faal netjes
Section titled “Faal netjes ”Als er iets faalt, wil ik weten wat het systeem daarna doet: of het opnieuw probeert, en automatisch of niet; wat er gebeurt als dezelfde transactie twee keer verwerkt wordt; waar mislukte records heen gaan, en of goede records langs een slechte blijven doorstromen; wie een melding krijgt, met welke informatie, en hoe die de mislukking opnieuw afspeelt; en hoe een gebruiker erachter komt dat er iets misging.
En vooral: kunnen we herstellen zonder het probleem erger te maken? Een strategie voor opnieuw proberen die dubbele data maakt, is niet echt een herstelstrategie. Goede architectuur gaat uit van falen en geeft ons een weg terug.
Monitor wat ertoe doet
Section titled “Monitor wat ertoe doet ”Plannen voor falen zonder monitoring is niet echt plannen. Als een integratie om 02.00 uur faalt en niemand het merkt tot een klant drie dagen later belt, hadden we geen operationele architectuur. We hadden hoop.
Bepaal wat zichtbaar moet zijn: is het proces gedraaid, hoe lang duurde het, hoeveel records zijn verwerkt, hoeveel geslaagd en mislukt? Wijken de volumes ineens af van normaal? Groeit de achterstand, nemen de fouten toe? Architectuur houdt niet op als de deployment slaagt. Iemand moet dit systeem morgen beheren, en dat hoort bij het ontwerp.
Denk in alle drie de richtingen
Section titled “Denk in alle drie de richtingen ”Blijf de drie lenzen de rest van deze cursus toepassen. Als we een datamodel ontwerpen: werkt het vandaag, kan het morgen groeien, en wat gebeurt er als de data verkeerd of onvolledig is? Een integratie: verplaatst ze de data van vandaag, kan ze het volume en de systemen van morgen aan, en wat gebeurt er als één kant plat ligt? Grote datavolumes: wat hebben we vandaag, waar gaan de getallen heen, en hoe herstellen we als een grote operatie maar gedeeltelijk slaagt?
De technologie verandert van hoofdstuk tot hoofdstuk. De vragen niet.
Architectuur bestaat door de tijd heen
Section titled “Architectuur bestaat door de tijd heen ”Een developer kan soms naar een eis kijken en vragen: “Werkt dit?” De architect moet meer vragen: werkt het vandaag, werkt het morgen nog, en wat gebeurt er als het helemaal niet werkt? Die drie vragen brengen ons voorbij de implementatie, het leven van het systeem in.
Je gaat niet elke toekomstige eis voorspellen of elke mislukking voorkomen. Dat is niet het doel. Het doel is iets bouwen dat past bij wat we vandaag weten, onszelf ruimte laten voor morgen, en een plan hebben voor als de werkelijkheid niet meewerkt.
Bouw voor vandaag. Plan voor morgen. Plan voor falen. Die drie lenzen gaan we steeds weer gebruiken.
Wat een architect hier beslist
Section titled “Wat een architect hier beslist ”- Wat de echte volumes en de groei zijn, en welke getallen het ontwerp zouden veranderen.
- Welke impliciete eisen de business nog niet heeft uitgesproken.
- Hoe het ontwerp van vandaag kan uitgroeien tot dat van morgen, zonder het systeem van morgen vandaag te bouwen.
- Wat er gebeurt als er iets faalt: herstel, reconciliatie en monitoring.