IT modernization & optimization

IT-modernisering richt zich op het upgraden of ombouwen van bestaande eigen systemen: technische schuld wegwerken, legacy migreren, architectuur gereedmaken voor AI. De-SaaS-ing gaat een stap verder: het vervangen van externe SaaS-abonnementen door maatwerksoftware die je zelf beheert. Beide kunnen onderdeel zijn van een moderniseringstraject, maar de keuze hangt af van de aard van het systeem, de abonnementskosten en de mate van vendor lock-in.

Technische schuld wordt strategisch riskant wanneer het nieuwe ontwikkeling merkbaar vertraagt, wanneer het de adoptie van nieuwe technologieën blokkeert, of wanneer het bijdragen aan de IT-kennis van het team ondermijnt.

FinOps is een aanpak waarbij IT, Finance en Business gezamenlijk verantwoordelijkheid nemen voor clouduitgaven. Het gaat niet alleen om bezuinigen, maar om weloverwogen besluiten over welke workloads hun kosten rechtvaardigen.

Door gefaseerd te werken: eerst in kaart brengen welke systemen kritiek zijn, dan stap voor stap ombouwen terwijl de bestaande systemen blijven draaien. AI versnelt dit aanzienlijk.

AI-readiness betekent: data toegankelijk en gestructureerd, koppelingen aanwezig tussen systemen, en infrastructuur die schaalt. De meeste organisaties hoeven niet alles opnieuw te bouwen -- wel gerichte aanpassingen op de plekken waar AI data nodig heeft.

Traditionele monitoring signaleert dat er iets misgaat. AIOps combineert die data met AI om patronen te herkennen en de oorzaak direct te benoemen, in plaats van alleen een alarm te geven.

Nee. Een AI-agent werkt ook op losse logs en metrics. Een CMDB voegt wel context toe, zoals eigenaarschap en omgeving, waardoor de agent scherpere antwoorden geeft.

Alles met structurele logs of events: webserver logs, infrastructuurmetrics, database-logs, identity-logs zoals Entra ID en CMDB-data. Meer aangesloten bronnen geven een completer beeld.

Dat hangt af van de inrichting. De meeste agents detecteren en wijzen naar de oorzaak. Zelf oplossen, remediation, is een vervolgstap met duidelijke grenzen.

Dat verschilt per databron. In dit artikel stond de eerste versie binnen dagen, en werd hij iteratief verbeterd. Een specifieke usecase, zoals sign-in problemen, gaat sneller dan een brede performance-agent.

De data is er wel, maar ze is complex, verspreid over meerdere velden en bronnen en vaak vervuild. Toegang vraagt specialistische kennis of query-talen, waardoor alleen een kleine groep specialisten ermee werkt. Tijdens incidenten of changes ontbreekt daardoor snel inzicht in de impact.

Elastic combineert schaalbare zoektechnologie, realtime analytics en AI-integratie in een platform. Je zoekt razendsnel over miljoenen configuratie-items, voegt dankzij het flexibele schema eenvoudig nieuwe velden toe en koppelt logs, metrics en kostendata. Rechtenstructuren, audit logging en datasoevereiniteit zijn ingebouwd voor gebruik in productie.

Via Elastic Agent Builder begrens je de acties van de agent: alleen goedgekeurde ES|QL-queries worden uitgevoerd. Elk antwoord is zo herleidbaar naar echte data in plaats van verzonnen tekst. Dat maakt de uitkomsten transparant en vergroot het vertrouwen van servicedesk, engineers en management.

Een Proof of Concept staat in 2 tot 4 weken. Een implementatie in productie duurt 6 tot 12 weken, afhankelijk van de complexiteit van de bronsystemen. Tijdens de implementatie leest de agent alleen data en wijzigt niets, waardoor de adoptie veilig en beheersbaar blijft.

Bij Agentic ITOps werken meerdere gespecialiseerde AI-agents samen, elk met een eigen rol: configuratie, incidentanalyse, FinOps of compliance. De kracht zit in het samenspel. De CMDB Agent is de eerste stap en blijft de stabiele kern: een uitlegbaar fundament met context waarop de andere agents terugvallen.

Vraag welk deel van de code door AI wordt gegenereerd, hoeveel mensen er in een team zitten en welke rollen zijn verdwenen. Vraag ook naar hun specificatie- en validatieproces, want daar zit bij hoge volwassenheid het echte werk. Kan je leverancier dat niet concreet onderbouwen, dan zit die op niveau 1.

Begin klein. Kies een applicatie of een releasetraject en spreek daar een vaste prijs per resultaat af, met heldere acceptatiecriteria. Meet doorlooptijd en kwaliteit tegen je huidige sprintkosten. Werkt het, dan breid je uit bij contractverlenging. Zet de meting vast in je contract, anders blijf je afhankelijk van rapportages van de leverancier.

Dat hangt af van de grootte van je applicatielandschap en het aantal partijen dat eraan werkt. Reken voor een eerste stap op een setup-programma van enkele weken, waarin je een applicatie, een team en het framework inricht. De businesscase reken je door tegen je huidige jaarlijkse ontwikkelbudget.

Zonder kaders ontstaat er code die niemand reviewt, die buiten je architectuur valt en die gevoelige data via willekeurige tools laat lopen. Binnen een enterprise wil je vaste modellen, vaste repositories, geautomatiseerde tests en logging van wat AI genereert. Dan houd je de snelheid van vibecoding en blijft je landschap beheersbaar.

AI-native ontwikkelen verandert niets aan je verplichtingen: je blijft verantwoordelijk voor waar code en data staan. Leg vast welke modellen gebruikt worden, of prompts en code als trainingsdata dienen en in welke regio de verwerking plaatsvindt. Vraag je leverancier om een verwerkersovereenkomst die de AI-tooling expliciet benoemt.

Begin met de technische contracten: de API-endpoints en datamodellen die 1:1 overeind moeten blijven. Die leg je vast voordat een AI agent iets genereert, anders breken bestaande integraties. Tests hoef je niet vooraf te bouwen, de agents genereren zelf unit- en integratietests bij de nieuwe code.

Die pak je met human-in-the-loop op: een senior developer werkt de complexe gevallen zelf af. Systeemintegraties zijn daarbij het lastigste stuk, daar ligt de automatisering rond 70 tot 80 procent. Reken dus op handwerk bij koppelingen en uitzonderlijke bedrijfsregels.

Reken op weken in plaats van de maanden die handmatig hercoderen kost. Het extraheren van de specificaties gaat relatief snel, de tijd zit in het valideren van de gegenereerde code en het afmaken van complexe features. Hoe schoner de legacy architectuur, hoe korter het traject.

Leg vast naar welke doelstack en welk paradigma je gaat, want je bouwt opnieuw op in plaats van 1:1 te kopiëren. Denk aan monoliet naar microservices of WPF naar Flutter. Spreek daarnaast af wie de gegenereerde code reviewt, meestal een senior developer of architect.

Als je applicatie standaard patronen volgt, en dat geldt voor ongeveer 80 procent van de systemen. Simpele CRUD-features halen 90 tot 95 procent automatisering, code met veel God classes vraagt meer handwerk. Een korte scan van de codebase geeft dat vooraf al aan.

AST-transformaties vertalen code letterlijk met platform-specifieke parsers en halen daarmee volgens Blis' ervaring nooit meer dan 60 tot 70% automatisering. AI-gedreven modernisering begrijpt eerst de intentie achter de code en laat een AI-agent die vervolgens vers implementeren. Dat brengt de automatisering naar 85 tot 95% voor de meeste features.

Een Universal Application Model legt de complete essentie van een applicatie vast, los van de oorspronkelijke programmeertaal of het framework. Blis bouwt dit met drie lagen: exacte technische contracten, semantische context voor de AI en het design systeem van de applicatie. Die combinatie houdt de nieuwe applicatie functioneel en visueel gelijk aan het origineel.

Dat verschilt per type werk: simpele CRUD-features automatiseert Blis voor 90 tot 95%, complexe businesslogica voor 80 tot 85% en UI/UX-implementatie voor 85 tot 90%. Complexe uitzonderingen vragen nog altijd menselijke input. Perfecte automatisering hoeft geen doel te zijn: 85 tot 95% is al een enorme sprong.

Ja, omdat Blis werkt met semantische specificaties in plaats van letterlijke codevertaling, zijn paradigmawissels mogelijk tijdens de rebuild. Denk aan React class components omzetten naar hooks, een monolith opsplitsen in microservices of een WPF-desktopapp herbouwen als Flutter-app. De keuze voor een nieuwe architectuur hangt niet meer vast aan de structuur van de oude code.

Legacy systemen hebben vaak maar 0 tot 20% testdekking. Blis' AI-agents genereren bij een modernisering automatisch unit tests, integration tests, end-to-end tests en property-based tests. Dat brengt de dekking bij de nieuwe applicatie in de praktijk dicht bij 100% vanaf de eerste dag.

Fusion development is het doorbreken van de 'glazen muur' tussen gebruikers en de makers van software. Citizen developers, developers en IT-beheerders werken samen in één multidisciplinair team aan een business-uitdaging.

Zodra een koppeling met een extern systeem nodig is, of het Power Platform de functionaliteit nog niet biedt. De developer bouwt dan de integratie, terwijl de citizen developer de rest van de oplossing met Power Platform blijft bouwen.

Dan kun je de app opschalen en verder ontwikkelen op Azure, met de kennis die al binnen het fusion development-team aanwezig is. Zo groeit een oplossing mee zonder dat je van team hoeft te wisselen.

Het is een connector die een developer bouwt en publiceert in het Independent Publisher Connector Program van Microsoft, zodat andere Power Platform-ontwikkelaars hem kunnen hergebruiken. Zo deel je uitbreidingen breder dan binnen één project.

Door een app te verpakken in een solution kunnen citizen developers hem zelf beheren, delen of hergebruiken zonder code te schrijven. Azure DevOps voegt daar versiegeschiedenis en gescheiden ontwikkel-, test- en productieomgevingen aan toe.

ALM omvat de mensen, het beleid en de technologie die nodig zijn om een oplossing te beheersen van concept tot uitfasering. Voor Power Platform-oplossingen voorkomt het dat eindgebruikers ongecontroleerd blijven bouwen.

Blis Digital onderscheidt zes fases: plan, develop, test, release, operate en learn. Elke fase heeft eigen keuzes, van het in kaart brengen van licentiekosten tot het opzetten van gescheiden test- en productieomgevingen.

Ook een Power Platform-app kan integraties, functionaliteit en gebruikerservaring verkeerd afhandelen zonder dat je dat direct ziet. Een softwaretester spoort daarom al in de plan-fase onduidelijkheden in requirements op, en test daarna de werkende oplossing.

Het Power Platform Admin Center en de Power Platform Build Tools for Azure DevOps vormen de basis, aangevuld met de Power Platform CLI en PowerShell Modules. Daarmee automatiseer je beheertaken die anders los en handmatig gebeuren.

De starterkit geeft via een Power BI-dashboard in één oogopslag inzicht in alle Power Platform-oplossingen binnen een tenant, ook die buiten het eigen team gebouwd zijn. Dat overzicht is de basis om van reactief naar proactief beheer te gaan.

Het is een volwassenheidsmodel, gebaseerd op het Capability Maturity Model, met vijf fases voor het opschalen van Power Platform-gebruik in een organisatie. Per fase staan concrete stappen, best practices en verantwoordelijkheden per discipline beschreven.

De implementatie van het Power Platform krijgt vaak meer aandacht dan het daadwerkelijke gebruik ervan, terwijl adoptie vooral een verandertraject is. Zonder begeleiding, ondersteuning en opleiding van business users blijft veel potentieel onbenut.

Fusion Teams brengen citizen developers, full-stack developers en IT Pro's samen, met eigen groeifases van eerste pilots tot een gedragen visie op development en support. Dat sluit aan op wat Blis Digital fusion development noemt.

Nee, met een Microsoft 365-licentie zitten de belangrijkste onderdelen van het Power Platform er meestal al bij. Je begint met het bepalen van een concrete usecase, zoals een BI-dashboard of een proces automatiseren.

Microsoft biedt verschillende leerpaden aan, en op YouTube staan talloze tutorials over specifieke onderdelen van het platform. Blis Digital helpt daarnaast met een inspirerende workshop, of door gewoon samen aan je eerste app te beginnen.

Playwright, Cypress en Jest staan als eerste op de lijst. Playwright simuleert gebruikersinteracties in meerdere browsers, Cypress geeft snelle, real-time testresultaten voor JavaScript en Jest unit-test losse PCF-componenten voordat ze in de app landen.

Op dit moment gebeurt dat vooral handmatig, wat inefficiënt en foutgevoelig is en weinig plezier oplevert voor developers. Dat is precies de reden waarom Blis testtools als Playwright, Cypress en Jest aan de DevKit wil toevoegen.

De DevKit gaat TypeScript-definities automatisch genereren op basis van Dataverse-entiteiten, zodat je dit niet meer handmatig hoeft te typen. Verandert het datamodel, dan werk je de types met een paar klikken bij, wat fouten voorkomt en het ontwikkelproces versnelt.

Werk je met een verouderd model in je testomgeving, dan rol je mogelijk ongemerkt foutieve code uit die je later moet herstellen. Blis lost dit nu op met goede afstemming met de klant en wil dit in de toekomst geautomatiseerd signaleren.

Vervelend, herhalend handwerk drukt de motivatie van developers, en minder gemotiveerde ontwikkelaars zijn minder productief en leveren mindere kwaliteit. Daarom besteedt Blis net zoveel aandacht aan het scherp houden van het eigen gereedschap als aan de software die klanten krijgen.

Storybook is een ontwikkelomgeving voor React die het effect van codewijzigingen direct laat zien, zonder dat je steeds naar Power Pages moet publiceren. Zo werk je aan losse PCF-componenten en heb je meteen documentatie op orde.

Een Power Pages-app draait om data uit Dataverse en stelt zonder die data weinig voor, terwijl handmatig data kopiëren of dummy-data genereren onhandig, traag en foutgevoelig is. Daarom bouwde Blis een proxy die Storybook rechtstreeks met de Power Pages-API verbindt.

De proxy voegt beveiliging en autorisatie toe, zodat gebruikers alleen toegang krijgen tot data waarvoor ze geautoriseerd zijn. Dat geeft een realistisch beeld van hoe een app in de praktijk werkt en borgt dat alles wat je bouwt veilig en compliant is.

Je bent af van het steeds opnieuw deployen en verversen om het resultaat van een codewijziging te zien. Voor Blis' developers is werken zonder Storybook inmiddels bijna ondenkbaar, omdat het de ontwikkelcyclus voor PCF-componenten flink verkort.

Het derde en laatste deel gaat over het geautomatiseerd testen van Power Pages en over de roadmap van de ontwikkeltoolkit, zoals automatische TypeScript-types en makkelijker authenticeren. Zo bouw je stap voor stap aan een vollediger ontwikkelproces.

Meer dan de interne site die Microsoft er zelf van maakt: met Power Pages bouw je krachtige klantportalen en self-serviceomgevingen waarin je veilig data deelt met klanten en medewerkers. In theorie kun je er zelfs een B2C-portal mee bouwen.

Niet helemaal: contentpagina's maken en data uit Dataverse tonen kan snel en met weinig skills, maar voor complexere functionaliteit heb je full-code kennis nodig. Dat maakt Power Pages een goed voorbeeld van fusion development, waar low-code en full-code samenkomen.

Liquid is een templatetaal die op HTML lijkt en snel te leren is, ideaal voor simpele taken zoals één tabel uit Dataverse tonen. PCF-componenten vragen meer ontwikkelervaring, zoals React, maar geven veel meer vrijheid en controle voor complexere functionaliteit.

Vooral als performance een belangrijke eis is, omdat Liquid server-side gerenderd wordt en dus voor snellere laadtijden zorgt. In de praktijk gebruikt Blis het niet vaak, omdat klanten zelf-serve taken die met Liquid kunnen ook vaak zelf oppakken.

Power Pages is een krachtig platform, maar de beschikbare ontwikkeltools schieten tekort voor snel, lokaal ontwikkelen, testen en deployen. Daarom bouwde Blis een eigen DevKit, waarover de volgende twee delen van deze serie meer vertellen.

No-code bouw je volledig met drag-and-drop, zonder code. Bij low-code werk je ook grotendeels grafisch, maar kun je complexere logica vormgeven in scripts. Citizen developers zijn businessmensen die zonder diepgaande technische kennis toch software bouwen.

Omdat je een app in elkaar klikt in plaats van code te schrijven, lijkt het alsof hij meteen naar productie kan. Maar ook low-code kent miscommunicatie tussen wie de app bouwt en wie hem gebruikt, en dat is precies waar testen voor nodig is.

Requirementstesten, waarbij een tester al gaten in de eisen opspoort. Integratie- en functionele testen, waarbij gecontroleerd wordt of modules samenwerken en data goed aankomt. En gebruikerstesten, waarin de eindgebruiker met een andere blik naar de app kijkt.

Nee, gebruikers testen vooral vanuit hun eigen perspectief en niet systematisch, waardoor gevaarlijke aannames uit het ontwikkelproces vaak onopgemerkt blijven. Een gebruiker gaat er bovendien vanuit dat de developer al aan alles gedacht heeft, wat niet altijd klopt.

Ook een app voor maar vijf gebruikers kan al verrassingen opleveren, dus kritisch doorklikken is minimaal nodig. Hoe groter de app en hoe meer gebruikers, hoe groter de kans op onbedoelde effecten en hoe strenger je kwaliteitseisen dus moeten zijn.

Monitoring vertelt je of iets werkt, observability laat je ook zien waarom. Observability combineert metrics, logs en traces centraal, zodat je het hele plaatje van de gezondheid van een systeem ziet in plaats van losse meetpunten.

Het begon met availability monitoring: geautomatiseerd pingen om te checken of een website of applicatie beschikbaar was. Was iets onbereikbaar, dan ging er een mail of sms naar een beheerder om het probleem op te lossen.

APM traceert en timet aanroepen binnen een applicatie, zodat je ziet waar tijd verloren gaat tussen gebruiker en systeem. Gartner verdeelt dit inmiddels in Digital Experience Monitoring, Application Discovery en AIOps voor IT-operaties.

De opkomst van microservices, containers, gedistribueerde systemen en cloud maakte applicatielandschappen te complex voor reactieve monitoringtools. Dat vroeg om een proactievere aanpak, waarbij metrics, logs en traces centraal samenkomen: observability.

RUM verzamelde passief data van echte gebruikers, waardoor je voor het eerst zag hoe mensen een service werkelijk ervaarden, niet alleen of systemen technisch draaiden. Dat leverde inzicht op om een service te optimaliseren op basis van echt gebruik.

Test zo vroeg en zo vaak mogelijk in het ontwikkelproces, in plaats van pas rond de livedatum. Hoe eerder je een probleem signaleert, hoe makkelijker en goedkoper het is om het op te lossen.

Omdat requirements ook na uitgebreid nadenken nog gaten kunnen bevatten die pas later in het proces opvallen. Door ze dubbel te checken voordat er code geschreven wordt, voorkom je dat diezelfde gaten pas bij een gebruiker of klant naar boven komen.

Je denkt dan misschien efficiënt met je tijd om te gaan, maar problemen komen zo pas in een laat stadium aan het licht. Dat brengt deadlines in gevaar, terwijl vroeg en vaak testen dat risico juist voorkomt.

Niet echt: ook in de tijd van watervalprojecten was er voor iedere fase al een apart checkmoment ingebouwd. Alleen de naam 'shift-left' is nieuwer, het idee om vroeg te testen bestond al veel langer.

Door problemen op te sporen voordat de tegels al gelegd zijn, zoals bij een badkamerrenovatie: een aannemer die vooraf belt over scheve tegels bespaart je achteraf gedoe. Bij software werkt vroeg testen precies zo en voorkomt het dure discussies over wie welke fout betaalt.

De happy flow moet werken bij correct invullen, een foutieve inzending moet een melding opleveren en de gebruiker moet concrete feedback krijgen om de fout te herstellen. Tussen stap twee en drie gaat het in de praktijk het vaakst mis.

De melding laat niet zien welk veld fout is, waardoor een gebruiker zelf op zoek moet naar de fout, bijvoorbeeld via de dev tools van de browser. Een goede melding markeert het specifieke veld, bijvoorbeeld met een sterretje of een rood kader.

Helemaal geen melding krijgen na het versturen, zoals bij het formulier van de middelbare school in dit voorbeeld. Je weet dan niet of de aanvraag is aangekomen of dat er iets is misgegaan, en moet gokken of achteraf navragen.

Een tester denkt ook als developer en designer mee: hoe laat je zien welke velden verplicht zijn, hoe voorkom je fouten en hoe communiceer je duidelijk als er toch iets misgaat. Goede foutafhandeling moet je expliciet specificeren, anders wordt het niet gebouwd.

Eerst moet de happy flow werken en moet de techniek op de achtergrond fouten goed kunnen afvangen, zonder onduidelijke server errors. Pas daarna kun je nadenken over hoe je de gebruiker daadwerkelijk helpt met heldere feedback.

Pas als hij ook getest is, niet al zodra de code naar 'completed' gaat. Een feature die technisch klaar is maar nog niet getest, kan alsnog problemen bevatten die pas bij de klant naar boven komen.

Terwijl developers aan de nieuwe sprint werken, kun je als tester alvast vragen stellen over de vorige sprint en zelfs ontbrekende requirements signaleren voordat ze een bevinding worden. Zo voorkom je dat je pas na de release ontdekt wat er mist.

Nieuwe features leveren nieuwe bevindingen op en gefikste bugs brengen soms weer een ander probleempje boven water. Onduidelijke requirements zijn vaak de onderliggende oorzaak, dus meer tijd voor refinement voorkomt dat de sprint blijft groeien.

Ze verwachten niet dat een gebruiker expres een tekstbestand van miljoenen tekens in een veld zou zetten. Toch helpen dit soort exotische tests om het product beter bestand te maken tegen onverwachte input, en daarom komt er een vaste checklist voor SQL-injectie en validatie.

Volgens deze tester liever goede features met een bekend probleem dan alles volgens planning maar middelmatig opleveren. Niet elke gevonden bevinding moet direct opgelost worden, zolang je het verschil ziet tussen een verbetering en een echt probleem.

Code is schoon als hij voor iedereen leesbaar is, ook voor een developer die er een jaar later voor het eerst naar kijkt. Dat vraagt om consistente conventies en duidelijke taal, zodat bugs sneller op te sporen zijn.

De verhouding tussen tijd die je besteedt aan het lezen versus het schrijven van code is ruim tien op één. Je bent dus voortdurend oude code aan het lezen om nieuwe code te kunnen schrijven, wat schone code des te belangrijker maakt.

Niet helemaal: het boek is inmiddels veertien jaar oud en Martin heeft een strikte zwart-wit visie. Blis is pragmatischer en hanteert voor kleinere projecten een iets minder streng regime, maar staat wel volledig achter het idee dat software nooit 'af' is.

Niet via dikke handboeken, maar door vaker samen aan tafel of achter een monitor te zitten. Senior developers passen conventies vaak 'op gevoel' toe, en dat overbrengen helpt bij het standaardiseren van de code-conventies binnen het team.

Tijd: budget en beschikbare uren zijn vaak te krap om code echt clean te maken, waardoor je een issue sneller maar minder leesbaar oplost. Developers moeten daarom beter uitleggen waarom die extra tijd de moeite waard is.

Bij Infrastructure as Code richt je cloud-infrastructuur in met scripts, in plaats van handmatig klikken. Elke omgeving, van test tot productie, wordt daardoor exact hetzelfde uitgerold. Dat voorkomt verschillen tussen omgevingen en de risico's die daaruit ontstaan.

Binnen een uur, terwijl dat vroeger dagen kon duren. Je zet de omgeving razendsnel op voor een presentatie en breekt hem daarna net zo snel weer af. Zo betaal je alleen voor de cloud-resources die je echt gebruikt.

Testomgeving en productie kunnen ongemerkt van elkaar gaan afwijken. Een bug die alleen in productie opduikt, of een beveiligingsrisico dat op test onzichtbaar blijft, is dan realiteit. IaC voorkomt dat door elke omgeving identiek uit te rollen.

Omgevingen die je snel opzet en net zo snel weer afbreekt, kosten alleen geld zolang je ze gebruikt. Zonder IaC blijven vergeten testomgevingen vaak onnodig lang draaien, en dat raakt direct de ROI van je project.

De inrichting van je infrastructuur staat vastgelegd in code, niet in het hoofd van één beheerder. Bij personeelswisselingen blijft alles gedocumenteerd en reproduceerbaar. Dat maakt het beheer en de groei van je cloudomgeving overzichtelijker.

De enterprise architect, de solution architect en de support engineer werken hierbij nauw samen. De enterprise architect bepaalt de kaders voor de organisatie, de solution architect ontwerpt de concrete implementatie en de support engineer onderhoudt het resultaat.

Die zet de kaders voor de hele organisatie, bijvoorbeeld welke cloudplatforms gebruikt worden. Ook beslissingen over naming conventions, netwerkinrichting en subscriptions vallen hieronder. Zulke richtlijnen zorgen dat alle teams binnen dezelfde kaders werken.

Dankzij IaC zijn oplossingen volgens vaste patronen ingericht, dus werkt alles op dezelfde manier. Componenten hebben voorspelbare namen en staan waar je ze verwacht, ongeacht aan welke oplossing je werkt. Dat scheelt veel zoeken en bellen.

Door bij het ontwerp al rekening te houden met kosten, niet pas achteraf. 'We hebben een SQL-database nodig' is te vaag: dat kan een Mercedes van een omgeving zijn, terwijl een Ford Focus ook volstaat. Ook het support-team kan later nog ingrijpen als kosten uit de hand lopen.

Een ontwikkelomgeving heeft genoeg aan een kleine, simpele server, terwijl productie met duizenden gebruikers een zwaardere server nodig heeft. IaC maakt het makkelijk om die varianten te bouwen, zodat je kosten bespaart zonder in te leveren op kwaliteit.