As analysts, engineers, and delivery folk, consulting to clients with areas of a lot of uncertainty, there is often a need to justify our "why": why are we investing time and energy building bespoke engineering solutions; what value would the business derive to motivated to pay for this?

In one of my recent projects, within the area of security and risk controls automation, this question of "why" came up multiple times, to justify the value to the business, to justify how the program of work was shaped, and equally importantly, to aid prioritisation of the program of work.

In this presentation, I explore how heuristics can be used for problem solving. If we started with a hypothesis, and then modelled our use cases using various heuristics to test the hypothesis, can we arrive at sufficient clarity to solve our prioritisation problem? At this point, you and George Box are likely to say, "but Sonal, all models are wrong". Yes, I agree, but humour me.

I'd like to share a story about experiments with DDD, Bounded Context and problem solving, and uncover the utility of getting creative with domain modelling. I hope to demonstrate value of modelling for reducing ambiguity, and its ability to shape and prioritise a program of work.