The Abuse of Reuse
Why Enterprise Architecture Is Wrong And Fails
Reuse! Rationalise! Consolidate!
Enterprise technology strategies frequently wave the flag of reuse as one of the most important things to do.
The idea is to avoid different technologies and services apparently duplicating similar functions and effort. Having a single common technology or service is considered cheaper and more efficient.
Reuse of a vaguely similar functions is encouraged or even mandated. These strategies go further and propose the pre-emptive building of big platforms for future reuse.
The problem is, this kind of reuse is wrong and damaging.
Problem 1: One Size Does Not Fit All
The first problem with such reuse strategies is that they assume a single technology or service solution can optimally cover the wide range of user needs.
But the user needs will be diverse — with differing requirements for agility, cost, risk, resilience, size, function, function, and other factors.
An expensive response is to “design high” — to build a single solution which attempts to more than cover all of these factors just in case, but meets none of them particularly well. An expensive jack-of-all-trades, master of none.
So a collection of different solutions will better fit the problem space. It’s common sense really. It’s why a good tool shed has a few kinds and sizes of hammer — big ones, small ones, metal pointy ones, blunt wooden mallets.
There’s a numbers game too. Why force an expensive heavy database, for example, onto all your organisation’s needs, when it is only really needed by, say, 3% of your services? A cheap light database would satisfy 97%. That’s a huge saving from not being block-headed about reuse.
Manage diversity, don’t ban it.
Problem 2: We Can’t Predict What We’ll Need
The second bad assumption is that user needs can be known sufficiently accurately ahead of time to inform the building of common solutions. That would need magic powers.
How can you encourage, or even mandate, the use of a solution when you don’t know user needs? You don’t even know them at the start of a project to meet one set of user needs, never mind years ahead to meet many sets of user needs.
It would be a foolish doctor that mandated a single treatment for for a patient before any diagnosis, never mind all future patients!
Accepting this reality is a core premise of agile development. This casts such reuse strategies as the antithesis of agile — waterfall on steroids.
Preplanned reuse is anti-agile.
Problem 3: Dependencies Slow You Down
Reusing a technology or service instance for many solutions, even if seems to support user needs, has disadvantages. These many solutions are tied to that technology — they are dependent on it — and worse, they are dependent on it not changing much.
And when many solutions have dependencies on a single technology, the risks and complexity of change increase dramatically. The costs and time to make even simple changes shoots up. The technology becomes a drag, and sometimes a single point of failure.
As the many solutions want to evolve and change in different directions, as they inevitably will, the anchor prevents them from freely doing that.
Your reuse is now a single point of failure, magnifies risks and complexity of minor changes, and prevents solutions independent evolution. Not a good outcome!
Don’t aggregate dependencies.
Problem 4: Enterprise Above Users
There is a deeper cultural problem with reuse strategies. They emerge from a mindset which places the needs of the enterprise above the needs of the user.
The desire for a service management function to have less technologies to manage trumps optimally meeting user needs.
This is, of course, a false ambition. We’ve said before, meeting user needs is the value that matters to organisations, nothing else. It’s no good making service management really efficient if ultimately users are unhappy.
Enterprise functions should never trump user needs.
Problem 5: Space for Innovation
It is true that many large enterprises have long lost the ability to innovate, and find themselves having to buy it in from more creative companies.
What’s the difference? In these large enterprises, set ways of working, processes and technologies are mandated, or inadvertently encouraged by the full weight of these massive organisations. It is really difficult to try anything different.
A sophisticated organisation strikes a balance between managing a finite set of technologies it can become efficient with, and yet making sure that space is set aside for experimentation — innovation which will replace that finite set with something better. That finite set is not static — it’s a dynamic steady state.
Better to aspire for dynamic - not static - steady states.
Shared Platforms Emerge
But surely there must be some efficiency to be gained from sharing technology, effort, knowledge and experience?
There is — but you have to get the priorities and sequencing right.
- First meet user needs, deliver value to users quickly. That’s the central focus. Iterate, grow and refine your solution to meet your users needs.
- Once user needs are being met, only then optimise your solution — make it cheaper and better by refactoring it, “paying off technical debt” in agile-speak. Feel free to move it to cheaper platforms, swap out components for shared ones if they fit — but only if they fit.
This way shared platforms emerge, and they always meet user needs.
Now this route may seem like much harder work and forbiddingly expensive. But it is made possible by developing with minimal commitment. That means avoiding sticky contracts and buying licenses, using open source technologies. It means loose coupling not deep integration. That means easy-on-easy-off pay-as-you-go cloud hosting.
In short, it means avoiding dependencies and delaying commitment.
Prologue: A Little Knowledge
It is worth understanding why mantras like “Reuse!”, and others like “Commodity!”, catch on.
On their own, the words themselves, don’t sound wrong. In fact they sound like rather jolly good things. Motherhood and apple pie.
But too many leaders are insufficiently technology literate. They can see nothing wrong with such simplistic and apparently noble aims.
It needs a deeper understanding of technology and solution development to see these oversimplifications.
To simplify technology, you need first to master it.
