WS6 Data Architecture (3).png

A next-generation platform roadmap is not a list of tools to buy. It is a plan to remove the biggest constraints in how your organization produces, shares, and uses data.

Most platform roadmaps fail for one simple reason: they start with architecture, not outcomes. The result is predictable. Teams ship “improvements” that feel elegant to engineers, while users still wait weeks for data, incidents still repeat, and executives still see the platform as a cost line.

This page keeps the same steps as before, but written in a more article-style flow.

1) Start with strategy inputs, not architecture

A roadmap is downstream of business priorities. If you start with architecture, you will optimize for technical elegance and still fail to move the business.

Begin by writing down three inputs. Keep them short.

If you cannot connect an initiative to one of these inputs, it is not roadmap material yet.

2) Map what you already have (the 60/20 rule)

Teams often assume new priorities require a new platform. In practice, much of what you need is already present.

Do a quick mapping of reality:

This prevents the classic mistake: adding a fifth warehouse or a third catalog “because this year is about AI.” Your roadmap should reduce surface area, not expand it.

3) Identify constraints (not tool gaps)