Application Portfolio Management is a framework for efficiently managing software applications and services.
Size: 243.5 KB
Language: en
Added: Jan 16, 2016
Slides: 5 pages
Slide Content
Application Portfolio Management
Randy Robinson, January 12, 2016
The Challenge
How do we manage years of legacy
applications while continuing to deliver
changes and new applications to meet
growing business needs and demands?
Mergers, acquisitions and lack of
modernization investment can cause a
seemingly unmanageable and highly
complex situation.
Step One – All Apps Are Not Equal
You must first understand your application inventory. If your applications have not
been classified, you must develop a system that allows you to do so according to
business value and/or criticality. The traditional Bronze, Silver, Gold and Platinum
designations are widely used.
Simple categorization is not enough. A critical
success factor in this step involves defining
service levels for each category. Service levels
are defined by three key components:
availability, reliability and performance (i.e.
throughput or response time).
According to ITIL, the industry standard for IT
Service Management, a Service Level
Agreement or SLA is the contract between IT
and the business stating the availability,
reliability and performance thresholds for a
service.
Availability is typically measured using percentages of up-time over a pre-defined time
frame. Reliability measures the number of incidents affecting an application over a
specified period of time. Performance varies by application and generally measures
the response time or throughput compared to target ranges.
There are always underpinning service dependencies on internal or external (or both)
parties. Operational Level Agreements or OLAs must be negotiated with and agreed
to by the dependent service providers in order for IT to deliver the promised level of
support. Examples of OLAs could include servers, cloud infrastructure, storage area
networks, network resources, cooling, electricity, etc.
Step Two – The Business Wants Platinum Service on All Apps!
If your company uses a direct chargeback model, and
you already have fees associated with application
usage, factor that information into the classification
process. If you do not use direct chargebacks, or you do
not have your fees broken down to the app level, then it
is time to roll up your sleeves and build a cost model.
Start by identifying your key business processes. Next,
identify the applications required to support those key
business processes. Repeat these steps for less critical business processes. Your
business partners may not readily understand how to classify an application, but they
will know how critical a business delivery capability is. Use this information to help
classify the applications.
If you don’t have a direct chargeback
model, you can still build a “show back”
model which shows the business how
much of the total IT budget they are
driving with their app usage.
There are many ways to build an
application portfolio cost model. If you
are interested in “lights on” costs only,
then you will need to identify the
underpinning infrastructure components
supporting each application and build a
cost model to allocate the infrastructure
costs based on application usage. The
people involved in supporting the
application can either have all or a
percentage of their time factored into the
cost model, or if you have a granular time reporting process, the actual time spent
supporting each app can be derived. Be sure to differentiate between employee
costs and contractor costs when necessary.
In most cases you will need to consider direct and indirect costs. Direct costs
represent the amount of time reported by an employee supporting an application.
The time not reported against specific application support comprises the indirect
costs. One model I have used involved determining what percentage of the overall
time is spent supporting a specific application, then allocating the same percentage
of indirect costs
Sample Calculation:
T = Total Employee Cost
D = Total Employee Cost
assigned to specific
applications
T – D = I (Indirect Cost)
If application #21 consumed
2.2% of the organization’s
direct cost for a given time
period, then 2.2% of the
indirect cost during that
same time period should be
allocated to application #21.
If you are trying to derive the total cost of ownership, you will have to track business
and IT personnel involved in project work related to each application and add it into
the overall calculation.
Step Three – IT Service Management
You’ve categorized your applications and
now have a cost model which describes
how much each application costs to
operate.
Two key ITIL processes are required to
effectively manage the application
portfolio: Incident Management and
Problem Management.
Incident Management involves a service desk and the personnel responsible for
restoring the service. Measuring this activity is necessary to determine whether or not
the SLAs are being met.
Problem Management involves researching root cause of an incident and deriving a
change to be implemented to prevent recurrence.
Step Four – Reporting
It is important to produce metric reports describing the
incident and problem management processes over a
given period of time. This generally reflects the number
of incidents and the priority level, the number of
problem management engagements and the success
rate.
These reports should be targeted for specific
audiences who will use them in the planning and
prioritization processes. When possible, automate the
reporting process and make them succinct and
meaningful to ensure their value to the recipients.
Step Five – Continual Service Improvement
Wait! Don’t rest on your laurels, it is time to look in the
mirror and find opportunities to improve your processes.
Continual Service Improvement is one of the key
cornerstones in the ITIL framework. Once a service is
designed and implemented, the service owner should
immediately begin reviewing the key performance
indicators to understand if the service is meeting SLAs.
There are always opportunities to improve. Solicit ideas from the people performing
functions within the services and make a list of the suggested changes. These
changes should be added to the appropriate backlogs where they can be evaluated
and prioritized accordingly.
• • •
You can learn more about IT Service Management from the ITIL Reference books. The
Incident and Problem Management processes are described in the ITIL Service
Operations reference guide and Continual Service Improvement is described in the ITIL
Continual Service reference guide.
About the Author
Randy Robinson has 26 years of IT experience with fortune 500 companies. His
experience includes 15 years of executive management, mainframe and distributed
application development, project management, web development, enterprise
architecture, B2B app development, operations/infrastructure, IT service
management, and application portfolio management.
In 2013, Unum created a new IT organization called Customer Solutions. Randy
accepted a position as Vice President – IT in this new area. His teams are responsible
for Unum’s customer facing technology platforms which include: customer web portal,
mobile application development and call center software platform support.