It is not, and it takes a lot of time to discover it.
The evolution curve looks nice, but if you have ever attempted to cast existing components on it, you surely got a lot of problems.
Problem #1 - Biases
I do work for a financial institution. Financial institutions are very conservative, partly because of regulators and partly because customers want to feel safe, and this is most easily achieved by a avoiding changes. Anyway, from the perspective of a financial institution, f.e. continuous deployment is a novel practice, and anyone trying to adopt it is a brave adventurer.
There is a way to overcome this - you need to step out of your comfort zone, and see how other industries are dealing with certain components. As of continous deployment - look at the automotive industry. When I tried to fix my previous car, it turned out that there were three types of steering rods available for this specific model from the specific year. And I bet they had sorted out continuous deployment long before even agile was described (yes, my car was created 5 years before the agile manifesto).
Problem #2 - Scope
I hope you have heard about SWIFT, the messaging mechanism for banks. It is very well defined. It is actually a cost of doing business, and all banks are using it. I was tempted to say it is a utility, but on the other hand... there is a plenty of potential adopters that could be using the messaging mechanism to communicate with banks if only it was cheaper and more accessible. And there are at least two alternatives trying to enter the market, so... I am lost. SWIFT is somewhere between an off-the-shelf product and utility, and I am not able to easily label it.
The number of potential adopters is also very intriguing, as the messaging mechanism for finances in general is probably a really great candidate for Jevons effect.
Problem #3 - Possible developments
Imagine, that you have created a custom-build component. How it can look like in the 'as a service' phase of evolution? Consider f.e. 'Risk Management'. Can you imagine Risk Management as A Service? How it could look like, what it could do? Or even more bizarre example - Complacency as A Service? Making predictions, guessing the service shape or the product standing behind it is actually pretty difficult, and cannot be done by a single person. Again, it requires a significant input from other people from other industries.
None, yet. But I would like to address those problems by creating a really simple component repository, that would allow for collaborative component analysis, a place, where people like you and me could discuss what is the component state.
Check my initial screen sketch: