Data virtualization, explained simply: query everything, copy nothing

The problem: your data lives in five places

Every growing company ends up in the same spot. Sales live in the ERP. Accounting has its own package. Operations run on spreadsheets. Maybe there is a project tool, a CRM, or in construction a BIM model with thousands of components. Each system is fine on its own.

The pain starts when you need an answer that crosses them. Which clients ordered more this quarter but pay later? Which machines cost more in maintenance than they produce? Somebody exports three files, pastes them into a spreadsheet, and by the time the report is ready the numbers are already old. Next month, someone does it all over again.

The usual answer: copy everything into one place

The classic fix is to build a central copy, often called a data warehouse. Every night, data from each system is extracted and loaded into it. It works, and for some heavy analytical needs it stays the right tool. But for an SME the bill is steep: a months-long project before the first result, pipelines that break when a source changes, and a permanent copy of everything that you now have to store, secure and keep in sync.

And the copy is always a little behind. You end up making decisions on yesterday, at best.

Data virtualization: query it where it lives

Data virtualization takes the opposite path. Think of a network of libraries. Instead of moving every book into one giant building, you build one catalog that knows where each book sits and fetches it on demand. The books never move. The catalog is what you search.

Concretely, a virtualization layer connects to each of your systems, learns what they contain, and translates your questions into each system’s language. You ask one question in one place. The layer collects the answer live, from the real data, and never keeps its own version of the truth.

What it changes in practice

• Fresh answers: a query reads current data, not last night’s export.
• No migration project: your systems stay in place, so the first useful result arrives in days rather than months.
• One source of truth: each system remains authoritative for its own data, so there is nothing to reconcile.
• Less to secure: no second copy of the whole company floating around.
• Freedom to change: replace a source system and only the connection changes, not the whole edifice.

The honest trade-offs

No architecture wins everywhere, and pretending otherwise sells badly. Live queries depend on the source systems being reachable, so a good virtualization layer uses caching to keep frequent questions fast. Virtualization also does not clean messy data by itself: if two systems spell a client’s name three ways, that still needs to be resolved. And for very heavy historical analysis on billions of rows, a warehouse still earns its keep.

For the everyday reality of an SME, though, the trade is usually excellent: most of the value is in crossing live operational data, not in archiving it twice.

Why LOBI-SYSTEMS built Senga on it

Senga was born from a hard case: construction projects, where a single BIM model is itself a database with thousands of objects, next to an ERP, inventories and planning tools. Copying all of that into one warehouse would have been a project nobody had time for. Connecting it turned out to be the better idea, and it now works in any industry.

The strategy also matches how we build everything. Your data stays yours, on your infrastructure, and Senga does not duplicate it. Your systems keep speaking the standards they already speak, whether that is SQL, Excel or IFC. And you get something useful in days, because there is no big-bang migration standing in the way.