SaaS Operations Management: BetterCloud Pioneers a New Market (451 Research Report)

Today we are thrilled to see 451 Research validate the rise of a new IT market category: SaaS Operations Management, or SOM. (View the report in SlideShare below.)

This is the second major analyst firm to validate a new IT market that BetterCloud is pioneering (Gartner was the first; read more on Gartner’s New Cloud Office Management Category here). Over the last 6+ years of its existence, BetterCloud has engaged with thousands of IT professionals facing a multitude of day-to-day operational challenges to administer and manage their SaaS app stack. Fast forward to today, where we are seeing cloud-forward companies create the new IT function of SaaS ops because we have reached a tipping point with SaaS. SaaS is now a common system of record for many organizations. The increasing popularity of SaaS means that its management challenges are growing swiftly too. IT is up against massive SaaS sprawl, plus a growing mountain of repetitive, manual work.

What is SaaS Operations Management (SOM)?

Great question! Hopefully you read about SaaS ops, a new increasingly common IT role in cloud-forward organizations. Businesses are looking to employ SaaS Operations Managers, SaaS Systems Administrators, and SaaS Administrators, among others, to manage day-to-day SaaS operations (here are some of their responsibilities).

In a nutshell, SOM consists of automating the operational admin and security tasks that an IT org needs to do to keep their SaaS applications running effectively in their environment. This translates to first defining acceptable use policies for SaaS apps and then using a platform to execute those policies—essentially being able to create, enforce, and optimize everyday usage policies for mission critical SaaS applications.

To learn more about how BetterCloud helps enforce policies, check out: SOM vs. CASB vs. IDaaS: The Unique Value of BetterCloud Demonstrated in 10 GIFs.

It’s important to note that SOM should not be confused with managing the uptime, performance, or availability of the SaaS app. Those functions are done by the SaaS vendors themselves or in the case of hosted private cloud/public cloud custom applications, it’s addressed by using an Application Performance Management (APM) vendor for the underlying cloud infrastructure.

SaaS Management: A Reference Architecture

This reference architecture below is a great way to visualize how SOM fits in with other aspects of managing SaaS apps. It was derived from the NIST Cloud Computing Reference Architecture and also endorsed by hundreds of customers, key industry analysts, and SaaS software vendors:

IDaaS: Identity as a Service | CASB: Cloud Access Security Broker | SOM: SaaS Operations Management | APM: Application-Performance Management | BPM: Business Process Management | IPaaS: Integration Platform as a Service

Systems of Record (SoR)

At the bottom of the architecture, companies like Google, Microsoft, Salesforce, Workday, and ServiceNow are valuable because they have now become the “system of record” (SoR), or single source of truth, for their customers’ most valuable information, such as customer records or employee data. As a result, they become deeply embedded in their customers’ business processes, making them hard to rip out.

Systems of Engagement (SoE)

At the topmost layer of the architecture, you see the newer crop of SaaS companies created by the “consumerization of the enterprise” wave by using technology as a “wedge” to gain widespread adoption—but not by trying to become systems of record. Instead, they are “systems of engagement” (SoE), meaning they are apps that employees actually use to get their work done.

For example, take Slack, which Forbes recently identified as the most valuable private cloud company. The same SoR companies offer SoE platforms as rich interfaces between users and their SoR data—they have become powerful businesses because they control both the end user interactions and their source of truth (like Office 365, Salesforce, and G Suite).

Systems of Control (SoC)

Sandwiched in between these layers are the “systems of control” (SoC). These are specific areas of technology where companies have innovated (and SoR and SoE vendors have ignored). They contain functions that SoR and SoE customers need: integration and control.

At any of these SoR and SoE SaaS companies, from our years of experience and interaction with them, integration and control are the ugly stepchildren of their product plans: Everyone wants it to work, but no one wants to work on it. The most common example is the admin console for SaaS apps. It’s built for the lowest common denominator of customers, which means only minimal admin functions are available in the admin console UI. Instead, many customers must manually build custom scripts using APIs to expose additional admin functions.

Companies have capitalized on these APIs by creating high-performing, scalable integrations and solving hard technical problems, like how to create a unified experience across these SaaS apps to administer and manage them for distinct sets of challenges (e.g., identity and access, security, data integration, performance monitoring, business process automation, etc). Entire categories and billion-dollar companies have now been created out of such “systems of control” layers alone: IDaaS (Okta), APM (AppDynamics), IPaaS (Mulesoft), CASB (Netskope), BPM (Appian).

Operations is another SoC layer representing critical operational IT functions like operational monitoring for surfacing critical insights and actions, carrying out admin and configuration tasks in bulk, orchestrating IT tasks and processes with workflows, defining and enforcing acceptable usage policies, cross-app reporting, and auditing admin tasks.

The Security layer highlights two key operational security concerns that security teams have raised around addressing “internal” insider threat vectors and bloated admin privileges. Insider threats are typically caused by missteps in SaaS app configurations and settings for users and their data objects inside those apps. Such missteps are either accidentally performed, intentionally put in place by disgruntled employees, or set to “default” with limited understanding of its implications. For example, a simple misconfiguration in the Google Admin console made headlines recently by exposing personally identifiable information (PII) and sensitive messages to the internet. Read more stories here that illustrate these types of insider threats and their devastating consequences. Bloated admin privileges arise from either too many admin roles being handed out in an unchecked manner or too much privilege given to specific admin roles. The SOM category addresses both operational IT and operational security challenges for multi-SaaS environments.

There are other related and distinct sets of security challenges (listed under “security” and “access” layers) that are addressed by CASB and IDaaS platforms which employ network proxy/gateway, SAML, SCIM, and MFA technologies. However, it is important to note that all functions of a SOM platform are implemented solely using unique non-standard APIsingesting user data, activity, events, and cataloging every admin action across each SaaS app. This aspect of using non-standard APIs makes SOMs a complex technology platform to build, which is a major reason why this market category is emerging so late compared to its neighboring SoC layers.

To download the 451 Research report, click here.

Shares

Leave a Reply

Your email address will not be published. Required fields are marked *