Vier fasen, van scope tot overdracht.

1. 01

   Verkennen

   Fase 1 van 4

   Een afgebakende scope, een vastgelegde architectuur en een afgesproken eindresultaat, voordat er iets wordt gebouwd.

2. 02

   Voorbereiden

   Fase 2 van 4

   Privénetwerk, Key Vault en Unity Catalog-governance staan klaar voordat de eerste pipeline draait.

3. 03

   Uitvoeren

   Fase 3 van 4

   Elke workspace, policy en catalogus komt binnen als een gereviewde pull request. Dev, test en productie draaien dezelfde code.

4. 04

   Overdragen

   Fase 4 van 4

   Gedocumenteerde architecturen en kennisoverdracht, zodat je teams het platform zelf kunnen beheren en doorontwikkelen.

• 01Verkennen

  • We classificeren de data voordat ze wordt geladen en leggen het doel en de eigenaar van elke dataset vast.
  • Persoonsgegevens blijven in de afgesproken regio. Voor EU-klanten betekent dat alleen EU-regio's.
  • We sturen geen klantdata naar externe AI-diensten, tenzij je daar schriftelijk mee instemt.
• 02Voorbereiden

  • Eén Entra ID-groep voor elk toegangsniveau op elke scope. Niemand wordt rechtstreeks toegevoegd.
  • Unity Catalog-groepen voor lezen en bijdragen op elk schema. Groepen voor tabellen of volumes alleen voor gevoelige objecten.
  • Secrets staan in Azure Key Vault, één kluis per omgeving, of bestaan helemaal niet omdat managed identities ze vervangen.
• 03Uitvoeren

  • Elke pull request draait lint, unittests, Terraform validate en plan, bundle validate, een securityscan, statische analyse en scans op dependencies en secrets.
  • Terraform apply en bundle deploy draaien vanuit pipelines, met workload identity federation en zonder opgeslagen secrets.
  • Acceptatie en productie vragen twee reviewers, en niemand keurt zijn eigen wijziging goed.
• 04Overdragen

  • Toegang wordt elk kwartaal beoordeeld en rechten die niemand gebruikt, worden verwijderd.
  • Elke job heeft een eigenaarsgroep en meldingen bij falen, en alerts dekken fouten, kostenpieken en securityevents.
  • Elke dataset heeft een bewaartermijn, en data wordt verwijderd of geanonimiseerd wanneer die afloopt.

1. 01

   Een korte schriftelijke status

   Wat er gedaan is, wat er volgt en wat vastzit, in een paar regels die je kunt doorsturen.

2. 02

   Een demo van werkende software

   Iets dat draait, geen slides, zodat je kunt reageren zolang een wijziging nog goedkoop is.

3. 03

   Beslissingen waar we jou voor nodig hebben

   Een korte lijst keuzes die we van je nodig hebben, elk met onze aanbeveling en de reden.

4. 04

   Risico's en open punten

   Risico's voor beveiliging, privacy, kosten en planning, en wat we aan elk doen.

5. 05

   Het werk in je eigen repositories

   Elke wijziging is een pull request die je kunt zien, beoordelen en van commentaar voorzien, met tests en een gekoppeld werkitem.

Bij de overdracht ontvang je de documentatie, de runbooks en de repositories. Tot die tijd kun je de actuele stand van het werk altijd inzien.

1. De wijziging is code, in een pull request met een gekoppeld werkitem.
2. Buildvalidatie en codescanning slagen.
3. Toegang loopt via Entra ID-groepen, zonder directe gebruikersrechten. Bevoegde rollen gebruiken PIM.
4. Elke dienst gebruikt een private endpoint en publieke toegang is uitgeschakeld.
5. Secrets staan in Key Vault, of zijn niet nodig omdat een managed identity wordt gebruikt.
6. Gevoelige data is geclassificeerd, getagd en beschermd.
7. Infrastructuur gebruikt onze Terraform-modules, zonder gekopieerde modulecode.
8. Databricks-resources worden als bundle via de pipeline uitgerold.
9. Nieuwe logica heeft tests en er is geen gedupliceerde code.
10. De documentatie en het runbook zijn actueel.
11. De wijziging is door dev, test, acc en main gegaan.

Dit zijn de eigen opleverstandaarden van NexOps, onze eigen visie en geen eis van een leverancier of certificering. Is jouw standaard strenger, dan volgen we die van jou. Is die minder streng, dan zeggen we dat en leggen we het besluit vast.

Alle samenwerkingsvormen