Application Portfolio and Services Portfolio are "Sibling" Portfolios That Should Live in the Same House

[rickyb]

Recently, I had a chance to get educated on the importance and management of both portfolios. Mark Bodman, Sr. PM for Application Portfolio Management (APM) and David Thigpen, Sr. PM for Services Portfolio Management (SPM) were kind enough to walk me through their applications and talk about how having both portfolios on the ServiceNow platform was a huge benefit to the enterprise. Here's what I learned.

The Service Portfolio Management (SPM) application in the ITSM product, documents the services provided by an organization. This is different from the Service Catalog which offers products along with the workflows, approvals, and fulfillment process for catalog items. The Service Portfolio documents the things IT does regardless if there is an orderable component. For example, a new employee is provided Internet access without having to order Internet access. Services in SPM are provided to employees without accounting on an individual basis. But that does not preclude the need for accounting the cost of providing those services. These "services that get taken for granted" need to be documented and their costs need to be accounted for. Without such documentation and accounting, there are gaps in the actual cost of running IT like a business.

The Application Portfolio, similar to the Service Portfolio, maps IT functionality the business requires, aggregated metadata used for planning purposes, and associated SW and Hardware that make up the applications.   APM is part of the IT Business Management (ITBM) product and provides the means to manage, maintain, and optimize an enterprise's application portfolio.

It didn't take much for me to see the benefits of managing both portfolios on a single platform. Having the portfolios within a single source CMDB adds dimensions that cross the planning domain, architecture domain, service domain, and operational domain. Being able to have a holistic view of your services and applications in that context creates a huge benefit over stand-alone systems that address each domain individually and have no real practical way of integrating to the level that a single platform provides.

This becomes glaringly apparent when service and application rationalization is considered. Dependency knowledge (service to application) has a lot of value. On a common platform, it is far easier to understand their interdependencies. When managing them in silos, you sometimes need to use the scream test — turn off a service or an application and see who screams the loudest to fully understand how an application or service is being used. Being part of a shared CMDB provides that high fidelity "map" of dependencies — no need to try and marry these key portfolios from multiple systems.

However, even with a common data source there is the need for a disciplined approach to ensuring all the right data is managed properly. Garbage in equals garbage out. It is imperative that an organization keeps the data up-to-date or planners will make poor decisions. Although the servers can be inventoried through discovery, it's not enough to tell you what applications are on them, or what services they're supporting. A disciplined approach to maintaining the data will pay off in the long run.

Maintaining the portfolios gets easier when ITSM and ITBM data are on a common platform. Having shared operational data around changes supports data integrity processes. Having operational data around incidents, problems, and subscribers supports rationalization decisions. Particularly in "on the fence" cases where all criteria are equal. Consider the decision to retire an application that is delivering middle of the road value. If you see excessive down time, multiple incidents, and problems your decision to retire "the problem child" is easier to justify. In the case of a deciding whether to retire a seemingly mediocre application, you see it supports a high value service to the business then that knowledge helps to support the decision to maintain that application.   It's fair to say whatever the scenario, shared data equals better rationalization decisions.

So, what's next… As IT evolves, we see a greater emphasis on organizations brokering services from external vendors, i.e. anything as a service. Currently and for the foreseeable future however there is need to view APM and SPM as sibling portfolios to manage IT effectively. In one poll taken at Knowledge17, the audience indicated that most organizations have a more complete application portfolio than a services portfolio. There are clear indications that this will change over time, and contributing to the trend are new standards like IT4IT which is re-defining the service as central to the IT operating model. Another trend to keep an eye on is Service Integration and Management. This is the management of a mixture of in-house and externally provided services. In that scenario IT acts as a broker of the external services to the rest of the organization and as an integrator with internal services. The Service Integration and Management model provides greater flexibility for IT to create a portfolio of applications and services making choices around build, buy, or broker.

Whatever the future is going to bring, I know Mark and David will have a hand in shaping it. I enjoyed our session and appreciated the knowledge they shared. If you want to know more about ServiceNow's APM or SPM applications reach out to either Mark or David on the ServiceNow community. I know they like talking about applications they're proud to be a part of.