This is the most frequent challenge people face when learning Evolution: there are components that fit into two phases of Evolution.
Look at the table below:
Arguments for Commodity | Arguments for Custom | |
Electricity | Electricity standards - power socket | Non-trivial production and infrastructure management |
LLMs | You interact with all LLMs in the same way | Constantly changing infrastructure, we do not really understand how does it work not what are the limitations |
Cloud Services | Predictable, SLAs, Contracts, Resilience, Easy to Use, Well-known | Non-trivial management |
The thing is that Evolution depends on your perspective. If you are a consumer of capabilities, you see and care only about the commodity aspects of those components. Therefore, you would place them in the commodity phase.
But if you are a producer, customers expect Commodity, but you deal with Custom all the time. This is what business is about - you simplify the world for your customers by handling the difficult stuff.
By convention, practitioners tend to place such components in the Commodity space - because the standard contract is very important for everyone, and experts will recognise underlying complexity anyway.
Long time ago, I have proposed a special notation to mark that a component has a complex chain of dependencies but it was purposefully removed from a map. Unfortunately, it did not pick up.
Opmerkingen