Machine Learning & MLOps Financial Services (Enablement)

07ML on Microsoft Fabric — FSI Positioning Built From Working Demos, Not Slideware

Live prototypes settled Fabric-vs-Databricks positioning for FSI — measured, not assumed

Role: Pre-Sales Solution Engineer

Executive summary

Created demos and prototypes proving end-to-end PyTorch ML workflows on Microsoft Fabric, clarifying Fabric vs Databricks positioning for FSI clients evaluating Fabric as an ML platform.

  • Microsoft Fabric
  • Fabric Data Science
  • Spark notebooks
  • AutoML
  • PyTorch
  • MLflow
  • Azure Databricks
SSituation

As Fabric introduced integrated Data Science, many Financial Services clients asked how it works as an ML platform. For pre-sales enablement, I built prototypes and demos showcasing PyTorch ML workflows on Fabric versus Azure ML and Databricks.

TTasks
  • Create sample Data Science experiments in Fabric (e.g., training a small PyTorch model in Fabric notebooks on Spark).
  • Show experiment tracking with MLflow in the Fabric UI.
  • Highlight ease of use: Fabric Warehouse as source, Spark training, model saved in OneLake.
  • Compare performance and features with Databricks to articulate enterprise readiness.
AActions

I built demos importing data into a Fabric Lakehouse, doing feature engineering in a Data Engineering notebook, then training PyTorch models in Fabric's Data Science experience—e.g., a credit-risk classifier built entirely in Fabric. I measured training time, consulted product contacts on platform nuances, and prepared comparisons (Fabric's Spark engine vs Databricks Photon, cost differences). I chose to demo on real client-shaped datasets rather than toy data, so the comparisons carried weight in front of engineers—not just executives. For real engagements, I tailored demos to client data and use cases as quick pilots.

RResults

The demos showed Fabric handling typical ML workloads—in one pilot, a model trained on Fabric matched the accuracy of the client's existing Databricks process for a small model, measured on the same data. They clarified Fabric vs Databricks positioning: Fabric for integrated analytics in a unified environment, Databricks for mature MLOps—supporting a "better together" story that specifically de-risked Fabric adoption for FSI clients whose engineers were writing it off as "not for ML yet". The prototypes strengthened competitive messaging and my ability to advise clients.

LLessons Learned

As an early explorer of Fabric's ML capabilities, I learned to navigate new-platform quirks before presenting them as answers. The credibility came from measuring rather than assuming—training times, integration ease—because the clients I was addressing could smell an untested platform claim instantly. Being tool-agnostic yet deep in both Databricks and Fabric let me propose optimal solutions.

Solution overview: ML on Microsoft Fabric — FSI Positioning Built From Working Demos, Not Slideware ML on Microsoft Fabric — FSI Positioning Built From Working Demos, Not Slideware — flow: Data then Engineer then Train then Store & compare. DATA Fabric Lakehouse ENGINEER Data Engineering notebook (Spark) TRAIN PyTorch in Fabric Data Science MLflow tracking STORE & COMPARE Model in OneLake Benchmark vs Databricks Positioning: Fabric (integrated analytics) + Databricks (mature MLOps)
Solution overview — ML on Microsoft Fabric — FSI Positioning Built From Working Demos, Not Slideware (illustrative; replace with your own diagram anytime)