SAP Logo LeanIX is now part of SAP
Solved

How to unlock the Power of SaaS Discovery in Your EAM?

  • 23 October 2023
  • 6 replies
  • 133 views

Userlevel 3
Badge +1

Welcome to our blog on how to enable SaaS discovery in your Enterprise Architecture Management. Are you ready to take your organization's digital landscape to the next level? Let's embark on this exciting journey together. 🚀

Step 1: Exploring SaaS Discovery

Before we dive into the technicalities, let's understand what SaaS discovery is all about. In essence, it's your key to uncovering all the software-as-a Service (SaaS) applications used within your organization. Imagine having a bird's-eye view of your digital ecosystem! We offer multiple ways to achieve this.

SaaS Discovery in EAM

 

  • Discover Integrations: Check out the Discover integrations available in our EAM product. If you can't find the one you're looking for, no worries! We have alternatives.
  • Custom Integration: Want something tailor-made? We've got you covered. You can set up custom integrations to fetch data.
  • File-Based Discovery: Prefer working with spreadsheets? You can set up an Excel file and let our machine learning algorithm do the rest.

To dive deeper into how SaaS services are discovered using key enterprise systems, check out our community blog: How Do SaaS Discovery Integrations Unlock Your Digital Ecosystem?

Step 2: Enabling SaaS Discovery

Now, let's get down to business. To enable SaaS discovery in your EAM, follow these steps:

  • Go to your EAM workspace: Log in and navigate to your EAM workspace.
  • Access Settings: Look for the "Settings" tab.
  • Advanced Settings: Under the "Advanced Settings" section, click on "Data Usage."

Here, you'll find that LeanIX provides advanced insights and assistance based on data from outside your workspace. But to access these features, LeanIX needs your consent.

Step 3: Sign the amendment and opt-In for SaaS Discovery

To make these powerful features available to you, we require your participation. Here's what you need to do:

  • Click on Opt-in Process: In the Data Usage section, you'll see an "Opt-in Process" button. Click on it.
  • Sign the document: You'll be redirected to a document that you need to sign. Don't worry; it's a straightforward process.

Step 4: Verification and Activation

After you've signed the document, our legal team will review it. If everything checks out, you're on your way to unlocking SaaS discovery! Typically, SaaS discovery will be enabled within the next 24 hours.

Facing Issues? If you encounter any issues or have questions along the way, don't hesitate to reach out to our support team. We're here to help you every step of the way.

Important Note:

This procedure is the same for all our valued customers as well as our partners. We believe in transparency and giving you full control of your data, which is why we ask for your consent. Rest assured, your data is in safe hands.

So, are you ready to harness the power of SaaS discovery in your EAM product? Follow these steps, and you'll be well on your way to gaining invaluable insights into your organization's digital landscape. Feel free to reach out if you have any questions or need assistance. Your journey to EAM excellence starts now! 🌟

icon

Best answer by Mostakim Mullick 10 November 2023, 12:46

View original

6 replies

Userlevel 4
Badge +1

When you say, SaaS can be discovered by, 

  • File-Based Discovery: Prefer working with spreadsheets? You can set up an Excel file and let our machine learning algorithm do the rest.

 

Are you referring to the SaaS Discovery: File-based Discovery for SSO and CASB systems feature on the SMP Q4 2023 roadmap?

I’m looking forward to this feature to test and prove the value of integrating with Microsoft Defender for Cloud Apps. My fear is that this integration will generate a lot of noise because of the way Defender categories SaaS events. We detected 2800 SaaS events in the last 30 days which include things like someone logging-in to read a company newspaper subscription. Would this “noise” be suppressed over time as you Linked or Rejected discovered SaaS apps?

Userlevel 3
Badge +1

When you say, SaaS can be discovered by, 

  • File-Based Discovery: Prefer working with spreadsheets? You can set up an Excel file and let our machine learning algorithm do the rest.

 

Are you referring to the SaaS Discovery: File-based Discovery for SSO and CASB systems feature on the SMP Q4 2023 roadmap?

I’m looking forward to this feature to test and prove the value of integrating with Microsoft Defender for Cloud Apps. My fear is that this integration will generate a lot of noise because of the way Defender categories SaaS events. We detected 2800 SaaS events in the last 30 days which include things like someone logging-in to read a company newspaper subscription. Would this “noise” be suppressed over time as you Linked or Rejected discovered SaaS apps?

@Stephen Gates Thanks for taking the time to read this blog. In this post, I wanted to discuss the concept of file-based discovery, which is already available in our SMP product. However, we're also planning to introduce this feature in our EAM product through the SaaS Discovery feature. So if you wanna use this feature, you can contact our support team and we can help you to use it and all the SaaS will be available in your EAM.

When you use file-based discovery, you'll need to provide the names of the services along with their service IDs, as detailed in our Discovery Capability Documentation. After this step, our Service Discovery process kicks in and utilizes our machine learning model. Services with scores above 0.9 on a scale of 0 to 1 are automatically included in the SaaS List. For services falling below this threshold, they undergo a manual review by our responsible team, who will either accept or reject them. It's important to note that our machine learning models continuously learn from our diverse customer base's activities, which influence the decision to include or exclude services.

You raised a valid concern about potential noise or unnecessary entries in your SaaS list. File-based discovery indeed focuses on checking whether a service is classified as SaaS or not, solely based on the provided service names. It doesn't consider factors like genuine logins or other interactions with those services.

However, we have a solution for this too. We offer a Service Discovery tab in SMP (see the screenshot below) that provides detailed information about which services were added to the SaaS discovery by matching with known SaaS offerings.


It also categorizes services as non-SaaS automatically and identifies those that require manual review based on their confidence score. This manual review process allows you to verify and remove any services from your SaaS list that shouldn't be there. It is already in our product roadmap and we will have this in EAM soon. I hope this information proves helpful. Please feel free to reach out if you need more in-depth information.

Additionally, I'd like to mention that we also offer Custom Integration in SMP, which works somewhat similarly to file-based discovery but does require some technical expertise. You can get a better understanding of the differences between Custom Integration and File-based discovery by reading our blog on the topic.

Userlevel 4
Badge +1

Thanks @Mostakim Mullick, I have 2 follow-on questions

1. Is the manual review of potential new SaaS apps included in the discovery time?

you say,

When you use file-based discovery, you'll need to provide the names of the services along with their service IDs, as detailed in our Discovery Capability Documentation. After this step, our Service Discovery process kicks in and utilizes our machine learning model. Services with scores above 0.9 on a scale of 0 to 1 are automatically included in the SaaS List. For services falling below this threshold, they undergo a manual review by our responsible team, who will either accept or reject them. 

 

And the SMP documents say,

The actual time it takes for the import to complete may vary, typically within 5 business days.

 

Does it take up to 5 days because of the manual review of potential new SaaS apps by the LeanIX research team?

 

2. Data needed to import SSO/CASB services?

The Discovery Capability documentation says the data needed to discover Applications from SSO/CASB is:

  • Required data:
    • appID string (max 255) - unique identifier of the app in the data source
    • appName string (max 255) - display- or clearname of the app in the data source

 

But the File-based Discovery - Recommended best practices for SSO/CASB import suggest many more fields are required. E.g. Vendor Name, Invoice Date, Amount.

Which one is correct? 

Userlevel 4
Badge +1

I think I found the problem in the File-based Discovery - Recommended best practices for SSO/CASB import documentation. I think a heading isn’t marked up correctly and someone forgot to change “Vendor” to “App”, which would make your original advice correct. 

 

 

Userlevel 4
Badge +1

Just noticed the documentation has been updated. Question 2 above answered - https://docs-smp.leanix.net/docs/file-based-discovery_manual-data-import

Userlevel 3
Badge +1

Thanks @Mostakim Mullick, I have 2 follow-on questions

1. Is the manual review of potential new SaaS apps included in the discovery time?

Does it take up to 5 days because of the manual review of potential new SaaS apps by the LeanIX research team?

 

2. Data needed to import SSO/CASB services?

The Discovery Capability documentation says the data needed to discover Applications from SSO/CASB is:

  • Required data:
    • appID string (max 255) - unique identifier of the app in the data source
    • appName string (max 255) - display- or clearname of the app in the data source

 

But the File-based Discovery - Recommended best practices for SSO/CASB import suggest many more fields are required. E.g. Vendor Name, Invoice Date, Amount.

Which one is correct? 

@Stephen Gates Thank you for your query.

Yes, the research team needs to investigate all aspects to determine if the reported service is indeed a SaaS solution.

The initial information was not accurate. We have updated it. The Vendor ID and Vendor Name are correct, but there were too many other irrelevant fields for Single Sign-On (SSO).

 

Reply