Internal system · In production

Map of the legacy warehouse

Tooling for a trading company’s legacy warehouse: a reusable client, a CLI for SQL and for the OLAP cube, auto-generated data maps and a check of how trustworthy the data is. The repository is deliberately local: the maps hold internal addresses and the full schema, and they do not leave.

The pain

The legacy warehouse arrived as a black box: several databases, hundreds of tables and views, an OLAP cube, no description at all. Every question started with excavation.

Now

A reusable client, a CLI for queries and a data map rebuilt by one command: databases, tables, views, columns, with a map of the cube beside it. Plus a check that the data can be trusted.

What the business gets

A question about the data starts with the map instead of digging through the database.
The traps are written down next to the data: where cost is also stamped on logistics rows, where a price sits in the document’s currency and a broken rate overstates it a hundredfold.
The trustworthiness check returns an exit code, so «the data can be trusted» is a run, not an opinion.
The maps are rebuilt by a command and do not go stale behind the schema.

From source to result

Legacy databases and the cube
Client and CLI
Auto-generated maps
Trustworthiness check
Calculations and reports

The maps are assembled from the database itself rather than written by hand: when the schema changes, the same command rebuilds the map and the difference shows up in the git diff.

How it works

There is one reusable client: both the CLI and the calculation scripts reach the database through it, so credentials and response parsing do not scatter across copies.

The findings are written up as separate documents: where the business-logic layer turned out to have bugs, how the load schedule is arranged and how it fails, where cost comes from and in which of the eight chains it is understated.

Outliers in the data are handled rather than ignored: a suspicious currency rate in a document is replaced with the nearest sane one, otherwise a single row from the accounting system overstates the calculation by an order of magnitude.

Who maintains it now

The engineer. The repository stays local with no public remote: the map contains internal addresses and the full schema.

Other cases for this step

Internal system · In production

Management finance loop

Every number the company has - in one system

The pain: The numbers lived in ten spreadsheets, private chats and the heads of three people. When key people left, both access and context left with them.
Now: One source: cash flow, budget, payment requests, reconciliation and reference books in a single application with roles and permissions.

Timeline: one month
Replaced: ten spreadsheets and a chat thread
Coverage: cash flow, budget, requests, reconciliation

The same system pays off across 3 more steps

Internal system · In production

Data platform

One source of truth instead of everyone’s own report

The pain: Every department exported marketplace data its own way, so meetings started with an argument about whose spreadsheet was right. Last year’s history did not exist at all.
Now: The platform collects data on a schedule and takes it through layers up to ready-made data marts. From there everyone - people, applications and agents - takes the numbers from the same marts.

Collection
Coverage
Replaced: manual exports in every department

The same system pays off across 2 more steps

Internal system · In production

IT infrastructure inventory

Services, access and owners - in one place

The pain: The inventory lived in a legacy panel and scattered notes: who is connected to what, what runs where, who owns it. When a person left, access and context left with them.
Now: One panel: a service tree, the «who has access to what» matrix, keys and portals, tasks, problems, changes and an audit log. Login under your own account, sections visible by role.

Sections
Timeline
Replaced: a legacy panel of 35 tabs

Type: Internal system
Status: In production
Coverage: 5 databases, ~427 tables and 329 views
Maintained by: an engineer
Replaced: digging through the database and one person’s memory

PythonMS SQLSSASDAXpython-tds