SaaS Management Platforms: Promise, Perception and Practicality

At Gartner, I have been involved in defining and covering quite a few management platforms. Among these ‘management’ platforms,  I see SaaS Management Platforms  as the most misunderstood and having the greatest challenges in the years ahead. This essay is not about SMP functionality but more about the meta-challenges facing management of SaaS applications.

To understand what makes SMPs complex and why they are ridden with challenges, we have to dissect the common traits of management platforms in general. Any management platform is designed with these principles in mind:

1. Task Automation – automate tasks that you’d have to otherwise perform manually
2. Workflow Orchestration – orchestrate workflows that yields a business outcome
3. Service Abstraction – abstract underlying services that you are trying to manage
4. Measure, Act and Improve – implement a feedback loop that measures parameters of the underlying system being managed, take action and improve the health of the overall system as a result.

We can explore other aspects but this is sufficient to understand how SMPs differ from other management platforms. SMPs have to automate tasks pertaining to each SaaS application, orchestrate workflows that span multiple SaaS applications and abstract away the complexity underpinning policy management and configuration automation. These aspects make SMPs the most ambitious of all management platforms built to date.

SMPs are unique as a management platform because there are an infinite [theoretical limit] number of entities [applications] they can manage.

It is nearly impossible for any single SMP to cope with the rate of change of all applications they manage.

Compare this to let’s say an unified endpoint management (UEM) platform – technically, a UEM platform manages a fixed [known] set of operating systems. Although the number of devices being managed can be huge, all of them share a few known OS variants – Windows, macOS, ChromeOS, Android, iOS, Linux or may be Raspberry PI. This is where SMPs begin to differ. And the gap between promise and practicality starts to widen.

SMPs aim to bring the same benefits of management to SaaS applications that UEM tools provide for device platforms. And if you didn’t notice, that exposes the first challenge. The unit of management shifts from operating systems to applications – that is a [step] change in granularity – one that has enormous ramifications. But wait a second, we have a precedent!

What SMPs are trying to do with SaaS applications, standalone mobile application management (MAM) providers have attempted to do with mobile applications for many years. MAM providers made a similar promise – we’ll manage applications independent of the OS. Although sound in theory, the practical challenges posed by the underlying operating systems and the lack of consistency between application configurations made their adoption very difficult.

Look around to see how many standalone MAM providers still exist.

UEM providers tried to address the problem of inconsistent application configuration through the creation of a cross-vendor initiative named appconfig.org. The goal of appconfig.org initiative was to standardize the management of applications across multiple UEM providers and also across operating systems. If applications adhere to a common configuration standard, then it’s a win-win-win for all parties involved – app developers, UEM providers and enterprises. We need something similar for enterprise SaaS applications.

SaaS applications face the same challenge but infinitely more complex. Why? Mobile applications are relatively simpler to manage compared to SaaS. They are governed by the rules of an operating system so there’s only so much wiggling room. SaaS applications, on the other hand are written for the web. There’s no “owner” for the web in the same way that Apple owns iOS, Microsoft owns Windows and Google owns Android.  You can start to appreciate the challenge for SMPs – the seemingly infinite depth and breadth of applications under management.

Depth: SaaS applications are constantly changing. SMPs must be aware of the nitty gritty of every feature.

Breadth: There are a myriad SaaS applications – the promise of SMPs is to provide [both] application-agnostic and application-specific management capabilities.

Let’s talk of customer perception of an SMP. Here are a few –

1. SMPs are magically “aware” of how to manage any SaaS application i.e. SMPs have API integrations with every SaaS application under management.
2. You can set a policy [once] in SMP and have it take effect across all SaaS applications i.e. SMPs as a single policy enforcement point. Imagine setting a DLP policy that takes effect across Dropbox, Box, OneDrive, GDrive, etc.
3. SMPs propagate and synchronize configuration between environments i.e. if I configure a pre-production tenant, the SMP can ensure consistency between production and pre-production tenants. Think of this as “continuous deployment” of SaaS application configuration.
4. SMPs can discover, manage and secure virtually any SaaS application.

We see SaaS Security Posture Management [SSPMs] tools starting to fill some of these gaps and address these client needs.

I am not suggesting that SMPs don’t satisfy these client needs, but to some degree, it’s not realistic to expect that SMPs are application-agnostic in the same way that UEMs are platform agnostic. UEMs have far fewer platforms to manage. Enterprise-grade SaaS applications number in the thousands and will only grow with time. This is why I strongly believe SaaS application management desperately calls for a declarative model for configuration metadata.

Practically speaking, SaaS applications need a declarative model for configuration metadata.

Analogies exist other domains, if we want to pursue them.

CycloneDX [CycloneDX] is a lightweight software bill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis.

Grafeas [Grafeas] is an open artifact metadata API to audit and govern your software supply chain.