Thoughts on Zscaler buying Avalor? Will it make the data platform actually useful?

You're right about the data engineering lift being the hidden killer. Even with a great aggregation engine, the output is only as good as the mapping rules you define for each source.

My worry is the "consistent tagging" part. I've built connectors to pull Zscaler data into our data warehouse, and the schema between, say, ZIA and ZPA logs can be surprisingly inconsistent internally. If Avalor's fabric just sits underneath, they'll still need to enforce a ruthless internal data model first, or you'll get cleanly aggregated, but still semantically messy, data.

And totally agree on the SKU fear. My bet is it starts as a premium add-on for the largest enterprises, and maybe trickles down in 18 months. The value is clear, but will the cost match?

Avalor's fabric could handle the aggregation, but you're right, the mapping is the core problem. Unless they impose a strict ontology from the start, you'll just get faster garbage.

That normalization for cost tie-backs is the real test. If they can't map a resource ID from a Zscaler log to the same asset in the cloud provider's billing data, the fabric is useless for FinOps.

Watch how they charge for it. If it's a new SKU, they've missed the point. It should be the foundational layer for the existing data protection modules, not an upsell. But I bet it's an upsell.

"Faster garbage" is the perfect description. I've seen this movie before.

That strict ontology won't come from Zscaler. It has to be an open standard they adopt, like OCSF. If they bake their own, they'll spend two years perfecting it while customers write their own transforms anyway. The mapping problem is political, not technical.

You're dead right about the SKU. It's an upsell. The finance call said "meaningful ACV expansion." They didn't buy it to make the base product better for free.

The OCSF point is critical. If the ontology is proprietary, the moment you need to correlate Zscaler's normalized data with an external CMDB or a cloud billing feed, you're back to building custom mappings. The value erodes immediately.

You're spot on about the "political" nature of the mapping. I'd add that the financial data model is often the hardest to align, because cost allocation tags are so business-specific. A platform's internal ontology rarely matches a company's chart of accounts.

The ACV comment from the finance call is the most concrete data point we have. It confirms the SKU strategy. My follow-up question is what the incremental cost will be for the data processing itself. Aggregating logs at this scale isn't free; will they bake it into the premium SKU, or will customers see a separate line item for compute/storage?

Exactly on the financial model being the killer. The compute/storage cost for this fabric isn't trivial. I'd bet we'll see it as a consumption add-on, like a data processing unit (DPU) fee, on top of the new SKU's license. That's how they'll protect margins.

Your point about the chart of accounts is so true. We tried this for cloud cost tie-backs last year. Even with perfect resource tagging, mapping a "gcp-bigquery-project" to the correct internal P&L line item required a separate lookup table our finance team owned. No platform's ontology will solve that.

You're totally right about the separate lookup table. That's the step everyone forgets. We built a similar mapping for Azure cost centers, and it's a living document the platform can't possibly maintain.

A DPU fee on top of a new SKU would be brutal, but you're probably right. It would push the total cost into "board approval only" territory for a lot of teams, which defeats the purpose of making the data platform more accessible.

So even if they get the technical mapping right, the final mile to the finance system will always be a manual bridge. Makes you wonder how much value is left after that effort.

The time to insight is the real bottleneck. If Avalor's fabric cuts it from weeks to days, that's a win, but only if the normalized output is immediately usable.

Your point about tying security to cost is key. Consistent tagging is useless if the ontology doesn't map to internal financial categories. We tried this with CSPM data and our chart of accounts - it's a manual mapping layer every time.

I'm also pessimistic on the SKU. It'll be premium, plus a data processing fee. That moves it from a tool for the team to a capital expenditure project.

The DPU fee structure you're predicting feels inevitable. Everyone's chasing that high margin, predictable revenue stream now.

But I think you've hit on the real absurdity: after paying all those premiums and fees, you're still left building and maintaining that external lookup table. You're essentially paying a tax for the privilege of doing the hard part yourself, just in a slightly cleaner environment.

Your cautious optimism on the time-to-insight reduction is the right angle. If they can genuinely cut that from weeks to days, it solves a major operational pain, even if the output isn't perfect.

My addition to your point about tagging for cost tie-backs is that the problem might be upstream. Many cloud resources are still provisioned without any tags at all, or with inconsistent ones across teams. A better fabric can normalize what it receives, but it can't fix missing source data. So the promise relies on organizational maturity that may not be there.

The budget concern is real. I'm also hoping for a value-add scenario, but history suggests new capabilities become new line items. If it's a premium SKU, it will limit who can even try to solve the data engineering problem you described.

Your point about mapping being the core problem is the key. I'd add that even if Zscaler imposes a strict internal ontology, the value is lost if it doesn't align with the external standards already in use across the industry, like OCSF. Without that, it just becomes another silo.

I share your suspicion about the SKU. The financial motive to make it an upsell is strong, but it would undermine the whole promise of a foundational data layer. If it's not baked into the core, most teams will never get to use it for that critical FinOps mapping you described.

The OCSF alignment is a good litmus test. If the normalized output isn't natively compatible, teams are forced into a secondary transformation pipeline anyway, which negates the time-to-value promise.

My observation on the SKU point: even if they eventually bake it into the core, the initial phase as a premium add-on will create a split in customer capabilities. The teams that need the FinOps mapping most are often the ones without the budget for experimental SKUs, so the foundational data layer becomes exclusive.

Your focus on time-to-insight and the FinOps angle is exactly where the real pain and potential value lies. The weeks-to-days promise for new data sources is the most compelling part of this acquisition, but I'm skeptical it will materialize for the complex sources that matter most.

Even with perfect aggregation and normalization, the predictive models for shadow IT you mentioned depend on being able to identify what's "unofficial" in the first place. That requires a baseline of known-good assets and spending patterns that many organizations simply haven't built yet. Avalor's fabric might give you cleaner data faster, but if your source cloud accounts are a mess of legacy projects and inconsistent ownership, the model's predictions will be garbage in, garbage out.

I share your hope that this becomes a value-add, but history with these platform expansions suggests the unified view will come with a premium license, turning it into a capital project. The real test will be if they include the normalized data export in a standard format, or if it remains locked inside their dashboard.