A customer asks potential vendors – I need a pig that can fly. Whoever can get me one, wins the deal.
Vendor 1 – The Engineer says “There is no such thing as a flying pig. Do not waste our time. We are not interested.”
Vendor 2 – The Geneticist says “I am going to create a new species of pig – one with wings.” He goes to work on a flying pig. He never comes back.
Vendor 3 – The Practical One says “Flying pig indeed! Yes, we can get you one.”
Vendor 3 takes a drone, makes it look like a pig on the outside and flies it. The approach that Vendor 3 takes is a classic example of redefining the problem or finding a suitable workaround to solve an issue.
Executing a database proof of concept has similar themes:
- There are no perfect databases and no perfect workloads either.
- Real-world scenarios are for the most part models that have been built over many years. You would be hard-pressed to find a good data model and well written queries.
- Ideally, you tweak the database to suit the workload. The alternative is attractive, but time-consuming and requires customer buy-in.
- Time is always short. Innovating workarounds to known limitations and focusing on strengths is important.
- Solutions that are realistic, simple, and effective work well for the majority. Do not let perfection become the enemy of the good.
Winning a database proof of concept requires the following steps:
Understand the data and the workload. By peeking into the contents, you gain insight into the actual business use case. By knowing the relations and basic thought process that went into building this model you are in a better position to make changes as needed. This is the hardest step and takes the most effort and time. However, the payoff is well worth the hard work – winning the customer’s confidence.
Load the data. This is by far the easiest part. As you load data, you perform requisites such as gathering stats, choosing the right partition strategy, and indexing.
Execute the workload. It gets more interesting here. At this point, you know if your database engine can deliver out of the box or needs tweaks. If you followed step 1, you have the in-depth knowledge to solve problems or make alterations. Unfortunately, most of us who have been in the industry long enough, including myself, have biases and preconceived notions. These biases can hinder your ability to find creative solutions to problems.
To quote Bruce Lee – “Empty your cup so that it may be filled; become devoid to gain totality.”
An open mind makes us more willing to consider alternatives. By locking ourselves up, we limit our capabilities. Our preconceived limitations define us and box us in.
Once you have executed the workload and identified how to meet your customer requirements, the next step is to package up the results and present it.
Converting a Successful Proof of Concept to a Deal is the Next Challenge
I have done enough proofs of concepts to realize that the winner is rarely the best engineered solution. Economics trump everything, which means cost-effective solutions that meet most of the customer requirements tend to win the deal.
To summarize, the ability to innovate, adapt, and be flexible more or less wins the deal.
On a closing note –
Being a Star Trek fan, everytime I run into a pickle with a proof of concept, I think back to the Kobayashi Maru Training Exercise.
From wikipedia (edited)
“The Kobayashi Maru is a training exercise in the Star Trek universe designed to test the character of Starfleet Academy cadets in a no-win scenario. The test’s name is to describe a no-win scenario, a test of one’s character or a solution that involves redefining the problem.”
