Of course, it would be pretty useless to have the perfect data strategy and forgetting about the necessary technology to support it.

You might know exactly what you need to know, what data you need, the needs you are addressing, which people are involved and have them super motivated to do this, but without technology, you won’t go far.

You need technology to:

  • Collect data;
  • Store data;
  • Move data;
  • Process data;
  • Visualize and communicate;
  • Deploy models and analysis.

Different technological solutions can do one or more of these. A good ERP will do all of these, but usually only to a certain extent.

My Basic Rules for Choosing Technology

When choosing technologies, these are my rules. Like any list of rules, there are exceptions, but these are my strong preferences:

  • Extensibility: easy to extend with new modules;
  • High interoperability: with known and clear interfaces that allow integration with other services (can be seen as a type of extensibility, if the system is part of a whole)
  • Portable compatibility: always opt for something that is not OS-dependent. I tend to like Webapps, as they run on browsers and, as such, are natively portable.
  • Low maintenance: you can choose between having your own platform that you’ll have to maintain, or you can get a managed service. I would go for the managed service for various reasons. Yes, managed services are more expensive, but they’re worth it.
  • Open-source: I’m an open-source advocate. Please note that open-source is not the same as free.

Be ready to invest

Be ready to pay for the technology - don’t be cheap on your foundation. A great building needs a great foundation. Invest the amount necessary to guarantee it.

Companies that fail to do this tend to suffer in the long run. You don’t want to have your data scientists or other specialized people focused on maintaining databases when some services do this automatically, do you?

From Technology to Documentation

Undocumented technology is unfortunately common and it’s effects are very real.

Sometimes, the missing documentation is just on how to onboard someone into the technology, but often it’s much worse.

I’ve encountered numerous times, complex systems, on which a company depends on - I’m talking about critical things like integration between payments and clients - where Documentation simply does not exist.

Then, when these systems fail (as they always do), often the person who built those systems is no longer at the company and there’s no-one there to maintain them.

This is a nightmare scenario that plays out far too often, leaving teams scrambling in the dark. Imagine trying to piece together a puzzle without the picture on the box; that’s what it’s like trying to fix these undocumented systems. It’s not just about the downtime or the immediate firefighting. It’s the long-term impact, the trust erosion from clients, and the internal panic that follows.

Worst of all, it’s entirely preventable.

The next chapter will talk about documentation, not only in terms of technology, but also in terms of processes and also explain why that’s relevant. I think you’ll like it.