Duplicate semantic models
Similar models and measures evolve independently, creating conflicting versions of business metrics.
Analytics & Business Intelligence Platform Consulting
Build and Operate a Governed Power BI Environment With Reliable Metrics, Secure Self-Service and Controlled Delivery
DataConsultant helps enterprises assess, architect, implement, migrate, govern, secure, optimise and operate Power BI across semantic models, reports, workspaces, gateways, deployment practices and the wider data platform.
✓Semantic-model architecture✓Governed self-service✓Migration & release control✓Performance & capacity✓Operational support
Data SourcesCloud databases
On-prem systems
Files & SaaS
Fabric / lakehouse
On-prem systems
Files & SaaS
Fabric / lakehouse
Access & TransformPower Query
Gateway patterns
Refresh paths
Source controls
Gateway patterns
Refresh paths
Source controls
Semantic ModelsRelationships
Measures / DAX
Security roles
Reusable metrics
Measures / DAX
Security roles
Reusable metrics
Workspaces & AppsDev / test / prod
Roles & ownership
Release controls
Distribution
Roles & ownership
Release controls
Distribution
ConsumptionReports
Paginated reports
Apps / Excel
Embedded analytics
Paginated reports
Apps / Excel
Embedded analytics
Microsoft Entra identityRLS / OLS & sharingMonitoring & auditCapacity & cost governance
Metric consistencyReusable semantic models and governed business definitions
Secure accessTenant, workspace, app and data-security controls
Controlled deliveryEnvironment separation, testing and deployment practices
Reliable operationsRefresh, gateway, incident and service ownership
Capacity disciplinePerformance, licensing and consumption decisions tied to workloads
Buyer trigger
Why Power BI Programmes Become Hard to Trust as Adoption Grows
Power BI can spread quickly because teams can create useful analytics without waiting for a central delivery programme. The same speed can create duplicated metrics, inconsistent access, fragile refresh paths and unclear ownership when the operating model does not mature with adoption.
Workspace sprawl
Ownership, purpose, lifecycle and access become unclear as team and personal workspaces accumulate.
Fragile refresh paths
Reports depend on gateways, credentials, source availability and refresh sequences that are not operated as a service.
Slow DirectQuery reports
Source latency, model design and high concurrency can turn apparently simple reports into an end-to-end performance problem.
Uncontrolled sharing
Workspace roles, app audiences, exports, external sharing and data permissions are not designed as one access model.
Manual releases
Business-critical changes move directly into production without reproducible testing, approvals or rollback preparation.
Capacity surprises
Refresh, model size, query concurrency and workload growth are not connected to capacity planning or cost ownership.
Orphaned content
Reports remain in use after creators move roles, source systems change or business definitions are superseded.
Current state → target state
Move From Report-by-Report Delivery to a Governed BI Product Model
The target is not central control of every visual. It is a repeatable architecture and operating model where teams can build quickly without recreating metrics, bypassing security or placing business-critical content outside controlled release and support.
Common current state
- Multiple copies of the same measures across PBIX files
- Production workspaces used as development environments
- Refresh dependencies known only to individual creators
- Direct sharing replaces planned app distribution
- Gateway, capacity and source issues investigated reactively
- Ownership disappears when report authors change roles
- Limited evidence of testing, approvals and change history
Target state with DataConsultant
- Reusable semantic models for shared business metrics
- Defined workspace patterns with lifecycle and ownership
- Documented gateway, refresh and source dependencies
- App audiences and access designed by business need
- Performance and capacity reviewed from telemetry
- RACI for business, data, BI, security and platform teams
- Tested release path with traceable promotion controls
Enterprise architecture role
Where Power BI Fits in a Modern Data and Analytics Architecture
Power BI is Microsoft’s business-intelligence and analytics experience for building semantic models, reports and governed consumption in the Power BI service, which is also integrated with Microsoft Fabric. It is strongest when reporting is connected to deliberate data-platform, semantic, identity and governance choices. DataConsultant designs the boundaries so business logic does not drift into hundreds of disconnected reports.
Business & operational sources
- ERP / CRM / finance
- Operational databases
- SaaS applications
- Files and APIs
Data integration & platform
- Warehouse / lakehouse
- ETL / ELT pipelines
- Data-quality controls
- Curated marts
Power BI semantic layer
- Star-schema modelling
- DAX measures and metrics
- Import / DirectQuery / Composite
- Direct Lake where Fabric fits
Power BI service
- Workspaces
- Reports / paginated reports
- Apps and distribution
- Deployment lifecycle
Business consumption
- Leaders and functions
- Self-service analysts
- Excel consumers
- Embedded applications
Identity & accessMetadata & lineageSecurity & privacyObservability & changeCapacity & FinOps
DataConsultant scope
What Our Power BI Consulting Service Covers Across the Platform Lifecycle
DataConsultant does not resell Power BI licences or present vendor features as consulting deliverables. The engagement focuses on the architecture, implementation, migration, governance, optimisation and operating work required to make Power BI sustainable in your environment.
Assess Your Power BI Estate Before Scaling It Further
Inventory workspaces, semantic models, reports, gateways, access paths and capacity dependencies before deciding what to standardise, migrate or retire.
Technical demonstration 01
Choose Power BI Connectivity and Semantic-Model Modes by Workload, Not Habit
Microsoft supports multiple connectivity patterns. The right choice affects freshness, source load, model flexibility, concurrency, refresh operations and capacity. The table below is a decision framework—not a substitute for workload testing.
| Pattern | How it behaves | Consider when | Architecture watch-outs | DataConsultant focus |
|---|---|---|---|---|
| Import | Data is loaded into the semantic model and queried in memory. | Interactive analytics Rich modelling and predictable query performance. | Refresh windows, model size, memory, freshness and source extraction. | Star schema, data reduction, refresh design, DAX and capacity fit. |
| DirectQuery | Queries are translated and sent to the underlying data source. | Source-resident data Freshness or data-location constraints make full import unsuitable. | Source latency, concurrency, query folding, network path and feature constraints. | Source tuning, model simplification, query diagnostics and load testing. |
| Composite | Combines Import and DirectQuery storage modes within one model. | Mixed workloads Some data benefits from caching while other data remains source-resident. | Relationship behaviour, cross-source performance and model complexity. | Partition and table strategy, aggregation design and validation. |
| Hybrid tables | Historical data can be imported while recent partitions use DirectQuery. | Fresh recent data Historical performance plus near-real-time recent facts. | Partition policy, incremental refresh requirements and capacity behaviour. | Refresh policy, hot/cold data design and performance testing. |
| Direct Lake | Power BI can read supported Fabric data in OneLake without a traditional import refresh. | Fabric data Lakehouse or warehouse architecture is already part of the target state. | Fabric capacity, supported model patterns and possible DirectQuery fallback behaviour. | Fabric/Power BI boundary, semantic design, security and capacity observability. |
| Live connection | Reports reuse an existing governed semantic model or supported Analysis Services model. | Central semantics Multiple reports should consume an authoritative model. | Model ownership, permissions, change impact and dependency management. | Shared-model operating model, certification, release and consumer governance. |
Microsoft documentation describes Import, DirectQuery and Composite semantic-model modes and a current decision guide covering Import, DirectQuery, Hybrid tables, Direct Lake and live connections. Licensing and feature availability should be revalidated for the client tenant during design.
Semantic architecture
Make the Semantic Model the Reusable Contract Between Data and Business Reporting
A mature Power BI design separates reusable business logic from individual report layouts. This reduces duplicated measures, makes security easier to reason about and allows multiple reports, Excel analyses and other consumers to build from governed semantic foundations.
Curated data inputs
Warehouse / lakehouseConformed business entities and history
Operational sourcesDirect access only where justified
Power Query transformationsShaping, parameterisation and query folding
Governed Power BI semantic model
Star-schema relationshipsFact and dimension structures designed for analytical behaviour
DAX measuresCentral definitions for revenue, margin, service, risk and other business metrics
Security rolesRLS/OLS patterns validated against actual consumer permissions
Measure ownershipDescriptionsFormat standardsRefresh policyLineage
Reusable consumption
Power BI reportsThin reports where shared models fit
Paginated reportingOperational and print-oriented outputs where needed
Apps / Excel / embeddedDifferent user experiences from governed semantics
Technical demonstration 02
Engineer a Power BI Release Lifecycle That Separates Build, Validation and Production
Microsoft Fabric deployment pipelines support configurable stages and commonly start with development, test and production. DataConsultant designs the surrounding controls—ownership, test evidence, environment binding, approvals, app updates and operational handover—rather than treating the pipeline button as the entire release process.
DevelopmentModel and report changes, source configuration, peer review, developer validation.
→
Test / UATData reconciliation, security-role testing, performance checks, stakeholder acceptance.
→
ProductionControlled promotion, app update, monitoring, rollback readiness and release evidence.
Workspace ownership & rolesEnvironment-specific connectionsApproval & acceptance evidencePost-release monitoring
Fabric deployment pipelines currently support two to ten stages; the default pattern is three stages. Availability and supported item behaviour should be checked against the tenant, capacity and current Microsoft documentation.
Replace Direct-to-Production Changes With a Repeatable Power BI Release Path
Define environment boundaries, test evidence, promotion controls, app updates and post-release support for reports and semantic models that matter to the business.
Integration architecture
Design Power BI Connectivity Around Source Location, Network Boundaries and Operational Ownership
Cloud BI does not remove source-system, credential or network dependencies. For on-premises data, Microsoft’s standard on-premises data gateway acts as a bridge and initiates outbound connections to Microsoft cloud services. Production design should also cover clustering, patching, service accounts, credentials and monitoring.
Enterprise data sources
Classify sources by network location, authentication, freshness, sensitivity and support ownership.
On-prem SQL / Oracle / files
Private network services
Cloud databases and SaaS
Fabric / OneLake data
Gateway & connection layerStandard gateway for shared enterprise connectivity where needed; outbound communication, credential boundaries, cluster resilience, updates and observability.
Power BI workloads
Map each semantic model and refresh to an accountable source and operational path.
Scheduled / incremental refresh
DirectQuery workloads
Semantic-model ownership
Failure and escalation routes
Migration & modernisation
Migrate to Power BI by Rebuilding the Information Product, Not Merely Recreating Screens
Legacy dashboards, spreadsheets, SSRS reports and other BI tools often contain embedded calculations, permissions and undocumented business logic. A safe migration identifies what should be retained, consolidated, redesigned or retired before production cutover.
01DiscoverInventory reports, users, owners, sources, schedules and dependencies.
02RationaliseIdentify duplicates, obsolete content and consolidation opportunities.
03MapTrace calculations, filters, security, subscriptions and report behaviour.
04ModelBuild reusable semantic models and governed measures rather than report-local logic.
05RebuildDevelop reports, apps, gateway paths and workspace placement.
06ValidateReconcile metrics, security, performance and user acceptance in parallel where required.
07Cut overPublish, communicate, monitor, retire old assets and preserve audit evidence.
Governance, security & ownership
Control Power BI at the Tenant, Workspace, Distribution and Data Layers
Power BI security cannot be reduced to row-level security. Tenant settings, Microsoft Entra identities, workspace roles, app audiences, semantic-model permissions, RLS/OLS, source security, export/sharing controls and operational ownership all affect the effective access model.
Power BI control architecture
Identity & administrationMicrosoft Entra identities, privileged admin roles, group-based access and admin accountability.
Tenant settingsFeature enablement and policy-aligned configuration by controlled user groups; not treated as a substitute for data permissions.
Workspace rolesAdmin, Member, Contributor and Viewer responsibilities aligned to least privilege and delivery roles.
DistributionApps, audiences, Build permission, sharing and external-consumer patterns defined intentionally.
Semantic-model securityRLS and OLS designed and tested for the actual consumer and connection scenarios.
Information protectionClassification and sensitivity-label integration considered where Microsoft Purview is in scope.
Export & external sharingTenant configuration, business need and residual data permissions reviewed together.
Audit & monitoringUsage, admin activity, access changes and exceptions captured for operational and control review.
Microsoft notes that tenant settings can help establish governance policies but are not, by themselves, a security measure. Effective control requires coordinated permissions and data-security design.
Design Power BI Self-Service and Security Guardrails Together
Define who can create, publish, share, export, administer and consume content—and which semantic models and controls provide the trusted path for business reporting.
Performance & scalability
Tune Power BI End to End: Source, Semantic Model, DAX, Report and Capacity
A slow report is rarely explained by one visual alone. DataConsultant traces the query path and workload pattern so remediation addresses the actual bottleneck rather than shifting load to another layer.
1. Source & refresh
- Query folding and source indexes
- Extraction windows and incremental refresh
- Gateway throughput and network path
- DirectQuery source concurrency
→
2. Semantic model & DAX
- Star schema and relationship design
- Model cardinality and unnecessary columns
- Measure logic and query plans
- Storage mode and aggregation choices
→
3. Report & capacity
- Visual count and interactions
- Concurrent usage patterns
- Refresh and interactive workload overlap
- Capacity telemetry and operating thresholds
Commercial & FinOps considerations
Separate Microsoft Licensing and Capacity Cost From DataConsultant Professional-Service Fees
Power BI architecture and commercial design are connected. User licensing, capacity, sharing patterns and Fabric adoption influence both technical options and operating cost, so commercial assumptions should be validated before architecture decisions are locked.
Microsoft platform cost model
Current Microsoft licensing includes Fabric Free, Power BI Pro and Premium Per User, with Fabric capacity SKUs for organisational capacity. Exact entitlement, sharing rules and prices depend on the tenant, region, agreement and current Microsoft terms.
- Per-user licensing: validate author, collaborator and consumer needs rather than licensing every persona identically.
- Capacity: size against model memory, refresh, concurrency and Fabric workloads, not just total user count.
- External / embedded use: validate the intended distribution and identity architecture before estimating licence requirements.
- Legacy Premium capacity: review transition requirements as Microsoft moves customers toward Fabric capacity licensing.
Reliability & operations
Operate Power BI as a Business Service, Not a Collection of Published Files
Business-critical BI needs service ownership, monitoring, incident response, controlled change and regular rationalisation. The operational boundary should include the dependencies that can actually cause reporting failure.
Stabilise and Operate Business-Critical Power BI With Clear Ownership
Connect monitoring, incident handling, gateway and refresh operations, controlled change, semantic-model maintenance and improvement into one service model.
Workload decision guidance
Prioritise Power BI Workloads by Business Criticality, Freshness, Consumer Scale and Control Need
The illustrative matrix below shows the questions DataConsultant uses to shape architecture and sequencing. It is not a claim about your organisation; actual ratings are established during discovery.
| Illustrative workload | Criticality | Freshness | Consumer scale | Architecture emphasis | Typical governance question |
|---|---|---|---|---|---|
| Executive KPI reporting | High | Daily / intra-day | Focused | Authoritative semantic model, reconciled measures, controlled release | Who owns each metric and approves definition changes? |
| Finance & management reporting | High | Period / daily | Broad | Security, reconciliation, repeatability, lineage and export controls | What evidence supports reported numbers and access? |
| Sales & operational dashboards | Medium–High | Near real-time / daily | Broad | Freshness, DirectQuery/Import trade-offs, mobile usability, scale | What latency is actually required for decisions? |
| Self-service departmental BI | Variable | Variable | Distributed | Shared semantic models, workspace standards and creator guardrails | Which data and measures are certified for reuse? |
| Regulatory / risk reporting | High | Defined cycle | Controlled | Access, lineage, reproducibility, retention and change evidence | What controls and records are required outside Power BI? |
| Embedded analytics | Product-led | Use-case specific | Potentially large | Identity, embedding pattern, capacity, API lifecycle and support | Who is the effective user and where is data security enforced? |
Platform fit & boundaries
When Power BI Is a Strong Fit—and When Another Platform Layer Should Carry the Workload
Power BI is an analytics and consumption platform, not a replacement for transactional applications, enterprise data engineering or every real-time operational workload. The architecture should place each responsibility in the layer best suited to it.
Power BI is typically well suited when you need
- Interactive business reporting and governed analytics for defined user groups.
- Reusable semantic models and centrally managed DAX measures for shared KPIs.
- Self-service report creation within controlled workspaces and approved data foundations.
- Integration with Microsoft identity, Fabric and common enterprise data sources.
- Apps, reports, paginated reporting, Excel consumption or embedded analytics from governed models.
- A managed BI operating model with refresh, release, usage and capacity oversight.
Architecture needs broader evaluation when
- The core requirement is transactional processing, data capture or operational workflow rather than analytics.
- Raw-data engineering, large-scale transformation or storage is being pushed into the BI layer instead of the data platform.
- Ultra-low-latency event monitoring needs a specialist real-time architecture before analytical consumption.
- Portability, non-Microsoft strategic standards, regulatory constraints or existing investments materially change the platform decision.
- Source performance cannot support DirectQuery behaviour and import or aggregation options do not meet freshness needs.
- The organisation lacks ownership, data quality or metric governance needed to make any BI platform trustworthy.
DataConsultant can assess coexistence or alternative platform patterns where Power BI should consume from, rather than replace, another enterprise capability.
Transformation roadmap
A Phased Path From Power BI Discovery to Stable Production Operations
The sequence is tailored to the estate. A focused assessment may stop after recommendations; a full implementation can continue through build, migration, release and operational handover.
1DiscoverObjectives, business-critical reporting, stakeholders, constraints and current pain points.Output: scope & evidence plan
2AssessTenant, workspaces, models, reports, gateways, access, capacity, risks and technical debt.Output: findings & priorities
3ArchitectTarget semantic, workspace, connectivity, security, deployment and operating model.Output: target blueprint
4BuildModels, measures, reports, gateways, workspace controls and automation.Output: working solution
5MigrateRationalise assets, rebuild, reconcile, map users and prepare cutover.Output: migrated portfolio
6Validate & deploySecurity, data, performance, UAT, release evidence and production promotion.Output: accepted release
7Operate & improveMonitor, support, optimise, rationalise, govern change and transfer knowledge.Output: runbook & service model
Tangible outputs
Power BI Deliverables That Support Architecture, Delivery, Governance and Operations
Deliverables are selected according to engagement scope. A short health check will not produce the same artefacts as a platform implementation or migration programme.
Current-state assessment
Estate inventory, findings, risk, technical debt, evidence gaps and prioritised remediation.
Target Power BI architecture
Source, semantic, workspace, distribution, security, environment and dependency design.
Workspace & tenant blueprint
Naming, ownership, roles, lifecycle, app audiences and configuration decision register.
Semantic-model standards
Modelling, measures, descriptions, security, refresh, reuse and quality expectations.
Migration plan & mapping
Asset disposition, dependencies, rebuild approach, reconciliation, cutover and decommissioning.
Security & governance model
Decision rights, tenant controls, roles, RLS/OLS patterns, sharing and exception handling.
Release & testing runbook
Dev/test/prod path, promotion controls, testing, approvals, rollback and app-update steps.
Operations & optimisation backlog
Monitoring, support ownership, performance, capacity, rationalisation and improvement actions.
Client prerequisites
What DataConsultant Needs to Assess or Implement Power BI Reliably
Missing evidence does not automatically stop an engagement, but it should be recorded as a limitation. Access should follow client approval and least-privilege principles.
Start with the information that proves how Power BI actually works today.
A useful discovery pack connects business-critical reports to their owners, semantic models, data sources, gateway paths, security groups, licensing and operational history.
Do not send credentials or highly sensitive data in the initial enquiry. Access, secure transfer and evidence handling should be agreed during mobilisation.
Engagement & scope
Choose a Power BI Engagement Model Around the Decision or Delivery Outcome You Need
Scope can be narrow or end-to-end. DataConsultant defines the responsibility boundary before work begins so the buyer can distinguish advisory, implementation, migration, enablement and managed-operation effort.
Consulting partner role
Power BI Support That Connects Reporting to Data Architecture, Governance and Operations
DataConsultant positions Power BI as part of the enterprise data and analytics capability—not as an isolated dashboard tool. We can work alongside internal teams, Microsoft specialists, systems integrators and other vendors without implying reseller or certified-partner status.
For team enablement, DataConsultant also provides Power BI training as a separate capability where learning and adoption are in scope.
Frequently asked questions
Power BI Consulting, Architecture, Migration and Operations FAQs
Answers to common enterprise questions about platform fit, semantic models, security, deployment, licensing, migration, scope and ongoing support.
What Power BI services can DataConsultant provide?
DataConsultant can scope Power BI assessment, architecture, implementation, workspace and tenant design, semantic-model engineering, report and app delivery, gateway integration, migration, security, governance, deployment controls, performance and capacity optimisation, adoption support and managed BI operations. Final responsibilities are agreed during discovery.
Can DataConsultant assess an existing Power BI environment before we expand it?
Yes. A focused assessment can review tenant and workspace structure, semantic models, reports, gateways, refresh dependencies, access patterns, deployment practices, performance, capacity, licensing assumptions, governance, ownership and operational risks. Findings should be evidence-based and prioritised for remediation or modernisation.
How do you decide between Import, DirectQuery, Composite and Direct Lake?
The choice depends on data volume, freshness, source performance, transformation needs, concurrency, Fabric architecture, security and operational constraints. Import, DirectQuery and Composite are established Power BI semantic-model modes; Direct Lake is relevant when data is held in supported Microsoft Fabric storage. The final pattern should be validated against the workload rather than selected by default.
Can Power BI use on-premises data securely?
Yes. Microsoft provides the on-premises data gateway as a bridge between local data sources and cloud services including Power BI and Fabric. The standard gateway initiates outbound connections and does not require inbound ports. Gateway topology, clustering, service accounts, patching, source permissions and monitoring should be designed as part of the production architecture.
Can you migrate reports from Excel, SSRS, Tableau, Qlik or another BI platform to Power BI?
Migration can be assessed and delivered, but it should not be treated as a mechanical file conversion. Data sources, calculations, security, report behaviour, user journeys, refresh dependencies, business definitions and acceptance criteria need to be mapped. Some assets can be retired, consolidated or redesigned instead of recreated one-for-one.
How do you govern self-service Power BI without slowing business teams down?
A practical model combines tenant settings, workspace standards, reusable governed semantic models, clear ownership, access roles, app distribution, certification or endorsement processes where appropriate, data-security controls, deployment standards, monitoring and support. Guardrails should be proportionate to data sensitivity and business criticality.
Does row-level security protect every Power BI user?
No. Row-level security is designed to restrict report consumers based on semantic-model roles and has important role and connection-mode considerations. Workspace permissions, source security, object-level security, sharing controls and tenant settings must be designed together. Security testing should cover the actual personas and access paths used in production.
Can you establish development, test and production release controls for Power BI?
Yes. A release model can separate development, test and production workspaces, define promotion and approval controls, incorporate Microsoft Fabric deployment pipelines where suitable, and add source control or automation where supported. Microsoft deployment pipelines can be configured with two to ten stages; the most appropriate lifecycle depends on the estate and licensing.
How do Power BI licensing and Fabric capacity affect the architecture?
Licensing and capacity affect authoring, sharing, audience access, workload features and operating cost. Microsoft currently provides Fabric Free, Power BI Pro and Premium Per User licensing alongside Fabric capacity SKUs. Licensing rules and prices can change, so the target design should be checked against current Microsoft terms and the organisation’s actual tenant and procurement model.
How is DataConsultant Power BI pricing calculated?
DataConsultant does not publish a fixed professional-services fee for this Power BI engagement. Pricing is scope-led and depends on estate size, semantic-model and report complexity, data sources, gateway requirements, migration volume, security and governance depth, deployment automation, environments, stakeholder participation, documentation, training and ongoing support. Microsoft licensing and capacity charges are separate vendor costs.
What information should we prepare for a Power BI assessment or implementation?
Useful inputs include tenant and workspace inventories, critical reports and PBIX files where available, semantic-model details, source and gateway inventory, refresh schedules, user and security groups, licensing and capacity information, business metric definitions, architecture diagrams, incident history, performance evidence, governance policies and access to platform and business owners.
Can DataConsultant continue supporting Power BI after go-live?
Yes. Follow-on support can be scoped through managed BI operations, optimisation, controlled enhancement, semantic-model maintenance, refresh and gateway monitoring, incident handling, release management, usage review, rationalisation, documentation and capability transfer. The service boundary and responsibilities should be documented before transition.
Power BI Enquiry
Request a Power BI Scope Review
Share your contact details and requirement. DataConsultant can review the likely workstream, evidence needed, stakeholder involvement and next step.