Commentary

Calculating the cost of DIY vs third-party SaaS solutions

One expert takes a look at the dollars and cents when it comes to just how much a difference exists between DIY and SaaS solutions.

March 2, 2017 by Dave Bennett — President & CEO, Mirus Restaurant Solutions

Now that 2017 is underway you may be evaluating whether to DIY or utilize a third-party Software as a Service solution for your organization, so it's a good time to outline where possible cost differences exist. While this topic has been discussed in my previous blogs, The benefits of 3rd party restaurant data warehousing and To SaaS or not? That's the question, it is worth addressing the elephant in the room. Therefore, in what could now be considered part 3 on this topic, we’ll add the dollars and cents to see just how much a difference exists between DIY and SaaS solutions.

Getting what you pay for

The biggest differences when making this comparison are going to be found in the upfront and ongoing costs. DIY solutions will have higher upfront costs. One could argue they then have relatively low ongoing maintenance fees. However, this doesn’t consider all costs associated with staff needed to manage and maintain the system, nor does it consider any changes needed as the business evolves. Furthermore, it ignores the real possibility that a self-constructed data warehouse has a much higher probability of failing to meet the needs of the business. This is typically something that isn’t discovered until you’ve invested all the time, effort and money to build out your new solution — just when those lower maintenance fees were supposed to kick in. This is where you could insert the phrase, "you get what you pay for," but more on this later.

If you were considering a DIY data warehouse solution for your restaurant business just a mere five years ago, you’d be faced with challenges associated with purchasing hardware, software, network infrastructure and then building out the space to house your new system or finding a suitable co-location facility. Today, you can turn to Amazon Redshift or Google cloud-based storage to remedy these hardware and networking needs. Ironically, in going to Amazon or Google, you are buying into the benefits of a SaaS subscription versus buying the assets.

However, while these services reduce your overhead by providing you with the resources to house your data, they don’t address the resources you’ll need (consultants or specialized IT team members) to create the data model (schema), or to get your data loaded and organized so you and your team can begin using it.

Roadmap for success

The design and analytical efforts begin with crafting your data model that will serve as your roadmap for integrating the different aspects of your operational environment. Most importantly, an appropriately crafted data model is needed if you’re going to use your data to answer questions about your business. Failure to appropriately craft the data model will, unfortunately, only be seen when answers to questions cannot be rendered. Oftentimes this doesn’t show up until well after the data warehouse has been in operation. The only fix for this is to go back and start over (we’ll come back to this), but first here’s a snapshot of some required skills needed to build your new data warehouse — IT Knowledge Required.

Creating a DIY data warehouse requires you to have IT team members with deep skills in the following areas:

Creation of a restaurant centric data model (Schema)
Data warehouse design
Business intelligence (BI) requirements
Database architecture, design, development, and administration
Extract, transfer and load (ETL) process

You can rent some storage space in the cloud and the company you rent from will be providing the hardware, software, networking services, infrastructure to house everything as well as support the systems and environment they’re maintained in. So, what’s the big deal? The big deal is — not to be disrespectful — if you don’t know a Snowflake from a Star (types of Schema used to create a dimensional data warehouse), you’re going to need specialized help (consultant, new hire or SaaS provider. The choice is yours). Let’s first look at a few of the items you’ll need from the IT Knowledge list above:

How do you get data into a warehouse?

To build a data warehouse, you first need to copy the raw data from each of your data sources, cleanse, and optimize it. The process of getting data into a data warehouse is called ETL: Extract, Transform, Load. Oftentimes these processes are dismissed by IT as being a simple data extraction solution. They are far from it.

1. Extract the data from the source system.

Ultimately you may have to acquire or create a middleware solution to extract and transport the data you want to load into your data warehouse. In this process, one of the challenges that you’ll need to avoid is copying all the data every time you sync. Some of your data sources could have hundreds of thousands of records, and copying every record during every sync is not a good idea. This optimization is when things really get complicated. Once your extraction and transport solution is complete you’ll then have to create the programs to transform and load the data as well.

2. Transform the data.

Transformation refers to the programs that need to be written to properly move data from the legacy operational environment into the data warehouse. There is a large amount of effort required to move data from one environment to another. This includes an understanding around the following functionality — filtering data, summarizing data, reformatting data, and selecting data from multiple disparate sources.

During transformation, data is cleansed, de-normalized, and pre-calculated so that it’s ready for analysis. Cleansing the data means that you resolve any inconsistencies (i.e., links that have been tagged in different ways, etc.). De-normalizing optimizes the data warehouse’s ability to read data, and pre-calculations include the calculations that you know you’ll need frequently (i.e.., net sales calculation, comp rules, etc.).

2a. Data Model (Schema)

To my knowledge, a restaurant-centric data model does not exist off the shelf, meaning you’ll need to add someone to your team or hire a consultant with skills in this area. Please note that just because someone knows what a Snowflake or Star schema is or has the skill to create a data model does not mean they’re familiar with the restaurant business, or more importantly, your restaurant business, your needs or objectives). This lack of understanding around things like Comp Rules, 53^rd week, etc., raises the stakes that something will be omitted or overlooked in the creation of the data model. As mentioned, making a mistake in the creation of the data model will have a major impact on the performance of your system’s ability to address the needs of all the stakeholders in your business. That’s a costly mistake. Also, each time you want to add new data— guest experience, speed of service, loyalty, reservation etc.—into your data warehouse you’ll have to perform this process again and hope that it’s also architected correctly.

On the other hand, SaaS service providers that focus on the restaurant sector have created a proven data model for restaurants. This streamlines the process that, in turn, shortens the time to completion from months to weeks, and ensures a successful implementation because you can see it and validate its capabilities before you buy.

3. Load the transformed data into the warehouse.

Once your data is loaded into your warehouse, it’s officially ready for analysis.

On-going costs

Building a data warehouse is not a "one and done" proposition. It’s an iterative process and will change over time as your needs change. However, many companies considering DIY don’t often stop and think about their data warehouses’ sustainability and/or costs, such as how upgrades, new integrations (Data Model, ETL) and ongoing maintenance will be handled.

Some of the future ongoing costs that companies forget about are:

Data formats changing over time
The time / cost of adding new data integrations
The time / cost of fixing broken data integrations
Requests for new features, new dimensions, etc.

I can’t emphasize ongoing costs enough. For example, if you’re connecting to an Application Programming Interface (API)-based service (which you most likely will at some point), you’ll encounter frequent updates being made to the API. If you want uninterrupted access to your data, you’ll need to be prepared to quickly respond to these updates. In short, if you have a data warehouse, you will need to have the IT infrastructure to maintain and support your current as well as future needs…and that’s costly. With a SaaS partner, all of this is taken care of.

Quantifying the costs

As mentioned, this is not a tutorial on how to build a data warehouse, but rather a snapshot of some of the challenges a DIY data warehouse presents and associated costs to create and maintain it. A data warehouse’s costs can be classified in several ways — recurring and one-time expenditures, and by capital and operational expenditures. The classifications include the rental or purchase of hardware, software, consulting and ongoing development and maintenance. The creation of a data warehouse is generally done in stages where initial expenditures are made in year one and successively lower one-time costs are made in subsequent years.

Assumptions

1. Fees

Consulting Fees for software development capped at $150K - but could be higher (as much as $250K).

Years 2, 3, and thereafter include new integrations (Food Cost, Guest Satisfaction, Loyalty, etc.) being added to data warehouse.

2. Employees

One specialized database skilled IT employee will be required to keep the solution operational.

A second IT Person will be necessary as deployment ramps up. After all, this solution runs 24 hours a day, 365 days a year.

3. Tools

Software costs for tools to mine data are typically a per user fee for DIY (Reflects 1 to 2 users).

4. Storage

The cost to house minimal data with cloud service providers (AWS, Google, etc.), includes network infrastructure, hardware, security, ongoing maintenance). Costs for service will escalate as storage needs increase and as data is accessed (I/O).

5. Time

Deployment of DIY may take 6 - 9 months before operational versus SaaS, which can be deployed and operational in 6 - 8 weeks.

6. Satisfaction

If you're unhappy with the SaaS service, you can cancel and move on. If you're unhappy with your DIY, your options are much more limited and far more expensive.

Summary

Having access to your data is incredibly important. An effective data warehouse empowers your team to more quickly to create reports that produce fact-based answers so decision-makers can make decisions that result in the best outcomes for the business. If you’re a believer in data-driven decision making as we are, then there really aren’t many projects of greater strategic significance.

While there are more options today making it easier to create your own data warehouse, there’s compelling evidence indicating that there remain numerous hurdles and costs to successfully completing the project. Gartner once estimated as many as 50 percent of data warehouse projects would have only limited acceptance or fail entirely.

Solid cloud-based providers deliver the results you need and are accountable for the entire solution—not just your data storage. Additionally, unlike DIY, SaaS providers continuously invest in software development, infrastructure and human capital. Providers that operate as an agile development environment may release new software updates every four to six weeks.

These investments ensure that the latest features are available, infrastructure can support a client’s ongoing needs and there’s ample highly qualified talent to address any questions or issues that might arise.

The choice is yours, DIY or SaaS. But given the costs, time to develop and possibility that a DIY solution might ultimately fail to deliver, it is safe to say that SaaS solutions are far faster to deploy, safer and less a much less costly approach than a DIY system.