The hardest part of modernizing enterprise BI is NOT the dashboard

For my team, a whole lotta enterprise BI modernization discussions start with the visualization layer, mostly around: 

Which dashboard should be rebuilt?
Should the reports use Direct Lake?
Should the organization move to a Lakehouse?
How should Power BI capacity be configured?

Those are important questions, but there is another one that tends to surface later:

Where should the business logic live?

In a multi-source environment, the same KPI can be derived from SAP, operational systems, spreadsheets, or application databases. If each report implements the calculation independently, moving the data into a modern platform doesn't automatically create consistent reporting.

A more maintainable pattern is to separate the responsibilities:

Ingestion: bring source data into the platform with appropriate batch or event-based patterns.

Transformation: clean, conform, and standardize data before it reaches reporting.

Business layer: define reusable measures and business rules in the semantic model.

Security: apply access rules at the appropriate data or semantic layer rather than duplicating them across individual reports.

Visualization: keep reports focused on analysis and user experience rather than embedding large amounts of transformation logic.

Microsoft Fabric, in that same environment, makes it feasible to bring several of these capabilities into one unified platform, but the architecture still needs clear boundaries between them.

I have found this distinction especially important when upgrading reporting environments that have accumulated years of spreadsheet logic and report-specific calculations.

For those working on enterprise BI modernization, where do you draw the line between data transformation logic and semantic-model/business logic?

And what has worked best for keeping KPI definitions consistent across multiple Power BI reports?