To place the Data Lake concept on the right shelf in our professional toolkit, it is important to start with a brief theoretical overview. When designing new data warehouses, we fundamentally base our approach on either Inmon's or Kimball's methodology. 

In Kimball's approach, data sent by source systems is stored using a dimensional approach in a star schema, from which data can be easily and quickly extracted to the data mart level. So, this practice answers the question of how we can extract data from our applications in a business-reportable format as quickly as possible, using a sort of bottom-up approach.  [1]

In contrast, Inmon advocates that the primary goal of our data warehouse is to answer questions posed in corporate terminology using a top-down approach, meaning he does not believe in using application-level data. The term "customer" can mean something completely different to a bank's retail business line compared to a wholesale or even a corporate business line. In the case of insurance companies, terminological difficulties can arise with definitions related to products (life, non-life, riders), which must be defined at the executive management level in a data warehouse built in the spirit of Inmon. 

Nowadays, however, significant shifts can be observed in the IT management triangle in favor of flexibility and short-term cost-effectiveness, but at the expense of future-proofing. This is exactly where the Data Lake concept comes in, where: 

• Storing data in a star schema as envisioned in the Kimball architecture and presenting data relatively easily and quickly, which are based on properly normalized data at the DW level, is not a priority. 

• Storing and reporting data according to Inmon's unified corporate terminology, and the preceding collaboration between different business units, is not a priority. 

• The only priority is to store current data in whatever structure – typically that of the source system – thereby achieving a very short-term project goal, which typically has no strategic significance (or if it does, future-proofing is drastically compromised), and even its medium-term sustainability is often questionable. Future-proofing can easily be compromised because certain unplanned but eventually necessary reports may often blur application-specific terms with often similar corporate terminology. To illustrate with a simple example, a management report contains data on individuals and non-individuals in such a way that, according to unified corporate terminology, sole proprietorships belong to non-individuals, while at the application level, they belong to individuals.

Based on the example above, we can see that data warehouses developed in the traditional Inmon or Kimball spirit carry real, long-term sustainable business value according to industry experience. They are "warehouses" that can be quickly moved, rearranged, and we can retrospectively examine changes in our "inventory". The modern-day data warehouse built in the spirit of Data Lake, however, is a "lake" that swallows a long-unused Csepel bicycle or a used battery. 

Although based on the example above it might seem that implementing a Data Lake is never advisable, this is far from true. However, during its application in an average large enterprise, we should consider the drivers emerging on a less technical level: 

• Do we want to implement it because we have no trump card against resistance from other business units?

• Our developers did not grow up in a data warehousing environment, so we view the application of the Data Lake concept as a kind of quick-win?

• Or perhaps we are taking the path of least resistance to meet management deadlines quickly and cheaply? 

Finally, let's see what the appropriate situations might be for a Data Lake implementation:

• A real but less foreseeable technical reason that makes a phased implementation necessary (e.g., GDPR compliance of a complex, legacy monolithic system being phased out)

• One of our key strategic goals requires the immediate collection of a large volume of heterogeneous (structured, unstructured) data, but future utilization needs are currently unforeseen (big data problem area).

• The data entering the Data Lake is used to train artificial intelligence models (machine learning), for example, to develop predictive logic.

• Immediate processing of continuously arriving (streaming) data is required, where running algorithms again on past data is also necessary.

It is to be feared that we will encounter the latter cases less frequently in a traditional large enterprise...