A few weeks ago, the following question popped up in the DDD-CQRS-ES slack
Here's the exchange I had with the original poster.
(reproduced with his permission)
Hey. I created this principle to help with scaling decisions my e-commerce team will be facing. Let me know what you think. If this already exists, please advise.
Scale-Conversion Linearity:
Definition -
The ability to scale a distributed system in direct proportion to the business transaction demand (conversion of prospects to actual customers) of its users and no less or more.
Rationale -
Building for scale requires trade-offs and overcoming design challenges, increasing the cost of the system. There are diminishing returns for this when the purpose of the system is not fulfilled resulting in cost that cannot be offset by income. Conversion of end users into paying customers (or the equivalent of revenue generating transactions) requires other aspects over and above scaling, such as pricing, segmentation, range and fit of offerings etc.
Implications -
Partnership between the engineering teams and business teams is required.
A value must be placed on scaling units that can be attributed to cost offset.
Negotiation points to refactor the system to break through scaling limits must be instituted. (edited)
Nice and succinct!
It does tie the engineering effort cost to the value generated by that part of the system. And points out the need for collaboration between dev and business.
I do miss the need for continued reevaluation and operational cost
Question: who is the audience of this principle?
What I sometimes do is have a set of one-liners summary in business term that encompasses a series of such principles.
They are reminders for everyone to help set context and priorities.
E.g in my previous domain :
All candidates must be able to enrol at all time. We do not send candidates home.
It is phrased in a way the business understands "All time" instead of 24/7
This one-liner encompasses a subset of capabilities and systems.
It also implies priority: if there is a serious problem with taking tests affecting lots of candidates... someone needs to stop whatever he is doing and help the operational teams.
Implies where the scalability and availability need to be placed.
Implies the need for metrics and KPIs that are useful.
Allows us to say "this is less important than that"
In that place, I have 3 of such one-liners.
The implications, for dev/ops/business, are ofc broad and not detailed. But once in place they did allow better reasoning & bargaining & negotiations.
One thing to note: they are about what we consider the core business.
So it's easier to say:
we need to do this ourselves and fully understand or this falls outside of our core principles, so we will not ..., we will limit the effort...
Practical examples:
-
A few years ago we had a major outage. We had people nagging us from all part of the business and external users... but that one-liner allowed me to protect the rest of the team from lots of those: "yeah I understand that this is a major issue for you right now and you can't work, but the priority is making sure that candidates can take their tests, and they can enrol in selections"
-
We use EID authentication for candidates & back office. It's more important to have alternate authentication methods for candidates than back-office
-
Some 3d party subsystem/services are used by candidates & back office. When there is an issue with such 3d party that affects candidates, we will be following resolution way more closely and require or create a way more detailed post-mortem report of who was impacted in what area, for how long. When it impacts the back office, we will make a more light post-mortem report.
So those one-liners are a distilled version of all the more detailed principles
PS: thanks you for the kind words Lyronne:
@ylorph If you wrote a book in the ilk of the above comments, I would not put it down. Thanks for the deep insights, sir. The audience is my CIO and to be floated up to the Digital Programme Board. Really poignant stuff!
PPS: putting this out today because of a discussion with Chris