DataViz Migration - an upstream/downstream SQL interoperability layer - {oa-lake}

Fri, 03 Jul 2026 00:00:00 +0000

Decision-support platforms often rely on several databases, several data warehouses / data lakes, and several reporting tools.

{oa-lake} introduces an intermediate SQL layer between data sources and dataviz tools.

Business rules, business objects, dimensions, measures, and calculations are centralized in this layer and then exposed to consuming tools.

Key point: data sources and reporting tools become independent of one another.

Architecture

{oa-lake} connects simultaneously to multiple data systems: relational databases, data warehouses, lakehouses, files, or APIs.

Queries are federated by a distributed SQL engine that performs the necessary joins, calculations, and transformations.

The resulting SQL remains standard and executable across different engines, which limits technology lock-in.

Business objects are defined once and then exposed to consuming tools.

Data sources

The data stays in its original systems.

Oracle, SQL Server, PostgreSQL, DB2, BigQuery, Snowflake, Redshift, Azure SQL (and others), or files can be queried within a single request.

The SQL Push-Down mechanism avoids any systematic copying of data: queries run directly against the existing systems, respecting the architectures already in place.

Typical use case: build a dashboard from data spread across several platforms with no prior migration.

SQL business layer

Dimensions, measures, hierarchies, and calculation rules are centralized in {oa-lake}.

This layer becomes the single entry point for reporting tools.

Business rules are no longer duplicated across every dataviz platform.

Key point: a single definition of indicators for the entire decision-support system.

Parquet cache

Data can be materialized in Parquet format.

This caching layer reduces response times and limits load on source systems. It’s managed automatically based on observed usage, with no manual intervention.

Typical use case: speed up the most expensive analytical processing.

Data visualization

Reporting tools connect to the model exposed by {oa-lake}.

Power BI, Looker, Spotfire, Tableau, Qlik, SAP BusinessObjects, or any SQL-compatible tool can use the same business objects.

Switching dataviz tools no longer requires rebuilding dimensions, measures, and calculation rules.

Progressive migration

Several tools can coexist during a transition phase.

The same business model can be exposed simultaneously to several reporting platforms.

Result: progressive migration of usage with no change to the data systems.

Data Lineage

The data lineage reconstructed by {openAudit} remains available across the whole chain.

Dependencies are documented from the source systems all the way to the indicators exposed in the dashboards.

Key point: transformations, calculations, and usage remain traceable across the entire architecture.

DataViz Migration - SAP BO, Power BI, Spotfire, or Cognos to an open, interoperable architecture

Thu, 02 Jul 2026 00:00:00 +0000

Data visualization platforms evolve regularly.

SAP BusinessObjects, IBM Cognos, Power BI, or Spotfire may succeed one another within the same Information System. Business objects, calculations, indicators, and business rules generally remain identical from one platform to the next.

{openAudit} analyzes technical repositories, semantic layers, and reports to reconstruct the dependencies between data sources, intermediate processes, and the objects exposed in dashboards.

Key point: the functional components of reporting platforms are extracted and then rebuilt in a format independent of the target technology.

Analysis of the decision-support estate

The parser-based analysis mechanisms cover SAP BusinessObjects universes, Cognos Frameworks, Power BI models, Spotfire Information Links, as well as the associated reports, dashboards, calculations, filters, and business objects.

The collected metadata makes it possible to reconstruct technical dependencies, semantic layers, and business rules.

Rationalization

Technical repositories are cross-referenced with usage logs. Unused reports, duplicates, and obsolete components are identified before the migration phase.

Result: a reduced scope for the actual migration.

SQL transcription

Queries, calculations, filters, aggregations, joins, variables, and business rules are reconstructed in the form of SQL.

The resulting SQL forms an open representation of the functional logic originally carried by the data visualization platform.

Key point: SQL becomes the pivot format for representing business objects.

{oa-lake}

The SQL processes are integrated into {oa-lake}.

{oa-lake} centralizes business objects, indicators, dimensions, business rules, and SQL transformations. The engine federates several data systems and exposes a single model to reporting tools.

Data can be materialized in Parquet format. Queries are generated against the physical systems or executed from the cache when needed.

Key point: business logic is defined once and then exposed to several data visualization platforms.

Interoperability |