Specific Integration Use Cases
The sections below provide guidance on how to leverage the capabilities of the Flexera One app to solve common business challenges:
| • | Scenario: IT Management is reviewing their hardware nearing its end of life (EOL) to plan for the next fiscal year. |
| • | Scenario: We’re being audited, and we need to prove our software isn’t at end of life and causing a vulnerability. |
Scenario: IT Management is reviewing their hardware nearing its end of life (EOL) to plan for the next fiscal year.
Current State/Business Problem
We have hardware CI data being created by multiple data sources—often times creating models that are essentially the same and nothing has useful lifecycle information. This makes it very difficult to plan ahead.
Recommendations
What CIs are nearing their end of life?
To know this, you need your current CMDB inventory “normalized” so it’s clear what’s what. If you are just relying on “discovery models,” that approach will almost certainly lead to more confusion than answers when often the same hardware is presented multiple ways—making it very difficult to know what’s what in your environment.
To accomplish this, you must perform the following steps:
| • | Install the Flexera One integration and configure it to allow data to flow from ServiceNow to IT Visibility and from IT Visibility back to ServiceNow. |
| • | In Import properties we need to enable Insert hardware models, Update hardware models, Hardware CI update. |
| • | Set Reconciliation Rules to make Flexera One the highest priority for the model_id field on the computer tables. |
Discovery Data
Flexera Normalized
Now that you have things normalized, it’s realistic to figure out the lifecycles. When lifecycles are attached to the “normalized” models that the CIs are using, you have a path to knowing what CIs are nearing their EOL, and you can act on those.
No further setup should be needed for this part to work. Now that the CIs have been normalized and associated to our model, the model should also contain related lifecycle data.
But that’s not the end of things. You now have a list of “what” is nearing its EOL, but how do you prioritize that list? This is where “Service Mapping” comes in.
With “Service Mapping” you can understand the relative criticality of these different CIs nearing their EOL. For example, if server X is supporting a tier 0 critical application service and server Z is only supporting a tier 2 application, then you can direct resources to the critical infrastructure first.
To accomplish this, you need to perform the following step:
| • | Check the “Enable Flexera Business Service Mapping” option in the import properties. |
This is just one example of where our data can help with important business decisions around prioritization and resources but there’s many similar use cases.
For example, normalization, lifecycle, and service mapping would also help you view your environment from new perspectives:
| • | What CIs are causing the most incidents or problems? |
| • | How critical are those items? |
| • | How should we handle it? |
| • | Is it a replacement scenario (EOL is up or almost) or do we need to get a backup in place while we have this CI serviced under warranty? |
These are day to day problems that come up, and with any one of these three pieces not in place, your ability to make an educated decision is drastically reduced.
Scenario: We’re being audited, and we need to prove our software isn’t at end of life and causing a vulnerability.
Current State/Business Problem
We have multiple data sources bringing data into ServiceNow CMDB with three different sources providing software. We don’t have any lifecycle data currently and need help making sure we can prove we’re up to date.
Recommendations
First step is going to be normalization. Until your software installation data is normalized, understanding your data and connecting the dots between an install and a lifecycle is nearly impossible. In order to prove everything is covered, it is essential to connect those dots on the software installation records/tables; otherwise, there may be discrepancies between the datasets, and identifying those becomes more difficult. Most of the built-in tools to validate data in ServiceNow are directed to out-of-the-box tables.
To accomplish this, you need to perform the following steps:
| • | Install the integration app, Flexera One, and configure the connections. If Flexera One is the only data source, then you only need to configure data going one way to ServiceNow and you can set up the connection record in ServiceNow using the token from IT Visibility. If a data source is feeding ServiceNow and you need to include that data source, you will need to set up IT Visibility to pull data from ServiceNow and push it back again to normalize it. |
| • | In Import Properties we need to enable Insert Flexera software models and lifecycles, Update Flexera software models and lifecycles, Insert software installations, and Update software installations. |
Now that we have things normalized, you also should have the associated software model lifecycles. When lifecycles are attached to the “normalized” models that the installations are using, you have a path to knowing what software installations you have that are obsolete or nearing EOL. Knowing this enables you to start to act on it, but generally it would be best to do targeted “campaigns” to solve the most important items first and work your way down.
No further setup should be needed for this part to work. Now that the software installations have been normalized and associated to our model, the model should also contain related lifecycle data.
To prioritize, you need to know a couple pieces. First item is generally “number” of installs since that’s an important factor in understanding the risk involved with obsolete software, but there’s other aspects to consider. An important one would be, “What software is associated with servers connected to critical business applications?” Obsolete software used on devices with no ability to connect to sensitive data or critical systems has one level of risk, but a server supporting a critical application with access to sensitive data is another entirely. This is where “Service Mapping” comes in to help provide the detail you need to pull together a list of what software is a risk on your critical systems.
To accomplish this, you must perform the following step:
| • | Check the Enable Flexera Business Service Mapping option in the import properties. |
Scenario: Our asset management team wants to be able to utilize workflows and processes in ServiceNow to manage software, but our platform team doesn’t want us touching more than absolutely necessary.
Current State/Business Problem
Currently none of our software models are normalized or have lifecycle data. This situation makes managing the data extremely difficult. To complicate matters, our platform team will not let us update anything outside the software installations/models and lifecycles—including the company table which they have forbidden us from adding new records to for publishers.
Recommendations
First step as usual is going to be normalization. Until your software installation data is normalized, understanding your data and connecting the dots between an install and its lifecycle is nearly impossible. In order to prove everything is covered, it is essential to connect those dots on the out-of-the-box ServiceNow tables; otherwise, there may be discrepancies between the data sets, and identifying those becomes more difficult. Also, most the built-in tools to validate data in ServiceNow are intended for the out-of-the-box tables. In order to normalize models, it is necessary to create a new “normalized” model. This is because, often times, there are multiple models for the same “normalized” model, and we can’t just update them all without turning them into duplicates and potentially causing other issues with ServiceNow discovery.
To accomplish this normalization, you need to perform the following steps:
| • | Install our integration app, Flexera One, and configure the connections. If Flexera One is the only data source, then you only need to configure data going one way to ServiceNow and you can set up the connection record in ServiceNow using the token from IT Visibility. If a data source is feeding ServiceNow, and we need to include that, we will need to set it up to pull data from ServiceNow and push it back again to normalize it. |
| • | In Import Properties we need to enable Insert Flexera software models and lifecycles, Update Flexera software models and lifecycles, Insert software installations, and Update software installations. |
| • | To avoid making new “company” records, make sure that coalesce for company is set to “name” so that we can match on name. That should prevent creating “duplicates,” but may not be enough to satisfy the platform team if their don’t want to allow updates to the fields on these records. Ideally, you would want to still be able to add the manufacturer_id field to the technopedia_id field in ServiceNow. This addition should not interfere with anything your internal team is managing. To do this, you would go to the transform map and remove the mappings for everything except name and technopedia id. This change allows it to still match on name but only include the additional mapping for technopedia_id. |
Now that you have things normalized, you should also have the associated software model lifecycles. When lifecycles are attached to the “normalized” models that the installations are using, you have a path to knowing what software installations are related to what “products,” and the “product type” field will note if this product has a license associated with it or not.
No further setup should be needed for this part to work. Now that the software installations have been normalized and associated to our model, the model should also contain related lifecycle data. The model is also related to the product with the product_type field that denotes if a product has a license associated with it or not.
Note:ServiceNow manages “licensable” at the product level. This is not as accurate as managing at the “model” or “release” level. It is, however, consistent enough to make a “relatively” accurate determination whether a software product will have a license associated with it or not.