The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Mark Bodman
ServiceNow Employee
ServiceNow Employee

Overview

As organizations implement new solutions by leveraging technology building blocks from vendors, over time the number of different technologies becomes large and difficult to track and manage. As technologies become older with many different versions / models, they eventually turn into a liability to key business functions and products if they are not updated periodically, and timely.

ServiceNow's approach to Technology Portfolio Management addresses the needs to manage the portfolio of technologies in a very different way than traditional means, but delivers all the results with decreased effort, greater fidelity and accuracy than are possible with traditional approaches. 

Traditional approach to Technology Portfolio Management

Most IT organizations who have a Technology Management function focus on collecting and cataloging the currently used and potentially used technologies the organization is interested in. A typical aspect of collecting the inventory is to collect the vendor, product, model and lifecycle of the various hardware models or software versions.

Vendor Lifecycles


Keeping up with the vendor products and lifecycles is a continuous process and limited to the capacity of the teams responsible. The most critical aspect of the data needed is the lifecycles of the technologies that the vendor provides, which is typically expressed, or inferred based on support policies. The core lifecycle phases of interest that are most common are:

  • General Availability: The date that particular model is available for purchase
  • End of Life: the date that product is no longer available for purchase
  • End of Support: the date that product is no longer supported by the vendor

While these are the most common phases, it’s typical that additional phases to be added if known such as Early Adoption, Extended Support and Limited Availability for example.


Internal Lifecycles


In addition to knowing the lifecycles from the vendor point of view, every organization has a viewpoint on how the internal use of that technology should be managed. Often, these lifecycles are informed by the vendor lifecycles in addition to internal licensing, risks, compatibility testing and ability to support the various models. The typical internal phases are similar to the vendors, with an added internal aspect to the lifecycle that’s managed internally. These internal phases would typical address the following concerns:

Limited Availability – software or hardware in use but require approval to use
General Availability – Same as from the Vendor, but may override the dates
Declining use – Not the currently best option, there is another model that is preferred
Remove – Hardware and Software actively being planned to be removed from use
Forbidden – Hardware or software that should not be used
Exception – Hardware or Software that can be used by exception only

Publishing standards


Once the inventory of technologies along with lifecycle data is created, it’s a common practice to publish the standards in a “Book of Standards” or “Standard Catalog” which is distributed as a guide for the broader organization to identify what technologies the move away from and go towards.  Often a standard catalog addresses communicating different coming and going versions of the same product, while also identifying which technology the organizations intends to move away from, or to abandon entirely. Common shifts would topics like going from on-premise to cloud, use of container technologies, moving from mainframe to scale-out, or transitioning between paid to open-source technologies.


Governance


With the tracking of the technologies comes the governance processes most often associated with the current and future use of known and new technologies as they are identified. With technologies currently available or in use, organizations will focus on the technologies in the later phases of availability from a vendor or deemed not the most suitable use for the organization combining these 2 lifecycles into a single governance approach. For example, tracking waivers to using technologies if there is a hard dependency on undesirable technologies identified, or an exception when timing or resources can’t address technology upgrades or transitions fast enough, presenting a known but acceptable risk.

ServiceNow approach for TPM


Given the ServiceNow platform and product coverage, our approach to managing the Technologies can be more baked-into the fabric of managing IT. That is to say, leverage other products and features of the platform that naturally provide critical functionality and data that’s required to implement a Technology Portfolio Management function but in a more robust way long-term.

find_real_file.png
Vendor and Internal Lifecycles


The ServiceNow approach to managing the technology lifecycles compresses the 2 different lifecycles into a flexible framework that focuses on the Vendor lifecycle primarily, allowing customers to override the lifecycles where needed. Various internal lifecycle concerns would be managed in context of the overriding lifecycle and other approaches we will cover below. This approach greatly mitigates the labor required to keep the data updated to use in subsequent governance processes.

find_real_file.png

In this example, we see the General Availability date of this software model provided by the Publisher is 10-2015. Also, we see the Internal End of Life date for this same software model is 4-2019. In both situations, the source for these lifecycles are internal, which indicates that you are managing that data on your own. The Source may be different if you load the data in from a lifecycle data provider, or by leveraging the ServiceNow provided data in our Software Asset Management Premium product.

Lifecycles in Software Asset Management subscriptions

Given the shared platform data model, when Software Asset Management Premium is installed, we are able to leverage the Asset Management Premium features including the added value of Vendor lifecycles data feed that is provided for known software. In this example below, we see that the source column is “S” which means ServiceNow is the source for that publisher data.

find_real_file.png

Focusing on as-is use of software and hardware first

The added benefits of using ServiceNow to tackle the lifecycles from Asset management doesn’t end at the lifecycles. There are other benefits in using our on-platform Asset Management solution to accelerate the as-deployed inventory of standards that is typically impossible to reconcile in a separate Technology Portfolio Management system. By starting with what’s currently in use, the main benefit of Technology Portfolio Management can be realized which is to identify the highest risk areas and “hot spots” where at-risk technology use presents critical business risks. The additional features Software Asset Management provides that are beneficial for Technology Portfolio Management are:

  • Normalization of product naming conventions based on meta-rules
  • Asset use, count and context
  • Leverages the ITOM discovery; only one probe needed
  • Additional asset context such as contract, licenses & entitlements, and risk metrics

Leveraging ServiceNow products for TPM

Given the many ServiceNow platform with our many products, in addition to the TPM feature, we leverage them together in being able to address aspects of the Technology Portfolio Problem. Here is a list what products are helping to solve various TPM problems:

Discovery – Provides an up-to-date inventory of Software and Hardware in the datacenter.
Service Mapping – Provides the map between the Instance (Application Service) and the discovered infrastructure.
Software Asset Management – Provides the normalization, lifecycle, and entitlement tracking.
Application Portfolio Management – Application inventory, ownership and related instance and SW inventory custodian.

This is not an exhaustive list of products and benefits, but it should become clearer on how ServiceNow is able to readily address operational use of standards more readily available than any other stand-alone method.

Assessing the technology risks

Because the ServiceNow approach focuses on the operational aspect of Technology Portfolio Management first, we are able to better automate and assess the risks associated with using technologies that are close to or beyond their supported lifecycles. The risk scores are set first at the Product Model level, then bubble up to the Application Service, and ultimately the Business Application where the owners of the Business Application can take action.

find_real_file.png

These calculated Business Application risks are then revealed on the Business Capabilities where the Business Applications are used.

find_real_file.png

The risk calculation can be configured based on the organizations tolerance for using technologies that are getting close to the critical lifecycle phases that indicate that end of life or end of support timeframe is drawing near. In situations where extended support has been negotiated, your internal lifecycles will override those provided by the vendors.

Mining the CMDB to understand how technology is used

To deliver the overall technology foot-print used in a Business Application, it’s necessary to short circuit the myriad of relationships that naturally exist in a CMDB between the various CI’s and dependencies. To identify that concise list of software (and hardware) being used exactly required a process to gather up all the relates SW, deduplicate it, normalize the naming conventions, and to get the other product meta-data subsequently used in the risk calculation.

This process APM provides as of Madrid is similar to what cave-divers do in “spelunking” to find all spaces available in a cave system. In our approach, we traverse all CMDB relationships associated to the Application Services (think instance of the Business Application) in order to present a concise list of Software actually in use. The following picture is a typical result of that process, allowing application owners to select which software models are pertinent to keep tabs on, which ones are not.

The following screenshot shows the related normalized software inventory that was identified.  The status column indicated what Software Models are currently associated to a Business Application for risk purposes, or not.  The Ignore column allows you to ignore some Software Models in the risks calculation, this is useful for discarding less important software models that were identified, or used for another Business Application shared on the same infrastructure.

find_real_file.png

Governing technology consumption: Building a Technology Catalog


Given ServiceNow’s focus on services, technology teams within our customers often take advantage of being service providers to their IT colleagues too. User experience improves, and management of the lifecycle of the consumption, experience for consumers, and better governance of the processes becomes a more integrated and seamless aspect of managing the consumption of technologies. It is recommended that approved technologies have Services created and provided in a catalog. By virtue of being in a catalog for consumption, they are approved for use. This approach makes it easy to see and consume any technology that is approved, have well defined offers, provide automated fulfilment and track subscriptions. technologies approved with the often-overlooked aspects of also providing an easy self-service vehicle allowing those in IT to leverage them. This includes license entitlement tracking, usage tracking, understanding costs, capacity, track who / what is consuming the technology, and being able to fulfill requests that require more complex handling through the appropriate built-in workflow processes. For those technologies that are in a limited use phase for example, additional approval steps can ensure that the use is justifies, tracked, and approved by the stakeholders concerned.

Other use cases and considerations

Taxonomy

The taxonomy of Software and Hardware is provided with UNSPC taxonomy by the Software Asset Management data and subscription by default.  This is a world-wide accepted structure that addresses the categorization of the software being used.  

The main source for the codes:https://www.unspsc.org/

Software is found in section starting with 432.  Here are the main categories you will typically see:


432315 BUSINESS FUNCTION SPECIFIC SOFTWARE

432316 FINANCE ACCTING, ENTERPRISE RESOURCE PLANNING ERP SOFTWARE

432320 COMPUTER GAME OR ENTERTAINMENT SOFTWARE

432321 CONTENT AUTHORING AND EDITING SOFTWARE

432322 CONTENT MANAGEMENT SOFTWARE

432323 DATA MANAGEMENT AND QUERY SOFTWARE

432324 DEVELOPMENT SOFTWARE

432325 EDUCATIONAL OR REFERENCE SOFTWARE

432326 INDUSTRY SPECIFIC SOFTWARE

432327 NETWORK APPLICATIONS SOFTWARE

432328 NETWORK MANAGEMENT SOFTWARE

432329 NETWORKING SOFTWARE

432330 OPERATING ENVIRONMENT SOFTWARE

432332 SECURITY AND PROTECTION SOFTWARE

432334 UTILITY AND DEVICE DRIVER SOFTWARE
432335 INFORMATION EXCHANGE SOFTWARE
432336 ELECTRICAL EQUIPMENT SOFTWARE

432337 SYSTEM MANAGEMENT SOFTWARE


Future technology plans


In many organizations, the ability to communicate future technologies planning to be introduced and required to used is an important aspect of technology lifecycle management. In a standards approach, this is typically done by communicating those technologies in an emerging phase, or with general availability dates in the future.
Leveraging PPM Project Roadmap views grouped into portfolios of planned technology efforts or transitions, customers can readily convey the particular timeline where new technologies will be introduced, and better plan impacts of those changes through the project scoping, resourcing, and funding activity. Project or portfolio naming naming conventions can be used to help convey technology transition themes, or specific technology transitions such as OS upgrade efforts or hardware refresh activities.
Likewise the a service catalog can be leveraged to commutate what standards will be introduced at the point of consumption. This providing a natural mechanism for those interested in a new technology that's not mainstream yet to register their interest.  Technology engineering teams responsible for making them available can engage the early adopters, and ensure a smooth transition of technology use as the new standard. 

Hardware Lifecycles

Technology lifecycle management often includes tracking the Hardware Lifecycles in addition to Software. Given the commoditization of Hardware and push to the cloud this is a diminishing concern for most IT organizations these days, but still a concern. Currently, ServiceNow doesn’t address hardware lifecycle management in same way we manage Software Models. In addition, often Hardware is used until it fails, or is fully depreciated. The main drivers for replacing hardware are therefore capability in the hardware, space and electricity run-rate costs, availability of spare parts or simply scheduled upgrades in keeping with the Moores law progression for example.

Conclusion

In summary, ServiceNow allows for the current-use of technologies to be identified, risks calculated, and impacts to business capabilities readily. ServiceNow provides an easy mechanism to provide consumers self-service processes to use technologies, and a robust tracking mechanism that ties workflow and asset management solutions where entitlements are managed. Only ServiceNow is able to seamlessly integrate otherwise disparate practices and processes into a seamless technology management discipline that is both pragmatic, and detailed for both the technology owners and their users.

More Information:

About Technology Portfolio Management

About Software Model Suggestions feature

Video on how the key ServiceNow products work together for TPM

 

6 Comments