SkySpark

SkySpark is the platform that much of the building analytics industry is actually built on, and understanding its commercial model is more important than understanding its feature list. SkyFoundry describes it as analytics software that collects data from smart and connected systems, stores and organises it, and surfaces issues. The Axon analytic engine applies rules to find faults, deviations and trends, and the Spark App shows the timing, duration, frequency and cost of each issue. There are more than five hundred built in analytic functions, and custom rules can be written through the Rule App. Alongside the fault detection work there is an Energy App covering electrical demand, consumption and cost as well as water and gas usage, plus KPI, Historian, Weather and Rule apps and a View Builder for custom views, all running in a standard browser. Open published application programming interfaces and a native Project Haystack REST API are provided.

Deployment flexibility is a genuine differentiator: SkySpark runs on premises, in the cloud, at the edge or as a desktop tool. Almost nothing else in this category offers that range, and for critical infrastructure, air gapped sites or organisations with data residency constraints it is often the deciding factor. The edge option matters for sites with poor connectivity.

How SkySpark is sold, honestly stated. SkyFoundry does not sell direct to end users as a software as a service subscription. It sells through a worldwide network of partners it describes as value added resellers, value added distributors and original equipment manufacturers, citing more than one hundred and forty partners worldwide and a partner directory. Value added resellers provide the software plus implementation services and project related training and support. Value added distributors add channel support, engineering services and training. Original equipment manufacturers embed SkySpark in their own hardware, software or SaaS products, under a separate OEM programme. SkyFoundry publishes no prices and no licence terms on its purchase pages. The practical consequence for a buyer is that your experience of SkySpark is largely your integrator experience: the rules library that is actually deployed, the point mapping quality, the dashboards you get and the ongoing support all come from the partner, not from SkyFoundry. Two SkySpark deployments can differ enormously. This is a different purchasing risk profile from a SaaS product, and it should be priced and governed accordingly, with the partner selection treated as the primary decision.

What SkySpark is not. It is not a utility bill management system: the Energy App handles consumption and cost from data, not supplier invoice capture and validation. It is not an ESG or carbon disclosure suite; no emissions accounting or framework reporting is described. It is not a building controls platform, it analyses rather than commands. And it is not a turnkey product: it is a platform and a toolkit, which is precisely why it is sold with implementation services. Buyers expecting to subscribe and log in to a finished application have misunderstood what they are buying.

SkySpark suits organisations with large, complex, well instrumented estates and either an in house analytics capability or a trusted integrator relationship: universities, hospital systems, airports, government estates, large corporate campuses, data centres and industrial sites. It is the right answer when the requirement is deep, customisable fault detection across heterogeneous building systems and when off the shelf rule sets will not be sufficient. It is also the right answer when deployment constraints rule out cloud only products, since on premises and edge deployment are fully supported. Service providers, energy service companies and controls contractors building their own analytics offering are a core audience: the OEM programme exists precisely so they can embed it, and many competing branded analytics products are SkySpark underneath.

The Project Haystack REST API and open published APIs make it a strong choice for organisations that want to own their data model and push data onward, and the Haystack tagging approach is a real asset for estates that want a consistent semantic model across mixed vendor equipment.

It is a poor fit for buyers who want a fixed price subscription, a published feature set and no integration project. It is a poor fit for small single site organisations with no integrator relationship, since the partner led model means professional services cost that can dwarf the licence on a small job. It is a poor fit where utility invoice management or carbon disclosure is the primary driver. Buyers should also be realistic about two things the vendor does not publish: protocol support and price. The main pages mention live links to automation systems and smart meters, SQL databases, Excel imports and utility web service feeds, and reference Project Haystack, but do not specifically name BACnet or Modbus, so a written connector list from the partner is essential. And because no pricing or licensing terms are published anywhere, get the licence model, the renewal basis and the point or data volume limits in writing, from the partner, before signing.