Naar de lesinhoud
EAW · E-learningsEerste module · vrij toegankelijk

Module 1 · Cloudstrategie en workloadkeuze

Van ambitie naar architectuurvraag

“Wij gaan naar de cloud” beschrijft een richting, maar nog geen probleem dat een architect kan oplossen. Begin bij een bedrijfsuitkomst: wie moet welke handeling kunnen uitvoeren, onder welke omstandigheden en met welk bewijs van succes? Bij Noordhaven is dat geen draaiende server, maar een duurzaam geregistreerde onderhoudsaanvraag met een ontvangstnummer. Dat verschil bepaalt welke afhankelijkheden in je ontwerp en je meting horen.

Splits uitspraken in requirements, constraints, aannames en onbekenden. Een requirement beschrijft gewenst gedrag of kwaliteit. Een constraint begrenst de oplossingsruimte, bijvoorbeeld het ERP dat voorlopig blijft staan. Een aanname is een voorlopig uitgangspunt dat je moet toetsen. Een onbekende is een expliciet informatiegat. N04 is een vastgestelde eis; “een tweede regio verdubbelt alle kosten” is zonder ontwerp en prijsmodel slechts een aanname.

Maak een kwaliteitsscenario met stimulus, omgeving, betrokken systeem, respons en maat. Tijdens de campagnebelasting uit N02 moet een geldige indiening binnen de meetgrens uit N04 succesvol eindigen; p95 blijft onder twee seconden. Leg ook vast hoe je geldige verzoeken telt, hoe clientfouten worden behandeld en wie het resultaat accepteert. Een product-SLA van een cloudleverancier meet niet vanzelf dezelfde handeling.

Het systeem van interesse omvat webapplicatie, duurzame registratie, identiteitsvoorziening en verbinding met ERP voor zover die de gebruikersuitkomst beïnvloeden. Het ERP valt buiten de migratiescope, maar blijft binnen de afhankelijkheidsanalyse. “Buiten scope” betekent dat je het niet verandert; het betekent niet dat de afhankelijkheid verdwijnt.

Waarom de meetgrens je ontwerp verandert

Een kwaliteitskenmerk zoals beschikbaarheid krijgt betekenis door het object dat je meet. Meet je alleen of de webserver reageert, dan kan een foutpagina als technisch antwoord meetellen. Meet je een duurzaam geaccepteerde onderhoudsaanvraag, dan horen validatie, opslag en ontvangstnummer bij succes. Teken daarom eerst het begin en einde van de handeling. Bepaal ook hoe je indieningen waarneemt die de applicatie door een netwerkfout nooit bereiken; alleen serverlogs kunnen deze klanthinder missen.

p95 onder twee seconden betekent dat het 95e percentiel van de gemeten responstijden onder die grens ligt. Het zegt niet dat iedere aanvraag binnen twee seconden klaar is. Leg vooraf vast welke requests in deze latencyverdeling zitten en rapporteer fouten daarnaast afzonderlijk. Anders kan het verwijderen van mislukte requests uit de meting de rapportage verbeteren terwijl klanten juist vaker vastlopen. Een synthetische proef helpt de keten volgen, maar vervangt echte gebruikersmetingen niet volledig.

Vertalen zonder ontbrekende eisen zelf te verzinnen

Noordhaven kan volgens N01 een ontvangstnummer geven voordat ERP een order heeft geboekt, mits de aanvraag duurzaam is geregistreerd. Daaruit volgt geen toegestane ERP-vertraging. Leg die als open beslispunt voor aan de proceseigenaar. Een architect mag een technische wachtrij ontwerpen, maar kan zonder afspraak niet stellen dat een klant twee dagen wachten acceptabel vindt. Splits dus het indieningsdoel en het vervolgproces in afzonderlijke meetbare uitkomsten.

Werk met een eisregel die bron, eigenaar, meetdefinitie en acceptatie bevat. Voor N04 is de product owner de eigenaar van het gebruikersdoel; een technisch team levert het testbewijs. Ontbreekt de absolute piekinstroom, dan heeft zesmaal normaal nog geen betekenis voor de benodigde capaciteit. De maandtotalen bepalen die piek niet. Vraag een tijdverdeling op en gebruik tot die tijd expliciet benoemde oefenscenario’s, zoals in het wachtrijlab.

Een zwakke en een bruikbare redenering

De cloud is schaalbaar, dus de campagne past, is een onbewezen sprong van platformeigenschap naar ketenprestatie. Een bruikbare redenering luidt: we verwachten de weblaag te kunnen uitbreiden, onderzoeken databaseverbindingen en de ERP-limiet en testen het ontvangstnummer bij de vastgelegde instroom. Dat levert een toetsbaar ontwerp op. Als het doel niet wordt gehaald, maakt de meting zichtbaar welk onderdeel of welke businessafspraak moet veranderen.

Kernpunt

Een architectuurvraag verbindt een gebruikersuitkomst aan een meetbaar criterium en een besliseigenaar.

Denk zelf na

Welke Noordhaven-uitspraak is een harde randvoorwaarde en welke informatie ontbreekt nog voor een cloudkeuze?

Uitgewerkt voorbeeld

N03 begrenst de plaatsing: ERP blijft 18 maanden in het datacenter. N16 bevat nog te onderzoeken volumes en quota. De architect registreert voor ieder informatiegat een eigenaar en beslismoment.

Probeer het zelf

Je oefent zonder account. Je antwoorden worden niet op je account opgeslagen. Ze verdwijnen wanneer je deze pagina verlaat. Dit is geen officiële beoordeling.

Terug naar het moduleoverzicht

Verder met de volledige training?

In de volledige training werk je door aan de vervolgmodules en bewaar je je voortgang op je account.

Bekijk de volledige training

Al toegang? Ga naar je cursus