Strategies for Data Platform Consolidation
Many shops experience database spread — the existence of far too many databases, often with redundant data, and often for very discrete needs. In these shops, databases are often built relatively quickly to expedite projects and applications. Once this is done repeatedly over the years and made the default go-to approach, the “data architecture” can become accidental. This is not just an application-first approach; it’s an application-only approach, with the data being secondary.
Of course, this is not a good idea that anyone would openly advocate. It’s borne of expediency.
Data platform consolidation may not be as sexy as starting a big data or IoT project. However, because these projects can make and save the company money, they are having a strong resurgence.
Furthermore, it’s a great excuse to take advantage of cloud database offerings.
Data warehouses have a lower total cost of ownership than data marts. That’s understood, but what is data warehousing in this business/financial context? It’s a shared platform. It’s a “build once, use many times” strategy. It means multiple business projects can use the data without having to build separate robust data layers. Allowing concurrent use of data at the data warehouse layer or creating a mart off the data warehouse is a lot less work, reduces risk, and lowers overall costs than does building from uncultivated, original source data.
For the rest of the article, please see here.