We have a solution called Data Architecture Review. With this solution, we conduct a complete review of the customer’s data environment. We collect a lot of data from the servers, analyze it, and produce a list of recommendations.
In most cases, this is the entry point to our engagement with a new customer. We usually begin with the review. When the customer sees the results of the review, they become a happy customer. From that point, we develop a long-term relationship with the customer, and make sure that they stay happy.
But it wasn’t always like that. Before we developed the Data Architecture Review solution, we did things in a different way. And we didn’t always manage to develop long-term relationships or keep our customers happy. We made a long way since, and we are really proud of where we are today. So I would like to share with you a story. A story about our journey and about why I believe in the Data Architecture Review…
Once Upon a Time…
In many cases, customers reach to us when they have performance problems with their data platform. Sometimes they are very specific, like: “Procedure X runs for 6 seconds; It should be less than one second”. In other cases, they can say something very vague like: “Everything is slow, we need to improve the overall performance”. Some customers complain about availability issues, usually after they experienced a disaster or two. Yet other customers just want us to make sure that the data platform is properly configured.
These patterns of customer requests haven’t changed much over the years. Our reaction did. In the early days, things were quite simple. We would charge the customer by the hour, and then one of our data professionals would work with the customer on whatever they want. So if the customer wanted to do performance tuning on stored procedure X, that what we would do. We acted like contractors. You tell us what you want us to do, and we’ll do it.
It turns out that in most cases the customer doesn’t know what the real problems with their data platform are. They may know that stored procedure X is slow, but they haven’t got a clue about the root cause of the problem. This is why they turned to us in the first place. If they had the skills to identify the root cause and solve all their data related problems, then they wouldn’t need us, would they?
What they should have said was: “We need your help to understand what the main data problems are, what the root causes are, and how to solve them”. Instead, they usually say something like: “We need you to tune stored procedure X”. And instead of telling the customer what they really should do, we used to tell them “OK”.
So here is a common scenario we used to have with our customers. The customer says “please tune stored procedure X”. We say “OK”, and do things like rewriting the code or adding indexes. We manage to reduce execution time from 6 seconds to 2.5 seconds. The customer appreciates it, but they are still not happy, because they actually want sub-second performance. End of story. Oh, and a week later they have an outage, and they lose 2 hours of data, because their DR solution is not properly configured and was never actually tested. But they didn’t ask us to look at their DR solution, so it’s not our fault, right?
The New Story
A few weeks ago, a new customer turned to us and said: “We need you to improve stored procedure Y”. Since we’ve learned