Wat is cloudarchitectuur en waar hoort het thuis?

Cloudarchitectuur beschrijven we in deze opleiding als het ontwerpen en onderbouwen van de samenhang tussen clouddiensten, applicaties, gegevens, verbindingen en operationele verantwoordelijkheden om een bedrijfsuitkomst te realiseren. Dit is onze werkdefinitie. Het werk begint bij het probleem en eindigt bij een uitvoerbaar besluit, inclusief de manier waarop je de werking gaat aantonen. Een lijst met cloudproducten is daarvoor onvoldoende: zij vertelt nog niet hoe een aanvraag correct wordt verwerkt of wie handelt bij uitval.

Een architect onderzoekt vooral beslissingen die verschillende onderdelen tegelijk raken of later kostbaar te veranderen zijn. De keuze voor een databasemodel beïnvloedt bijvoorbeeld transacties, herstel, kosten en migratie. Een providerselectie kan gevolgen hebben voor kennis, contracten en een toekomstige exit. Niet ieder configuratieveld is daarom een architectuuronderwerp. Het wordt relevant wanneer het een eis, afhankelijkheid, risico of structurele veranderbaarheid beïnvloedt.

NIST beschrijft cloud computing aan de hand van beschikbaarstelling op aanvraag, netwerktoegang, gedeelde middelen, elasticiteit en gemeten dienstverlening. Virtualisatie is een mogelijke techniek daaronder. Een organisatie met virtuele servers maar alleen handmatige aanvraagprocessen heeft daarmee nog niet alle eigenschappen van cloud ingericht. Voor de architect is het onderscheid nuttig: sneller voorzieningen krijgen vraagt ook om bevoegdheden, standaarden en een bruikbaar leveringsproces.

We gebruiken een fictieve organisatie, Noordhaven, om de redenering zichtbaar te maken. De oefenfeiten hebben N-codes. Ontwerpvoorstellen zijn geen aanvullende feiten: een managed webdienst is bijvoorbeeld een te onderzoeken keuze, geen reeds aangeschafte voorziening. Later pas je dezelfde denkwijze toe op DeltaLab met eigen D-codes. Dat tweede probleem heeft andere deadlines en werkbelasting; een goed advies mag daardoor op een andere architectuur uitkomen.

De verbinding met andere architectuurdisciplines

Enterprise architecture richt zich in onze indeling op samenhang en richting over veranderingen en organisatieonderdelen heen. Zij kan uitgangspunten meegeven over standaardisatie, investeringen en leveranciersafhankelijkheid. Businessarchitectuur verduidelijkt welke bedrijfsvermogens, waardestromen, informatie en verantwoordelijkheden de verandering moet ondersteunen. Bij Noordhaven helpt dat om onderhoud aanvragen te onderscheiden van werk plannen en factureren. De cloudarchitect hoort niet stilzwijgend te beslissen dat een ontvangstnummer hetzelfde betekent als een ingeplande monteur.

Solution architecture verbindt de verschillende domeinen voor een afgebakende oplossing. Cloudarchitectuur werkt daarin onder meer plaatsing, dienstgrenzen, platformafhankelijkheden en cloudspecifieke operationele keuzes uit. Infrastructuurarchitectuur onderzoekt ook onderliggende compute, netwerk, opslag en beheer, binnen én buiten de cloud. Dataarchitectuur maakt betekenis, eigenaarschap, gebruik en lifecycle van gegevens samenhangend. Securityarchitectuur ontwerpt hoe risico’s worden beheerst. Deze perspectieven overlappen: een workloadidentiteit raakt security, een replicatiekeuze data en infrastructuur.

Deze indeling is een werkverdeling voor de cursus, geen universele functiebeschrijving. In een klein team kan één architect alle perspectieven vertegenwoordigen. Leg dan alsnog vast wie het bedrijfsrisico accepteert, wie een technisch ontwerp uitwerkt en wie de dienst gaat bedienen. Disciplines benoemen helpt om vragen te stellen die anders tussen verantwoordelijkheden verdwijnen.

Van bedrijfsprobleem naar een toetsbare ontwerpbeslissing

Noordhaven verliest nu de mogelijkheid tot indienen als ERP uitvalt. Begin met de betekenis van accepteren: volgens N01 is dat duurzame opslag plus een ontvangstnummer. Onderzoek vervolgens of ERP daarvoor direct nodig is. Zo ontstaat een oplossingsrichting: registreer de aanvraag zelfstandig en laat ERP daarna verwerken. Dit is nog geen bewezen oplossing. Je moet ook uitwerken hoe dubbele orders worden voorkomen, hoe de klant de status ziet en wat er gebeurt wanneer ERP langdurig onbereikbaar blijft.

Je ontwerpdocumenten beantwoorden verschillende vragen. Een contextplaat toont partijen en afhankelijkheden. Een datastroom beschrijft wat tussen onderdelen beweegt. Een beslisdocument verklaart de keuze en alternatieven. Een herstelplan beschrijft handelen bij verstoring. Een kostenmodel en roadmap maken het besluit financieel en organisatorisch uitvoerbaar. Gebruik één aanvraagidentiteit en dezelfde eisen in al die documenten: anders kunnen afzonderlijk aannemelijke onderdelen samen toch een onwerkbare oplossing vormen.

Hoe je met deze opleiding werkt

Lees eerst de uitleg en verklaar het concept in eigen woorden. Doorloop daarna het uitgewerkte ontwerp: probeer bij iedere stap te voorspellen waarom die nodig is. Maak vervolgens de begeleide oefening vóór je hints en uitwerking opent. Pas daarna werk je de zelfstandige dossieropdracht en de open ontwerpverdediging uit. Een andere keuze dan het voorbeeld kan goed zijn als jouw feiten, voorwaarden en bewijs haar dragen.

Basiskennis betekent hier dat je de rol van een webapplicatie, database en netwerkverbinding kunt uitleggen. Kun je dat nog niet, begin dan met de begrippenlijst en de uitleg van compute en opslag; noteer waar je aanvullende begeleiding nodig hebt. Het leerresultaat is een onderbouwd ontwerp voor afgebakende casussen. Een kennistoets of leesmarkering op zichzelf toont geen zelfstandige vakbekwaamheid aan.

Kernpunt

Cloudarchitectuur verbindt bedrijfsuitkomsten met technische keuzes, verantwoordelijkheden en bewijs; de andere architectuurdisciplines leveren noodzakelijke perspectieven.

Denk zelf na

De directie vraagt twee cloudregio’s. Welke vraag stel je eerst, en met wie bespreek je die?

Uitgewerkt voorbeeld

Vraag welke bedrijfsverstoring en welk verlies men wil voorkomen. Bespreek de geaccepteerde uitval en dataverlies met de proceseigenaar, onderzoek met data-, security- en infrastructuurperspectief de afhankelijkheden en vergelijk daarna mogelijke herstelpatronen. Twee regio’s zijn een mogelijke maatregel, nog geen uitgewerkte eis.