Depending on whether you “build” your data lake in the cloud or on premise, it could take anywhere from six months to a year—and in some cases longer to be fully deployed. In our “want it now” culture, this timeframe might be too long for some CIOs. But those companies that are faithful to creating and using a big data platform should see not only breakeven but real return too.
Plainly speaking, a data lake—done right—takes time. Laying the foundation for analytics, making sure data are transformed so as to be usable, secured/protected, and properly managed—all these things are gradual tasks. A real data lake and its associated applications don’t happen overnight, or at least shouldn’t.
What is a data lake? In an effort to avoid too much sales-speak, here’s a working definition: a data lake is a group of data stores where you can capture, manage and analyze massive amounts of raw data. It’s a home for messy data such as web logs, social data, text files, PDFs and more. You can also keep non-messy data in a data lake, the kind that traditionally belong in a relational table. Data lakes are mostly built on open source Hadoop; however other platforms such as NoSQL databases or cloud storage (i.e. Amazon’s S3) work just as well.
From a financial lens, a two stage approach is a good way of looking at a data lake project. In stage 1 most of your time will be spent identifying use cases, examining current data sets and data sources, assessing your current technologies and checking on what new systems you’ll need that can scale as your business grows. You’ll also want to build a plan for data quality, data management, security, and metadata management throughout your “data pipelines.”
Stage 1 will continue as you either go straight to the cloud or start the process of jumping through the fiery hoops of capital allocation requests for hardware with your CFO. These efforts could add anywhere from one to three months to your project (maybe more). And of course you’ll want to start proof of concepts, and then pilot various use cases. All in all, stage 1—which is preparing for comprehensive analytics—is an exercise in delayed gratification.
In stage 1 of a data lake build, your incoming revenues will mostly be tiny and initial costs could be substantial. Considerations for initial cash outlays include hardware, data management software and engineering costs to expand needed functionality. Don’t forget incremental utility, overhead, supply costs and more for the data lake project. Consider stage 1 the “investment” part of your data lake effort while you get operational.
Now we get to stage 2 of your data lake project. In this round you’ll be in full production and doing “magical things” such as enabling Apache Spark and its various algorithmic libraries, turning your data scientists loose on raw data sets and possibly building BI-like reports for business analysts from data on the lake. You might also realize cost savings from consolidating various data facilities in your organization and possibly offloading ETL processes to Hadoop.
In truth, your data lake project—no matter how many stages—should be viewed in totality. Stage 1 or whatever you choose to call it will likely not have stand-alone profitability from a NPV perspective. And it’s hard to get to stage 2 without doing stage 1. Combining stages 1 and 2 should give you an “accept” from a capital budgeting viewpoint.
There are a few cautions: the above analysis isn’t black and white as there could be instances where you start earning more than you are investing in the first stage of your data lake project. However, in most cases it’s good to remain cognizant that you might not earn a financial return (on a discounted basis) until you’re well down the road of your data lake initiative. And that may be OK with your leadership team, as long as expectations for financial return are adjusted accordingly.
Read the other articles in this series:
