The short answer
When a team that has never run a broker is asked to rebuild a batch settlement process as event-driven, the strongest answer starts by asking what actually breaks today. A broker the team cannot operate is a new outage source, replayable audit evidence is an architectural constraint, and sometimes the right recommendation is not to rebuild.
This is the scenario we put to enterprise architecture candidates. It is the only one of our screens where the best answer may be to recommend against the thing the client asked for, which is precisely why we use it.
A client wants an event-driven rebuild of a batch settlement process. Their team has never run a broker in production and the regulator requires replayable audit evidence. What do you recommend?
The trap in the question
The question arrives with a solution already attached. The client wants event-driven, so the candidate's job appears to be designing it. But nothing in the scenario says batch is failing. It says the client wants a rebuild, the team has no broker experience, and a regulator needs replayable evidence. Two of those three facts argue against the rebuild.
What a senior answer contains
- Asks what breaks today before designing what replaces it, and whether batch is actually the problem. Settlement is batch-shaped in many institutions for good reasons, and an architecture that ignores them inherits the problems without the reasons.
- Names the operational cost honestly. A broker the team cannot run is a new outage source, not an upgrade. Somebody has to own partitions, retention, consumer lag and upgrades at three in the morning, and the scenario says nobody on the team has done it.
- Treats replayable audit evidence as an architectural constraint, not a feature. Replay means deciding what is retained, for how long, in what immutable form, and whether reprocessing the same events produces the same result. Those decisions shape the design; they cannot be bolted on.
- Is willing to recommend not rebuilding, and can say what would change that answer — a team with operating experience, a demonstrated failure in the batch process, or a business requirement batch genuinely cannot meet.
Where a mid answer stops
- Starts from the target architecture and works backwards to justify it. The diagram is usually good. The reasoning that produced it is the problem.
- Treats the regulator's requirement as a logging question. Logs record that something happened; replayable evidence means being able to reconstruct and re-run it. Those are different systems.
- Cannot describe who operates the thing after go-live.
The wider point
Anyone can be hired to build what a client asks for. The architects worth placing are the ones who will tell a client the request is wrong when it is, explain why, and say what evidence would change their mind. That is hard to see on a CV and easy to see in this conversation.
This is the published screen for enterprise architects. The role page carries the scenario, the full rubric and the technologies we screen on.