Forum Discussion
Moving from XMLA to TMDL (.pbip) for Automated Metadata Extraction & Audits
Hi v-dineshya
Thank you for this brilliant architectural breakdown! I completely agree with your 3-layer approach.
My current framework focuses heavily on your Layer 1 (Static Analysis via TMDL). I've found that for most teams, getting a reliable Data Dictionary, mapping relationships, and standardizing documentation without needing to query a live workspace is the biggest immediate bottleneck during handovers.
Your points about the enterprise edge cases—especially DirectLake storage behaviors and >10GB model performance stats—are incredibly valid. Augmenting the static TMDL parser with an "on-demand" XMLA module specifically for runtime performance metrics is exactly the right direction for a holistic governance roadmap.
Really appreciate you sharing these enterprise insights with the community!
Hi theBItoolbox ,
Thank you for reaching out to the Microsoft Community Forum.
Please try below Architecture.
1. TMDL Parsing Layer (Static Analysis): Please use for Data dictionary generation, Naming standard validation, Documentation, Git-based diffing and Pull request validation checks.
2. XMLA Layer (Runtime Analysis): Please use for Performance auditing, Dependency graphs, Storage statistics and Model health KPIs.
3. Usage Layer (Telemetry): Please use for Power BI Activity Logs and Log Analytics / Fabric monitoring.
Enterprise Edge Cases where TMDL alone breaks.
1. DirectLake / Hybrid models (Fabric): Runtime storage behavior differs significantly from metadata definition.
2. Large semantic models (>10GB): Performance tuning requires engine stats.
3. Legacy models not converted to .pbip, Still XMLA-first environments.
4. External tools modifying models: Tabular Editor scripts may introduce changes not reflected locally until sync.
Note: If you are building a framework, use TMDL as your primary metadata for Faster, CI/CD native and Developer-friendly. Use Augment with XMLA “on demand” to Run deeper audits periodically (not continuously) and Plug gaps (performance, dependencies, usage).
I hope this information helps. Please do let us know if you have any further queries.
Regards,
Dinesh
Hi v-dineshya
Thank you for this brilliant architectural breakdown! I completely agree with your 3-layer approach.
My current framework focuses heavily on your Layer 1 (Static Analysis via TMDL). I've found that for most teams, getting a reliable Data Dictionary, mapping relationships, and standardizing documentation without needing to query a live workspace is the biggest immediate bottleneck during handovers.
Your points about the enterprise edge cases—especially DirectLake storage behaviors and >10GB model performance stats—are incredibly valid. Augmenting the static TMDL parser with an "on-demand" XMLA module specifically for runtime performance metrics is exactly the right direction for a holistic governance roadmap.
Really appreciate you sharing these enterprise insights with the community!
Hi theBItoolbox ,
Please try the suggested architecture, if you are facing any issues. Please do let us know, we will happy to help you.
Regards,
Dinesh
Hi theBItoolbox,
As we haven’t heard back from you, we wanted to kindly follow up to check if the response provided by the user for the issue worked? or let us know if you need any further assistance.
Thanks and regards,
Anjan Kumar Chippa
