In the final part of our series breaking down common data and analytics pain points, we explore tool selection and its impact on your data ecosystem and end users. You can read about other common challenges in our full white paper, but today we’ll be keying in on the figurative nuts and bolts of our data stack.

The Problem

Quick question: Which of these tools have you used before?

• Nibris
• Metropolis Software
• LK Avalon
• Bloober
• 11 Bit

You mean you haven’t heard of these tools? How can this be? Well, it’s because they are Polish video game designers. This is how most data professionals feel whenever they march through the vendor exhibit section of any large conference. Who? What? Ooh, free socks!

There has been an explosion of platforms, tools and vendors as technology advances. Hard-to-solve use cases proliferate, and no single solution grabs the market leader position. Some of these tools are gone as soon as they arrive, others have a genuine value proposition with differentiation from other tools in their space.

How are you going to know the difference?

It’s not really like you can go to a vendor salesperson and say, “What reasons would I not buy your tool in favour of your competitor?” That’s not how they are incentivised. You need this tool. You must have this tool. You must spend most of your budget on this tool.

Mapping the right tool to best fit your needs and then sufficiently budgeting for it without overspending is half art and half clairvoyance. It gets more complicated with the diversity of commercial models. The old days, you select a product tier, such a Platinum, Diamond and Double Uranium Awesome Sauce, and then you have an annual fee.

Now, pricing models can be quite sophisticated:

• User-based pricing by software role, SaaS or on-prem, add-ons, extras, NFP, etc.
• Consumption-based pricing on data store, queries computed, views used, credits consumed here or there, rows processed, rows available for processing, etc. Edition-based pricing with any combination of the above
• Full DR with multiple nodes, blue/ green deployment

And then there’s how to negotiate for the best price based on the above and the sales structure and incentives of your vendors. I’m renewing ten kajillion dollars of licenses, so why am I not getting great pricing on my two additional users?

Tricky, right?

The Solution

This whole process just requires an understanding of what you need at each step in the data workflow, an understanding of which tools solve which use cases great / good / meh / completely bleh. You’ll see legacy tools do most the stretching in this matrix as they are desperately needed to expand pipeline from their traditional battlelines where newer tools are likely beating them in features, pricing and excitement.

Why yes, my DOS-based ETL tool can also automate your coffee service. Absolutely.

Unfortunately, most consultancies are only slightly less biased than the vendor salespeople. And that’s because of partnerships, which in vendor land is called “channel.” We are courted by vendors to promote their technologies as system integrators all the time. All. The. Time. It takes an exceptional effort to remain truly neutral.

At InterWorks, we combated this gravitational pull towards vendor fealty by saying “No” sometimes:

• No, we are not going to go full stack and promote your products soup to nuts when we only really love this particular thing that you
• No, we are not going to sell 64 cores of server capacity to this poor university department when they need, at most, eight
• No, we are not going to promote this terrible product even if you promise to pay us exorbitant amounts on the backend

Those are all true stories, by the way.

It’s important to understand incentives. Vendors incentivise new sales. They need growth because they have shareholders. More is better. So new sales, and not renewals, are your best bargaining chips when it comes to dealing with vendors. Consultants want services, which means most of them want complex solutions to create a lot of months of work for a lot of people in a single project. This is also how you see the dumpster fires called “custom tool development” in the wake of big consultancies.

Is InterWorks any different? We definitely try to be. Our approach has always been a small sales team and a lot of consultants. It means that when we get a customer, we are fully incentivised to building a long-term relationship. By design, we don’t have the scale of marketing or sales to churn and burn a bunch of new logos if we were to do the money grab on Phase 1 of a project.

Instead, we have to prove our value with each engagement. Every project is an audition, and we embrace that pressure. Our consultants and our solutions then become our brand. By intentionally making our success as aligned as possible with our customers’ success, it creates an opportunity for us to be your trusted advisor for the longterm. That’s very much an intentional decision by our founder and all our leaders to craft that DNA.

The technical domains and thereby the tools that we focus on the most often include:

• Data warehouses and lakes Data pipelines with multiple use
• Last mile data preparation
• Visualisation and reporting
• Data governance including MDM, quality, observability and security
• Data science framework and models
• AI and ML
• Cloud and infrastructure

Monitoring and administration of platforms Over the past two years, we’ve greatly expanded our partnership ecosystem to make sure we’re able to match the right tool to the needs of our customer. With all that said, let me get you to some definitive steps to help layout a method in evaluating the features and finding a reasonable expenditure.

Here’s some quick ideas on how best to manage a vendor evaluation process from our experience:

• Gather your stakeholders and collaborate on needs
• Document your functional requirements with Must Have, Nice to Have, Not Wanted Begin building a broad list of potential tools
• Start with demonstrations of the tool. Make sure you feed them your requirements to get the best look at the feature set as it relates to your requirements
• Understand pricing models early, don’t fall in love with a product only to find out its beyond your budget.
• Narrow your options down to two (or maybe at a stretch three)
• Conduct a bake-off between the two on the same use case with your same users
• Conclude with a scorecard of your requirements with your stakeholders based on features, demo, POC and pricing

One final piece of advice that I’ll put forward: Never give away your IP to a platform.

There’s an ongoing attempt from the earliest days to today to attempt to lock you in, whether it’s a CRM, ERP, DWH or any other tool in the alphabet soup. What I mean is own your metadata and own your business logic. Make sure you can export anything and everything out of a platform if needed.

Also, let us help do all these things for you. After 27 years, we have a PhD in navigating all of this.

Summary

There are two parts to this summary. One of which you and only you have to own. What are your requirements? What does the tool need to do (Must Have / Nice to Have / Not Wanted) and how much money can we invest in solving these requirements.

The second bit is where you can get help and that’s finding the right tool for your requirements and your budgets. There are a lot of great tools, but is it the right tool for you?

Good hunting.

Want to Learn More?

Find this information helpful? We have plenty of other challenges to cover as part of this blog series, such as data governance, people resourcing, strategy, and user adoption and ROI. Scroll down for links to those blogs, or download the full white paper for easy desktop access.

Know your challenges but don’t know where to start in solving them? Reach out to our team, and we can help you figure out the best solutions for your needs.