ISV: a multi-tenant analytics platform as a subscription product

A data and AI consultancy growing toward an ISV model had until then delivered separate dashboards per customer. Customers wanted to move to a subscription on predictive analytics, demand forecasting per store and SKU, churn scoring, inventory anomaly detection, plus enrichment of unstructured data such as reviews and tickets. The existing gold layer held only historical aggregates, no real models, and was not built for repeatable rollout per customer.

A shared multi-tenant platform on Fabric where tenant isolation sits below the model layer: a dedicated workspace and lakehouse per customer, or where that is not feasible, OneLake Security down to table and row level. Real ML models run on the gold layer through Spark notebooks with MLflow for model registration; AI Functions classifies reviews and tickets as an extra signal. Shared model definitions are managed through a service principal and rolled out per customer, so consultants do not start from scratch for every new client.

The business model required repeatability: every new customer has to come online faster than the last, or the subscription does not scale. Isolating below the model layer instead of relying on report-level RLS alone was a deliberate choice, model-RLS is a filter within a shared model, not a data wall, and for an external platform serving multiple customers that distinction was non-negotiable. Open Delta tables also prevent lock-in toward one customer-specific stack.

Standing up a fully separate Azure environment per customer gave the strongest isolation, but made the product more expensive than the target market (mid-market) could bear, and raised operational overhead linearly per customer. Putting everything in one shared model with only report-level RLS was cheaper, but a data leak from customer A to customer B would have made the product unsellable.

• Shared capacity with per-tenant CU monitoring is needed to prevent one heavy customer from degrading the experience of others.
• The line between "in Fabric" and "in Azure Machine Learning" had to be drawn deliberately based on MLOps maturity per use case, not by defaulting everything to the same platform.
• Hard tenant separation costs more to manage than one large shared model, but is the precondition for a sellable product.

Microsoft Fabric (workspaces, Lakehouse, OneLake Security), Data Science with MLflow, AI Functions, Copilot in Fabric for consultants, Git integration and Deployment Pipelines.

• Isolate tenants below the model layer by default, not as an exception for "important" customers.
• Manage shared model definitions centrally through a service principal, so a model update does not have to be repeated by hand per customer.
• Separate ML promotion (MLflow registry) from BI promotion (Deployment Pipelines) from the first customer onward, not once it starts hurting at the tenth.

The biggest speed-up in onboarding did not come from automating the technology, but from documenting one reusable tenant blueprint (workspace structure, security roles, model definitions) that only needed configuring per customer from then on. A pitfall the team caught late: without per-tenant CU monitoring, nobody noticed one customer's heavy batch job was structurally eating capacity from the other customers, until those other customers started complaining about slow dashboards.