As analysts, engineers and delivery folk working in areas with a lot of uncertainty, there's often times a need to justify our "why" - why are we investing time and energy building bespoke engineering solutions, and where is the value for the business?
In one of my recent projects working within the area of security and control automation, this question of "why" came up multiple times, to justify how the program of work was shaped, to justify the solution approach, and to justify the value to the business, among other things.
In our 40 minutes together, I'd like to embark on a journey to address these whys using a Business Analysts' favourite approach: modelling. At this point, you and George Box are likely to say, "but Sonal, all models are wrong". Yes, I agree, but humour me.
Using a case study from one of my recent projects, I'd like to uncover the utility of DDD modelling techniques and bounded context, by demonstrating its creative application. Along this journey, I hope that as we validate or disprove a working hypothesis, we'd also uncover its impact on ambiguity and the ability to shape the program of work.