May 5, 2009
I’m a big fan of Domain Driven Design, but one of the subtler points I have found when implementing it concerns the notion of logical domain models. Eric Evans advocates the use of a single domain model – the one enshrined in the codebase – as a defense against the bad old days of ivory tower architecture where unimplementable logical domain models were produced by people who hadn’t coded in years, to be thrown over the wall into development teams who were then miserably handicapped by them until they inevitably decided to chuck them out and start making some progress instead. However, I believe this to be a failure in application rather than an intrinsic flaw. Logical domain models can actually be exceptionally useful when correctly applied. They get developers thinking in abstract terms and stop us making a whole bunch of assumptions that typically result from jumping immediately to implementation (“I’m programming in language-of-choice so of course I’m going to code it like blah”). Far preferable is that all such decisions are made explicitly, as conscious informed choices about the different trade-offs to be balanced in building a system. The subtlety with Domain Driven Design is that to get the best of both worlds – abstract modelling and a single model - the logical domain model should be evolved into the implementation domain model (I think of it as being a bit like a heatmap, with certain areas expressed logically and other, increasingly larger, areas expressed in implementation terms as your team iterates through sprint cycles). To be clear here, this has nothing to do with Big Design Up Front but simply the complimentary practice to BDD/TDD of whiteboarding sessions – but where we start by considering the logical model rather than immediately addressing implementation details.
What I have recently come to realise is that another model precedes the logical domain model, namely the business value throughput model. This is simply the exercise of domain modelling in terms of value rather than state/behaviour, and will be familiar to most people involved in business process engineering and organisational efficiency improvement. However, rarely does it get carried down to the level of software delivery. Instead, we base our decision making on a nebulous exercise called “project prioritisation”. In the worst case, this means MoSCoW (it is beyond me why we persist in this – why not just assign everything a “Must” and save all involved a deeply predictable day of pain!), or if we’re lucky we might end up with a slightly more helpful score out of ten or similar. The problem with this is as follows: if our aim is to generate business value then prioritisation is actually an implicit form of valuation – true, otherwise what’s the point? However it is an insidious, surreptitious form that slips under the radar without any kind of rigour, transparency or quantification. Is that story a “Must” because it will generate the most business value, or because someone bought an expensive new middleware platform and now they are looking for a problem to solve? Is that a “Must” because it will generate the most business value, or because you are fine-tuning your CV?! Is that a “Must” because it will generate the most business value, or because you know it will benefit the senior management’s current pet project?
So, what might a more explicit version of valuation look like? Well, we have recently been been trying out a very simple MMF model based on decision tree analysis:
Value = (Generated Business Value * Cumulative Risk) - Estimated Cost
Cumulative Risk = Project Risk * Market Risk
When I have presented this to various audiences, a wide range of initial objections have been raised – which normally fall under one of the following headings:
1.) Uncertainty (pt 1.): The business value delivered by a project is notoriously hard to measure and normally not even vaguely clear until a couple of years after delivery. How on earth can you expect me to work it out in advance?
Answer: This is an estimate, not a commitment. We fully expect it to be “wrong” – that is why we are limiting our liability by implementating the minimal marketable featureset, so we can drive out the real answer in production. We are just trying to come up with a rough figure on the basis of the information available right now, so we can move beyond the world of Must-Should-Could-Would towards anything that better resembles sanity. No-one is going to hold you to it. Please go and pair with an architect or someone in marketing or finance if you are struggling.
2.) Uncertainty (pt 2.): I don’t know enough yet to estimate the benefit or costs
Answer: Then that fact needs to be priced into your valuation as risk (similarly, inexperience at performing valuations should also be priced as risk). As that risk will almost certainly now be crippling your MMF valuation, why don’t you defer that piece of work and concentrate on something you are more certain about?
3.) Non-fiscal benefits: But the benefit of this will be in brand value/market awareness/etc
Answer: Fine, but without a subsequent programme of work to monetise that brand value it will be a pointless undertaking. You need to cross-attribute a percentage of the value delivered by the latter workstream back onto what we are considering now.
4.) Indirect benefits: But my web service doesn’t generate revenue. It’s the client systems that consume it which generate the business value?
Answer: Firstly, you do currently have more than one consumer don’t you? No, then why is it a web service and not an in-process component? Because you think other systems might need it in future? Then why not defer support for other message protocols until you know for certain which ones you’re going to need? Ah sorry, I misheard you – you do have multiple clients. In that case, you should simply cross-attribute a certain (usage-based?) percentage of the clients’ generated value back onto your service, as it is a value-throughput modelling dependency.
With this approach, we simply do whatever has the highest estimated value at any point in time. In doing so, prioritisation takes care of itself and we are finally, mercifully released from MoSCoW hell. Furthermore, a number of additional side-benefits become apparent as the process starts being applied in practice:
- MMF refactoring: once numbers start being assigned against MMFs, business stakeholders begin requesting whiteboarding sessions with architects to drive out other alternatives that entail less risk. This leads to a detailed technology-engaged breakdown of the business case and multiple iterations of MMF refactoring, with product managers and architects jointly discussing and creating business solutions around the table. Welcome to the world of agile technical strategy!
- Incremental release of small chunks of functionality. The estimated value of anything with more than a couple of non-trivial risks drops through the floor, creating a strong driver towards a “perpetual beta” style release model.
- A quantitative justification against system rewrites.
- A strong driver to improve IT capability maturity. If your IT department can’t be predictable about the costs of building even small chunks of functionality then that source of risk will impact the valuation of everything they do, and needs to be mitigated as soon as possible.
- Optimal implementation point: this is simply the maximum point on the valuation curve, where if you travel any further down the Cone of Uncertainty before starting to build then the reduced risk from greater clarity is outweighed by the risk from failing to deliver in optimal market conditions.
- Target delivery date: see the above. At last we have a quantitative means of separating meaningful delivery dates from arbitrary political statements.
- Should I do the highest risk stuff first or last? Are you talking about MMFs or components within an MMF? If the former, just do the highest value work regardless. If the latter, then always seek to maximise the estimated value of the MMF. That means take on the the highest risk work first. Doing so will remove that risk and up the feature’s valuation should you recalculate at the end of your day’s work.
More about this next time. For now one final point. If you outsource a programme of work and wish to use this approach, then don’t forget to ensure you engage with two consultancies to avoid the obvious conflict of interests: one to do the valuation, and another to do the build. (Yes I know they are lovely people, but you can’t really expect them to toil ceaselessly to find you the build option that will earn them the least money can you?!…)