The problem
Departments rarely ask for middleware. They say things like “appointments get double-booked” or “we copy the same client details into three tools”. The risk is jumping to the tool someone has heard of. The firm then pays for a product that solves the wrong problem, or sends client data somewhere nobody approved.
I turned those complaints into requirements, compared the options that met them, and gave leadership a shortlist with the reasons written down.
How I worked
- Collected the pain points from the people doing the work, in their words, with an example of each failure.
- Turned them into requirements: the job to be done, the systems involved, the data, and who owns it afterwards.
- I asked the questions that narrow the field before looking at any vendor: which platform the firm already pays for, whether data may leave the tenant, and whether anyone can run a self-hosted tool.
- I researched in tiers: official documentation and licence pages first, then vendor forums and practitioner reports. I treated contested claims as claims until two independent sources agreed.
- I ended with a shortlist with conditions, never a single winner without caveats.
Try the questions
For a Microsoft-native firm the likely direction is predictable. The point of the tree is the thinking around it: what changes if the firm runs on Google, cannot let data leave, or has nobody to maintain a self-hosted tool.
The governance screen every option passes
| Question | If yes | If no |
|---|---|---|
| Does it touch client, financial or other regulated data? | Data-flow map, retention rule, processor terms, owner sign-off | Continue |
| Can it write or delete records? | Test account, dry run, approval step, rollback plan | Continue |
| Can data leave the tenant? | Check contract, residency and logging; otherwise self-host or stop | Continue |
| Can an admin revoke access and export data quickly? | Proceed to a pilot | Reject the option |
| Is there an internal owner after rollout? | Proceed | Stop: unowned middleware becomes shadow IT |
Research method, shown on public sources
For this page, I re-ran the collection step on the vendors’ public pages with the self-hosted crawler on my lab.
| Step | What happens | What it produces |
|---|---|---|
| Frame | I write the requirements and inclusion rules before searching | Decision brief |
| Index | I list the titles, dates and versions of sources before reading them | Source register |
| Collect | I use the crawler for open pages, and a controlled browser only where needed | Retrieval log with timestamps |
| Normalise | I rewrite each useful passage as a claim, and keep vendor claims apart from independent ones | Claim matrix |
| Look for negatives | I re-search for rate limits, hidden costs, permission gaps and breaking changes | Risk register |
| Compare | I score fit, data flow, admin control, cost and evidence quality; unknowns stay unknown | Shortlist with conditions |
What it proves
In an interview, I can walk through
- how I gathered and prioritised the pain points;
- the endpoint mapping between the two real systems, at the level the NDA allows;
- why I ruled out some popular options early.