Hoe voorkom je deze 8 risico’s binnen het Power Platform?

Het Microsoft Power Platform biedt een brede, betaalbare en uiterst toegankelijke set van tools om jouw digitaliseringsproject mee te realiseren. Hierdoor wint het platform aanzienlijk in populariteit en zien we dat bijvoorbeeld Microsoft 365-experts en gebruikers met affiniteit voor low-code op de werkvloer aanhaken. Het ecosysteem is er dan ook voor bedoeld om het ook voor gebruikers die niet fulltime oplossingen ontwikkelen mogelijk te maken om zelf te kunnen digitaliseren. Er liggen echter risico’s op de loer die succesvolle adaptatie van het Power Platform in de weg kunnen staan.

Er zijn diverse zaken die ervoor kunnen zorgen dat een oplossing niet zo’n groot succes wordt als er in eerste instantie werd gehoopt. Ook bij Shared hebben we in het verleden deze fouten gemaakt en de lessen die we hieruit hebben getrokken komen voort uit jaren van ervaring. Zeker organisaties die breder in willen zetten op het Power Platform doen er goed aan deze risico’s te (h)erkennen en voor te zijn. Het zou jammer zijn wanneer deze valkuilen een succesvolle introductie van het Power Platform in de weg staan.

Omdat jij geen jaren hebt om die ervaring op te doen, hebben we daarom de 8 belangrijkste valkuilen op een rijtje gezet. Voor het gemak hebben we ook wat manieren toegevoegd om ze te voorkomen. We behandelen de volgende valkuilen:

1. Té gemakkelijk denken over de behoefte van eindgebruikers
2. Technische risico’s over het hoofd zien
3. Té snel starten met ontwikkeling (en het ontwerp afraffelen)
4. Niet bijhouden en toepassen van de meest recente best practices
5. Onnodige kosten door niet te optimaliseren voor het licentiemodel
6. Instabiele oplossingen door gebrek aan testen
7. Hoge kosten door niet het datamodel te optimaliseren
8. Hogere onderhoudskosten door gebrek aan documentatie en ALM

1. Té gemakkelijk denken over de behoefte van eindgebruikers

Écht goede oplossingen bieden zowel overduidelijk waarde voor eindgebruikers alsook een positieve business case. Gek genoeg is die eerste daarvan vaak het moeilijkst. Dit komt bijvoorbeeld omdat ontwikkelaars de praktijk van processen onbedoeld simplificeren of generaliseren. Ook is het mogelijk dat eindgebruikers functionaliteiten wensen die niet hun kernprobleem oplossen, maar slechts een symptoom.

Je kunt dit voorkomen door een gedegen Business Requirements Analyse uit te voeren. Er zijn onder deze noemer diverse methoden om tot het kernprobleem te komen (Ishikawa, 5xWhy, etc.). Ook is het nuttig om een Domeinmodel op te stellen (én te valideren) om de leefwereld van de eindgebruiker te modeleren. In combinatie met de MoSCoW-methodiek zijn requirements te prioriteren om te komen tot een minimale set (MVP). Laat de requirements valideren door jouw eindgebruikers in combinatie met het UI-ontwerp en de business logica.

2. Technische risico’s over het hoofd zien

Er kan soms gemakkelijk vanuit worden gegaan dat een bepaalde oplossing technisch gerealiseerd kan worden. Het kan echter zo zijn dat gevoelsmatig simpel te automatiseren taken juist de grootste hersenkrakers opleveren. Denk hier bijvoorbeeld aan het samenvoegen van Pdf’s of het automatisch ophalen van het aantal pagina’s in een Pdf. Beide zaken die niet konden in het Power Platform en waar Shared zelf connectoren voor heeft ontwikkeld. Andere risico’s zijn een veel te complex datamodel (met performance issues tot gevolg) of een Power Apps component wat net niet doet wat je had verwacht.

Het is in dit kader verstandig om de onderdelen in een oplossing die nog niet in detail zijn uitgewerkt of die men nog niet eerder heeft gebouwd als risico’s te zien. Deze risico’s moeten uitgewerkt zijn en waar nodig binnen een experiment gevalideerd worden alvorens de ontwikkeling te starten.

3. Té snel starten met ontwikkeling (en het ontwerp afraffelen)

Tijdens het realiseren van een low-code oplossing is voor velen het leukste werk het ontwikkelwerk. Zelf concreet aan de slag om iets vanuit niets te maken waar anderen blij mee zullen zijn. Het ‘saaiere’ ontwerpproces waarin vooral ook veel vastgelegd dient te worden schiet er daarbij al snel bij in. Daarbij weet men ook vaak niet zo goed welke stappen er in het ontwerpproces genomen dienen te worden. Je begrijpt dat dit ertoe zal leiden dat de oplossing regelmatig voor een groot deel opnieuw zal moeten worden gebouwd en dat de oplossing nooit ‘af’ is voor een formele release door gebrek aan scope en afgebakende requirements.

Vereis als verantwoordelijke dat voorafgaand aan de bouw de volgende zaken zijn opgesteld: Requirements-overzicht inclusief acceptatiecriteria, scope-bepaling, ERD (Entity Relationship Diagram), User Interface mock-ups, document met business logica en een testplan. Dit klinkt misschien als veel documentatie, maar ze vormen de blauwdruk waarmee een oplossing in één keer op de juiste manier kan worden gebouwd. Het op papier zetten forceert ontwikkelaars om écht goed na te denken over hun aanpak.

4. Niet bijhouden en toepassen van de meest recente best practices

Het Microsoft Power Platform is sterk in ontwikkeling. Wekelijks worden de individuele delen van het platform uitgebreid met nieuwe functionaliteiten die regelmatig de workflow van een ontwikkelaar beïnvloeden. Zo komen er keer op keer nieuwe manieren om iets te bewerkstelligen en worden oudere methoden uitgefaseerd. Om te weten in welk scenario je welke methode moet toepassen, vereist dit dat je op de hoogte bent van de meest recente best practices. Want ook in een low-code platform kun je zaken op de verkeerde manier bouwen.

Binnen Shared doen we dit door als team proactief wekelijks de nieuwste ontwikkelingen, tips en tricks te verzamelen in onze Shared Power Platform Hub (SharePoint Community site). Partners van Shared kunnen hier toegang tot krijgen. We halen die informatie voornamelijk uit een community van LinkedIn professionals, nieuwsbrieven zoals Power Platform Weekly, fysieke meet-ups, de Power Platform Releaseplanner van Microsoft en de blogs van Microsoft per platformonderdeel (bijvoorbeeld de Power Apps blog).

5. Onnodige kosten door niet te optimaliseren voor het licentiemodel

Hoewel het ontwikkelen van Power Platform oplossingen voor een aanzienlijk deel gratis kan, zul je vroeg of laat voor de wat serieuzere oplossingen de premium functionaliteiten van het platform nodig hebben. Hierbij komen zoals je wellicht weet ook licentiekosten om de hoek kijken. Het licentiemodel van het Power Platform staat (nog) niet bekend om zijn eenvoudigheid en Microsoft experimenteert regelmatig met de opzet hiervan. Wie er lang genoeg mee werkt weet dat er voor diverse premium functionaliteiten ook gratis alternatieven zijn, elk met hun eigen kanttekeningen. Ook zijn er verborgen mechanismen binnen het licentiemodel die pas na intensiever gebruik aan het licht komen. Zo kun je bijvoorbeeld na verloop van tijd moeten gaan betalen voor de opslag van data of kunnen jouw Power Automate flows te veel acties bevatten waardoor er een vrij zware licentie nodig is. Het loont om hiervan op te hoogte te zijn.

Het meest simpele om dit te voorkomen is om de Power Platform Licensing Guide (2024) door te nemen. Hoewel dit boekwerk van 33 pagina’s veel antwoorden verstrekt, zijn bewoordingen op diverse plaatsen ambigu. Aanvullende kennis door het simpelweg te doen en door te volgen welke kant Microsoft strategisch op gaat met het licentiemodel helpt hierbij. Shared adviseert je hier ook graag bij.

6. Instabiele oplossingen door gebrek aan testen

Het zal niet de eerste keer zijn dat een oplossing in productie tóch nog fouten bevat die niet zijn opgemerkt tijdens het testen. We zien in veel Power Platform projecten dat de ontwikkelaar ook de tester is van de oplossing. Dit zorgt er bijvoorbeeld voor dat enkel de individuele delen van een oplossing worden getest, de testen niet aansluiten op de praktijk of dat een kleine ‘bug fix’ toch implicaties bleek te hebben op andere plekken toen de oplossing eenmaal in productie stond. Ook kan het gebeuren dat juist de eindgebruikers testen, maar zij niet weten wat de ‘zwakke plekken’ van de oplossing zijn en deze dus niet voldoende testen.

Dit is allereerst op te lossen door voorafgaand aan de ontwikkeling test-/acceptatiescenario’s uit te werken met de eindgebruikers. Deze scenario’s zijn praktijkvoorbeelden waarin de gebruiker een bepaald doel wil bereiken met behulp van de oplossing. Het succesvol kunnen uitvoeren van deze scenario’s zorgt ervoor dat de oplossing wordt geaccepteerd. Deze testscenario’s kunnen worden uitgebreid met automatische testen met behulp van bijvoorbeeld Power Apps Test Studio en het Power Automate Test framework wat we bij Shared hebben ontwikkeld. In combinatie met ALM pipelines kun je dit proces van acceptatietesten voor een groot deel automatiseren zodat in geval van een succesvolle test de oplossing automatisch wordt bijgewerkt in de productie-omgeving.

7. Hogere kosten door niet het datamodel te optimaliseren

Het modeleren van data is een kunde. Zeker voor de minder ervaren ontwikkelaars kan normalisatie van het datamodel tot hoofdbrekens leiden. Een goed datamodel is echter essentieel om 1) een efficiënte en snelwerkende oplossing te hebben, 2) het gemakkelijk te maken om de oplossing te ontwikkelen en later uit te breiden en 3) om ervoor te zorgen dat er niet onnodig veel database capaciteit wordt verbruikt. De eerste twee punten leiden tot een verhoging van de ontwikkelkosten en de laatste tot eventuele licentiekosten nadat de oplossing al enige tijd in gebruik is.

Allereerst zijn er generieke Data Modeling courses te vinden op bijvoorbeeld Udemy, zoals Mastering Data Modeling Fundaments. Deze principes zijn platform-onafhankelijk. Daarnaast biedt Microsoft diverse artikelen rondom Dataverse modeling, datatypes, data limieten en Virtual tables en kun je lezen over het nut van ERD’s binnen het Power Platform. Bekijk de Power Platform licensing guide voor het vergaren van gratis Dataverse storage en de tarieven wanneer je daar overheen gaat.

8. Hogere onderhoudskosten door gebrek aan documentatie en ALM

In de praktijk wordt een Power Platform oplossing primair door één ontwikkelaar ontwikkeld. Deze ontwikkelaar weet perfect hoe de oplossing in elkaar zit en heeft deze waarschijnlijk zo gebouwd dat hij of zij efficiënt kan ontwikkelen. Dit alles verandert echter wanneer de oplossing officieel in gebruik dient te worden genomen. In de praktijk zien we vaak dat oplossingen in dezelfde omgeving worden ontwikkeld als dat ze worden gebruikt door eindgebruikers, dat de oplossing niet tot nauwelijks is gedocumenteerd, dat de oplossing niet modulair is opgebouwd en dat de oplossing niet ontworpen is om gemakkelijk te onderhouden en van een Ontwikkel- naar een Test-/Productie-omgeving te verplaatsen. Gezond Application Lifecycle Management (ALM) noemen we dat.

Er zijn diverse best practices die toegepast dienen te worden om het bovenstaande te voorkomen. Zo is het bijvoorbeeld essentieel om de oplossing van begin af aan te ontwikkelen in een Ontwikkelomgeving, deze te testen door eindgebruikers in een Testomgeving en deze daadwerkelijk te gebruiken in de Productie-omgeving. De ontwikkelaar werkt vanaf de start in een Solution en maakt daarin gebruik van Omgevingsvariabelen en Connectie referenties waarin afwijkende instellingen tussen omgevingen worden geconfigureerd. De ontwikkelaar documenteert complexe PowerFx-formules inline en voegt notities met toelichting toe aan Power Automate acties.

Kom je er toch niet uit?

De hierboven beschreven valkuilen en oplossingen betreffen slechts een deel van de obstakels die je tegen kunt komen in jouw Power Platform-projecten. Mocht je er zelf niet uitkomen, laat het ons dan weten.

Stel ons een vraag!