Skip to content

An independent study reference written by Dr Phuc V. Nguyen. It is not official subject material — for assessment requirements always follow your subject outline and vUWS.

Analytics as a service

Analytics as a service means renting the analytics stack instead of owning it. A provider runs the storage, the compute, the modelling tools and often the models themselves, and the organisation pays for what it uses. The delivery layers stack up: infrastructure (bare machines and storage), platform (managed databases and pipelines), and software (a finished dashboard or scoring service the business logs into). Renting buys elasticity and speed, and it hands over control of where data sits, how it is secured and how easily you could leave. The choice is a governance decision as much as a cost decision.

Why it matters

Think of electricity. Almost no factory generates its own power any more, because a grid serving thousands of customers can run its generators near full capacity while any single factory would leave its own generator idle most of the time. Analytics platforms went the same way. You plug in, you pay for the hours you draw, and somebody else worries about the machines. What you give up is the ability to see inside the plant.

Before you read on — recall

A team runs one model-training job that occupies a large cluster continuously, every hour of every day, with no seasonal peak. On cost grounds alone, what does this pattern suggest?

Formulas

When renting beats owning
Crent=h×r,Cown=Km+fC_{\text{rent}} = h \times r, \qquad C_{\text{own}} = \frac{K}{m} + f
Renting costs the hours actually used hh times an hourly rate rr. Owning costs the capital outlay KK spread over mm months of useful life, plus a fixed running cost ff for power, cooling and administration that is paid whether or not the machine is busy. Renting wins when demand is spiky, because hh falls with idle time while K/mK/m does not. The premium in rr is the price of that flexibility, and a workload that never idles pays it for nothing.

Worked examples

Scenario

A retailer reforecasts demand once every seven days. The job needs 40 machines for six hours, and for the remaining hours in that cycle the capacity would sit idle. The team asks whether to buy the cluster.

Solution

Work the arithmetic. Forty machines for six hours is 240 machine-hours every seven days, roughly 1,040 a month. At A$0.50 an hour that is about A$520 a month. Buying 40 comparable machines might cost A$200,000 spread over 36 months of useful life, so about A$5,600 a month before power, cooling and an administrator. The owned cluster would be busy under 4% of the available hours, and idle capacity still costs full price. Renting wins by a wide margin here, and it would stop winning if the same cluster ran continuously.

Scenario

A hospital wants a hosted service to score readmission risk, but its patient records are not permitted to leave the country.

Solution

The delivery model has to bend to the constraint rather than the other way round. Three options survive: a provider region physically inside the country, a private deployment of the same software on hospital-controlled infrastructure, or keeping identifiers on site and sending out only features that legal and security have confirmed are anonymised and cleared to leave. De-identification is not anonymisation, and neither by itself makes the data exportable. Each costs more than the plain shared service, and the decision belongs with the people who carry the legal exposure, not with the team that likes the tool. Write the exit path into the contract, because moving several years of records out later is the expensive part.

Common mistakes

  • Analytics as a service removes the need for data engineering. Renting the platform removes the racking, patching and capacity planning, not the modelling of the data. Somebody still has to define what a customer is, wire the pipelines and repair them when a source system changes.
  • Cloud analytics is always cheaper. It is cheaper for spiky or occasional workloads and often dearer for a steady round-the-clock one, because a rented machine that never idles pays a flexibility premium every hour for flexibility it never uses.
  • If the provider is certified and secure, the organisation has transferred its obligations. Certification covers the provider's part of the stack. Responsibility for who may see the data, how long it is kept and whether the use is lawful stays with the organisation that collected it.
  • Once data is in a managed platform it can be moved out just as easily. Getting data out usually costs money and effort that getting it in did not, and dashboards, permissions and pipeline logic rarely transfer at all. Lock-in is built out of that asymmetry, not out of a contract clause.

Revision bullets

  • Renting the analytics stack instead of owning it, billed by use
  • Layers: infrastructure, managed platform, finished software service
  • Elasticity is the real prize, so spiky workloads gain most
  • Rented cost rises with hours used; owned cost does not fall when idle
  • Data residency, exit cost and lock-in are the standing trade-offs
  • Legal responsibility for the data does not transfer with the hosting

Quick check

A team runs one model-training job that occupies a large cluster continuously, every hour of every day, with no seasonal peak. On cost grounds alone, what does this pattern suggest?

A marketing team signs up for a hosted customer-scoring service on a departmental card and starts uploading customer records. The strongest objection is that

Connected topics

More in The Analyst and What Comes Next

Sources

  1. Mell, P., & Grance, T. The NIST Definition of Cloud Computing. NIST Special Publication 800-145, 2011.
    The standard definition of the service layers (infrastructure, platform, software) and of on-demand, measured, elastic provisioning.
  2. Armbrust, M., et al. "A View of Cloud Computing." Communications of the ACM, 53(4), 50-58, 2010.
    Sets out the economics: elasticity removes the cost of provisioning for peak, and transfers the risk of idle capacity to the provider.
How to cite this page
Dr. Phil's Quant Lab. (2026). Analytics as a service. Derivatives Atlas. https://phucnguyenvan.com/concept/ba-analytics-as-a-service
Next concept
Cloud for analytics
Built by Dr. Phuc V. Nguyen ·Follow on LinkedInWork with PhilEmail