[Reading time: 1 minutes 29 seconds]
"There are three great virtues of a programmer; Laziness, Impatience and Hubris."
-- Larry Wall
Given this, reuse is certainly a no-brainer: it allows us to be lazy. Yay!
In the context of architecture (and thus, of course, organisation structure), there is a risk of aiming for the wrong thing.
You may be thinking that reusability begets autonomy.
If you’re getting your product right, the two may indeed be related. But they’re not the same, and they’re not connected.
Reusability means creating something that can easily be changed to adapt to new circumstances.
But autonomy means that it can be used in new circumstances.
One is looking at this from an architectural standpoint: how to change the plumbing.
The other is looking at business outcomes: being easily able to use the same thing for a new business purpose.
Ideally, of course, without adaptations; but certainly without having to ask for support or permission. Even by less-technical teams.
That’s a much taller order than building something that another programmer could adapt (of course they could).
It’s a trap to only consider reusability of your architecture component. It’s certainly an indicator for a well-done design, but it’s not enough – it doesn’t solve the business problem.
You need to also consider whether this architecture will offer autonomy, to the people who benefit from it; say: data scientists, or payroll, or whoever else takes the things you build and makes them earn money.
And that is a property of your organisation structure, not your application structure. And it requires you to think about something other than technology.