Extract engineering data without programming or database skills — multi-ALM, versionable, transferable, read by the whole team.
One desktop tool, one declarative language, one self-contained report — write the KPI, run it anywhere, and the reviewer drills from the number back to the requirement, test or finding behind it.
Metrix produces reports as interactive HTML dashboards — sortable tables, filters, search, tooltips, drill-ins and a breadcrumb to find your way back — and the same run can also export to Excel and JSON for downstream tools. Whichever format you open, every number carries its full accounting: the query that produced it, the items it matched, and the items it considered for evaluation. Nothing is hidden behind a dashboard call.
No separate trend database to configure, no OLAP cube to feed. Every time you run a metric it becomes a point on the trend; shape, delta and direction read at a glance across 8+ sprints or weekly CI builds. The trend is the history of your runs — nothing extra to set up.
Drill into the items behind a deviating KPI, and attach your analysis next to the finding. A missing trace is sometimes a genuinely missing link, sometimes just an item dropped from the count because an attribute on the source or sink was never set — and because the DSL is formal, every such gap leads back to its rationale. The action then follows naturally: a process improvement, a small data correction, or coaching the team on how to set the attributes.
Author the KPI, the charts that visualise it and the callouts that interpret it in the same declarative Metrix language — intuitive, versionable, reviewed in the same pull request as the code. Because the explanation ships with the metric, an engineer and an auditor read from the same source of truth. Books and chapters move between projects, so new projects start from the team’s accumulated catalog instead of a blank screen.
Think about the insight, not the plumbing. One desktop tool handles extraction, storage, trending and visualisation — no database admin, no BI ticket, no quarter-long dashboard back-and-forth. Connectors live in the tool, credentials stay on your machine, and the whole pipeline runs the same way on the desktop as it does headless in CI.
Follow feature → requirement → test → result in one expression — no joins, no SQL, no pre-aggregated views to maintain. The engine is built for depth queries on real engineering graphs: blitzschnell on tens of thousands of items, with the trace that justifies the number returned alongside it. Answers come back in seconds, not after a batch run.
A Metrix book is a short DSL file (.mxb): your KPI, chart and callout definitions, versioned in Git. The same engine runs it on your desktop while you write it, and headless in CI tonight.
.mxb file with a few declarative KPI, chart and callout definitions in a readable DSL. It lives in Git next to the code, reviewed in a PR like any other change.Everyday patterns disappear and new ones take their place. The before/after is what engineers tell us after their first full sprint on it.
A 25-member engineering team on a Grafana / BI reference stack spends about €303,500 over three years — licences, infrastructure, dashboard build-out, and a specialist premium plus the translation loop between engineers and BI staff.
The same team on Metrix lands at about €132,500 — a 56 % saving, engineers own the KPI, no translation loop. The whitepaper scales the comparison from 5 to 2,500 seats across three AWS assurance tiers and is honest about where the gap narrows.
A spreadsheet gets mailed around, three people edit it in parallel, and by the review nobody agrees which cell is current. The number is re-derived every time it’s questioned.
The KPI definition sits in Git next to the code. Anyone who disagrees opens the .mxb book; anyone who re-runs it gets the same number. No "which copy of the spreadsheet?"
You need a new KPI by Friday. You raise a ticket, wait a sprint, get a dashboard that nearly measures the right thing, and iterate another sprint while the central team juggles ten other requests.
The team that needs a KPI writes a KPI. A few lines of DSL, a run, a report — before lunch. The central team is freed up for governance, not for ticket triage.
The team sees its KPIs once a quarter in an audit slide deck, discovers something regressed six weeks ago, and spends a week forensically reconstructing why. The feedback loop is longer than the memory.
Engineers see their KPIs in the inner loop — after every nightly, in every PR, on the dashboard they open daily. A regression gets caught the day it lands, not the quarter after it ships.
Each project built its own KPI definitions and its own report template. Comparing release A against release B means two spreadsheets with slightly different formulas — and the ROI story becomes anecdote.
The same book runs on both projects. "Test-pass across three releases" is one chart, built from one definition — and the ROI argument stops being “trust me” and starts being “here is the trend”.
Deciding whether a KPI is “the right one” means staring at 400 lines of SQL, dashboard config and a stored procedure only the original author remembers. The debate dies, the dashboard stays as-is.
The metric is a few lines of DSL that read like a sentence. An engineer, a PM or an auditor can read it, challenge it and propose the change as a pull request — the conversation stays about what to measure.
The person who built the dashboards leaves. Three months later nobody can add a column, let alone a new metric; the team re-derives half the knowledge and quietly accepts the rest as “how it’s always been”.
Books, chapters, scopes and template snippets are text in the repo. New hires read them like code; new projects start from the last project’s catalog, not from a blank screen. Expertise accumulates on the shelf, not in a head.
Where Metrix is today, and the two releases on the horizon. Dates are targets, not promises; scope moves between releases rather than slipping end dates.
The Metrix DSL, book/chapter authoring, multi-ALM connectors, HTML / JSON / Excel reports, trend out of the box, and signed licence files. Runs the same way on the desktop and headless in CI.
.mxl packages. Ships with a starter set for the common ALMs and safety standards.The full planning docs live inside the project; this page shows the headline for each release.