Wat is composable architecture?

Uw ERP is gebouwd toen het bedrijf half zo groot was als nu. Elk nieuw instrument dat sindsdien is toegevoegd — een klantenportaal, een verzendintegratie, een AI-ondersteunde offertemodule — is vastgebouten aan een systeem dat nooit bedoeld was om dat gewicht te dragen. De ontwikkeling vertraagt, de onderhoudskosten stijgen, en de mensen die het oude systeem door en door kennen worden een single point of failure. Composable architecture is het structurele antwoord op dat probleem. Dit artikel legt precies uit wat het inhoudt, waarom het relevant is voor middelgrote bedrijven, en hoe u er stap voor stap naartoe kunt zonder opnieuw te beginnen.

Wat betekent "composable architecture" eigenlijk?

Composable architecture is een ontwerpfilosofie waarbij een bedrijfsapplicatie wordt gebouwd — of geleidelijk herbouwd — als een verzameling onafhankelijke, uitwisselbare componenten, elk verantwoordelijk voor één duidelijke taak, verbonden via goed gedefinieerde interfaces (doorgaans API's). Vergelijk het met LEGO in plaats van beton: u kunt een blokje toevoegen, vervangen of verwijderen zonder de hele constructie te slopen.

De term werd rond 2020 door Gartner populair gemaakt, maar het onderliggende idee is ouder: modulair ontwerp, service-oriented architecture (SOA) en microservices delen dezelfde kern. Wat composable architecture toevoegt is een bedrijfsmatige invalshoek — het is niet alleen een technisch patroon, maar een bewuste strategie om software in lijn te houden met een bedrijf dat voortdurend verandert.

Belangrijke concepten die bij composable architecture horen:

• Packaged Business Capabilities (PBCs): afzonderlijke eenheden van bedrijfsfunctionaliteit (voorraadbeheer, facturering, routeplanning) die onafhankelijk van elkaar kunnen worden ingekocht, gebouwd of vervangen.
• API-first design: elk component stelt zijn data en logica beschikbaar via een gedocumenteerde API, zodat niets opgesloten zit in een gesloten black box.
• Loose coupling: componenten zijn afhankelijk van elkaars interfaces, niet van elkaars interne implementatie — zodat één component kan veranderen zonder dat een ander er last van heeft.
• Event-driven integration: componenten communiceren door gebeurtenissen te publiceren en te ontvangen (bijv. "order bevestigd", "voorraadniveau bijgewerkt") in plaats van directe aanroepen, wat de kwetsbaarheid vermindert.

Waarom is dit nu relevant? Wat is er veranderd?

Het standaardantwoord op groeiende bedrijfscomplexiteit was jarenlang een grotere monoliet — een allesomvattend ERP dat alles beloofde af te handelen. Dat werkte goed zolang processen stabiel waren en integraties zeldzaam. Het werkt niet meer wanneer:

• Een logistiek bedrijf zijn warehouse management systeem moet koppelen aan drie verschillende carrier-API's, een selfserviceportaal voor klanten en een realtime routeoptimalisatie-engine — allemaal geïntroduceerd in de afgelopen 18 maanden.
• Een productiebedrijf AI-gestuurde vraagprognoses wil toevoegen zonder de volledige productieplanningsmodule te herbouwen.
• Een professioneel dienstverlener een klantgericht projectdashboard nodig heeft dat live data ophaalt uit zijn interne FileMaker-systeem, zijn boekhoudplatform en zijn CRM — tegelijkertijd.

Monolithische systemen hebben hier moeite mee, niet omdat ze slecht zijn gebouwd, maar omdat ze zijn gebouwd voor een ander tijdperk. Elke nieuwe vereiste betekent ingrijpen in de kern, het geheel opnieuw testen en het risico op een onverwachte regressie ergens anders. De kosten en de angst voor verandering nemen met elk jaar toe.

Composable architecture doorbreekt die cyclus door verandering tot de norm te maken in plaats van de uitzondering.

Hoe verschilt composable architecture van microservices?

Microservices is een technisch implementatiepatroon: een applicatie opsplitsen in zeer kleine, onafhankelijk te deployen services, elk met een eigen proces. Composable architecture is de bredere strategie — microservices kunnen één manier zijn om die te bereiken, maar ze zijn niet de enige manier en zijn voor middelgrote bedrijven vaak overdreven.

Een praktisch composable systeem voor een productiebedrijf van 50 medewerkers kan bestaan uit:

• Een FileMaker-kern die productieorders, voorraadniveaus en aangepaste workflows beheert
• Een REST API-laag die die data beschikbaar stelt aan externe systemen
• Een cloudgebaseerd Power BI- of Metabase-dashboard voor managementrapportages
• Een mobiele webapplicatie waarmee medewerkers op de werkvloer productiestappen registreren
• Een OpenAI-aangedreven module die klantoffertes opstelt op basis van historische opdrachtendata

Geen van die componenten hoeft "microservices" te zijn in de strikte technische betekenis. Ze hoeven alleen maar loosely coupled en via API verbonden te zijn. Dat is composable denken toegepast op een schaal die daadwerkelijk haalbaar is zonder een team van 20 engineers.

Hoe ziet composable architecture er in de praktijk uit?

Productie: productieplanning loskoppelen van het ERP

Een middelgrote fabrikant runt zijn volledige bedrijfsvoering — inkooporders, productieplanning, voorraadbeheer, klantorders — in één FileMaker ERP dat in de loop van 10 jaar is opgebouwd. Dat werkt goed voor het kernproces. Het probleem: elke keer dat het commerciële team een nieuwe klantgerichte functie wil (een bezorgtrackingpagina, een geautomatiseerde orderbevestigingsmail, een dealerportaal), moeten aanpassingen worden gedaan in het monolithische FileMaker-systeem, moet alles opnieuw worden getest en moet een nieuwe versie worden uitgerold.

Met een composable aanpak blijft het FileMaker ERP het systeem of record voor productiedata. Er wordt een lichtgewicht API-laag toegevoegd — FileMaker Data API of een aangepaste middleware — die orderstatus, voorraadniveaus en levertijden beschikbaar stelt als overzichtelijke JSON-endpoints. Het dealerportaal wordt een aparte webapplicatie die data ophaalt via die API. Wanneer het portaal een nieuwe functie nodig heeft, wordt die onafhankelijk ontwikkeld en uitgerold. De FileMaker-kern wordt niet aangeraakt.

Resultaat: het kern-ERP blijft stabiel en eenvoudig te onderhouden; de klantgerichte laag ontwikkelt zich in het tempo dat het commerciële team nodig heeft.

Logistiek: carrier-API's koppelen zonder het TMS te herbouwen

Een logistiek bedrijf beheert zendingen in een FileMaker-gebaseerd transport management systeem (TMS). Wanneer een nieuwe carrier (PostNL, DHL, DPD) wordt toegevoegd, kopieert iemand handmatig trackingnummers vanuit het webportaal van de carrier naar FileMaker — elke zending, elke dag opnieuw. Wanneer de status van een zending wijzigt, heeft de klant geen idee totdat iemand belt.

Composable architecture betekent hier het introduceren van een carrier-integratielaag: een set API-connectoren, één per carrier, die trackinggebeurtenissen automatisch naar FileMaker doorsturen op het moment dat de carrier zijn systeem bijwerkt. Elke connector is een onafhankelijk component. Een vierde carrier toevoegen betekent een vierde connector schrijven — niet het TMS herbouwen. Een carrier verwijderen betekent één connector uitschakelen — verder verandert er niets.

De klantgerichte trackingpagina is een apart webcomponent dat dezelfde data ophaalt via API. Deze kan worden herontworpen, verplaatst naar een nieuw domein of volledig worden vervangen zonder enige impact op het TMS zelf.

Professionele dienstverlening: AI-ondersteunde voorstellen zonder het practice management systeem te vervangen

Een adviesbureau gebruikt FileMaker voor het beheren van projecten, personeelsinzet en klantgegevens. De directie wil AI-gegenereerde projectvoorstellen — waarbij klanthistorie, eerdere projectscopes en beschikbare capaciteit worden ingevoerd om in enkele minuten een eerste conceptvoorstel te genereren.

Bij een monolithische aanpak zou deze AI-functie binnen FileMaker moeten leven, gebouwd als een aangepast FileMaker-script of plugin — kwetsbaar, moeilijk te updaten en afhankelijk van de uitrolcyclus van FileMaker.

Bij een composable aanpak is de AI-functionaliteit een aparte service: een op Python gebaseerd API-endpoint dat een client-ID en projecttype ontvangt vanuit FileMaker, de relevante records ophaalt via FileMaker Data API, de OpenAI API aanroept met een gestructureerde prompt en een opgemaakt conceptvoorstel teruggeeft. FileMaker start het proces met één scriptstap. De AI-logica bevindt zich buiten FileMaker en kan worden bijgewerkt, opnieuw getraind of vervangen zonder het practice management systeem aan te raken.

Hoe beweegt u zich naar composable architecture zonder opnieuw te beginnen?

Dit is de vraag waar de meeste bedrijfseigenaren en IT-managers daadwerkelijk een antwoord op nodig hebben. Het antwoord is: stapsgewijs, te beginnen aan de randen.

Stap voor stap: van monoliet naar composable

1. Breng de grenzen van uw huidige systeem in kaart. Bepaal welke onderdelen van uw monoliet stabiel en kerngebonden zijn (weinig verandering verwacht) versus welke onderdelen volatiel zijn (regelmatige updates nodig, externe integraties vereisen, of de meeste onderhoudsproblemen veroorzaken). De stabiele kern blijft; de volatiele randen zijn kandidaten voor extractie.

2. Identificeer uw eerste "strangler fig"-kandidaat. Het strangler fig-patroon houdt in dat u een nieuw onafhankelijk component naast het oude systeem bouwt, relevant verkeer daarheen omleidt en de oude code geleidelijk laat uitdoven. Een goede eerste kandidaat: een rapportagedashboard, een klantgericht portaal of één enkele integratie (bijv. uw boekhoudkoppeling). Kies iets dat echt pijn veroorzaakt, maar niet het kloppende hart van uw bedrijfsvoering is.

3. Voeg een API-laag toe aan uw bestaande kern. Voordat u iets kunt verbinden, moet uw bestaande systeem kunnen communiceren met de buitenwereld. Als u met FileMaker werkt, activeer dan de FileMaker Data API of bouw een aangepaste middleware die de records en bewerkingen beschikbaar stelt die andere componenten nodig hebben. Documenteer deze zorgvuldig — een ongedocumenteerde API wordt een nieuwe monoliet.

4. Bouw het eerste nieuwe component onafhankelijk. Gebruik het juiste hulpmiddel voor de taak, niet het hulpmiddel dat u al heeft. Een klantenportaal kan een React-webapplicatie zijn. Een rapportagelaag kan Metabase zijn dat een gerepliceerde database bevraagt. Een AI-module kan een FastAPI Python-service zijn. Houd het klein en afgebakend — één taak, één component.

5. Definieer het contract en bescherm het vervolgens. Het API-contract tussen uw kern en uw nieuwe component is een belofte. Beide kanten zijn ervan afhankelijk. Versiebeheer uw API-endpoints (bijv. /api/v1/orders) en wijzig nooit de responsstructuur van een gepubliceerde versie zonder een versieupdate door te voeren. Deze discipline is wat composable architecture op de lange termijn laat werken.

6. Herhaal dit met het volgende pijnpunt. Composable transformatie is geen project — het is een doorlopende manier van werken. Elke keer dat u een nieuwe functionaliteit nodig heeft, stelt u de vraag: "Werkt dit beter als een nieuw onafhankelijk component, of hoort het echt thuis in de kern?" In de meeste gevallen horen nieuwe functionaliteiten buiten de kern.

Wat zijn de afwegingen en de echte valkuilen?

Composable architecture is niet gratis. Dit zijn de eerlijke nadelen:

• De operationele complexiteit neemt toe. In plaats van één systeem om te monitoren, heeft u er nu vijf. Elk component kan onafhankelijk uitvallen. U heeft logging, alerting en iemand nodig die het totaalplaatje begrijpt.
• API-versiebeheer is moeilijk vol te houden zonder discipline. Als u uw API's niet rigoureus versieert en documenteert, ontstaan er ongedocumenteerde afhankelijkheden die net zo kwetsbaar zijn als elke monoliet — behalve dat de kwetsbaarheid nu verborgen zit over de grenzen van componenten heen.
• Dataconsistentie wordt uw verantwoordelijkheid. In een monoliet zijn transacties eenvoudig. Over gedistribueerde componenten heen moet u zorgvuldig nadenken over wat er gebeurt wanneer één component wordt bijgewerkt en een ander de gebeurtenis niet ontvangt. Dit is een technisch probleem dat de meeste businessteams onderschatten.
• De initiële investering in de API-laag is reëel. Uw FileMaker- of legacy ERP-data op een nette manier via API beschikbaar stellen kost tijd en zorgvuldigheid. Het is geen weekendproject. Maar het is ook een eenmalige fundering — elk volgend component profiteert ervan.

Voor de meeste middelgrote bedrijven is het juiste antwoord een pragmatische composable aanpak: geen volledige microservices, maar een doordacht gemodulariseerd systeem waarbij de meest volatiele onderdelen onafhankelijk zijn en de stabiele kern beschermd en goed ontsloten is via API.

Checklist composable architecture: bent u er klaar voor?

Controleer voor u begint waar u staat:

• Weet u welke onderdelen van uw huidige systeem het vaakst veranderen?
• Stelt uw bestaande kernsysteem een gedocumenteerde API beschikbaar (of kan het dat)?
• Heeft u een duidelijke eigenaar voor de integratielaag (middleware, API gateway)?
• Is uw team in staat meerdere kleine componenten te onderhouden in plaats van één groot systeem?
• Heeft u monitoring en alerting per component afzonderlijk?
• Heeft u de datacontracten tussen uw huidige systemen gedocumenteerd?
• Is er een duidelijk bedrijfspijnpunt dat het eerste nieuwe component rechtvaardigt — en niet alleen architecturale ambitie?

Heeft u drie of meer vragen met "nee" beantwoord: begin dan met de API-laag en de strangler fig-aanpak voordat u volledige composability nastreeft.

FAQ

Is composable architecture alleen voor grote ondernemingen? Nee. Het principe schaalt goed naar beneden. Een logistiek bedrijf van 30 medewerkers met een FileMaker TMS en twee carrier-API-connectoren is al in betekenisvolle zin composable. Waar het om gaat is de mindset — bouw nieuwe functionaliteiten vanaf dag één als onafhankelijke componenten, in plaats van de kern altijd uit te breiden.

Betekent composable architecture dat ik naar de cloud moet overstappen? Niet noodzakelijk. Composable architecture gaat over de relatie tussen componenten, niet over waar ze draaien. U kunt een on-premise FileMaker-kern, een cloudgehost webportaal en een lokaal gedeployde AI-service samen composable laten samenwerken. Hybride is gangbaar en vaak het juiste antwoord.

Hoe beïnvloedt composable architecture mijn vendor lock-in risico? Het vermindert dit aanzienlijk — als elk component een gedocumenteerde API blootlegt en onafhankelijk vervangbaar is, kunt u elke leverancier verwisselen zonder alles opnieuw te bouwen. Dit is een van de meest onderschatte strategische voordelen voor bedrijven die jarenlang gebonden zijn geweest aan één ERP-leverancier.

Wat is het verschil tussen composable architecture en simpelweg veel SaaS-tools gebruiken? Veel SaaS-tools gebruiken zonder een doordachte integratiestrategie is fragmentatie, geen composability. Composable architecture vereist een bewust API-ontwerp, een helder systeem of record en weloverwogen beslissingen over waar elke functionaliteit thuishoort en hoe componenten met elkaar communiceren. Ad-hoc SaaS-sprawl is het tegenovergestelde van composable — het creëert nieuwe monolithische afhankelijkheden die u niet beheerst.

Kan FileMaker deel uitmaken van een composable architecture? Ja — en het is een natuurlijke keuze voor de rol van kern-systeem-of-record in veel middelgrote composable opstellingen. FileMaker's Data API, gecombineerd met aangepaste middleware of een API gateway, stelt het in staat te fungeren als een goed ontsloten data- en logicakern, terwijl onafhankelijke webapplicaties, mobiele apps, AI-services en externe integraties er omheen worden gebouwd.

---

Als uw bedrijf op het punt is aangekomen waarop uw huidige systeem u meer afremt dan vooruithelpt — waarbij elke nieuwe integratie voelt als een openhartoperatie — is composable architecture het serieus overwegen waard als structurele oplossing, niet alleen als technische trend. Bij Loggix helpen we bedrijven precies bij dit soort transities: in kaart brengen wat in de kern moet blijven, de API-laag ontwerpen die alles koppelbaar maakt, en de onafhankelijke componenten bouwen — of dat nu een op maat gemaakte webapplicatie is, een carrier-API-connector of een AI-module binnen uw bestaande FileMaker-omgeving — die uw software laten meegroeien met uw bedrijf. Als u wilt nadenken over hoe een composable aanpak eruit zou zien voor uw specifieke situatie, is dat gesprek een goed beginpunt.