Modern Data Stack : Centralize intelligence, not data...

 

Modern Data Stack : Centralize intelligence, not data... Each BI tool vendor has invented its own "language," its own grammar, its own internal logic. Examples include DAX, MDX, LookML, Semantic Models, etc. And each tool adds its own internal mechanisms, which change completely from one tool to another. Next, users create specific business rules, which are not always the same from one dashboard to another, from one technology to another, sometimes replicated, sometimes adapted… with subtle variations that create uncertainty.   So we "patch", we "tinker", and we end up consolidating a business logic specific to each tool... which amounts, slowly but surely, to creating a... fatal dependency.   There are several options to change this situation.   Option 1:  Data preparation in the database A (false) good idea… Centralizing data preparation in modern and scalable databases has real advantages : We "empty" the BI layer of its complexity, we create transparency. We centralize business logic in a single location. This effectively creates interoperability on the BI side.   But in practice, centralizing all the preparation quickly becomes very cumbersome.  Three concrete examples: Every business change requires IT intervention. Pipelines need to be completely replayed to update a simple dashboard, with cloud costs skyrocketing. And above all, a BI platform is (almost) always multi-source, and switching everything back to a single data source represents a huge migration effort. This leaves complex, difficult-to-maintain dependencies.   In short, in this scenario, we largely lose the flexibility and responsiveness favored by the business (self-BI). Option 2:  Implementation of  "oa-lake"  The missing layer between the two worlds Then the idea of ​​oa-lake was born, with an underlying idea:  "centralize intelligence, not data": Instead of loading, transforming, and cross-referencing data from multiple sources to feed Power BI, Looker, Strategy, or other systems, oa-lake provides a distributed SQL layer: oa-lake unifies sources as they are (Oracle DB2, BigQuery, Excel…) - no need to migrate to change BI solutions . oa-lake generates a Parquet pivot format , calculated on demand, with a perishable cache. oa-lake applies business rules in simple SQL , outside of dashboards and source databases, which remain focused on their primary role, without encapsulating (and masking) business complexity. Schedule a 30-minute meeting with the technical teams in early 2026 for a feedback session. oa-lake does not replace existing tools. The idea is neither to redo an ETL process nor to build a new data warehouse. It is a simple, open intermediate layer, where the business logic is written only once, in readable SQL.    Bonus  We are able to migrate existing dashboards, especially from legacy technologies (SAP BO, Cognos...) in an automated way to this architecture to strongly catalyze your migration projects.  See also:  How to prevent your IT system from migrating... only to become more complex?