SharePoint is de voorbije vijf jaar sterker veranderd dan in het decennium daarvoor. Als je bij SharePoint nog denkt aan subsites, paginalay-outs en master pages, of als je beeld gebaseerd is op een tutorial uit 2019, dan werk je met een verouderd beeld van het platform.
De moderne SharePoint-architectuur ziet er fundamenteel anders uit. Ze is sneller, flexibeler en beter geïntegreerd met de rest van Microsoft 365. Maar ze vergeeft ook minder snel wanneer je de onderliggende ontwerpprincipes verkeerd begrijpt.
In dit artikel krijg je een praktisch overzicht van hoe modern SharePoint is opgebouwd, welke keuzes belangrijk zijn bij het ontwerpen van een intranet en waar het in de praktijk vaak misloopt.
Van subsites naar hubsites
De belangrijkste architecturale verandering in modern SharePoint is het verdwijnen van de subsite. (Microsoft Learn: Information architecture in the modern SharePoint experience)
In de klassieke versie van SharePoint bouwden organisaties een hiërarchie op door subsites onder elkaar te plaatsen. Het intranet stond bijvoorbeeld op /sites/intranet, HR op /sites/intranet/hr, Finance op /sites/intranet/finance, enzovoort. Dat zorgde voor een duidelijke URL-structuur en centraal beheer, maar had ook belangrijke nadelen. Machtigingen werden automatisch overgenomen door onderliggende sites, content verplaatsen was omslachtig en de volledige structuur werd na verloop van tijd moeilijk te beheren of te reorganiseren.
Modern SharePoint vervangt dat model door hubsites. In plaats van sites onder elkaar te plaatsen, koppel je zelfstandige sites aan een hub. Die hub zorgt voor gedeelde navigatie, een consistente huisstijl en zoeken over verschillende sites heen, zonder dat er nog een hiërarchische afhankelijkheid ontstaat.
In de praktijk betekent dit dat elke afdeling of dienst een eigen SharePoint-site krijgt, met een eigen levenscyclus, machtigingen en governance. De hub verbindt die sites visueel met elkaar en maakt ze gezamenlijk doorzoekbaar. Je kunt een site later eenvoudig aan een andere hub koppelen of volledig losmaken, zonder dat de inhoud verandert.
Voor het ontwerp van een intranet is dat een enorm verschil. Een goed opgebouwde hubarchitectuur geeft teams de vrijheid om hun eigen omgeving te beheren, terwijl medewerkers toch één samenhangende intranetervaring krijgen. Een slecht ontworpen hubstructuur oogt tijdens de demo misschien logisch, maar wordt in de praktijk al snel moeilijk te onderhouden.
Belangrijke keuze: hoeveel hubs heb je nodig? Voor veel organisaties volstaat één centrale hub. Grotere organisaties kiezen vaak voor een hiërarchie met één centrale intranethub en daaronder hubs voor verschillende afdelingen of domeinen. Modern SharePoint ondersteunt ook koppelingen tussen hubs, zodat je hubs onder andere hubs kunt organiseren zonder terug te grijpen naar het oude subsite-model. Microsoft ondersteunt tot 2.000 hubsites per tenant (Microsoft Learn: Planning hub sites). In de praktijk wordt die limiet meestal niet bepaald door SharePoint, maar door hoeveel governance je organisatie kan beheren.
Communicatiesites en teamsites zijn niet uitwisselbaar
Modern SharePoint biedt twee belangrijke sitesjablonen. De meeste mensen weten dat ze verschillend zijn. Veel minder mensen weten wanneer je welke gebruikt.
Communicatiesites zijn bedoeld om informatie te publiceren. Eén of enkele personen publiceren content, terwijl veel medewerkers die lezen. Ze bevatten paginalay-outs die geschikt zijn voor nieuws, hero-banners, nieuwswebparts en doelgroepgerichte communicatie. Ze zijn niet gekoppeld aan een Microsoft 365-groep. Daardoor zijn ze ideaal voor intranetten, afdelingspagina’s, beleidspagina’s en andere omgevingen waarbij één groep publiceert en een grote groep leest.
Teamsites zijn ontworpen voor samenwerking. Ze zijn gekoppeld aan een Microsoft 365-groep, een Teams-kanaal, een gedeelde mailbox, Planner en een SharePoint-documentbibliotheek. Ze zijn bedoeld voor projectteams, werkgroepen en afdelingen die samen documenten beheren en content creëren.
De fout die veel organisaties maken, is dat ze teamsites voor alles gebruiken, ook voor hun intranet, simpelweg omdat Microsoft Teams deze automatisch aanmaakt. Teamsites zijn echter geen goede intranet-homepages. Ze zijn niet ontworpen voor een breed publiek, bieden minder flexibiliteit voor contentpresentatie en de gekoppelde Microsoft 365-groep zorgt voor extra complexiteit op het vlak van machtigingen en governance, terwijl je dat voor bedrijfsbrede communicatie net wilt vermijden.
Belangrijke keuze: gebruik communicatiesites voor je intranethub en alle pagina’s die gericht zijn op medewerkers. Teamsites bestaan naast het intranet en dienen voor samenwerking, niet als onderdeel van het intranet zelf.
SharePoint Framework (SPFx): de uitbreidingslaag
Standaard biedt SharePoint een uitgebreide set webparts, zoals nieuws, evenementen, snelle koppelingen, documentbibliotheken en medewerkersprofielen. Voor veel intranettoepassingen zijn die meer dan voldoende.
Wanneer dat niet volstaat, biedt SharePoint Framework (SPFx) de mogelijkheid om de omgeving uit te breiden. SPFx is een ontwikkelmodel op basis van TypeScript waarmee je aangepaste webparts, extensies en applicatie-uitbreidingen kunt bouwen die rechtstreeks binnen SharePoint-pagina’s draaien. SPFx ondersteunt verschillende JavaScript-frameworks, zoals React, Angular, Vue.js, Handlebars en andere. (Microsoft Learn: SharePoint Framework overview)
SPFx is krachtig. Maar het brengt ook verantwoordelijkheden met zich mee.
Aangepaste SPFx-oplossingen worden opgeslagen in de appcatalogus van de tenant. Ze moeten worden uitgerold, beheerd en bijgewerkt terwijl Microsoft het platform blijft doorontwikkelen. De SharePoint Online Workbench en het onderliggende FAST-framework waarop moderne SharePoint-pagina’s draaien, worden regelmatig aangepast, niet volgens een planning die jij bepaalt. Daardoor kunnen maatwerkoplossingen die vorige maand nog perfect werkten, zich na een platformupdate onverwacht anders gedragen.
Wanneer je intranet afhankelijk is van eigen SPFx-componenten, moet iemand daar blijvend verantwoordelijkheid voor nemen. Dat betekent onder meer:
- De SharePoint-roadmap en release notes van Microsoft opvolgen
- Aangepaste componenten testen in een testomgeving voordat ze tenantbreed worden uitgerold
- De code onderhouden wanneer de afhankelijkheden van SPFx wijzigen
- Versiebeheer van de appcatalogus uitvoeren wanneer een vorige versie moet worden teruggezet
Geen van deze taken is onoverkomelijk. Maar het is wel extra ontwikkelwerk dat meestal niet wordt meegenomen in de oorspronkelijke inschatting van het project.
Belangrijke keuze: controleer vóór je een eigen SPFx-webpart ontwikkelt eerst of een standaardwebpart of een oplossing van een derde partij hetzelfde probleem kan oplossen. Maatwerk is vaak de juiste keuze, maar het moet een bewuste beslissing zijn, geen standaardkeuze.
Microsoft Graph: de laag die alles met elkaar verbindt
Modern SharePoint staat niet op zichzelf. Het is verbonden met de rest van Microsoft 365 via Microsoft Graph, de API-laag die gegevens ontsluit uit onder meer Outlook, Teams, OneDrive, Entra ID en Planner.
Dat is precies wat moderne SharePoint-intranetten zo krachtig maakt wanneer ze goed zijn opgebouwd:
- De People-webpart haalt profielgegevens en de organisatiestructuur rechtstreeks uit Entra ID
- Doelgroepgerichte content gebruikt Entra ID-groepen om informatie automatisch te personaliseren. Er is dus geen aparte gebruikersdatabase nodig
- My Feed verzamelt informatie uit Microsoft 365, zoals documenten waaraan je hebt gewerkt, aankomende vergaderingen en nieuws van sites die je volgt
- Viva Connections toont je intranet rechtstreeks binnen Microsoft Teams via dezelfde Microsoft Graph-koppelingen
Ook de Graph-machtigingen binnen SharePoint zijn belangrijk om goed te begrijpen. SPFx-oplossingen en app-registraties vragen gedelegeerde machtigingen of machtigingen op applicatieniveau aan. Bij gedelegeerde machtigingen kan een applicatie alleen uitvoeren wat de aangemelde gebruiker zelf mag doen. Dat is het standaard- en veiligste model. Applicatiemachtigingen werken los van de aangemelde gebruiker en verdienen daarom extra aandacht tijdens de goedkeuring.
Of je nu een intranet zelf bouwt of een bestaande oplossing gebruikt: als IT-team moet je begrijpen welke Microsoft Graph-machtigingen worden aangevraagd en waarom.
Viva Connections: de toegangspoort tot je intranet in Teams
Viva Connections is Microsoft’s antwoord op de vraag: “Hoe krijgen medewerkers toegang tot het intranet als ze de hele dag in Teams werken?”
Viva Connections toont SharePoint-content binnen Microsoft Teams via een dashboard met Adaptive Cards, een nieuwsfeed en koppelingen naar belangrijke informatie. Medewerkers kunnen dezelfde omgeving ook openen via de SharePoint-homepage of het Viva Suite-webportaal. SPFx is het enige ondersteunde uitbreidingsmodel voor Viva Connections. Wil je eigen dashboardkaarten bouwen, dan moeten die ontwikkeld worden met SPFx Adaptive Card Extensions. (Microsoft Learn: Viva Connections overview)
Het is belangrijk om goed te begrijpen wat Viva Connections wél en niet is:
Viva Connections is wel: Een toegangspoort. Een manier om je SharePoint-intranet beschikbaar te maken via Teams, het web en mobiele apparaten zonder alles opnieuw te bouwen. Vooral interessant voor organisaties waar Teams het centrale platform voor dagelijks werk is.
Viva Connections is niet: Een intranet. Het vervangt de SharePoint-contentlaag, het governancemodel, de nieuwsstructuur of de functionaliteiten rond adoptie niet. Het is een manier om content weer te geven, geen volledig intranetplatform.
Een veelgemaakte fout is om Viva Connections te zien als vervanging voor een goed opgebouwde intranetarchitectuur. Een slecht gestructureerd SharePoint-intranet blijft een slecht gestructureerd intranet, ook wanneer je het via Teams beschikbaar maakt.
Waar oplossingen zoals Involv binnen deze architectuur passen
Een vraag die IT-teams vaak stellen wanneer ze intranetoplossingen evalueren, is: “Vervangt dit SharePoint, of draait het boven op SharePoint?”
Voor oplossingen die gebouwd zijn op SharePoint Framework, zoals Involv Intranet, is het antwoord het tweede. Het product wordt uitgerold als SPFx-pakketten in de appcatalogus van de tenant. Het draait volledig binnen de eigen SharePoint-omgeving van de klant, gebruikt de bestaande Entra ID-authenticatie en werkt met gedelegeerde Microsoft Graph-machtigingen. Alle gegevens blijven opgeslagen in SharePoint-lijsten en -bibliotheken binnen de tenant van de klant. Er is geen aparte hostingomgeving, geen datamigratie en geen extern identiteitssysteem nodig.
De architectuur ziet er als volgt uit: je Microsoft 365-tenant → je SharePoint-sites → SPFx-pakketten die daarboven de intranetlaag vormen.
Wat het product toevoegt, is de componentlaag, meer dan zestig vooraf gebouwde en configureerbare intranetwebparts, aangevuld met governancefunctionaliteiten zoals een contentdashboard, goedkeuringsworkflows en doelgroepgerichte content. Daarnaast biedt het een mobiele app en adoptiefuncties zoals welkomsttours, verplichte leesbevestigingen, pushmeldingen en analytics. Functionaliteiten die je anders zelf zou moeten ontwikkelen.
De rol van IT verandert daarbij niet. Je blijft verantwoordelijk voor de SharePoint-omgeving, de Entra ID-configuratie en je Microsoft 365-tenant. Je hoeft alleen niet langer zelf een volledige bibliotheek met intranetcomponenten te ontwikkelen én te onderhouden.
De keuzes die het grootste verschil maken
Wanneer je een moderne SharePoint-intranetarchitectuur ontwerpt, zijn dit de beslissingen die uiteindelijk het verschil maken:
- Hubstructuur: Hoeveel hubs heb je nodig en hoe koppel je afdelingssites aan elkaar?
- Keuze van sitesjablonen: Gebruik je communicatiesites voor communicatie en teamsites voor samenwerking, en pas je dat consequent toe?
- Eigenaarschap van SPFx: Als je maatwerk ontwikkelt, wie onderhoudt dat dan op lange termijn?
- Microsoft Graph-machtigingen: Begrijp je welke machtigingen je oplossingen aanvragen en waarom?
- Viva Connections: Gebruik je het als toegangspoort tot een goed opgebouwd intranet of als vervanging voor een doordachte intranetarchitectuur?
- Adoptie: Wie is verantwoordelijk voor content, meldingen en onboarding, en beschikt die persoon over de juiste tools?
Modern SharePoint biedt een uitstekende basis. Maar wat je erop bouwt én wie het daarna onderhoudt, bepaalt uiteindelijk of je intranet succesvol wordt.
Benieuwd hoe Involv Intranet eruitziet binnen je eigen Microsoft 365-omgeving?
