An inflection point comes where there is a dramatic change in direction. In a typical business or software process, this is the fulcrum around which the rest of the process rotates.
They’re often easy to spot by looking at the before and after. For a typical shopping scenario, the inflection point is the buy now point. Everything before that is sales, everything after is fulfillment.
Some processes may also have secondary inflection points. Broadband provisioning for example has one inflection point where the order is confirmed, a fulfillment process that may involve site visits, transfer of your number from your previous provider and other preparatory work, and then a second inflection point once everything’s ready and you start paying line rental and usage fees.
Inflection points in software
The reason I’m interested in this at the moment is that these can be unnecessarily complex things to model in software.
We have a natural tendency, especially in domain driven thinking, to simplify the mapping between the business and software domains, so that we can reduce the cognitive load switching between the two.
For inflection points, this simplicity of mapping can easily lead to additional code complexity.
For a typical physical sale, most of the following will occur at the point the user hits the “buy” button :
- Verify payment
- Decrement stock count
- Send confirmation email
- Trigger warehouse workflow
- Trigger delivery workflow
- Redirect user to confirmation page
Like all good developers, we’ll break these down into functions so we can test each step individually, we’ll put the payment options, the warehouse and delivery systems and email behind interfaces so we can mock them out. But we’re still doing too much.
Decoupling inflection points
We have a single user interaction with a lot of side effects, making it harder to reason about, delaying the user response and coupling the success of the interaction to multiple external systems. Yes, the payment provider is essential in creating the order, but does it break the order if the email, warehouse and delivery components don’t start until several minutes later?
There is an opportunity here to use event listeners or scheduled tasks or other asynchronous processes to decouple the success of the order from the other systems. It means that the steps in the business process aren’t as easy to follow, so the triggers for the consequentials need to be clear (“all orders without a delivery workflow should have one created”), and this approach definitely prefers pull conditions rather than push conditions, so each step knows what it depends on, but not what depends on it – the payment process now only cares that it creates an order, not who fulfils that order.
How do you deal with your inflection points?