Latest / M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands / Stil verval in Microsoft 365: governance voor SharePoint, Power Apps, Power Automate en AI (AI-nasynchronisatie)

Transcript

Stil verval in Microsoft 365: governance voor SharePoint, Power Apps, Power Automate en AI (AI-nasynchronisatie) · M365.FM – Microsoft 365, Copilot & AI podcast in het Nederlands

• 0:00
  Speaker 2: Klaar voor 10 dagen Microsoft 365, Copilot, AI, Azure en
• 0:05
  Speaker 2: de mensen die de toekomst van werk vormgeven? Deze januari
• 0:09
  Speaker 2: is M365 komt terug en we pakken groter uit. Doe
• 0:12
  Speaker 2: mee voor live sessies, praktijkdemo's en praktische kennis van MVP's
• 0:17
  Speaker 2: en experts uit de hele wereld. Geen algemene sliedes, geen
• 0:20
  Speaker 2: eindeloze modewoorden. We pakken de echte uitdagingen aan Copilot Studio,
• 0:25
  Speaker 2: AI Agents, Fabric, Beveiliging, Governance en Automatisering. Of je nu IT-professional,
• 0:31
  Speaker 2: ontwikkelaar of businessleader bent, er zijn sessies voor jou ontworpen.
• 0:35
  Speaker 2: Met 10 volledige dagen kun je diverse technologieën verkennen en
• 0:38
  Speaker 2: verbinding maken met een wereldwijde community. Kijk live mee en
• 0:41
  Speaker 2: neem praktische inzichten mee terug naar je organisatie. Januari 2027,
• 0:46
  Speaker 2: 10 dagen, 1 Microsoft Community. De registratie is nu geopend.
• 0:51
  Speaker 2: Ga naar m365com.net en verzeker je plek vandaag nog. Dat
• 0:56
  Speaker 2: is m365com.net. Meld je nu aan op m365con.net en we
• 1:03
  Speaker 2: zien je live in januari.
• 1:05
  Speaker 4: Het is 13 voor 4 ochtends UTC. Het meeste IT-personeel slaapt.
• 1:10
  Speaker 4: Maar ergens in de cloudlogs vormt zich een patroon. Het
• 1:12
  Speaker 4: begint klein, drie nieuwe SharePoint lijsten genaamd. Test aangemaakt binnen
• 1:17
  Speaker 4: vier minuten. Dan een plotselinge piek in wijzigingen van rechten
• 1:20
  Speaker 4: zonder ticket. Ten slotte valt een reeks Power Automate flows tegelijkertijd.
• 1:24
  Speaker 2: En de telefoon gaat niet over. Dat is het enge deel.
• 1:27
  Speaker 2: De CEO krijgt geen telefoontje omdat het systeem technisch gezien
• 1:30
  Speaker 2: niet down is. De serverlampjes branden nog steeds groen. Maar
• 1:33
  Speaker 2: als je goed naar dat patroon kijkt, zie je geen storing,
• 1:36
  Speaker 2: maar entropie.
• 1:37
  Speaker 4: Entropie? Die geleidelijke afgeleiding naar wanorde. Het voelt alsof we
• 1:42
  Speaker 4: ons zo focussen op de luide fouten, de ransomware, de
• 1:46
  Speaker 4: dedels aanvallen, dat we deze stille verrotting negeren. We hebben
• 1:49
  Speaker 4: het vandaag over de dood door duizend sneden in het
• 1:52
  Speaker 4: Microsoft 365 ecosysteem, nietwaar?
• 1:55
  Speaker 2: Precies. We bespreken hoe platformsystemen stilletjes falen, lang voordat ze
• 1:59
  Speaker 2: luid falen en, belangrijker nog, hoe je die afwijking stopt
• 2:02
  Speaker 2: met discipline in plaats van heldendaden. Want op dit moment
• 2:05
  Speaker 2: draaien de meeste organisaties op heldendaden. Ze hebben die ene
• 2:08
  Speaker 2: powerplatform man die de flow repareert wanneer die s'nachts kapot gaat.
• 2:12
  Speaker 2: Dat is geen strategie, dat is een risico.
• 2:14
  Speaker 4: Dus laten we deze entropie ontleden. Het bronmateriaal waar we
• 2:17
  Speaker 4: vandaag naar kijken, beschrijft het als een samengestelde instabiliteit. Het
• 2:21
  Speaker 4: begint bij het substraat zelf. SharePoint.
• 2:24
  Speaker 2: Juist, SharePoint, het Zwitserse zakmes dat iedereen tegelijkertijd probeert te
• 2:28
  Speaker 2: gebruiken als hamer, zaag en relationele database. Het kernprobleem is
• 2:32
  Speaker 2: dat SharePoint een samenwerkingssubstraat is. Het is ontworpen voor documenten
• 2:36
  Speaker 2: en lijsten met gegevens die mensen lezen. Maar mensen proberen
• 2:39
  Speaker 2: het te behandelen als SQL-server.
• 2:41
  Speaker 4: Ik heb dit honderd keer gezien. Je krijgt een verzoek
• 2:44
  Speaker 4: voor een eenvoudige tracker en plotseling heb je een lijst
• 2:47
  Speaker 4: met 50 kolommen, 5 verschillende opzoekketens en een rechtenstructuur waarvoor
• 2:51
  Speaker 4: je een doctoraat nodig hebt.
• 2:53
  Speaker 2: En daar begint het verval. Het document noemt het schema-discipline.
• 2:57
  Speaker 2: Het klinkt saai, maar het is cruciaal. Bijvoorbeeld het benoemen
• 3:00
  Speaker 2: van lijsten. Je ziet lijsten met namen als Ion's Trial
• 3:03
  Speaker 2: Tracker of Project XTEM. Dat is prima voor een zandbak,
• 3:06
  Speaker 2: maar niet voor productie. Noem de lijst naar het zakelijke object.
• 3:09
  Speaker 2: Het is een incident, geen tracker van Yen.
• 3:11
  Speaker 4: En technische schuld hoopt zich ook op in de kolomnamen. Toch?
• 3:15
  Speaker 4: Je noemt een kolom vandaag status, verandert de weergavenaam in
• 3:18
  Speaker 4: huidige staat, maar de API ziet nog steeds status. Dan
• 3:22
  Speaker 4: verwijder je deze en maak je status
• 3:24
  Speaker 2: 2. Status 2, status definitief, status echt. Het is een
• 3:27
  Speaker 2: nachtmerrie voor iedereen die daarop een app probeert te bouwen.
• 3:30
  Speaker 2: De regel is simpel, interne namen veranderen nooit. Labels zijn
• 3:33
  Speaker 2: voor de gebruikersinterface, niet voor de API. Als je dit
• 3:36
  Speaker 2: niet afdwingt, bouw je een wolkenkrabber in een moeras. En
• 3:39
  Speaker 2: dan is er nog het vraagstuk van relaties.
• 3:41
  Speaker 3: Oh. de gevreesde opzoekkolom.
• 3:43
  Speaker 2: Opzoekvelden zijn verleidelijk. Ze voelen als een relationele join, maar
• 3:46
  Speaker 2: SharePoint is geen relationele database. De richtlijn hier is strikt.
• 3:50
  Speaker 2: Eén opzoekveld per kritieke weergave, misschien twee als je geluk hebt.
• 3:53
  Speaker 2: Als je probeert relaties met meerdere stappen te leggen, zoals
• 3:56
  Speaker 2: het filteren van een lijst op basis van een opzoekveld
• 3:58
  Speaker 2: dat verwijst naar een andere lijst, moet je daarmee stoppen.
• 4:01
  Speaker 4: Dus waar ga je dan heen? Als SharePoint die complexiteit
• 4:04
  Speaker 4: niet aankan, geef je het dan op
• 4:05
  Speaker 2: Je verplaatste data, dat is een gesprek over dataverse of SQL.
• 4:09
  Speaker 2: Als je transactionele integriteit en complexe joins nodig hebt, misbruik
• 4:13
  Speaker 2: je SharePoint en zal het systeem je daarvoor straffen. Niet vandaag,
• 4:17
  Speaker 2: misschien niet morgen, maar uiteindelijk bereikt een query de limiet,
• 4:21
  Speaker 2: breekt delegatie en toont je app lege schermen.
• 4:24
  Speaker 4: Over dingen breken gesproken, laten we het over rechten hebben.
• 4:27
  Speaker 4: Dit is een enorm pijnpunt, de valstrik van rechten op itemniveau.
• 4:31
  Speaker 2: Het is het klassieke, ik wil dat alleen de maker
• 4:33
  Speaker 2: hun eigen items ziet, verzoek. Het klinkt redelijk, maar technisch
• 4:37
  Speaker 2: gezien is het een doodlopende weg. Als je de overerving
• 4:39
  Speaker 2: op elk item in een lijst van 50.000 items verbreekt,
• 4:42
  Speaker 2: moet de server de toegangscontrollenlijst voor elke rij controleren telkens
• 4:46
  Speaker 2: wanneer een gebruiker een query uitvoert. Het vernietigt de prestaties.
• 4:49
  Speaker 4: De oplossing is dus om de overerving op site-niveau te verbreken,
• 4:52
  Speaker 4: niet op item-niveau.
• 4:53
  Speaker 2: Altijd. Als je rijen anders moet beveiligen, heb je aparte
• 4:56
  Speaker 2: lijsten of een andere gegevensbron nodig. En gebruik alsjeblieft groepen.
• 4:59
  Speaker 2: Wijs nooit rechten toe aan een individueel persoon. Mensen gaan weg,
• 5:02
  Speaker 2: groepen blijven bestaan.
• 5:04
  Speaker 3: Het thema lijkt hier te zijn stop met improviseren, wat
• 5:07
  Speaker 3: ons perfect bij de tweede pijler brengt, Power Apps. De
• 5:10
  Speaker 3: tekst beschrijft power apps alsof wel deterministisch of chaos met
• 5:13
  Speaker 3: een opslagknop. Dat is een vrij scherpe tegenstelling.
• 5:16
  Speaker 2: Dat is het, maar het is accuraat. Een canvas app
• 5:19
  Speaker 2: voelt als een leeg canvas. Je kunt schilderen wat je
• 5:21
  Speaker 2: maar wilt. Dat is het gevaar. Een deterministische app betekent
• 5:24
  Speaker 2: dat jij, de ontwikkelaar, de status beheert. Je weet precies
• 5:27
  Speaker 2: welke gegevens worden geladen, wanneer ze worden ingediend en wat
• 5:30
  Speaker 2: er gebeurt als het mislukt.
• 5:31
  Speaker 4: Tegenover de chaosbenadering, waarvan ik aanneem dat het gewoon is
• 5:34
  Speaker 4: om besturingselementen op een scherm te gooien en te hopen
• 5:36
  Speaker 4: dat de submitform functie werkt.
• 5:37
  Speaker 2: Precies. GAROS is vertrouwen op impliciet gedrag. Het is complexe
• 5:41
  Speaker 2: logica in de unselect, eigenschap van een knop plaatsen die
• 5:45
  Speaker 2: drie gegevensbronnen bijwerkt, een e-mail verzendt en naar een nieuw
• 5:48
  Speaker 2: scherm navigeert, allemaal zonder enige foutafhandeling. Als het internet halverwege wegvalt,
• 5:53
  Speaker 2: zijn je gegevens beschadigd.
• 5:54
  Speaker 4: Dus hoe maken we het deterministisch?
• 5:56
  Speaker 2: Je centraliseert je lees- en schrijfacties. Je besturingselementen moeten niet
• 6:00
  Speaker 2: rechtstreeks de database opvragen. Ze zouden waar nodig naar lokale
• 6:03
  Speaker 2: collecties of variabelen moeten kijken. En je moet submit form
• 6:06
  Speaker 2: als een atoomhandeling behandelen. Als je patch gebruikt, moet je
• 6:10
  Speaker 2: gelijktijdigheid afhandelen.
• 6:11
  Speaker 4: Gelijktijdigheid is een belangrijke. Twee mensen die tegelijkertijd hetzelfde record bewerken.
• 6:16
  Speaker 2: Als je dit niet expliciet afhandelt, wint de laatste persoon
• 6:19
  Speaker 2: die opslaat en wordt het werk van de ander overschreven
• 6:21
  Speaker 2: zonder dat ze het weten. Daar is die stille fout weer.
• 6:23
  Speaker 2: Het systeem is niet gecrashed, maar de gegevens kloppen niet.
• 6:26
  Speaker 4: De tekst noemt ook operationele discipline in apps, loggen wat
• 6:30
  Speaker 4: de app deed, niet alleen wat hij hoopte te doen.
• 6:32
  Speaker 2: Dat is het verschil tussen speelgoed en een hulpmiddel. Een
• 6:34
  Speaker 2: professionele app genereert telemetrie. Gebruiker X navigeerde naar scherm Griekse Y.
• 6:39
  Speaker 2: Gebruiker Z probeerde het formulier in te dienen, mislukt met
• 6:42
  Speaker 2: foutcode 133. Als je die logbestanden niet hebt, ben je
• 6:45
  Speaker 2: aan het debuggen met gokwerk.
• 6:46
  Speaker 4: Laten we overschakelen naar de machinekamer, Power Automate. De beschrijving
• 6:50
  Speaker 4: hier is levendig. Tijdbommen onschadelijk gemaakt met protocollen.
• 6:53
  Speaker 2: Flows zijn angstaanjagend omdat ze op de achtergrond draaien. Je
• 6:56
  Speaker 2: kunt niet zien dat ze falen tenzij je oplet, en
• 6:58
  Speaker 2: ze falen net zoals gebouwen afbranden. Eerst stilletjes, dan plotseling
• 7:01
  Speaker 2: allemaal tegelijk.
• 7:02
  Speaker 4: Wat is de nummer één oorzaak van die brand?
• 7:04
  Speaker 2: Een gebrek aan defensief ontwerp, specifiek triggers. Als je een
• 7:07
  Speaker 2: flow hebt die wordt geactiveerd wanneer een item wordt gewijzigd,
• 7:10
  Speaker 2: en je stelt geen triggerconditie in, dan wordt die flow
• 7:12
  Speaker 2: elke keer uitgevoerd wanneer iemand dat item aanraakt, zelfs als
• 7:15
  Speaker 2: ze alleen een typfout verbeteren.
• 7:17
  Speaker 4: Dus heb je duizenden onnodige runs die je API-limieten verstoppen.
• 7:20
  Speaker 2: Precies. Je hebt scope triggers nodig. Voer deze flow alleen
• 7:23
  Speaker 2: uit als de status verandert naar goedgekeurd. Die ene wijziging
• 7:26
  Speaker 2: kan je belasting met 90% verminderen. En dan is er
• 7:28
  Speaker 2: nog gelijktijdigheid.
• 7:30
  Speaker 4: Klopt. Standaard probeert Power Automate alles parallel uit te voeren
• 7:33
  Speaker 4: om behulpzaam te zijn.
• 7:34
  Speaker 2: Wat een ramp is als je hetzelfde lijstitem probeert bij
• 7:37
  Speaker 2: te werken of een teller wilt verhogen. Je krijgt racecondities.
• 7:40
  Speaker 2: Je moet limieten voor gelijktijdigheid instellen. Soms moet je het
• 7:43
  Speaker 2: dwingen om sequentieel te draaien, één voor één, om de
• 7:45
  Speaker 2: gegevensintegriteit te waarborgen.
• 7:47
  Speaker 4: En foutafhandeling? Het try-catch patroon is niet zo ingebakken in
• 7:50
  Speaker 4: de visuele designers als in code, toch?
• 7:53
  Speaker 2: Je moet het zelf bouwen. Je maakt een scope blok
• 7:55
  Speaker 2: voor je hoofdacties, dat is je try, en daarna een
• 7:58
  Speaker 2: parallel blok dat alleen draait als de eerste faalt, dat
• 8:00
  Speaker 2: is je catch. Als je geen catch blok hebt dat
• 8:02
  Speaker 2: je waarschuwt, kan een flow wekenlang falen zonder dat je
• 8:05
  Speaker 2: het weet, totdat een gebruiker vraagt, hé, waar is mijn goedkeuring?
• 8:08
  Speaker 4: Die stilte is de vijand. Het lijkt erop dat het
• 8:11
  Speaker 4: doel van al deze protocollen is om stille fouten om
• 8:14
  Speaker 4: te zetten in luide, begrensde fouten.
• 8:17
  Speaker 2: Ja, ik wil dat het systeem tegen me schreeuwt als
• 8:19
  Speaker 2: er iets misgaat, zodat ik het direct kan herstellen. Ik
• 8:22
  Speaker 2: wil niet dat het fluistert terwijl het de database zes
• 8:24
  Speaker 2: maanden lang corrompeert.
• 8:25
  Speaker 4: Nu kunnen we niet over de toekomst van dit platform
• 8:27
  Speaker 4: praten zonder I te noemen. Copilots AI Builder. Iedereen wil
• 8:33
  Speaker 4: ze inschakelen. Maar de tekst waarschuwt, de piek begon niet
• 8:37
  Speaker 4: met code, het begon met een PDF.
• 8:41
  Speaker 2: AI is de ultieme versneller. Als je governance slecht is,
• 8:44
  Speaker 2: zal AI het sneller slechter maken. Het gevaar van AI,
• 8:48
  Speaker 2: specifiek grote taalmodellen of co-pilots, is hallucinatie en te ruime toegang.
• 8:53
  Speaker 4: Bibliothecaris, geen orakel. Ik vond die zin mooi.
• 8:56
  Speaker 2: Het is de perfecte analogie. Een orakel verzint de waarheid.
• 9:00
  Speaker 2: Een bibliothecaris vindt de waarheid die al bestaat. We willen
• 9:03
  Speaker 2: dat onze bedrijfs AI een bibliothecaris is. Het moet alleen
• 9:06
  Speaker 2: antwoorden op basis van toegestane kennisbronnen. Als het het document
• 9:09
  Speaker 2: niet kan vinden, moet het zeggen, ik weet het niet,
• 9:11
  Speaker 2: in plaats van een beleid te verzinnen.
• 9:13
  Speaker 4: En hoe dwingen we dat technisch af?
• 9:15
  Speaker 2: Je hebt grenzen nodig. Bij AI Builder documentverwerking heb je
• 9:18
  Speaker 2: een mens nodig voor scores met een lage betrouwbaarheid. Als
• 9:21
  Speaker 2: de AI niet 90% zeker is dat die factuur 500
• 9:24
  Speaker 2: dollar is, moet de mens dit controleren. Je laat het
• 9:26
  Speaker 2: niet zomaar naar het erp schrijven.
• 9:28
  Speaker 4: En voor de chatbots, de co-pilots?
• 9:30
  Speaker 2: Bronnenvermeldingen zijn verplicht. Als de bot een antwoord geeft, moet
• 9:33
  Speaker 2: deze linken naar het brondocument. Geen bronvermelding, geen output. En cruciaal,
• 9:37
  Speaker 2: geen directe gegevenswijzigingen. Je laat een chatbot niet rechtstreeks je
• 9:40
  Speaker 2: SQL database bewerken. De chatbot moet een strikt beheerde Power
• 9:44
  Speaker 2: Automate Flow activeren om de wijziging door te voeren. De
• 9:47
  Speaker 2: Flow is de poortwachter.
• 9:48
  Speaker 4: Dus de AI is alleen de interface. De governance logica
• 9:51
  Speaker 4: leeft nog steeds in de rigide, deterministische lagen die we
• 9:54
  Speaker 4: eerder bespraken.
• 9:55
  Speaker 2: Precies. De AI is de zachte, diffuse front-end. De back-end
• 9:59
  Speaker 2: moet koud...
• 10:01
  Speaker 4: We hebben de pijlers behandeld, SharePoint, Apps, Automate, AI. Maar
• 10:06
  Speaker 4: niets hiervan werkt zonder wat de tekst de governance ruggengraat noemt.
• 10:10
  Speaker 4: De controles die niet knipperen.
• 10:12
  Speaker 2: Dit zijn de saaie zaken die je baan redden. DLP,
• 10:15
  Speaker 2: beleid voor gegevensverliespreventie, omgevingsstrategieën. Je kunt mensen geen productie-apps laten
• 10:20
  Speaker 2: bouwen in de standaardomgeving.
• 10:21
  Speaker 4: De standaardomgeving is het wilde westen.
• 10:23
  Speaker 2: Het is de plek waar governance komt te sterven. Je
• 10:25
  Speaker 2: hebt een scheiding nodig tussen dev, test en prod. Je
• 10:27
  Speaker 2: hebt beheerde oplossingen nodig. Als je onbeheerde zipbestanden naar productie verplaatst,
• 10:31
  Speaker 2: vraag je om problemen.
• 10:33
  Speaker 4: En service principles. Stop met het draaien van bedrijfsfloes onder
• 10:36
  Speaker 4: het account van Steve. Want als Steve de loterij wint
• 10:39
  Speaker 4: en ontslag neemt,
• 10:40
  Speaker 2: Ligt het hele crediteurenproces stil. Gebruik een service principle, een
• 10:43
  Speaker 2: niet-menselijke identiteit, zodat het systeem afhankelijk is van de architectuur,
• 10:47
  Speaker 2: niet van het personeelsbestand.
• 10:48
  Speaker 4: Het komt allemaal neer op een keuze, nietwaar? De conclusie
• 10:51
  Speaker 4: legt het bloot. Afstemming of entropie?
• 10:53
  Speaker 2: Dat is de binaire keuze. Er is geen middenweg. Je
• 10:56
  Speaker 2: dwingt vroegtijdig structuur af, wat beperkend voelt en je aanvankelijk vertraagt.
• 11:00
  Speaker 2: of je betaalt later voor de wederopbouw. En wederopbouw is
• 11:03
  Speaker 2: altijd tien keer zo duur.
• 11:05
  Speaker 4: Het is interessant. We begonnen met praten over technische instellingen,
• 11:08
  Speaker 4: geïndexeerde kolommen, gelijktijdigheidslimieten, maar dit is echt een filosofisch standpunt
• 11:13
  Speaker 4: over hoe technologie beheerd moet worden
• 11:14
  Speaker 2: Dat is het. Het gaat om het respecteren van de tool. SharePoint,
• 11:18
  Speaker 2: Power Platform,
• 11:19
  Speaker 4: AI
• 11:19
  Speaker 2: dit zijn ongelooflijk krachtige tools, maar...