Tips for building an advanced data platform #data #building : #1/10

With these tips my focus is more on practical aspect of data platforms addressed to data platform engineers or managers. Here is a compilation of tips that I either implemented from the start, learned it along the way or currently having in works in my current assignments.

Tip #1: Build your data platform as a product - This, in my opinion, is the most impactful thing you can do for your data platform users.

When a company builds an application or a service, it builds a product which has:

Ø Customers

Ø Technical infrastructure

Ø Product planning to define what to build

Ø Marketing efforts to get customers

Ø Customer support to handle problems and incidents

Now, what if we apply the same way of thinking to an internal data platform?

• Customers: every data platform has users, who are most likely company employees
• Technical infrastructure: you need resources and technologies to create a data platform
• Product planning: building a data platform requires a lot of planning like choice of tools, functionality, data warehouse design etc.
• Marketing: you need to promote your data platform’s functionality to on-board new users and explain added functionality to existing users
• Customer support: any data platform team needs to respond to users’ requests and handle data-related incidents

If we can apply product characteristics to a data platform, then why don’t we build data platform as a product instead of creating a set of connected technologies that make sense only to data platform teams?

Consider data platform as an internal product, its target market as your company and target audience as employees. Create name and logo for the data platform and advertise it internally under its name instead of a generic “data platform” term or the name of your data warehousing solution. Get all your data tools under this name and refer to them as a functionality.

For example, if your data platform product is named “Euclid” (Greek word for “data”), then your Tableau Server is the data visualisation functionality of Euclid. From the perspective of a user, they will be using a “Euclid dashboard that aggregates Euclid’s data”. It’s much easier for everyone to remember one product name and get the idea of its functionality, rather than trying to figure out what different data technologies do and how they are interconnected. When using Excel Spreadsheets, you generally don’t think about what modules, resources and APIs it consists of, right?

I also recommend creating a landing page for your data platform product. A simple internal webpage with data platform’s name, logo and a list of links to functional components is sufficient. For better access and visibility, assign it a simple internal URL address (using the same Euclids example from above, something like internal-domain.com/Euclid or Euclid.internal-domain.com would look great). Create a user manual for your data platform product and put the link on the landing page.

The most important thing here is having a single entry point to all functionality of your data platform. No need to research countless internal wiki articles and ask teammates for the information — anyone can start using the data platform just by visiting a link.