Microsoft Fabric doesnt have real EPM Planning capability

Here’s a practitioner-level EPM critique of Microsoft’s Fabric + Lumel, grounded in both the actual capabilities announced and Microsoft’s historical track record in planning.

What Microsoft + Lumel actually announced (stripped of marketing)

At its core, this is not Microsoft building a planning product it’s:

Microsoft Fabric + Lumel (ISV) = embedded planning on top of Power BI semantic models

Key elements:

• Planning inside Fabric (Fabric IQ workload)

• Runs directly on Power BI semantic models + OneLake (zero-copy)

• Writeback into Fabric SQL / OneLake

• No-code / Excel-like UX for business users

• Consumption-based pricing (Fabric capacity)

In EPM terms, this is:

• A planning layer embedded into a BI/data platform

• Architecturally similar to:

  • Power BI + writeback tools (Acterys, Inforiver, etc.)

  • Not equivalent to a full-stack planning engine

Who would want this?

Microsoft is addressing a gap in that Planning could sit on the same data model as reporting, not in a separate cube/platform.

Combine that with leveraging the huge existing Power BI install base with a Low barrier to entry (pricing + UX) then maybe small to medium sized companies might yet again take a risk that they hope its “good enough planning”.

But history matters: Microsoft’s repeated failure in planning

OutlookSoft (acquired 2007 → became PerformancePoint)

• Intended as Microsoft’s enterprise planning platform

• Failed due to:

  • Weak modelling vs Hyperion/Cognos

  • Poor scalability

  • Lack of ongoing investment

• Eventually killed

PerformancePoint → Excel + SharePoint era

• Shifted to “Excel as planning UI”

• Result:

  • No true planning engine

  • Fragmented governance

  • Shadow IT explosion

Acterys-style ecosystem (Power BI writeback vendors)

• Microsoft never built native planning

• Relied on ISVs to fill the gap

• Result:

  • Inconsistent capabilities

  • No standard modelling layer

  • Weak enterprise credibility

  • Acterys ended up selling themselves to another vendor

Pattern (important insight):

Microsoft consistently:

Underinvests in planning as a first-class application layer

Instead they:

• Build platform primitives

• Hope partners solve the “last mile”

• Lumel is just the latest iteration of this pattern.

Structural limitations of the Fabric + Lumel approach

Even if Lumel is strong, the architecture has inherent constraints:

No native planning engine (this is the big one)

True EPM solutions are:

• Built on purpose-built in-memory calculation engines

• Designed for:

  • multi-dimensional modelling

  • sparsity handling

  • real-time recalculation

Fabric + Lumel:

• Built on Power BI semantic model + SQL + data platform

That’s fundamentally:

• Analytical first

• Planning second

Modelling limitations

EPM reality:

• Planning = calculation graph + dependency management + versioning

Fabric stack:

• Semantic models ≠ planning models

Implications:

• Complex driver-based planning becomes:

  • harder to maintain

  • more brittle

  • less transparent

Scalability of planning logic

Fabric scales data well.

But planning pain is: recalculation complexity, not data volume

Purpose-built platforms:

• optimized for:

  • cascading calculations

  • scenario explosion

  • version management

Fabric:

• optimized for:

  • querying large datasets

These are different problems.

Vendor ownership risk (critical)

This is subtle but important:

• Lumel = ISV

• Planning = not owned by Microsoft core product

So:

• roadmap risk

• dependency risk

• potential fragmentation (again)

History suggests:
Microsoft may never fully own this layer, so you have different owners to what you think is one problem.

Why companies will choose a leader in EPM and NOT Fabric/Lumel

Purpose-built planning engines

• Designed from day 1 for planning

• Capabilities:

  • driver-based modelling

  • dimensional flexibility

  • real-time recalculation

Enterprise modelling discipline

They provide:

• structured modelling paradigms

• dependency graphs

• governed model lifecycle

Fabric + Lumel:

• closer to:

  • “build-your-own planning app”

Great for flexibility, risky for scale.

Cross-functional planning (beyond finance)

Dedicated EPM platforms can extend to:

• workforce planning

• supply chain

• sales planning

• integrated business planning (IBP)

Fabric + Lumel:

• limited to:

  • simple financial planning

Scenario planning at scale

Modern planning is:

• many scenarios

• rapid iteration

• AI-assisted forecasting

Purpose-built platforms:

• handle this natively

Fabric approach:

• depends on:

  • underlying data model

  • compute orchestration

So high dependency on IT and data engineering required.

Bottom-line EPM expert view

What Microsoft offers:

• An architectural vision (unified data + planning)

• Leveraging Fabric as the backbone

• Partnering instead of building from scratch

What remains unresolved:

• No native planning engine

• Continued reliance on ISVs

• Risk of repeating the “almost but not quite EPM” pattern