Apache Ossie invoeren zonder dat je metricdefinities weer uit elkaar groeien

Waarom betekent dezelfde metric nog steeds iets anders in Power BI, Databricks en je AI-agents?

Omdat elk platform zijn eigen kopie van de logica bijhoudt, en niets die kopieën op één lijn houdt. Netto-omzet is een DAX-measure in een semantisch model in Power BI, een metric view in Databricks, een SQL-query achter een ander dashboard en steeds vaker wat een AI-agent afleidt uit kolomnamen. Elke versie klopte toen iemand ze schreef. Na verloop van tijd sluit de ene geannuleerde bestellingen uit en de andere niet.

Ossie benoemt zelf vier symptomen: metrics die uit elkaar groeien tussen dashboards, dure manuele afstemming, onbetrouwbare grounding voor AI en complexe point-to-pointkoppelingen tussen tools. AI-agents maken het derde zichtbaar: een agent die drie omzetmeasures vindt, kan niet weten welke Finance heeft goedgekeurd. Daarover schreven we al in waarom je AI-chatbot andere cijfers geeft dan je Power BI-dashboards.

Wat is Apache Ossie, in gewone taal?

Apache Ossie is een open specificatie om semantische metadata te beschrijven, zodat metrics, dimensies, relaties en businesscontext tussen BI-, analytics- en AI-platformen kunnen bewegen zonder dat je ze manueel opnieuw bouwt.

Snowflake introduceerde het in september 2025 als Open Semantic Interchange (OSI), samen met een groep BI-, catalog- en AI-leveranciers. De specificatie werd in januari 2026 gepubliceerd onder Apache 2.0. In juli 2026 werd het project opgenomen in de Apache Incubator en hernoemd tot Apache Ossie. Meer dan 70 organisaties staan op de ecosysteempagina, onder meer Snowflake, Databricks, Microsoft, Salesforce, dbt Labs, Qlik, ThoughtSpot en Tabular Editor. Databricks onderhoudt converters tussen zijn metric views en Ossie, en dbt Labs maakte MetricFlow open source als referentie-implementatie.

Een Ossie-model is een declaratief YAML-bestand met vier bouwstenen:

• Datasets: businessentiteiten die verwijzen naar een tabel, view of query.
• Fields: attributen op rijniveau, die je als dimensie of tijdsdimensie kunt markeren.
• Metrics: aggregaties, die over meerdere datasets kunnen gaan.
• Relationships: de sleutels waarmee datasets aan elkaar gekoppeld worden.

Modellen, datasets, fields en metrics hebben elk een description en een ai_context met instructies, synoniemen en voorbeelden voor AI-agents. Het belangrijkste detail voor de invoering: één metric kan haar expressie in meerdere dialecten bevatten, waaronder ANSI_SQL, DAX, DATABRICKS, SNOWFLAKE, TABLEAU, MDX en BIGQUERY. Leveranciersspecifieke details komen in custom_extensions.

Ossie zit nog in de incubatiefase en de specificatie evolueert. De Apache Software Foundation geeft aan dat incubatie niet noodzakelijk iets zegt over hoe volledig of stabiel de code is. Dat is een reden om met een afgebakende set metrics te beginnen, geen reden om te wachten. Meer lees je op ossie.apache.org en in de specificatie op GitHub.

Wat standaardiseert Ossie, en wat laat het aan jou over?

Ossie standaardiseert hoe je een metric noteert en uitwisselt. Het beslist niet wat de metric betekent, wie er eigenaar van is of wie een wijziging goedkeurt.

Wat Ossie je geeft:

• één structuur voor metrics, dimensies en relaties
• één metric met een expressie per platform
• beschrijvingen en AI-context in hetzelfde bestand
• een open formaat dat elke leverancier kan lezen en schrijven

Wat het aan jou overlaat:

• afspreken wat "netto-omzet" meetelt, en wat niet
• de persoon aanduiden die die definitie mag wijzigen
• wijzigingen goedkeuren en hun geschiedenis bijhouden
• de businessbetekenis en elke platformexpressie in sync houden

De specificatie heeft geen velden voor eigenaarschap, stewardship, certificering of goedkeuring. Voor een uitwisselingsformaat is dat een logische keuze, maar het betekent dat Ossie invoeren geen puur technisch project is. Zijn twee afdelingen het vandaag oneens over omzet, dan lost het niets op om beide versies in YAML te schrijven. Je hebt de onenigheid dan gewoon in een netter formaat.

Die afspraak is het deel dat de meeste organisaties onderschatten, en ze heeft meestal al een plek: het businessglossarium, waar een begrip een definitie, een eigenaar en een goedkeuringsspoor heeft. Liggen je KPI's nog niet vast, begin dan bij één KPI, één definitie.

Wie is eigenaar van Ossie-definities: de business of IT?

Allebei, elk voor een ander deel: de business is eigenaar van de betekenis, het datateam van de expressies. Een finance lead beslist dat netto-omzet zonder btw en zonder geannuleerde bestellingen is. Een analytics engineer schrijft die regel in DAX voor het Power BI-model en in SQL voor de metric view in Databricks. Geen van beiden kan het werk van de ander goed doen.

Het risico is dat je die twee op verschillende plekken bijhoudt. Staat de businessdefinitie in een wiki en de expressies alleen in een Git-repository, dan merkt niemand het als het ene wijzigt en het andere niet. Houd beide in één record bij, en laat een wijziging aan een van beide door dezelfde eigenaar nakijken. Zo kunnen de zin die Finance goedkeurde en de code die in elk platform draait niet ongemerkt uit elkaar groeien.

Hoe weet je of je rapporten de Ossie-definitie echt volgen?

Door ze te controleren, en dat te blijven doen, want een definitie publiceren verandert niets aan de measures die al bestaan. De meeste Power BI-omgevingen bevatten al tientallen measures en metric views die een versie van je kern-KPI's berekenen. De afgesproken definitie in Ossie schrijven raakt daar niet aan.

En afwijkingen komen steeds terug, om heel gewone redenen:

• Gekopieerde measures: een team kopieert een semantisch model en past één measure aan voor een lokale behoefte.
• Lokale aanpassingen: een analist voegt een filter toe "alleen voor dit rapport" en houdt dezelfde naam.
• Nieuwe rapporten: iemand bouwt een nieuwe measure van nul in plaats van de afgesproken te hergebruiken.
• Gewijzigde definities: de eigenaar past de regel aan, en oudere implementaties blijven zoals ze waren.

Een eenmalige audit vindt de verschillen van vandaag en mist die van volgende maand. Wil je van Ossie een definitie maken die wordt afgedwongen, en geen document dat je één keer publiceert, vergelijk dan doorlopend de gecatalogeerde measures met de afgesproken berekeningslogica, en markeer wat niet conform is, zodat de eigenaars kunnen ingrijpen.

Waar bewaar je je Ossie-definities het best?

Voor de meeste organisaties is het praktische antwoord: een businessglossarium voor de afgesproken betekenis en de goedkeuring, met Git ernaast voor de engineeringworkflows. Zo verhouden de belangrijkste opties zich tot elkaar.

Git is uitstekend voor engineers: versiebeheer, code review en geautomatiseerde uitrol. Houd het dus. Wat Git niet biedt, is een plek waar Finance de zin kan lezen, betwisten en goedkeuren. In de praktijk gebruik je vaak beide: het glossarium als beheerd record, en de geëxporteerde Ossie-YAML in Git voor pipelines en uitrol.

Een praktisch kader: afspreken, vertalen, goedkeuren, publiceren, opvolgen

• Afspreken: de business-eigenaar en de mensen die de metric gebruiken, spreken de definitie in gewone taal af in het glossarium: wat telt mee, vanaf welke datum, en wat valt erbuiten.
• Vertalen: het datateam schrijft de Ossie-metric, met een expressie voor elk platform dat je gebruikt, plus een beschrijving en AI-context.
• Goedkeuren: de benoemde eigenaar keurt de betekenis en de expressies goed, en elke wijziging blijft bewaard in de geschiedenis.
• Publiceren: exporteer de definitie als Ossie-YAML naar de platformen en AI-agents die ze nodig hebben.
• Opvolgen: markeer de measures en metric views die niet meer conform zijn, zodat hun eigenaars ze kunnen rechtzetten.

Waar begin je?

Begin niet met je volledige datamodel. Kies de 10 tot 20 KPI's waarover nu al discussie is, meestal die op het maandelijkse managementrapport. En begin ook niet met een leeg blad: de measures en metric views die je al hebt, tonen hoe elke KPI vandaag berekend wordt, inclusief waar de versies verschillen.

1. Lijst de KPI's op die in managementrapporten staan en waarover discussie is.
2. Verzamel de DAX-measures, metric views en SQL die ze vandaag berekenen.
3. Maak van wat je vindt één ontwerpbegrip per KPI in het glossarium, en duid een eigenaar aan.
4. Laat de eigenaar de definitie afspreken, voeg de Ossie-expressies toe en laat ze goedkeuren.
5. Exporteer die begrippen als Ossie-YAML en toets bestaande rapporten eraan.

Houdt de eerste reeks stand, voeg dan de volgende toe. Een kleine set definities die mensen vertrouwen, is meer waard dan een volledig model waarover niemand het eens is.

Waar dScribe past

In dScribe zit de Ossie-definitie in het begrip in het businessglossarium, naast de businessdefinitie, de eigenaar en de goedkeuringsgeschiedenis. Businessmensen spreken de betekenis af, het datateam voegt de platformexpressies toe, en beide staan in één beheerd record. Neem één begrip, Netto-omzet:

• Businessdefinitie: "Gefactureerde omzet na kortingen, zonder btw en zonder geannuleerde bestellingen."
• Eigenaar: Finance.
• Goedkeuringsgeschiedenis: elke wijziging aan de definitie of aan een expressie, met wie ze goedkeurde en wanneer.
• Ossie-definitie: de metric met een expressie per platform, zoals hieronder.

metrics:
  - name: net_revenue
    description: Invoiced revenue after discounts, excluding VAT and cancelled orders.
    expression:
      dialects:
        - dialect: ANSI_SQL
          expression: SUM(CASE WHEN orders.status <> 'cancelled' THEN orders.amount - orders.discount END)
        - dialect: DAX
          expression: CALCULATE(SUMX(orders, orders[amount] - orders[discount]), orders[status] <> "cancelled")
    ai_context:
      synonyms:
        - "net sales"
        - "revenue after discounts"

Het fragment is illustratief en volgt de huidige ontwerpversie van de Ossie-specificatie.

Zo doorloopt dat begrip zijn levenscyclus in dScribe:

1. Vertrek van wat er is. dScribe scant de bestaande metric view "Net revenue" in Databricks en stelt een ontwerpbegrip voor in het glossarium.
2. Afspreken en goedkeuren. Finance spreekt de businessdefinitie af en keurt ze goed.
3. Vertalen en exporteren. Het datateam voegt de DAX-expressie toe, die door dezelfde eigenaarsreview gaat als de businessdefinitie. dScribe exporteert het begrip als Ossie-YAML, apart of samen met een reeks begrippen.
4. AI-agents bedienen. Een AI-agent die naar netto-omzet vraagt, krijgt de goedgekeurde definitie, de eigenaar en de formule via de MCP-server van dScribe.
5. Afwijkingen markeren. Een measure "Net Revenue" in een regionaal Power BI-rapport telt geannuleerde bestellingen nog mee. dScribe markeert ze als niet conform aan het gekoppelde begrip, zodat de eigenaar ze kan rechtzetten voordat de cijfers in een vergadering uit elkaar lopen.

De business ziet en keurt de zin goed, het datateam onderhoudt de expressies, en Power BI, Databricks en AI-agents lezen uit hetzelfde goedgekeurde record. dScribe laat je ook weten wanneer een rapport dat niet doet. Begrippen worden gekoppeld, niet gekopieerd, aan de datasets, kolommen en rapporten die ze gebruiken, via connectoren voor Power BI, Microsoft Fabric, Databricks, Snowflake, dbt, Tableau, Qlik en Looker. Dezelfde definitie verschijnt in de zoekfunctie van dScribe, in de browserextensie op Power BI-rapporten en via de open API. Voor het bredere plaatje, lees hoe je één bron van waarheid maakt voor mensen en AI.

Kort samengevat

Ossie geeft elk platform dezelfde taal voor een metric. Je glossarium beslist wat die metric betekent, en controleert of elk rapport ze nog volgt. Spreek eerst de definitie af, schrijf ze één keer met een expressie per platform, geef één eigenaar de zeggenschap over wijzigingen, en blijf de measures controleren die al in omloop zijn.