Hiltermann POC · pitch and demo script

Event Bus + HIP

Events for “something happened”. HIP for “I need data from elsewhere”.

The machine does it. A person only steps in for the exceptions.

Hiltermann plans to route every system through its Middleware, HIP. This POC shows a stronger pattern: an Event Bus that every system joins on its own, with HIP as one participant that is called directly only to fetch data. Below: the pitch, a 10-minute demo you can give click by click, a recorded fallback, and what it takes to reach production.

Everything shown runs on the test environment. Screenshots and recording: 29 September 2026. All customer data is fictional (KVK test register).

The pitch

Everything through HIP, or Event Bus + HIP

In both pictures the same systems do the same work. What differs is who has to know whom, and what has to change when a new system arrives.

Everything through HIP

request create Lead look up store draft contract archive Intermediair App HIP Salesforce KVK register Version Store FIS DMS (new) new call in HIP: change, test, release

Event Bus + HIP

request fetch data subscribes itself Event Bus Intermediair App HIP Salesforce KVK Extractor Version Store FIS DMS (new) no other system changes
Left: HIP calls every system, so every new system is a HIP change. Right: every system, HIP included, publishes to and listens on the bus. The app makes one direct call (the request); HIP is otherwise called only to fetch data. The DMS joins by subscribing itself, which is exactly what happens live in step 5 of the demo.
Automation first. Hiltermann is becoming a FinTech, so the goal is as much automation as possible. Every manual step counts as too expensive: the machine does the work, and a person only steps in for the exceptions — as a manual-check Task for the Intermediair Desk in Salesforce, answered with one click (Yes / No / Other).
Everything through HIPEvent Bus + HIP
Adding a systemThe HIP team builds a new integration: mappings, calls into the new system, error handling, a test cycle and a HIP release. Every flow that should reach the new system changes.The new system gets its own key and subscribes to the events it needs. Nothing else changes. In the demo the DMS is plugged in live, in front of the room.
Who depends on whomEvery system depends on HIP, and HIP depends on every system: it knows every address, every format and every order of steps.Every system depends only on the bus and the event catalogue. A publisher does not know who listens. HIP is one participant.
When one system is downHIP's flow stops at that step, or HIP needs retry logic per target. A slow system slows the whole chain. HIP down means everything is down.Events wait on the bus (7 days in the POC). The system catches up when it is back; the others carry on. The bus itself must stay up, which is why production uses a managed, highly available bus.
Changing a business stepChange and release HIP's orchestration.Change the one system that owns the step.
Seeing what happenedHIP's logs.One event log: every fact, who sent it, who received it, every delivery attempt. The Event Monitor shows it live.
Where HIP is the right toolEverywhere, by design.Fetching data from several systems in one answer (the customer file), and translating for older systems that cannot handle events.

The shared language: eight events

Each system knows the event catalogue, not the other systems. Every event is a CloudEvent 1.0, an open standard. The colours are the ones the Event Monitor uses.

EventMeansSent byHeard by
new-applicationAn office asked for an assessment (a new version)Middleware (HIP)KVK Extractor, Salesforce, Version Store
kvk-infoThe company's register data, or "not found"KVK ExtractorMiddleware, Salesforce, FIS, Version Store
customer-assessedScore, decision and reasonsMiddleware (HIP)Salesforce, FIS, DMS, Version Store
lead-qualifiedA salesperson qualified the LeadSalesforceVersion Store
contract-draftedA draft contract for an approved customerFISVersion Store
contract-signedThe customer signed; link to the signed PDFFISDMS, Version Store
document-archivedA report or signed contract is archivedDMSVersion Store
assessment-status-changedProgress for the office that asked; the only event an office receivesMiddleware (HIP)That one office only

What the POC proves

  • The machine does the work: from the request to the decision, the Salesforce record, the contract and the archive, nobody at Hiltermann has to click anything. A person only steps in for the exceptions.
  • Nine systems on one bus, each connected on its own: the Intermediair App (two intermediary offices), the Middleware (HIP), the KVK Data Extractor, Salesforce, the Version Store, FIS (the contract system), the DMS and the Event Monitor.
  • Three ways to connect: native for our own services, webhook for SaaS such as Salesforce, and a live stream for browser apps. Anything that can make one HTTPS call can publish.
  • A real Salesforce org creates and fills in its own Lead, and publishes an event when a salesperson qualifies it.
  • Real register data from the official KVK test environment.
  • An answer in 0.3 seconds, from the click to a decision with its reasons.
  • A new system plugged in live: no change to the Middleware, no deployment, no restart.
  • Offices never see each other's data: the bus only delivers an office its own events.

How long it took

3 hfirst commit 28 Sep, 22:16; all system stories merged and running on test by 01:17
13stories built, each specified first, then built, tested and deployed
550automated tests, next to about 18,000 lines of code

Built by the product owner with AI coding agents (Claude Code). That is the POC; production takes longer, because it has an organisation around it. See To production.

The demo

Ten minutes, click by click

Each step says what you click, what the room sees and what you say. The times are a guide for a 10-minute slot.

Before the demo (15 minutes before)

Log in once on the login page with this login; after that every demo site opens by itself. Everyone may try it; all data is fictional.

Salesforce is the product owner's own demo org (its own login). Open one browser with separate windows, so you can switch with Alt+Tab.

WindowAddressWhere
Event Monitormonitor.test.hiltermann.akest.nlBig screen, full screen (square icon, top right)
App, office Van Dijkapp.test.hiltermann.akest.nl/?office=vandijkLaptop
App, office Jansenapp.test.hiltermann.akest.nl/?office=jansenLaptop, second window
Salesforceorgfarm-18cd87ff91-dev-ed.develop.my.salesforce.com, tab LeadsLaptop (already signed in)
FIS (contracts)fis.test.hiltermann.akest.nlLaptop
DMSdms.test.hiltermann.akest.nlLaptop
  • The monitor says LIVE in green and, once both app windows are open, 8/9 systems connected. The DMS box is grey and says offline; the switch in the top bar says DMS OFF. If it says ON, click it once.
  • Click Reset view on the monitor, so the event log starts empty.
  • The DMS page says it is not connected and holds no documents.
  • Clean test data. A rehearsal leaves data behind: running 90003942 again for Van Dijk then becomes version 2, and the Salesforce Lead already exists. That still works: the app then shows version 2 and Salesforce updates the same Lead.
  • Save the fallback video on the laptop (see The fallback). When the network fails, this page does too.
10:00 – 1:00

The stage

Show
The Event Monitor, full screen.
They see
The Event Bus in the middle and every system around it. Each box says how it is connected (NATIVE, WEBHOOK, STREAM, OFFICE) and which events it sends and listens to. The DMS, on the right, is grey: offline.
Say
“Every box here joined the bus on its own. Nobody wired Salesforce to the Middleware, or the Middleware to FIS. The grey one is the document system; we will plug it in during this meeting.”
The Event Monitor before the first request.
21:00 – 2:30

The first request

Click
In the Van Dijk window, under Demo customers: Global Bigdofind, KVK 90003942, €1,000,000. Then Request assessment, and switch to the monitor straight away.
They see
Dots fly: new-application from the Middleware into the bus and on to Salesforce, the KVK Extractor and the Version Store; kvk-info coming back; customer-assessed; contract-drafted from FIS; and the white, ringed assessment-status-changed dots, which go only to Van Dijk. In the app: Request received (via Middleware), KVK data found (via Event Bus), then Approved, score 100/100, decided in 0.3 s, with every reason and its points.
Say
“The app made exactly one call, to the Middleware. Everything after that is events. The Middleware does not know that Salesforce, FIS or the Version Store exist.”
1.5 seconds after the click: the events on their way.
The office sees each step arrive: approved, score 100.
32:30 – 3:30

Salesforce fills itself in

Click
In Salesforce: Leads, open Unknown (KVK 90003942), company Global Bigdofind. If it was open already, refresh the page: Salesforce does not refresh a record by itself. Open Details and scroll to Assessment.
They see
The status path at Assessed – Approved, and the KVK number, intermediary Van Dijk Assurantiën, loan amount, legal form Commanditaire Vennootschap, founded 27-03-1987, SBI 46461, score 100, decision approved and the five reasons.
Say
“Salesforce is a subscriber like any other system. The bus delivers the events straight into Salesforce. Nobody typed anything, and the Middleware was not involved.”
The Lead, filled in by the events.
43:30 – 4:30

Salesforce publishes

From HILTERMANN-34 on, Salesforce also does this step by itself the moment an application is approved — then you only show the result.

Click
On the same Lead: Qualified in the status path, then Mark as Current Status. Salesforce says Status changed successfully. Switch to the monitor.
They see
An orange lead-qualified leaves Salesforce and goes to the Version Store, with a log row Qualified by your name. It goes out right after the save, through a background job: allow a few seconds.
Say
“Salesforce is also a publisher. A salesperson's normal click is now a fact every other system can use, without anybody building an integration for it.”
The salesperson's click.
Seconds later, on the bus, straight from Salesforce.
54:30 – 5:30

The live plug-in

Click
On the monitor's top bar: the DMS OFF switch.
They see
Connecting…, then DMS connected: the DMS box turns green and the counter goes to 9/9.
Say
“That was the whole integration. The DMS registered its own subscription at the bus. No change to the Middleware, no deployment, no restart of anything. In the everything-through-HIP world this is a HIP change, a test cycle and a release.”
If it fails
A red call-out on the monitor: use the Connect button on the DMS page, which does the same.
DMS connected, 9/9. Nothing else changed.
65:30 – 6:30

Signing the contract

Click
In the FIS window, contract HC-2026-0001 for Global Bigdofind is waiting. Say where it came from first (below), then Review & sign, type a name under Full name, tick I have read this agreement and agree to its terms and click Sign contract. Switch to the monitor, then to the DMS page.
They see
A green contract-signed goes to the DMS and the Version Store, followed by a purple document-archived from the DMS. On the DMS page: Signed contract HC-2026-0001, Global Bigdofind, with Open PDF.
Say
“FIS, our contract system, drafted this by itself the moment the customer was approved. Nobody told it to. And the DMS we plugged in a minute ago archived the signed copy on its own. The first assessment has no report there: the DMS only sees what happens after it joined.”
Tip
On the monitor, click the document-archived row and then Open the document to show the PDF.
The draft FIS made by itself.
Signed, then archived by the new DMS.
76:30 – 8:30

The retry: version 1 and version 2

Click
In the Jansen window (the second office): Test BV Donald, KVK 68750110, €500,000, then Request assessment.
They see
The same flow on the monitor, now with the DMS receiving customer-assessed and archiving a report. In the app: Declined, score 50, with the decisive reason Loan amount too high for this company.
Say
“The customer asks too much for a one-person company. The intermediary tries again with a lower amount.”
Click
Test BV Donald, €150,000, then Request assessment.
They see
Application · Version 2: Approved, score 60, and under Compared with version 1: Resolved: Loan amount too high for this company. The list shows v2 Approved · v1 Declined. Then show the Van Dijk window: it still shows only Global Bigdofind. And the DMS page: two assessment reports.
Say
“Each office only ever receives its own events; the bus enforces that. The Middleware numbers the versions, the Version Store keeps every version just by listening, and the intermediary sees exactly what changed.”
Version 1: declined, the amount is too high.
Version 2: approved, the concern resolved.
The DMS after the run: everything since it joined.
88:30 – 9:30

The customer file: why you call HIP directly

Click
On the monitor: KVK 68750110 in any row of the event log. A wide Customer file panel opens. Refresh asks again; × or Escape closes it.
They see
The call itself, GET middleware/v1/customers/68750110: the Middleware asked five systems at the same time and answered in about 0.3 seconds, with each system's own time (in the recorded run Salesforce took 330 ms, the Version Store 69 ms, the DMS 26 ms). Below it, what each system knows right now: the Lead from Salesforce, the application history from the Version Store (version 2 approved with Resolved: Loan amount too high for this company, version 1 declined), contract HC-2026-0002 from FIS, the two assessment reports from the DMS, and the Middleware's own assessments. A system that is down shows Not available, and the rest of the file comes back anyway.
Say
“This is what HIP is for: I need data from elsewhere. One call, several sources, one answer. Events for something happened, HIP for fetching.”
One call, five systems, each with its own time.
The history of both versions, from the Version Store.
99:30 – 10:00

Wrap-up

Show
The two diagrams at the top of this page.
Say
“Adding a system is a key and a subscription. HIP stays, and gets simpler: it no longer has to carry every flow between every system.”
Afterwards
Switch the DMS off again on the monitor, so the next run starts the same way.

If something goes wrong live

You seeDo
The app says still in progressA version is still running. Wait a few seconds and try again.
The Salesforce Lead did not changeRefresh the page. Salesforce does not refresh a record by itself.
lead-qualified does not appearIt is sent by a background job in Salesforce. Keep talking; it usually arrives within seconds.
The DMS switch shows a red call-outUse Connect on the DMS page.
The monitor shows a rehearsal's eventsReset view. It clears the screen, not the data.
Nothing loads at allPlay the recorded run below.

The fallback

When the network fails: the recorded run

A full run on test, recorded on 29 September 2026: 2 minutes 17 seconds, no sound. Every shot carries the step number of the script above, so you can talk over it exactly as you would give the live demo.

  • Save it on the laptop before the meeting: right-click the video and choose Save video as. When the network is down, this page is too.
  • It covers steps 1 to 8 and the unplugging at the end.
  • If only one system is slow or down, for example Salesforce, keep going live: the rest of the flow carries on, which proves the point. Switch to the video only when the bus or the network itself is gone.

To production

From POC to production

The POC proves the pattern end to end, with a real Salesforce and real register data. Here is what it is not yet, which bus fits Hiltermann, and how long the real thing takes.

What the POC is not

  • Everything runs on one server, with one database and no failover.
  • Every system has a fixed key; there is no single sign-on and no key rotation.
  • Salesforce is a free Developer org, KVK is the test register, and the assessment rules are demo rules.
  • There has been no load test, penetration test or disaster-recovery test.

What stays, what changes

Stays: the pattern; the event catalogue in the open CloudEvents 1.0 format, so no lock-in to one vendor; the rules every system follows (one identity per system, handle an event twice without harm, offices only see their own events); the Salesforce side; the monitor as an operations view.

Changes: the bus becomes a managed service in Hiltermann's own cloud. Identities come from Hiltermann's identity provider, secrets from a vault, and everything is set up as code.

Which managed event bus

Three real options. The best choice follows the cloud that HIP already runs in, so find that out first.

Azure Event Grid (namespaces)Confluent Cloud (managed Kafka)Synadia Cloud (managed NATS)
Fits whenHiltermann runs on Microsoft Azure, common for Dutch lessors and insurersThere are streaming needs beyond integration: large volumes, long history, analyticsYou want the least change from the POC
Match with the POCVery close: CloudEvents 1.0 natively, push to webhooks and pull by consumersGood, but different: topics and consumer groups; webhooks to SaaS through a connectorIdentical: the POC runs on NATS JetStream
Replay and catch-upUp to 7 days; add Event Hubs for longerLong retention and replay are its strengthYes, as in the POC
SalesforceWebhook into Salesforce, as in the POCReady-made Salesforce connectorsWebhook, as in the POC (our own gateway stays)
RegionWest Europe, in the NetherlandsAzure West Europe or Google Cloud NetherlandsEU regions available
Identity and networkMicrosoft Entra ID, managed identities, private endpointsAPI keys or OAuth, private networkingAccounts and keys per system
Running costLow at Hiltermann's volume: pay per capacity unit and per operationHighest: roughly $1,000 to $3,000 a month for a standard production cluster (industry estimate)Plan-based; ask for a quote
Watch out forReplay beyond 7 days needs a second serviceNeeds Kafka skills; owned by IBM since March 2026Smaller vendor, rare in Dutch financial IT
Advice. If HIP runs on Azure, take Azure Event Grid namespaces, and add Event Hubs only when replay beyond 7 days is really needed. Choose Kafka only for a streaming need beyond connecting systems. On AWS, EventBridge is the equivalent; AWS has no region in the Netherlands, so Frankfurt or Ireland keeps the data in the EU.

Security

  • One identity per system from Hiltermann's identity provider instead of fixed keys, with secrets in a vault and rotated automatically.
  • Office isolation at the bus, as in the POC: an intermediary only ever receives its own events and can never ask for internal ones.
  • Every delivery signed or authenticated; the POC already signs its webhooks and uses OAuth towards Salesforce.
  • Lean events. An event carries identifiers and facts, not a customer file. Sole traders are people, so their data falls under the GDPR: EU region, limited retention, a processing agreement with the vendor.
  • Private network for internal systems; only SaaS webhooks come in from the internet, through a gateway. Keys never reach a browser.
  • Compliance. Hiltermann Lease is a lessor, not a bank or insurer: check with compliance whether DNB or DORA outsourcing rules apply through the group or its financiers. Either way keep a vendor register, an exit plan and an incident process.

Monitoring

  • Already in the POC: the live monitor, every delivery attempt recorded (delivered, failed, parked), health checks on every service, and error tracking.
  • For production: the cloud's own metrics and alerts on publish rate, failed deliveries, dead-lettered events and consumer lag.
  • A documented way to resend dead-lettered events.
  • One correlation id, the assessment id, through every system.
  • The monitor idea as the operations view of the business flow.

Effort: a realistic estimate

Total: about 2 to 3 months, then days per extra system.

With a small team: a product owner, one or two developers working with AI coding agents, and part-time help from Hiltermann's Salesforce admin and its infrastructure and security reviewers. Every system after the first takes days, not weeks: a key, a subscription and that system's own handling of the events.

What AI does not speed up: decisions, security reviews, contracts (the KVK API, the bus vendor), Salesforce release windows and change boards. Those set the pace, not the building. Compared with running the project by hand until May 2027, that is several months sooner, and every later system is cheaper.