Module Management houdt een actueel register bij van elke module die het platform kan aanbieden en beheert per implementatie de ingeschakelde status van elk daarvan. Beheerders schakelen een module in om het volledige gebied ervan in het draaiende systeem te brengen, of schakelen deze uit om dat gebied netjes terug te trekken, en de wijziging heeft direct effect in de gehele suite. Wanneer een module wordt uitgeschakeld, verdwijnen de navigatie-items uit de zijbalk, stoppen de routes met bedienen en weigeren de programmatische endpoints toegang, zodat een uitgeschakelde functionaliteit werkelijk afwezig is en niet slechts verborgen achter een menu.

Het register bevat de beschrijvende identiteit van elke module: de weergavenaam en beschrijving, het pictogram en basispad die de module in de navigatie verankeren, de ordening die de positie in de zijbalk vastlegt, en de markering die aangeeft of de module fundamenteel is voor het platform. Het bevat ook de gedeclareerde afhankelijkheden van elke module, de andere functionaliteiten die aanwezig moeten zijn om te kunnen functioneren. Daarbovenop onderscheidt de module kernfunctionaliteiten, zoals de fundamenten voor systeembeheer en het dashboard, die het platform nodig heeft om te werken en daarom beschermt tegen uitschakeling. Het resultaat is een compositielaag waarmee een organisatie de suite op haar structuur kan afstemmen, terwijl gegarandeerd wordt dat het platform nooit onder het minimum zakt dat het nodig heeft om te draaien.

Centraal in dit domein staat het idee van een module: een op zichzelf staande bedrijfsfunctionaliteit met een stabiele identiteit, een plaats in de navigatie en een afgebakende grens voor de data en acties die het beheert. Elke module wordt aangeduid met een unieke korte naam die nooit verandert, zodat de rest van het platform er betrouwbaar naar kan verwijzen, ook wanneer de beschrijving, het pictogram of de positie in de loop van de tijd worden verfijnd. Rond die identiteit ligt het presentatieve detail dat een module haar gezicht in de interface geeft, en de ordening die bepaalt waar deze verschijnt ten opzichte van de andere modules.

Het tweede ordenende concept is de ingeschakelde status, het eenvoudige maar ingrijpende gegeven of een functionaliteit momenteel deel uitmaakt van de implementatie. De status is niet cosmetisch: deze bepaalt in één keer de navigatie, het bedienen van routes en de toegang, en daarom behandelt het register de status als de gezaghebbende bron van waarheid voor wat het platform op dit moment aanbiedt. Het derde concept is afhankelijkheid, de relatie die elke module aangeeft ten opzichte van de andere waarop deze steunt. Een functionaliteit die gebruikmaakt van connectorinfrastructuur of het systeemfundament benoemt die behoeften expliciet, en het register leest die declaraties als een graaf in plaats van een platte lijst, zodat het in- of uitschakelen van een functionaliteit altijd wordt beoordeeld tegen het web van relaties eromheen. Een vierde onderscheid, of een module core is, zet de fundamenten apart waarzonder het platform niet kan draaien, en die fundamenten worden permanent ingeschakeld gehouden. Samen beschrijven deze concepten een systeem dat samengesteld is in plaats van vast, waar de vorm van de suite een expliciete, beheerde configuratie is.

De bepalende workflow is compositie. Een beheerder bekijkt het register, ziet elke module met de huidige status, beschrijving en afhankelijkheden, en schakelt functionaliteiten in of uit om aan te sluiten bij de behoeften van de organisatie. Wanneer een module wordt ingeschakeld, worden de gedeclareerde afhankelijkheden gecontroleerd zodat deze nooit online komt zonder de functionaliteiten die zij vereist; het register brengt elke ontbrekende voorwaarde naar voren en schakelt de keten in de juiste volgorde in. Wanneer een functionaliteit wordt uitgeschakeld, controleert het register de andere richting, door de modules te identificeren die afhankelijk zijn van de module die wordt teruggetrokken, zodat niets naar een afwezige functionaliteit blijft verwijzen. Deze tweezijdige beoordeling maakt van wat een kwetsbare handmatige oefening zou kunnen zijn een begeleide, veilige operatie.

Naast het in- en uitschakelen onderhouden beheerders de metadata van modules, door beschrijvingen, pictogrammen en de ordening in de zijbalk aan te passen om de navigatie samenhangend te houden naarmate de implementatie evolueert. Zij beheren het register zelf, door te bekijken welke functionaliteiten actief zijn, welke donker worden gehouden en hoe de gehele omvang is ingericht. Elk van deze acties is een administratieve handeling die door rechten wordt bewaakt, zodat het samenstellen van het platform een weloverwogen daad is die wordt uitgevoerd door hen die daartoe gerechtigd zijn, en het huidige register altijd een doordachte configuratie weerspiegelt in plaats van opgestapelde afwijking.

De waarde van een compositielaag ligt in de striktheid waarmee deze consistentie afdwingt, en Module Management is daar nauwgezet in. De afhandeling van afhankelijkheden is transitief: omdat afhankelijkheden een graaf vormen, lost het register ze op langs hun volledige ketens, zodat het inschakelen van een functionaliteit alles daaronder meebrengt en het uitschakelen ervan wordt geblokkeerd of doorgevoerd naargelang wat er nog op steunt. Dit voorkomt de klassieke fout van een platform waar een functie nominaal aanwezig is maar stilzwijgend defect omdat iets wat zij nodig had nooit werd ingeschakeld.

De bescherming van de kern is absoluut. De fundamentele modules waar het platform op steunt om te functioneren zijn gemarkeerd als core en kunnen onder geen enkele omstandigheid worden uitgeschakeld, wat een hele categorie van zelf toegebrachte uitval wegneemt. De handhaving is verdediging in de diepte in plaats van één enkele controle: het uitschakelen van een module trekt deze terug uit de navigatie, stopt de routes en weigert de endpoints, zodat de grens standhoudt of een verzoek nu via de interface arriveert of rechtstreeks tegen het programmatische gebied van het platform. Omdat de ingeschakelde status en de toegangsgrens één en hetzelfde zijn, is er geen kloof tussen wat een gebruiker kan zien en wat deze kan bereiken. Het register bewaart ook een stabiele identiteit voor elke module, zodat rechten, auditgegevens en integraties die naar een functionaliteit verwijzen geldig blijven bij elke wijziging in de presentatie ervan, en de compositie van de suite leesbaar en beheersbaar blijft, hoe vaak deze ook opnieuw wordt vormgegeven.

Module Management is de laag waardoor elk ander onderdeel van de suite beschikbaar wordt. Het werkt samen met het fundament voor rechten en toegangsbeheer: het register bepaalt of een functionaliteit in een implementatie bestaat, en toegangsbeheer bepaalt wie deze mag gebruiken, en samen vormen de twee het volledige antwoord op wat een bepaalde gebruiker kan doen. Het maakt rechtstreeks gebruik van Connector Management, aangezien data-integratiemodules hun afhankelijkheid van connectorinfrastructuur declareren en het register die relatie eert bij het samenstellen ervan. Functionaliteiten zoals Content Management bevinden zich stroomafwaarts en komen pas online wanneer aan hun systeem- en connectorvoorwaarden is voldaan.

Omdat het register de zijbalk bepaalt, vormt het de ervaring die het Dashboard levert en de navigatie die elke operationele module overneemt, van financiën en inkoop tot personeels- en activafunctionaliteiten. De audit- en activiteitenlaag van de suite legt wijzigingen aan het register vast naast elke andere administratieve gebeurtenis, zodat de geschiedenis van hoe het platform werd samengesteld op dezelfde plek leeft als de rest van het operationele register van de organisatie. In de praktijk is Module Management de naad die één suite laat verschijnen als evenzoveel verschillende platforms, elk precies afgestemd op de afdeling of entiteit die het draait, terwijl het daaronder één samenhangend systeem blijft.

AI Workers zijn volwaardige gebruikers van Module Management en werken via hetzelfde register en dezelfde rechtengrens als elke beheerder. Een beheerder kan een Worker in gewone taal vragen welke functionaliteiten in een implementatie zijn ingeschakeld, waarvan een bepaalde module afhankelijk is, of welke modules zouden worden geraakt door het terugtrekken van een specifieke functionaliteit, en de Worker antwoordt door het actieve register te lezen en de afhankelijkheidsgraaf te traceren. Dit maakt van de compositie van het platform iets wat een beheerder in gesprek kan bevragen in plaats van met de hand te reconstrueren.

Workers handelen ook. Binnen de aan hen verleende rechten schakelt een Worker modules in of uit, lost de afhankelijkheidsketen op die een wijziging vereist, en past de metadata van modules aan, waarmee de compositie wordt uitgevoerd die een beheerder beschrijft. Zij bewaken het register op afwijkingen en uitzonderingen: een functionaliteit die is ingeschakeld zonder een afhankelijkheid die deze zou moeten hebben, een configuratie die afwijkt van een beheerde standaard, een poging om een kernfundament te verstoren, en zij melden die als waarschuwingen voordat ze fouten worden. Wanneer de declaraties van een module of een voorgestelde configuratie binnenkomen als een document of een externe definitie, halen Workers de relevante structuur eruit en verzoenen deze met het register. In besluitvormingsondersteuning wegen zij de stroomafwaartse impact van een wijziging af en zetten de gevolgen ervan uiteen, en in beheerde workflows nemen zij deel als goedkeurings- of beoordelingsschakel, door een voorgestelde wijziging in de compositie van het platform te onderzoeken en deze goed te keuren of aan te houden volgens de regels die de organisatie heeft vastgesteld, zodat het opnieuw vormgeven van de suite zowel sneller als gedisciplineerder verloopt.