What Is SaaS (Software as a Service)?

The most widely cited definition comes from the US National Institute of Standards and Technology (NIST). In Special Publication 800-145, published in its final version in October 2011, Peter Mell and Timothy Grance describe three cloud computing service models — Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS) — along with five characteristics that turn an offering into a cloud service in the first place: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured, usually usage-based billing.

With SaaS, the provider runs the entire application — from the infrastructure up to the interface. The customer signs in through a browser or a thin client application and uses the software without managing servers, an operating system, or storage themselves.

Anyone who runs an application themselves runs it fresh at every site: provisioning servers, maintaining the operating system, closing security gaps, updating version after version. With ten plants each running their own installation, that is ten separate update rounds with ten possible points of drift — different patch levels, different failure patterns, different people to call. With SaaS, it is one software version for all ten plants at once.

Then there is the cost shape: a self-hosted installation is an upfront investment — servers, licenses, failover. SaaS turns that into an ongoing, usually monthly fee that grows or shrinks with usage, without building your own failover in the first place.

The price for that is control: whoever no longer operates the system also no longer decides alone when an update lands, where the servers sit, or in what order new features appear.

Most SaaS applications run as a multi-tenant architecture: one shared application and infrastructure serves many customers (tenants) at once, logically separated but running on the same underlying systems. The alternative is single-tenant: each customer gets its own, isolated instance.

Multi-tenancy is why SaaS providers can ship new features quickly to every customer at once — and why customizing the software for a single customer is more constrained there than with a self-hosted installation.

An SLA (service level agreement) sets out the availability the provider commits to — usually as a percentage per year — and what applies if something breaks: response time, escalation path, compensation. For a production application, this figure is not a side detail: an SLA that is fine for an office tool can fall short for an application that runs a shift schedule.

SaaS updates typically arrive automatically and for every customer around the same time — often staged (a small group first, then everyone), with release notes describing what changes. Unlike with a self-hosted installation, a customer can rarely defer an update indefinitely; usually only within a fixed window. That calls for a small internal change management process of its own: who in the company reviews a new version before it goes live, and who decides when a change touches live operations.

• Internet connectivity. SaaS assumes a reliable link between the plant and the provider — often the weakest point on a shop floor, which is why a second, independent link or local buffering during an outage belongs on the checklist.
• Sign-in and permissions. Single sign-on (SSO) through standards such as SAML or OAuth ties the SaaS application into existing user management instead of maintaining a separate password list.
• Interfaces. APIs connect the SaaS application to an MES, an ERP system, or a namespace such as the Unified Namespace — without them, SaaS stays an isolated interface rather than part of the landscape.
• Encryption. Data is encrypted in transit (TLS) and at rest; the server location also determines which jurisdiction’s law applies to the data.

1. Define data classes

   Which data is allowed to leave the plant for the cloud, and which stays local? That decision comes before choosing a provider, not after.

2. Vet the provider and the contract

   Data processing agreement, server location, SLA, notice period — and, critically, the ability to export your own data back out again in an open format.

3. Set up integration

   Single sign-on, interfaces to the MES/ERP system and the namespace, network access — before the application goes into shift operation.

4. Monitor operations

   Availability, update announcements, and usage are watched on an ongoing basis, not just checked once at signing.

• Not a waiver of data protection responsibility. Under EU rules, the customer usually remains the data controller and the provider is the processor, requiring a data processing agreement — not just trust.
• Not a substitute for handling internet outages. Without local buffering, the application stalls the moment the connection drops — it needs the same store-and-forward logic used elsewhere in the landscape.
• Not a uniform product. The degree of configurability, the server location, and export options vary considerably from one provider to the next.
• Not a substitute for IaaS or PaaS when you need to build your own application — for that, the other two service models remain the right choice.

• Internet dependency on the shop floor. Where network connectivity is weaker than in the office, missing buffering decides whether a line outage becomes a production stop.
• Unresolved data sovereignty. Server location and applicable law often only get checked after signing — they belong in contract review, not in the after-the-fact review.
• Vendor lock-in. Without a guaranteed export in an open format, switching providers gets more expensive the longer you use the service.
• Forced updates without change management. Anyone who does not review new versions in advance experiences changes live, instead of on a planned schedule.

pronubes is the platform between the shop floor and IT — run as SaaS, hosted in the EU, with a data processing agreement as part of the contract.

• pronubes Edge buffers locally through connection loss — an outage at the plant interrupts transmission, not data capture.
• pronubes Zones and pronubes Insights run as multi-tenant SaaS: one software version for every customer, updates without on-site IT effort.
• Data can be exported in open formats at any time — SaaS ties you to an operating model, not to a format.

That keeps operations with the provider — and the decision of which data goes where with the customer. More on the platform