Your Practial experience Needed: Starting Application Portfolio Management in ServiceNow

[mohammadanwer]

Hello ServiceNow Community,

I am exploring ServiceNow Application Portfolio Management from an enterprise architecture and transformation perspective, and I would appreciate guidance from practitioners who have implemented or used APM in real enterprise environments.

My key questions are:

1. What are the minimum data elements we should capture first to establish a reliable application portfolio in ServiceNow APM?
2. How do you practically assess application health, business value, technical risk, cost, and duplication within ServiceNow APM?
3. What approach works best for application rationalization decisions such as retain, retire, replace, modernize, or consolidate?

I would be grateful for any implementation lessons, recommended dashboards, maturity approach, or examples of how APM is connected with CMDB, business capabilities, technology portfolio, and transformation roadmaps.

[Jim Palmer]

In my practical experience with APM, most of the implementations focused on lifecycle management (support risk) and data collection in the platform before the indicators.

Being an infrastructure person, things like TRM, TPM and VR fit more within my operational lived experience and I found the indicators to be more theoretically useful but never implemented in my engagements.

Minimum elements always started with the CSDM in the design domain, Business Applications and Capabilities.

This creates an inventory and links to the function they provide. The starting point for consolidation. The recommendation is to start with the most important Business Apps, but if you have the list, get them all in. But as you move down the stack to Service Instances, limit your scope as the data volume becomes difficult.

We also focused on the non-technical attributes like owner (business + technical), lifecycle stage (plan/build/operate/sunset) - being in the design domain in CSDM.

As a minimum this shows the application landscape, wat they do for the business and provide a source of truth. Then Enterprise Architects can assess health outside the platform (if necessary) based on the inventory. This stage doesn't require the APM plugin though.

Note: data certification is important to maintain the data.

Then move into the Service Instances (a.k.a. Application Service) components. If you want any operational risk indicators in the platform, this is critical. It links the design to the service delivery domain.

With some form of service mapping (top-down, manual, tag whatever...) the versions, vendors, the components of the delivery systems can be evaluated. Without mapping, you at least can view the deployed instances and define owners so you could at least ask for more data from the owner teams to help assess health. In a previous life, I was asked every 6 months to provide the software versions and lifecycle status of the infrastructure components I managed to the EAs for risk management.

In a lot of businesses the service instances and components are institutional knowledge or stored in write-only documents. If you can document and manage this in the platform, life becomes much easier and not just in the EA sense.

With the instances recorded and mapped and Software/Hardware Asset Management implemented, you get the software/hardware lifecycles which provide lifecycle visibility, or at least the ability to eyeball manually. This is where most of my implementations have focused on. Being able to manage vendor support risk (n-1 version support).

They rarely got the time to setup the indicators in the project, but the data was there.

Some touched on TRM, but again, not indicator based but more for "here's a our approved list of technologies". In one enagement this was planned to link to catalogs for new technology requests and architectural decisions and to track technical debt and drift.

The last phase was the automated indicators and reporting.

That's where application health, business value, technical risk, cost, and duplication can be evaluated in the platform. Though if you have the business application metadata and owners, the EAs can do this off platform, rather than using indicators and work in (shudder) spreadsheets and record decisions in the platform.

Considering my operational background, I always look at things that effect the runnning of the platforms. It's not a bad thing that this data is already in the platform.

These all have to be rolled up to the Service instance -> Business application

Operational Risk:

• Component lifecycle health (min, max, median software component life).
• Vulnerability numbers (how many recorded vulnerabilities in the last x days, over lifecycle, with CVE score
• Technical debt; Recorded by project (the tech debt register), TRM drift, accepted risk records.

Operational costs:

• Incidents, problems, changes raised (success and failure rates, age, outages, etc).

Financial costs:

• Very few implementations touched on financial indicators as that wasn't really captured in the platform. You can try HAM TCO if you have it working or Workflow Data Fabric to source financial data from other systems, but that's just an idea, I don't know if it'd work.

Business value:

• User surveys

I've stayed away from the strategic decision making process as that's a task for the EAs for the organisation. Enterprise Architecture (APM) provides visibility for decison making at the Enterprise architecture board and SPM provides mechanisms to track and process decisions, ideas, risks etc.

I will say that these indicators are my go-tos, but each EA group have their own ideas of what is important and their weighting. So suggest the indicators to the EA group to determine whats important to them and iterate so they can see what they get and validate often. Especially since business value is highly dependant on what the org values - scalability, security, ease of operation, stability, agility.

Summary;

Start with the Design domain and inventory all your business apps.

Move to Service design and Service instances domain - with relationships - for a single Business App, just because mapping is hard.

Design and implement your data collection & indicators against the archetype.

Then start rolling out against other Business apps of a similar type to allow evaluation.

I hope this helps.