If a POC considers only the building of a mockup then one misunderstood its role. It’s a primary goal of a PoC to prove that a solution is feasible, and not only achievable. As part of feasibility, it needs to be proved that the solution addresses the requirements (scalability, security, stability, etc.), that it makes sense within the broader architecture, respectively the whole ecosystem where the people and other actors are also considered.
Unfortunately, many PoCs seem to focus only on proving that the technology works, and even then, topics like assumptions, requirements/recommendations, limits, risks, opportunities are ignored, which on the long term creates a series of challenges that can easily go beyond the solution itself. Even if a PoC doesn’t addresses all the functionality, it still needs to address these points.
I can see an association between a PoC and the FOMO, though I think a PoC is usually performed while looking for a solution to a problem existing in the organization or an opportunity to improve the state of art. A PoC lingering for years can be a question of priorities or a reflection of the fact that the technology is not mature enough.
What you described seems to be missing processes at service management level where the know-how in IT is missing. That’s not part of the data but of the IT strategy. Conversely, the data strategy can take this as assumption and address it as requirement to the IT strategy.
Conversely, if a solution has an impact on another solution, then a chain reaction is possible. However, if the PoC leads to the PoC of the same solution, then the first PoC didn’t addressed the full extent of the requirements. That’s something that can be addressed at project level (and not at strategic level).
Regarding the amalgamation, could you please explain how a strategy can help with the improvement of a process? A strategy can define goals, objectives, principles, and a few other components, though for improvement is in theory another process responsible (e.g. continuous process improvement).
As per my understanding standardization is a method of productionization (e.g. using a framework for building data products).
Unfortunately, data engineering seems to be missing the engineering part from its name and ignore completely the systems engineering topic.
