Help
Join the Community
-
Documentation
Find detailed info about ServiceNow products, apps, features, and releases.
-
Impact
Drive a faster ROI and amplify your expertise with ServiceNow Impact.
-
Partner
Grow your business with promotions, news, and marketing tools for partners.
-
Store
Download certified apps and integrations that complement ServiceNow.
This is a thread to capture the best practices for managing your application portfolio. I fully expect this article to continue evolving as members ask questions, provide feedback and discuss additional topics.
When you first inventory the Business Applications in your organization, it's sometimes difficult to agree on a proper definition for the Business Application, the categorization structure, and metadata that describes an application. These best practices will assist you in defining your organizations application portfolio with a focus on cutting costs, aligning spend, delegating ownership, and properly distinguishing one application from another.
Federate ownership and up-keep of the inventory
One of the most important first-steps to address in making sure APM will be successful is to stand-up a full lifecycle management process for the Business Application so that owners are responsible for maintaining the application meta-data. When federating the management tasks, we often find that a minimum of 2 owners of each Business Application is required: one business owner and one IT owner. This provides the minimum number of stakeholders required to understand just about anything you need to know about every Business Application.
Not federating the ownership is the most common failure point of an APM practice. While Enterprise Architects and portfolio owners may want to maintain very tight control over all APM data, it's critical to make the process easy for application owners to keep the Business Application data updated to so that the details continue to be accurate and trustworthy when making decisions.
It's also important to limit the manual effort to maintain the Business Application data as well. There are a few approaches to consider to make this easier:
- Scope the required attributes to a minimum, make everything else optional.
- Incrementally add more details to the owners responsibilities, don't overwhelm them the first day.
- Leverage Assessments to help automate setting certain metadata by asking the owner questions and using the result to set a value. Data Criticality is a typical example whereby a question approach to setting the value is more effective than leaving it to the user to choose the correct value.
- Increase the cycle frequency incrementally, start with a yearly process, then bi-annually then quarterly. Most APM data doesn't change too often, so it's usually OK at first.
- Source values from a trusted source wherever possible. If you have a user table in the business application for example, provide a feed of that user count to set the "users" value in APM rather than relying on the owners setting that value manually.
- Incrementally automate each data source as they become available and mature within the platform. For example, use Software Asset Management (SAM) to compute software currency after you implement SAM on the platform.
Define a lifecycle process for Business Applications
When delegating ownership, you must also allocate rights to the appropriate owners to maintain certain metadata, and add processes to both introduce new business applications into the organization, and to decommission them with appropriate policies and re-allocation of assets used. This includes other aspects such as data retention policies, decommissioning all QA and development environments too. We recommend creating a service to add new applications from the service catalog that creates the Business Application record in the Planning stages of a project. This also help application teams consider that information in their solution such as what the criticality is, who will be the owners, what are the services, and all other key aspects required to maintain the application while in operation.
Broadcast the APM services to the entire organization as well. This will allows IT and business teams to declare what applications they are using that may not be part of the inventory. Usually, there is Shadow IT (undocumented applications) in use that will begin to show up, a self declaration process is helpful to identify them. Your service should accommodate declaring these Shadow IT applications and account for a process that brings them into the portfolio to ensure proper IT management and accountability with the minimum level of governance required.
Leverage the default services to help manage the application lifecycle to include creating a new one, requesting architecture review, and retiring it as well.
Governance and ownership changes
It's important that the portfolio be governed to ensure accuracy, completeness, and correctness of the data. This starts with governing ownership, as people will change responsibilities or leave the organization, creating a gap in ownership that must be filled in a timely manner. Often, these ownership gaps are not detected until someone has a question about the application, we recommend tying ServiceNow users into your HR system so that as people come and go, the appropriate re-assignment of business applications can occur. Likewise, as the responsibilities of employees change it's important to identify new owners to maintain the data.
On-boarding owners is critical as well as the responsibilities of keep the data up to date is critical. Often, GRC processes depend on APM data to scope audits, and owners maintain key attributes about the Business Application can effect inclusion or exclusion in audits, such as PCI (Payment Card Industry) where all Credit Card data must be handled properly. Failure to maintain proper data about the applications may result in missing an audit, therefore putting the organization at risk in being denied processing payments for products and services for example.
Periodic reviews leveraging surveys, assessments and data certification are leveraged to ensure accurate and complete data. Also, as the hardware and software products ages, the risks of those products being used beyond their end-of-support or end-of-life need to be understood and dealt with. Technology Portfolio Management leverages the Software Asset Management, Discovery and ServiceMapping to feed data into this risk calculation as part of the APM process. Mature organizations can take advantage of other products on the platform to ascertain technology risks across many dimensions, but End of Life tends to be rather difficult without the assistance of other tools to complete the picture.
Keep the inventory as flat as possible
Avoid defining your Business Applications as deep hierarchies, such as parent Business Applications with a deep nesting of child Business Applications. Defining such hierarchies obscures the inventory, preventing you from comparing applications, spotting differences and similarities between applications, managing ownership effectively, determining what business capabilities are supported by each, and capturing dependencies properly. The metadata comparison between Business Applications provides necessary criteria to compare each application with one another to determine redundancies, and identify cost and risks.
Additional risks of nesting Business Applications is understanding what the Child / Parent relationship actually means. Is this a dependency? A decomposition of structure? A platform app / platform host relationship? This ambiguity becomes difficult to determine after the fact, or to use the hierarchy effectively in planning activity. Some EA frameworks support this from a modeling perspective, it hinders the portfolio management efforts however.
Use a differentiating, descriptive naming conventions and Application Services
If you have multiple applications that are similar, make sure the naming convention distinguishes one form another. Similar Applications may be deployed to different sites, business units or geographic location. If they managed independently from one another, they should be named to include the criteria which makes each different. If the same exact code-base is used in different locations, you may choose to use the Application Instances to distinguish the different deployments of the same exact application. This may be the situation for applications deployed per store for retailers for example.
Example of one Business Application with multiple deployments as Application Services:
- Online Sales (Business Application)
-
- Online Sales - Dev Instance (Application Service)
- Online Sales - QA Instance
- Online Sales - North America
- Online Sales - South America
- Online Sales - EMEA
- Online Sales - APJ
We recommend using Service Mapping to identify each instance of the Business Application and to properly scope business impact, infrastructure and underlying assets used in each, which may be different even of the main code-base is the same. Unless you are using an automated release and deployment process, it's common there will be differences that need to be tracked and understood from an operational context.
Using the proper naming standard will pave the way for properly managing the portfolio as planers can better understand the operational use and footprint, and that operations can better understand the business context of each Application Service.
Platforms running many applications
When cataloging larger software, packages which hosts multiple independent Business Applications such as our own ServiceNow platform, first apply the practices of keep the inventory flat and to have each application distinguishable from one another per usage and by name. From there, you need to decide on how to distinguish the platform vs. individual applications for tracking / management purposes. The platforms can often change independent of the applications hosted on them, but by itself a platform usually served no business purpose until an application within the platform is created or deployed.
One method to group similar applications into one platform as of Kingston is to leverage the Application Family as a grouping metaphor for platforms. For example, all applications on the SAP platform within your organization would be related to the SAP Family, allowing you to leverage the family entry to group individual SAP Business Applications, regardless of the related category, processes, or capability supported.
Example:
- SAP Family — Application Family
- SAP (Finance) — Business Application
- SAP (HR) — Business Application
- SAP (Production Management) — Business Application
New Platform approach in New York
As of our New York release, we provided to new mechanism to capture the platform dynamic by adding 2 choices to the Architecture Type choice list:
- Platform Host
- Platform App
When you select Platform App, the default Business Application form reveals a required reference field to another Business Application which is a Platform Host. This reference allows you to distinguish the type of Business Application dependancies that exist in this specific host / app dynamic of most platforms. It also allows different ownership and attributes for both the host, and the apps they are hosting. This is also valuable when dealing with other processes such as Discovery and Service Mapping where this information can help in determining the Service Mapping results expected.
Separation of concerns
When attempting to document Business Application portfolios you may come across elements that are not really applications, rather they are software packages, or certain technologies, projects, or processes. It's difficult to properly maintain different things in a common, Business Application definition where you treat them all alike for comparisons and governance purposes. Separating the portfolio into the proper CI types / tables will ensure that each item in the portfolio is the same kind of item and managed together accordingly. Using the established definition from ServiceNow CSDM may help end internal debates, allowing you to quickly realize benefits from your Application Portfolio Management efforts using our out-of-box functionality.
One common point of confusion is to separate concerns between Business Applications from Business Services. They may seem very similar on the surface, however become very different when used or managed over time. Business Services are an aggregation of Business Applications, used in catalogs and operations to manage SLA and consumption of the business applications, and specifically Application Services as the "instances" of the Business Application.
Another common problem we see is overloading the existing ServiceNow CMDB defined Application (cmdb_ci_appl) as Business Application. The new CI type (cmdb_ci_business_app) was introduced in Istanbul, and should supersede the (cmdb_ci_appl) CI type for managing the portfolio. In Kingston, the Business Application is now provided on zBoot. The key differentiation is that an Application represents the physical executables deployed on services, populated through SCOM for example. The Business Application on the other hand represents the logical portfolio construct, usually populated by the application owners, aggregating many instances (Application Services) with different physical constructs and meta-data into one Business Application record that can be used to make planning decisions, even when there are no physical constructs available, such as a cloud hosted application.
Don't treat IT Business Applications any differently
If an "application" is used by IT to conduct important work, such as with managing events, batch processing, authentication, or managing infrastructure deployments make sure you capture them as Business Applications for your IT functions. They are really no different than Applications used in HR or Finance Business Application for example. Service Desk management container management applications such as Docker or Kubernetes serve an important business purpose for the IT organization which in turn keeps the business running smoothly. They require the same management needs to fund and keep current, and to rationalize when there are redundancies. Because IT applications are typically treated more like "plumbing", architects often overlook them when rationalization the portfolio or in demand management activities, making it very difficult for IT to demonstrate value, or justify funding. This is especially true as most IT Business Applications are foundational aspect for delivering other Business Applications and Services.
Separating Business Application from infrastructure
Business Applications these days may be hosted in the cloud, or on internal cloud platforms such as Kubernetes, Docker or VMWare which changes the physical footprint dynamically. It's important that you still define the Business Application as a logic construct that becomes an enduring record, even when the resources are highly dynamic. You may not be able to identify all the specific hardware related to each application at a given moment, that's perfectly fine for portfolio management & planning activities. The business context, ownership, risks, cost and value of Business Applications are important to track, especially when the applications are brokered entirely on cloud infrastructure such as those hosted on AWS, Google, or are custom applications developed on ServiceNow. This also includes many mainframe based applications which are often more obscure than those written for dedicated infrastructure or cloud platforms. No matter how obscure the physical aspects of a Business Applications, they need to be treated equally for ongoing management purposes.
Use ServiceNow Service Mapping and Discovery to automate the association of the infrastructure to the Business Application. From an APM perspective, often the teams within IT and business units will know what the URL is to access each instance of the Business Application, and can assist the Service Mapping exercise that will keep tabs on all infrastructure used and up-stream and down-stream dependancies. ServiceNow leverages the Application Service as the key entity to track each Application Instance, ensuring all environments are understood for governance and lifecycle management purposes.
Leverage trusted sources wherever possible
Within the ServiceNow platform, there are many modules used to manage different aspects of IT, including areas like GRC, Configuration Management, Asset Management, IT Finance Management, Project management, Service Management and Catalog Management. We treat Business Applications as just another CI type, related to the Business Service and many other CI's that can provide a wealth of information and details about each Business Application. As you mature the Application Portfolio Management practice, incrementally leverage appropriate systems of record to reduce the manual burden required to capture critical details such as cost, risk and value.
External data sources from ServiceNow may be leveraged to update Business Application detail, however there is an increasing cost to maintain integrations, so it's important to understand which is the true System of Record for any data source when leveraging external data. ServiceNow as a platform, has worked hard to reduce the need for a multitude of disparate IT tools and information sources, driving down complex, costly integrations.
Grouping applications for analysis
There are multiple grouping metaphors that can be leverage to analyze the application portfolio. For analysis, the most common mechanism to see similar applications together is the Application Category, a 2 level hierarchy that allows you to "bucket" like applications with one another for rationalization purposes. The Application Family is valuable for grouping like applications per family. The category structure is usually arbitrary and unique per organization created for rationalization purposes.
Other popular mechanisms for grouping applications is to relate them to Business Process, or Business Capability hierarchy, introduced in the ServiceNow Jakarta release. These are more business-oriented hierarchies typically created and managed by business architects.
Of course, metadata stored per application is another simplest approach to further refine and define which applications are alike or different. Typical metadata criteria such as business criticality, architecture type, deployment type (SaaS or On Premise) or data certification criteria are all useful in refining your analysis process to disposition applications in a rationalization process.
New Application Roadmaps in Madrid
We have created a new feature in APM that was already there to some degree in PPM, but now is explicitly a feature we support from the Business Application directly. The approach in APM is to leverage your Demands and Projects to capture the "action" that is to be taken at a high level. Just as many roadmaps imply, these are usually high-level, longer term intents that in a classic approach, may not be connected to funding vehicles. Our approach is to combine the funding vehicle to the Business Application in order to ensure a 1-1 match of the roadmap intents, and actual follow through.
This linkage can be seen all over APM, being able to right-click the bubble chart on the Analysis to create the demand, from the Capability Map, or from Technology Portfolio view. All of these views allow users to tee-up roadmap items as needed, preserving the context from where you are.
From the Business Applications
In the Business Application, we are able to see all the relates Ideas, Demands, and Projects by adding the Related Link in your form configuration, see below example where this is configured.
From this point, you can easily navigate between the Business Application and any related investment being planned against it.
To see the roadmap for your particular Business Application, a button is provides on the top of the form that opens up the roadmap view.
From a Demand or Project
When working on a Demand or Project associated with the Business Application, you can associate the Business application(s) that will be impacted. In the details tab, there is a multi-select option that allows you to scope which Business Application, and Business Capabilities will be impacted.
Likewise, the Demand Action at the top of the form in the "Business Application view" form, we can select the intended action of this demand. The Actions can be changes to suite your roadmapping needs, the most common actions such as enhance, decommission, replace, upgrade are provided by default.
The dynamic roadmap
With the application now connected to the investments vehicle(s), you can then use the "View Roadmap" button to bring them together in a dynamic configurable roadmap view that allows you to see all roadmapped items in real-time. As decisions to invest, changes in timeline, dependancies, or scope is changed in your planning office, the application owners can now see how the actual plans effect each Business Application in real-time.
Maturing your APM Practice
As you continue to evolve your APM practice with additional metadata, it's important to also continue to eliminate manual data collection by automating tasks that would otherwise require the application owners to manually manage the applications. The ServiceNow platform provides a unique opportunity in automating the data collection as you leverage and mature other products on the platform.
Some examples on automating data gathering are the User Count field in APM. By default, this field is manual selection of user ranges. Alternative sources for this information gathered from the user table, or from all the Service Subscriptions managed by Service Portfolio / Catalog Management access to the Business Application is another source in a mature organization.
Conclusion
There will always be special cases, complexities, and debates when evolving your Business Application portfolio. When questions arise, remember your key objective is to understand how your portfolio provides business value, what it costs, what the risks are, and which ones require invest to deliver strategic outcomes. Distilling a solid application portfolio to manage to these important criteria will be the basis for keeping the application portfolio optimized over time.
