Business Informatics is a translation discipline

When I tell people I study Business Informatics, the usual response is to picture it as a compromise — a bit of programming, a bit of management, mastery of neither. I understand the instinct, but I think it misreads the field. The core skill is not the union of two syllabuses. It is translation.

Two languages, one problem

Engineers reason in systems: state, constraints, edge cases. Business people reason in outcomes: cost, risk, timing, who is accountable. Both are describing the same problem, and both are usually right within their own frame. What goes wrong is the handoff — the requirement that loses its meaning crossing the gap, the technical constraint that never reaches the person making the trade-off.

Most project failures I have seen were not failures of engineering or of strategy. They were failures of translation between them.

Sitting in the middle is uncomfortable — you are rarely the deepest expert in the room on either side. But being able to hold both models at once, and move a decision cleanly from one to the other, turns out to be scarce and valuable.

What I try to practise

1. Restate a technical constraint as a business trade-off before proposing a solution.
2. Turn a vague business goal into something a system can actually be measured against.
3. Make the cost of a decision legible to whoever is accountable for it.

That is the work I find most interesting, and it is why the projects I care about tend to sit at seams — an AI model and the humans who have to trust it, a curriculum and the students who have to plan around it, a dataset and the decision it is supposed to inform.