Microsoft Fabric and Power BI engineering for MedTech, sized for the workload that actually dominates a device company platform.
Fabric capacity planning usually starts from users, reports and refresh schedules, which is the right model for an organization whose data arrives from business systems. A device company ingests continuously from a connected fleet, pulls high-frequency parameters from manufacturing historians, and both scale with units shipped and production volume rather than with headcount. The analytical workload is frequently the smaller half, and sizing that ignores this produces a capacity decision that holds for a year.
Quality reports a failure rate against devices in service. Commercial reports against units shipped. Service reports against units under contract. Finance reports against units invoiced. Each is calculated correctly from a defensible source, all four differ, and leadership meetings become reconciliation sessions. A reporting platform does not resolve this, because the disagreement is about definitions rather than about tooling, and installing better software over an unresolved semantic problem produces faster disagreement.
The second problem is specific to this industry: the platform has to absorb telemetry and manufacturing data at volumes the commercial systems never produce.
The same metric has four defensible definitions
Installed base, failure, active device and field action mean different things per function, all legitimately.
Fleet ingestion dominates the workload
Device telemetry and historian data exceed every business system, and both grow with the business rather than with users.
Manufacturing data crosses an IT and OT boundary
Pulling from historians is an industrial integration question before it is an analytics one.
Quality system data has different obligations
It can sit on the same platform and should not inherit the governance applied to commercial reporting.
Report sprawl outpaces governanceCannot Be Acted On Immediately
Self-service was the point, and without certification and ownership the estate becomes uncertifiable.
Capacity cost scales with the installed base
Which is the same axis the business grows on, so the platform bill grows with success rather than with adoption.
Two pieces of work determine whether a Fabric implementation succeeds in a device company, and neither is a Fabric question. The first is agreeing what the contested metrics mean. The second is sizing capacity against a workload dominated by ingestion rather than analysis. Both are cheaper before the platform than after it.
Step 1
Resolve the contested definitions first, since better tooling over an unresolved semantic problem produces faster disagreement.
Step 2
Model capacity against fleet and production growth rather than against users and reports.
Step 3
Decide which workloads belong on the platform, since unification is a commercial convenience rather than an obligation.
Â
Step 4
Separate contending workloads, so telemetry ingestion does not compete with interactive reporting on shared capacity.
Â
Step 5
Keep quality system data governed to its own obligations rather than to general platform standards.
Â
Step 6
Design the OT boundary deliberately, since historian access is an industrial integration decision.
Â
Step 7
Build the semantic layer as the product, because that is what determines whether the estate converges.
Â
Step 8
Establish workspace structure and certification before the estate grows past the point of correction.
Â
Step 9
Engineer performance on certified assets, since slowness is why people build their own extracts.
Â
Step 10
Start with one cross-functional question, such as reconciling manufacturing output against quality dispositions for a single product line, since that establishes the relationships everything else reuses.
Â
A platform migration does not resolve a definition disagreement.
Four functions reporting four installed base figures will continue to do so on new infrastructure, because each will build a model from the source they trust using the definition they defend. The semantic work is the actual deliverable and the platform is where it lives. Organizations that sequence the migration first and the definitions later arrive at a modern estate with the original problem intact and a harder conversation about who was wrong, because now it is visible side by side.
General Fabric and Power BI engineering is covered on our platform pages. These are the capabilities that matter where the workload is dominated by device and manufacturing data.
Size and Ingest
Capacity Modelling
Sizing against telemetry volume, production data and fleet growth rather than against user counts, with cost projected per device per year.
Fleet Telemetry Ingestion
High-volume device data landed efficiently, with late-arriving events, reconnection bursts and retention tiering handled deliberately.
Manufacturing and Historian Integration
Process data brought across the industrial boundary, read-only, covered on our manufacturing analytics page.
Workload Separation
Ingestion, engineering and interactive reporting isolated so one does not degrade another on shared capacity.
Model
Semantic Layer Engineering
Installed base, failure, active device and the other contested terms defined once, owned and certified, which is the actual deliverable.
Lakehouse and Warehouse Design
Storage and modelling organized around consumption and device identity rather than around source systems.
Device-Centric Data Modelling
The device as a timeline rather than a record, covered on our data platform page and required for every historical question.
Reporting and Dashboard Delivery
Power BI built on governed models, with performance engineered rather than discovered after adoption stalls.
Govern and Operate
Workspace and Lifecycle Design
Structure, ownership, promotion paths and deployment pipelines established before the estate grows.
Certification That Means Something
Attached to assets people actually use, since a certification mark on something the organization bypasses certifies nothing.
Access and Quality System Boundaries
Row and object level security, with quality system data governed separately from commercial reporting.
Capacity and Cost Operations
Monitoring consumption by workload, with cost attributable and tracked against installed base growth.
What CaliberFocus does, and does not do?
A unified platform needs workload-specific architecture based on data, latency, governance and cost. We size capacity for device ingestion, resolve semantic definitions before migration, and design around available features rather than announced roadmaps.
A single platform serves functions with genuinely different requirements for what counts as a reliable number. The third column is what each needs, and applying one standard across all of them over-engineers some and under-serves others.
| Audience | What they ask | What a reliable answer requires |
|---|---|---|
| Manufacturing | Yield, OEE, scrap, throughput, downtime | Harmonized definitions across sites, covered on our manufacturing page |
| Quality | Nonconformance trends, complaint rates, CAPA status | A defensible denominator and traceability to the controlled source |
| Regulatory | Submission support, commitments, field action populations | Traceability and reproducibility, since the number may be examined externally |
| Service and installed base | Fleet status, utilization, intervention volume | Device identity resolution and stated confidence, covered on our installed base page |
| Commercial | Territory, customer, product performance | Consistency and speed. The least demanding evidentially and the most used |
Enterprise analytics should connect business outcomes without erasing functional context. A quality metric, a financial measure and a production KPI may describe the same manufacturing event from different perspectives, all correctly, and every governed measure needs an owner, a definition, a calculation method, a population and a reporting period attached to it.
A MedTech Fabric implementation integrates sources with very different volumes and characteristics. The third column is the architectural implication, and the first two rows account for most of the engineering effort and most of the capacity.
| Source | Relative volume | What it implies architecturally |
|---|---|---|
| Device telemetry | Dominant, and growing with the fleet | Tiering, summarization, late arrival handling and retention policy |
| Manufacturing and historian | Large, and growing with production | Industrial boundary, time alignment and deliberate resolution reduction |
| Quality systems | Small, and the most consequential | Separate governance, controlled access and traceability to the source |
| ERP and supply chain | Moderate and transactional | Reconciliation to the system of record rather than a parallel truth |
| Service and field systems | Moderate, frequently semi-structured | Extraction and device association, covered on our document AI page |
| PLM and engineering | Small and slow changing | Revision applicability mapped to units actually built to it |
Reconnection bursts and executive reporting should not share capacity.
A regional connectivity outage ends and several thousand devices reconnect and upload simultaneously, which is the largest load event a device platform experiences. If that ingestion shares capacity with interactive reporting, the visible symptom is that dashboards became slow on a day nobody changed anything, and the diagnosis takes considerably longer than the incident. Separating the workloads costs capacity planning effort and removes a category of unexplained performance complaint that erodes confidence in the platform.
A device company needs commercial analysts exploring freely and a small set of reports supporting quality and regulatory activity under control. The failures are applying control discipline to everything, which stops the business, or to nothing, which creates exposure. The workable answer is a visible boundary: a defined set of assets under control, clearly marked, with everything else explicitly outside it.
Governance
- Workspace structure, naming and ownership established before the estate grows past the point of correction
- Certification attached to assets people actually use, since a mark on a bypassed asset certifies nothing
- Contested metric definitions owned by a named function and versioned, since a change restates history
- Decommissioning as routine activity, because an estate that only grows becomes unnavigable
Security and access
- Row and object level security designed against the organizational reality, including affiliates and partner access
- Quality system content governed to its own obligations rather than to general reporting standards
- Process parameters and manufacturing data treated as intellectual property, covered on our manufacturing page
- Patient-associated device data handled to the obligations your counsel defines
Compliance
- A defined boundary between controlled and exploratory assets, visible to users rather than documented centrally
- Engineering controls capable of supporting the frameworks that apply, which may include FDA regulation, ISO 13485 and electronic record expectations
- Applicability, interpretation and validation strategy determined by your quality and regulatory functions rather than by us
- Platform release cadence managed, since vendor updates reach controlled assets on somebody else schedule
Quality
- Refresh reliability monitored and surfaced to consumers rather than discovered when a number looks wrong
- Data freshness visible in the report, since a stale dashboard that loads successfully is the quiet failure
- Lineage from report to source maintained and navigable by a business user
- Usage monitored, because an unused certified asset and an over-used uncertified one are both findings
Every shadow dataset in an organization begins with somebody who needed an answer faster than the governed path delivered. When a certified report takes ninety seconds and a personal extract takes three, the governance model has lost regardless of policy, and the estate fragments one convenience at a time. Performance on certified assets is therefore a governance control rather than a user experience preference.
Capacity consumption by workload
Ingestion, engineering and reporting tracked separately, since one can quietly consume what another needs.
Certified asset performance
Against the local extracts built to avoid them, which is the comparison that predicts fragmentation.
Estate direction
 Reports and workspaces created against decommissioned, because an estate that only grows stops being usable.
Cost per device per year
The economic measure for a platform whose volume scales with the installed base rather than with users.
Refresh reliability and freshness
Per source, since a report blending live telemetry with a stale extract presents both as current.
Definition changes
Since a changed metric restates history across every report consuming it with no data event.
Platform programmes are usually reported as workloads migrated and reports delivered. The outcomes that matter here are whether the contested numbers converged and whether capacity costs what was modelled.
| Category | What we measure | Why it matters |
|---|---|---|
| Trace one KPI to the transaction | Whether you can name the contributing sources, the definition owner, confirm the calculation is consistent across departments, identify the underlying records, verify historical relationships are preserved, detect missing records, reconcile source counts, confirm access restrictions, reproduce the calculation and explain why two reports differ | If these cannot be answered consistently, the gap is engineering and semantics rather than tooling |
| Metric convergence | Whether functions now quote the same installed base and failure figures | The actual deliverable, and the platform is where it lives |
| Capacity against model | Consumption and cost against what was projected before commitment | Where device companies are surprised, because fleet growth drives it |
| Cost per device per year | Platform cost normalized to installed base | The economic measure for a workload that scales with the business |
| Certified asset performance | Load and refresh times against the extracts built to avoid them | The reason people leave the governed path |
| Workload isolation | Whether ingestion bursts affect interactive reporting | A category of unexplained slowness that erodes platform confidence |
We will model capacity against fleet and production growth rather than user counts, reconcile the contested metric definitions, review telemetry tiering and retention, assess whether ingestion and reporting workloads are isolated, and compare certified asset performance against the extracts people built instead.
Share the current challenge and we can scope a capacity and reporting assessment.
Security & Compliance
