Integratieplan
Objecten
§ 4.1Klaar
Voorbereiding architectuur-overleg
Woensdag 3 juni 2026
Integratieplan CRM ↔ Tobias 365
Gezamenlijk doorlopen en invullen van het Integratieplan (Bijlage S) met de Architectuurboard van Ymere. Deze pagina volgt het Ymere-format, vult onze antwoorden in waar bekend, en markeert expliciet wat ik vooraf moet bespreken met Ben & Jos.
01 · Beoordelingscriteria Ymere
Waar de Architectuurboard op scoort
Zes criteria. Per criterium een snelle inschatting waar we staan voor het overleg.
Criterium 1
Volledigheid technische uitwerking
Architectuur, datamodel, API's, datatoegang en bronverantwoordelijkheid zijn uitgewerkt in het beantwoordingsdocument. Ymere-template tot in detail invullen woensdag.
Criterium 2
Realiteitsgehalte & toepasbaarheid
Standaardconnector Tobias 365 bestaat en draait al in productie bij meerdere corporaties. Just-in-time + synchronisatie is bewezen patroon.
Criterium 3
Kwaliteit architectuurkeuzes
REST + JIT als primair patroon is verdedigbaar. Onderbouwing keuzes vs. event-driven / webhooks nog scherp te maken met Ben & Jos.
Criterium 4
Aantoonbare praktijkervaring
60+ corporaties; standaardconnector Tobias 365 in productie bij meerdere klanten. Concrete cases noemen (zie praktijkvoorbeelden).
Criterium 5
Risico's & mitigerende maatregelen
Algemeen risicolog uit projectplan beschikbaar. Voor Tobias 365-koppeling specifiek nog een gerichte sessie met Ben & Jos om risico's en mitigaties scherp te krijgen.
Criterium 6
Security & beheerbaarheid
OAuth 2.0, TLS 1.2+, least-privilege scopes zijn standaard. Pentest-rapport, exacte token-rotatie en logging-policy verifiëren met Jos.
02 · Status per onderdeel
Statusdashboard Bijlage S
In één oogopslag waar we staan op de onderdelen van het Ymere integratieplan-format.
Integratieplan
Orkestratie
§ 4.2Bevestigen
Integratieplan
BIV-classificatie
§ 4.3Bevestigen
Integratieplan
Privacy / AVG
§ 4.4Klaar
Integratieplan
Regie
§ 4.5Uitzoeken
Integratieplan
Standaardisatie
§ 4.6Bevestigen
Security
Netwerktoegang
§ 5.1Bevestigen
Security
Authenticatie
§ 5.2Klaar
Security
Autorisatie
§ 5.3Bevestigen
Security
Versleuteling
§ 5.4Klaar
Security
Pentest
§ 5.5Bevestigen
03 · Architectuurcontext
CRM ↔ Tobias 365
Positionering en integratiepatronen die ten grondslag liggen aan het integratieplan.
3.1 · Positionering
Embrace Customers als regisserend CRM
Embrace Customers fungeert als centraal CRM met regie over omnichannel klantcontact, zaakgericht werken en selfservice. Het systeem orkestreert processen richting interne afdelingen en ketenpartners.
Tobias 365 (Aareon) is bronsysteem voor: huurders/relaties, contracten, financiële gegevens, vastgoed- en eenheidsgegevens.
Embrace Customers houdt zelf de bron voor zaken/dossiers, taken, contactmomenten en selfservice-uitkomsten. Geen redundante opslag van Tobias 365-brondata — pull/JIT in plaats van replicatie.
3.2 · Integratiepatronen
Beschikbare patronen Embrace Customers
- REST API's (primair) — JSON, real-time, OAuth 2.0, geschikt voor data-uitwisseling én procesaansturing.
- Webhooks (selectief) — notificaties bij statuswijzigingen; momenteel primair ingezet bij Dynamics Empire/Zig. Voor Tobias 365 verkennen we of hier toegevoegde waarde ligt.
- Batch-bestanden (uitfaserend) — alleen nog bij NCCW ERP-klanten; geen onderdeel van nieuwe implementaties.
- Database-koppelingen — niet ondersteund, volledig uitgefaseerd.
04 · Integratieplan
4.1 · Objecten
Bijlage S · Objecten
Welke objecten worden uitgewisseld
Welke objecten worden er uitgewisseld? Is het bronsysteem van de koppeling ook bronsysteem van het object? Zijn deze objecten voor meerdere doelsystemen nodig? Worden alleen de objecten uitgewisseld die nodig zijn (dataminimalisatie)?
Uit Tobias 365 naar Embrace Customers (pull / JIT):
- Persons / Organizations — persoons- en contactgegevens (aanvullend op de Embrace-relatie)
- Contracts — contractinfo, prijscomponenten, huuropzegging, inspecties
- Customers — financiële gegevens, betalingen, betalingsregelingen
- RealEstateObjects — eenheidsgegevens, woningwaardering, attributen
Bronsysteem = Tobias 365 voor al deze objecten. Embrace Customers slaat deze gegevens niet redundant op; de actuele waarde komt JIT uit Tobias bij raadpleging of via een synchronisatie-pull voor kerngegevens.
Dataminimalisatie: per use case wordt alleen het minimaal benodigde subset opgehaald via specifieke endpoints (bijvoorbeeld GET RealEstateObject in plaats van bredere queries).
4.2 · Orkestratie
Bijlage S · Orkestratie
Trigger, stappen, transformatie, sync/async, full/delta
Op welke manier ontstaat in welk systeem de initiatie (trigger)? Welke stappen worden uitgevoerd? Hoe wordt data eventueel getransformeerd? Verloopt de uitwisseling synchroon of asynchroon en hoe? Betreft het een full-load of een delta-load?
Trigger:
- Gebruikersactie in CRM (klant opzoeken, klantkaart openen) → JIT-pull richting Tobias 365
- Procesactie (reparatieverzoek aanmaken, contractwijziging) → procesgestuurde call richting Tobias
- Periodieke synchronisatie van kerngegevens → pull vanuit Embrace richting Tobias
Stappen (JIT-voorbeeld): gebruiker zoekt klant → CRM stelt OAuth-token → GET Persons / Contracts / Customers / RealEstateObjects parallel → mapping naar Embrace datamodel → tonen op klantkaart.
Datatransformatie: mapping in de standaardconnector van Embrace; geen externe ETL-laag.
Synchroon / asynchroon: synchroon voor JIT (klantkaart blokkeert op antwoord). Procesgestuurde updates kunnen async via job-queue.
Full-load vs delta-load: initiële load (eerste vulling) en delta voor periodieke sync. Initial load gaat in roadmap volledig API-gedreven; batchbestanden worden uitgefaseerd.
Voor Ben & Jos
Welke combinatie van JIT + synchronisatie-pull hanteren we exact voor Tobias 365 bij Ymere? Welke entiteiten via sync, welke alleen JIT?
Voorstel: JIT voor financiële gegevens en contractdetails (altijd actueel). Synchronisatie-pull (nightly + on-demand) voor stabielere kerngegevens (RealEstateObjects, contract-metadata). Bevestigen of dit overeenkomt met de productiepraktijk bij vergelijkbare klanten.
Voor Ben & Jos
Welke frequentie hanteren we voor de synchronisatie-pull, en wat is de exacte job-architectuur (queue, retry, dead-letter)?
Voorstel: nightly volledige delta-sync + 4-uurs delta voor RealEstateObjects + ad-hoc trigger bij relevante events. Retry met exponential backoff, dead-letter queue richting alerting.
Voor Ben & Jos
Is "initial load via API" uit de roadmap al productiewaardig voor Tobias 365, of is dat nog te bouwen voor Ymere?
Voorstel om te bevestigen: we presenteren initial-load-via-API als roadmap-item dat voor Ymere op tijd beschikbaar is. Als dat niet kan: alternatief één-malige batch met duidelijke afbouw aankondigen.
4.3 · BIV-classificatie
Bijlage S · BIV
BIV-classificatie van beide applicaties
Wat is de BIV-classificatie van beide applicaties?
Embrace Customers: typisch BIV = Midden / Midden / Midden voor corporatie-CRM, met specifieke aandacht voor C (Vertrouwelijkheid) gezien persoonsgegevens van huurders. Definitieve classificatie wordt vastgesteld in samenwerking met Ymere op basis van hun classificatieraamwerk.
Tobias 365: wordt vastgesteld door Ymere/Aareon; Embrace neemt het over.
Voor het overleg
Welke BIV-classificatie hanteert Ymere zelf voor Tobias 365 en CRM? Vragen ze om bevestiging of leveren ze de classificatie aan?
Voorstel: woensdag aan Ymere vragen welke classificaties gelden, en bevestigen dat onze maatregelen (TLS 1.2+, OAuth 2.0, audit logging, ISO 27001 / SOC 2 voor Azure-componenten) passen bij Midden of hoger.
4.4 · Privacy / AVG
Bijlage S · Privacy
Persoonsgegevens in en tussen systemen
Staan er persoonsgegevens in het systeem opgeslagen? Worden er persoonsgegevens uitgewisseld?
Ja, beide systemen verwerken persoonsgegevens van huurders en contractanten.
- Wat wordt uitgewisseld: NAW, geboortedatum, contactgegevens (telefoon/e-mail), contract-relatie, betalingsgegevens. Geen BSN tenzij expliciet vereist en geautoriseerd.
- AVG-grondslag: uitvoering van de huurovereenkomst (art. 6.1.b) en wettelijke verplichting waar van toepassing.
- Dataminimalisatie: alleen die endpoints die nodig zijn voor de use case (zie autorisatie). Geen brede broadcast van persoonsgegevens.
- Bewerkersovereenkomst: Embrace heeft een DPA als onderdeel van de overeenkomst.
- Hosting binnen EER: Azure West-Europa (Nederland) en QTS Groningen. Geen verwerking buiten de EER.
- Bewaartermijnen: conform Ymere's verwerkingsregister; Embrace volgt de instellingen die door Ymere worden bepaald.
4.5 · Regie
Bijlage S · Regie
Monitoring, tokenbeheer en logging
Zijn er monitoring- en beheersafspraken (koppelvlak down / foutieve berichten)? Afspraak over beheer en vernieuwen van tokens/wachtwoorden? Logging-afspraken (account, tijd, koppelvlak, parameters; bewaartermijn, archief, performance-impact)?
Monitoring: Embrace monitort 24/7 via Zabbix (infra), Microsoft App Insights (Azure-componenten) en Elastic Cloud (logging). Bij afwijking automatisch ticket richting Service Delivery team en proactieve melding richting Ymere via ticketsysteem.
Foutafhandeling op koppelvlak: retry met exponential backoff, dead-letter queue bij persisterende fouten, alerting naar service-team. Verstoring van koppelvlak → automatische incidentprioriteit.
Logging: applicatie- en koppellogs in Elastic Cloud met account, timestamp, endpoint en (gehashte/gemaskeerde) parameters waar relevant.
Voor Ben & Jos
Wat is onze exacte token-rotatie-policy voor de Tobias 365-OAuth-tokens? Hoe automatiseren we dit en hoe rapporteren we het naar Ymere?
Voorstel: client-credentials flow met access-tokens met korte levensduur (bijv. 1 uur) + automatische rotatie van client-secrets per 12 maanden (of conform Ymere-beleid). Geen lange-lopende tokens in onze code. Bevestigen door Jos.
Voor Ben & Jos
Wat is onze exacte audit-log policy: welke velden, bewaartermijn, archief-locatie, performance-impact, en hoe is Ymere als afnemer inzichtelijk?
Voorstel: centrale Elastic-index met 90 dagen hot + 1 jaar warm/cold + archief in Azure Blob. Op verzoek inzage via gedefinieerde queries of export. Performance-impact verwaarloosbaar door async write. Concrete velden & retention bevestigen met Jos.
Voor Ben & Jos
Hebben we al een dashboard / statuspage die Ymere kan inzien voor de Tobias 365-koppeling specifiek?
Voorstel: publieke statuspage is in ontwikkeling (al benoemd in SLA). Tot die tijd inzage op aanvraag via Service Delivery. Roadmap-datum bevestigen met Ben.
4.6 · Standaardisatie
Bijlage S · Standaardisatie
VERA en berichtformaat
Zijn de berichten gestandaardiseerd in VERA of een andere branchestandaard? Welk formaat heeft het bericht (JSON, XML, Excel)?
Berichtformaat: JSON, REST API conform OpenAPI / Swagger documentatie.
VERA-compliance: de Embrace-standaardconnector voor Tobias 365 sluit aan op de Aareon-API zoals geleverd. Voor de eigen Embrace-API's gebruiken we onze eigen schema's; VERA wordt gevolgd waar relevant en gangbaar in de corporatie-keten.
Voor Ben & Jos
In hoeverre voldoen onze API's en de Tobias 365-koppeling aan de VERA-standaard? Welke entiteiten/velden zijn VERA-conform, welke niet?
Voorstel: we presenteren onze positie als "VERA-aware, niet 100% VERA-strict" en bieden mapping waar nodig. Concrete VERA-mapping per entiteit afstemmen met Ben. Belangrijk: Ymere is mogelijk niet eisend op 100% VERA — verifiëren in het overleg.
05 · Security
5.1 · Netwerktoegang
Bijlage S · Netwerk
Beveiliging van het koppelpunt
Is de toegang tot het koppelpunt netwerk-technisch beveiligd? En op welke manier?
Endpoints zijn alleen bereikbaar via HTTPS (TLS 1.2+) over het publieke internet, achter Azure Application Gateway / WAF met OWASP Top 10 ruleset. IP-allowlisting is per klant configureerbaar.
Voor Ben & Jos
Past Ymere IP-allowlisting toe, of werken we volledig over openbare endpoints met OAuth + WAF? Is er behoefte aan een private endpoint / ExpressRoute?
Voorstel: standaard publieke endpoint met WAF en OAuth 2.0 is voldoende. Optioneel IP-allowlisting als Ymere dat hanteert. Private endpoint / ExpressRoute is afwijkend van onze standaard; mits gewenst onderzoeken we de impact.
5.2 · Authenticatie
Bijlage S · Authenticatie
OAuth 2.0
Standaard dient deze via OAuth 2.0 te verlopen. Als dit afwijkt, toelichten.
Volledig OAuth 2.0 via client-credentials flow voor server-to-server (CRM ↔ Tobias 365). Voor eindgebruikers van het CRM: SSO via Microsoft Entra ID (Azure AD) van Ymere.
Identity provider in roadmap: Keycloak wordt geïntroduceerd als nieuwe IDP voor verdere professionalisering en federatieve koppelingen.
5.3 · Autorisatie
Bijlage S · Autorisatie
Least privilege
Is de toegang tot het koppelpunt geautoriseerd tot het minimale dat nodig is? Alleen die koppelpunten openstellen die nodig zijn voor de uitwisseling.
OAuth-scopes worden ingericht per use case. Alleen de endpoints die nodig zijn voor de uitwisseling worden opengesteld — bijvoorbeeld GetRealEstateObject zonder PostRealEstateObject als alleen lezen nodig is.
Voor Ben & Jos
Welke exacte scope-set hebben we voor de Tobias 365-koppeling bij Ymere? Heeft Ben de mapping van use cases naar endpoints / scopes paraat?
Voorstel: we tonen woensdag een tabel "use case → endpoint → scope → read/write". Ben levert deze uiterlijk dinsdag aan op basis van de standaardconnector.
5.4 · Versleuteling
Bijlage S · TLS
TLS 1.2 of hoger
De uitwisseling van de data vindt versleuteld plaats met TLS 1.2 of hoger.
Alle data-uitwisseling vindt versleuteld plaats over TLS 1.2 of hoger. TLS-configuratie sluit zwakke ciphers uit. Data-at-rest in Azure is encrypted (Microsoft-managed keys; optioneel customer-managed keys).
5.5 · Pentest
Bijlage S · Pentest
Aantoonbaar getoetst op security
Zijn de koppelvlakken aantoonbaar getoetst op security? Bijvoorbeeld door een pentest.
De Embrace-omgeving en koppelvlakken worden periodiek door een onafhankelijke partij gepentest. Embrace verstrekt op verzoek een samenvatting van het meest recente pentest-rapport.
Voor Jos
Wat is de datum van het meest recente pentest-rapport, welke scope (omvat dit de Tobias 365-koppeling expliciet?), en zijn de bevindingen afgesloten?
Voorstel: samenvatting van het meest recente pentest-rapport meenemen naar het overleg. Status bevindingen: gesloten / open + termijn. Aankondigen wanneer de volgende pentest is.
06 · Risico's
Risico's & mitigerende maatregelen
Voor de Tobias 365-koppeling specifiek. Doorlopen tijdens het overleg en eventueel uitbreiden.
Midden
Performance bij JIT-pull richting Tobias 365
Klantkaart opent traag bij hoge latency of grote volumes ondergeschikte data.
Mitigatie
Hybride strategie: synchronisatie-pull voor stabiele kerngegevens, JIT alleen voor financieel/contract-actueel. Caching met korte TTL. Asynchrone laden van niet-kritieke widgets op de klantkaart.
Midden
Beschikbaarheid Tobias 365
Wanneer Tobias 365 onverhoopt onbereikbaar is, kan kritieke klantinformatie ontbreken in het CRM.
Mitigatie
Graceful degradation: laatste bekende sync-gegevens worden getoond met duidelijke "verouderd"-marker. Alerting bij failures. Statuspage en escalatieprocedure (Solution Board met KPN, Aareon, Embrace).
Hoog
Initial load via API mogelijk nog niet productiewaardig
Roadmap-item; risico dat dit voor Ymere nog niet op tijd beschikbaar is. Fallback batch is uitfaserend.
Mitigatie
Vóór woensdag intern (Ben) bevestigen of API-initial-load productiewaardig is voor Tobias 365. Zo niet: éénmalige batch met afbouw-roadmap helder communiceren.
Midden
Tokenbeheer en wachtwoord-rotatie
Vergeten rotatie kan leiden tot ongeplande downtime van de koppeling; lange levensduur verhoogt risico.
Mitigatie
Geautomatiseerde rotatie via Key Vault, monitoring op token-leeftijd, alerts bij 80% expiry. Documenteren in beheerproces en aan Jos overdragen.
Laag
VERA-compliance discussie
Ymere kan strikte VERA-compliance verwachten op alle entiteiten.
Mitigatie
Vooraf VERA-positionering helder: "VERA-aware, mapping waar zinvol". Per entiteit aangeven hoe gemapt; ruimte voor toekomstige uitbreiding.
Laag
HSO als integratiepartner
Mogelijke afhankelijkheid van HSO bij delen van de integratie; rolverdeling onduidelijk.
Mitigatie
Woensdag rolverdeling Embrace / Ymere / HSO expliciet maken. RACI op tafel leggen voor implementatie, beheer en incidenten.
07 · Aantoonbare praktijkervaring
Concrete cases die we kunnen noemen
Referenties uit de praktijk om bij criterium 4 sterk te scoren.
Productiestandaard
Standaardconnector Tobias 365
In productie bij meerdere corporaties — JIT + synchronisatie-pull als bewezen patroon voor persons, contracts, customers, real-estate.
Schaal
60+ implementaties
Standaard implementatiemethode met gemiddelde doorlooptijd circa 18 weken. Inrichting via standaardconnectoren (Tobias 365, Aareon DMS, PCA, Casix, Unexus).
Webhooks
Dynamics Empire / Zig in productie
Aantoonbare ervaring met event-driven integratiepatronen bij ERP-koppelingen — relevant als referentie voor design-keuzes.
Documenten
Aareon DMS-koppeling
JIT-ophalen van documenten bij openen klantkaart of portaal. In productie. Direct vergelijkbaar patroon voor Tobias 365.
Identity
Entra ID SSO bij meerdere corporaties
Productie-implementaties met SSO op Microsoft Entra ID — relevant voor Ymere's eigen tenant.
Roadmap
Keycloak als nieuwe IDP
Doorontwikkeling identitymanagement voor federatieve identiteitskoppelingen — onderdeel van technische roadmap korte termijn.
Voor Edwin (en eventueel Ben)
Welke specifieke corporatie-namen mogen we noemen als referentie tijdens het overleg?
Voorstel: drie concrete namen voorbereiden met korte één-regel-omschrijving van de Tobias 365-koppeling daar. Bij voorkeur corporaties van vergelijkbare omvang als Ymere.
08 · Documentatie
Mee te nemen naar het overleg
Checklist conform Bijlage S — status per item.
Architectuurdiagram koppeling
Beschikbaar in beantwoordingsdoc; eventueel detail-diagram voor de Tobias 365-koppeling toevoegen.
Overzicht gebruikte objecten
Persons, Organizations, Contracts, Customers, RealEstateObjects, ServiceObjects.
Bron- en doelsysteem per object
Tobias 365 als bron voor alle vier; CRM als bron voor zaken, taken, contactmomenten, selfservice.
Gebruikte persoonsgegevens
NAW, geboortedatum, contactgegevens, contractdata. Geen BSN tenzij expliciet geautoriseerd.
API-documentatie
Beschikbaar via Embrace-kennisbank. Bevestig met Ben: meest actuele Swagger/OpenAPI-link voor Ymere.
Endpoint-overzicht
Use case → endpoint → scope-tabel woensdag op tafel. Ben levert dinsdag aan.
Security-documentatie
ISO 27001-, SOC 1/2-rapporten Azure beschikbaar. Eigen security-beleid Embrace verifiëren met Jos.
Monitoring-beschrijving
Zabbix + App Insights + Elastic. Specifiek voor de Tobias 365-koppeling: dashboard / alerts toelichten — Jos.
Pentest-rapport / samenvatting
Meest recente samenvatting meenemen. Datum + scope bevestigen met Jos.
09 · Voorstel agenda
Tijdsindeling voor woensdag
Indicatieve agenda — kan in overleg met Ymere bijgesteld worden.
-
00:00Welkom & doelDoel van de sessie, scope (1 integratie: CRM ↔ Tobias 365), beoordelingscriteria kort doorlopen.
-
+10 minArchitectuurcontext & positioneringEmbrace Customers als regisserend CRM, bronverantwoordelijkheid, integratiepatronen.
-
+25 minIntegratieplan — Objecten & OrkestratieWelke entiteiten, trigger, sync vs JIT, full- vs delta-load. Open punt: initial-load via API.
-
+50 minBIV, Privacy & StandaardisatieBIV-classificatie afstemmen, AVG-grondslag bevestigen, VERA-positie.
-
+70 minRegie: monitoring, tokens, loggingMonitoring-stack, foutafhandeling, token-rotatie, logging-policy + bewaartermijn.
-
+90 minSecurityNetwerk, OAuth, autorisatie / least-privilege scopes, TLS, pentest.
-
+110 minRisico's & mitigatiesDoorlopen risicolog koppeling; benoemen mitigaties; rolverdeling Embrace / Ymere / HSO.
-
+130 minPraktijkvoorbeeldenConcrete referenties van Tobias 365-koppelingen elders. Q&A.
-
+145 minAfronding & vervolgEventuele open punten richting Architectuurboard, follow-up acties.