SaaS Governance Series: Why SaaS should be classified

About the series

This is the second part of my series on SaaS Governance. We can probably assume that every enterprise company has created and implemented their own public cloud governance. Trying to cope with all the regulations that are out there and adding their own bouquet of rules to them. Most if not all of these governance rules deal with the well-known hyperscalers (AWS, Azure, GCP), but what about SaaS? Most companies shy away from this topic because there is no central unit like a SaaS Center of Excellence (SCoE) that manages all of their SaaS applications. This series tries to demonstrate you ways to regulate your companies SaaS without impacting the business.

Legacy governance processes meet SaaS

I want to start this passage with a quote : “If the only tool you have is a hammer, everything looks like a nail.” And this is exactly the biggest challenge most enterprise companies face when their legacy software approval processes (software governance processes) face the motley world of SaaS applications. Approving or buying SaaS applications is by far not the same like concluding a contract with Microsoft about Windows licenses. They vary in size and function from a simple tool, to a business application toward an entire platform such as Microsoft 365. And since there are no specialized departments like a SaaS Center of Excellence, all applications are treated equally with the same process hammer.

Why SaaS should be classified

I don’t usually give this away in the first few seconds of an article, but the answer is as simple as this: If you classify SaaS, it is possible to attach different processes to each class. In enterprise companies established software governance or software approval processes normally include a lot of parties. The below list shows the most common ones:

• Software Asset Management
• Information Security
• Data privacy department
• Enterprise Architecture
• Purchasing Department
• Client Services
• (Worker Council)

All of those have their own micro processes that leads to an approval of software. To get to an overall approval for a SaaS solution often month pass by until a requester is getting the final go. This might make sense if you want to approve a platform like M365 but not for a SaaS solution that ten marketing employees would like to use. Often this approval process is very rigid and not very agile, as everyone is happy to have found a uniform software approval process that is valid throughout the company group, given the number of departments involved. The only way away from the one hammer and towards a toolkit is to find a commonly accepted classification for SaaS. This classification then becomes the basis for new appropriate processes. SaaS also increases monthly requests for software approvals. From my experience so far, this can be up to ten requests in a month. The existing processes are not suitable for this sheer amount and cause a backlog of requests.

What classifications and processes works best

From my experience I would use a three or four tier approach. It depends on whether your company is part of a group or not. In addition, I would recommend that you have your newly created SaaS Center of Excellence 🙂 implement two new processes:

• A SaaS approval process, that fits your governance needs for SaaS platforms and SaaS business application that are used in different departments
• A SaaS light process, that fits your governance needs for SaaS tools and SaaS business applications that are solely used by one department or a small amount of users

As part of the SaaS classification I would not only use characteristics that describe different classes but also introduce governance, management and accessibility rules to them. You will find examples of this in my class examples. Here are the four classes I would go for:

Free SaaS
characteristics: no registration, no technical interfaces, no company data
process : no software approval process
management: no management
accessibility: no repository

Community SaaS
characteristics: registration required, technical interfaces used or planned, company data, x users or x amount of costs/year
process : SaaS light process
management: decentralized management
accessibility: EA repository, CMDB, SAM database, SaaS Management solution

Managed SaaS
characteristics: registration required, technical interfaces used or planned, company data, x users or x amount of costs/year
process : SaaS process
management: central management
accessibility: Company software catalog, EA repository, CMDB, SAM database, SaaS Management solution

Corporate SaaS / Group SaaS
characteristics: registration required, technical interfaces used or planned, company data, x users or x amount of costs/year
process : Corporate software approval process, Group software approval process, SaaS process
management: Corporate/Group management
accessibility: Corporate/group software catalog, Company software catalog, EA repository, CMDB, SAM database, SaaS Management solution

Where you draw the line between Community SaaS and Managed SaaS depends entirely on whether you want to base this more on the amount of users or the annual licensing costs.

This classification is just my approach to this topic, but you can of course find your own way that fits the needs of your company, or consult me to find the your perfect way together.

Originally published at http://torbenhamburg.wordpress.com on September 22, 2022.