How can our customers derive value from Rightsizing App licenses? (aka ELM)

What is it?

Rightsizing application licenses means helping customers identify which app-licenses can be de-provisioned or downgraded, and then act on it. Currently, this functionality is packaged under the module ELM — Elastic license management.

For example, you’ve purchased a bunch of "pro" (high-cost) licenses of Zoom, and have given them to different people in your company. Now, it turns out that:

1. Joe doesn’t really use Zoom at all
2. Mary only uses Zoom for attending meetings, for which she only needs a "basic" (low-cost) license

 It might be good if we rightsize Zoom licenses — by downgrading Mary from a Pro to a Basic license; and de-provisioning Joe from Zoom — thus freeing up those Pro licenses.

What’s the benefit?

There are three reasons to free up the licenses:

1. Freed-up licenses can be given to new users. Otherwise, one would have had to either buy more licenses mid-term; or over-provision and then pay mid-cycle via a true-up check.
2. Even if those licenses are left unused, it will help at renewal time to see how many licenses of what type are actually in use and renew accordingly.
3. It reduces the security risk — people who stop using an app also stop securing it (changing old passwords, updating apps, deleting old data etc), so it is better to take it away.

How does it work?

There are just two things needed

1. Discover

• Find "Joe" — users to be de-provisioned. People who have an app-license but are inactive (not using the app at all)
• find "Mary" — users to be downgraded. People who have an app-license and are active, but are not using the high-license-tier features.

1. Act

• take rightsizing action :: De-provision Joe, Downgrade Mary’s license.
• and/or inform others (e.g. app admins) so they can take the rightsizing action

Discover: To find our Joe and Mary, we are looking for three pieces of information.

1. Which users have what kind of app-license? 
2. Have they been using the app at all? 
3. What app-features have they been using?

Best case — we publish an engagement-connector for the app AND the customer has actually deployed that connector. Woohoo! ... we have first-party authentic and accurate data from the app itself for the above use cases as well in many others (depending upon the connector/app)

Next Case — no engagement connector. Only SSO. We can’t find Mary (users to be downgraded). We can likely find Joe (users to be de-provisioned). Specifically

1. Without the engagement connector, we can’t get any info on who is using what features, so we can’t find Mary (users to be downgraded)
2. But we can likely tell who has (and has not) been logging-in using SSO, and thus using the app at all ... IF the app’s SSO is configured correctly:

• The app needs to be exclusively behind SSO. After all, if some users can directly login to the app without using SSO, then neither SSO nor us will know about it — and we might falsely think that the user is inactive when they are not
• The app’s SSO session needs to be configured to time-out after some short interval (like a day or a week). If the SSO-session is allowed to be long (like an year, or infinite), then the user won’t need to login via SSO to use the app ... so, neither SSO nor us will have login-events even when the user is actually using the app, and we might falsely think that the user is inactive when they are not!

1. Even if we know Joe is an inactive user, how do we know that Joe actually has a license assigned to him in the app?

• After all, Joe might only have been given access to the app via SSO, but not actually given a license in the app (yes, that’s how sometimes SSO-admins set up things). In this case, we’ll say "hey, you should de-provision these 100 inactive users", and the app-admin might examine the list and say, "half of these users are not even provisioned in the app — so this is bad data (even though it is not) and I won’t act on the remaining half of the data".
• Alternately, we might have one of our new lightweight connectors for the app, which fetch provisioned-users ... meaning that we can connect to the app and get authentic data for that piece "which users have what kind of app license?"

In summation for Discovery. The best case is an Engagement connector. Else a lightweight provisioned-users-connector AND a properly configured SSO setup for the app. Else just the properly setup SSO.