Managing Applications: How much money can you save with a

Managing Applications: How much money can
you save with a Collaborative Workflow tool?
Abstract
In recent years the application has become king. For a business to remain competitive it needs to manage
applications and their lifecycle as efficiently as is possible. With the rapid rise in mobility it’s imperative that
organisations can be agile in their response to application management. In this white paper we will explore what
value can be added by using workflow tools for application management.
Initial Request
To run a business effectively your
organisation will require new and
updated applications from time to time.
This is typically known as "application
churn". The churn volume will vary
vastly depending on the organisation's
size and type. Small organisations may
only require a handful of new and
updated applications each month,
whereas very large organisations may
have to deal with a few hundred
requests in the same period. If you are
an IT system integrator then you will
have many customers all demanding applications each month. How is this best handled?
It depends on where you are right now; you may already have a system and process in place to handle these
application requests. Perhaps you utilise a helpdesk/service desk system to log these requests? Perhaps you have an
intranet or extranet webpage? Or perhaps it's simply a case of asking the right person (it's all about who you know
right?). The key here is that we need to be able make this request visible to the right team or individual.
Most workflow tools provide a portal for anyone in the business to raise new requests. Typically users are also able
to browse the existing application catalogue (if you choose to enable this feature) so that they can see if the
application already exists in the environment, or perhaps check on the progress of their requests. If you choose to
use AppTracker, the market-leading collaborative workflow tool, the form is fully-customisable so you can collect the
information exactly as you need it. You can ask users for the date they need the software, and if you're feeling really
brave you can allow them to set the priority of the request. If you already handle new application requests via
another tool (service desk system for example) then you may want to look at using our API to automatically create a
new request in AppTracker when one is created in the existing tool. Either way, it's key that your new application
request enters your application workflow as soon as is possible so that there are no hold-ups in moving the request
forward.
Value Add
Why is this process more efficient with a workflow tool such as AppTracker?



Centralised and standardised software request process
End-users can search the existing application portfolio to help minimise duplicate requests
API allows integration with existing systems
Based on our experience you can make an approximate time-saving of 20% if you use a workflow tool rather than
email or manual methods for managing software requests.
Validation
One of the benefits in using a collaborative workflow tool is that the right people will be instantly notified when
certain events are triggered. For example when we're setting up AppTracker we make sure that the team who
validate new software requests subscribe to specific notifications. This means that they will receive an email the
instant that the request for Adobe Photoshop is submitted.
Once an application has been
requested there should be some
form of human intervention to
validate that the request is
something the business wants to
proceed with. Does the requested
product duplicate functionality in
an existing product? Is this the right
version of the product for the
existing
desktop/laptop/tablet/server
build? Is a new license required?
Once a yes/no decision has been
made, this request needs to be
updated accordingly. If you're using
a workflow tool such as AppTracker
the concept of Accepting or
Rejecting a submission will exists
whereby an administrator can
accept or reject the request as
needed.
Assuming we accept this request, the application now needs to be passed to the Discovery team. This may involve a
short stroll and a chat, perhaps sending an email, or in the case of a workflow tool we simply assign the application
to the Discovery Team and they will be instantly notified.
Value Add
Why is this process more efficient with a workflow tool such as AppTracker?



Administrators can subscribe to instant notifications of new software requests
Administrators have rapid access to the existing software estate, so can quickly ascertain if the new request
is valid or not
Full tracking so previous requests can be reviewed if required
Using a workflow tool to centrally validate application requests can save approximately one third of the time when
compared to handling the process manually or via email.
Discovery
The discovery process is a critical one. It involves collecting and recording:
 Installation instructions ("Make sure you enable the XYZ feature and click 'No' when it asks for ABC")
 Configuration instructions ("After you've installed the application go into the options and change XYZ")
 Licensing details ("The serial number required for installation is 12345")
 Application dependencies and prerequisites ("This application needs Java Runtime 1.x")
 Who is the "Application Owner"
 Who will undertake User Acceptance Testing
 Known compatibility issues ("This won't work as a virtual app")
It very common for organisations to hold some installation instructions for some software titles. There will probably
be some gaps where discovery documentation was never created, or perhaps has been misplaced, especially if you
haven't been strict with your
application management. For the new
application requests it's a very good
idea to ensure discovery
documentation is created for all titles.
It's useful if you can setup a template
for this documentation so that the
discovery team always records a
consistent set of metadata for each
application. You will also want to make
sure that the installation source media
is stored in a central repository, and it's
good practice to setup a naming
standard for the directory structure
and filenames.
If you're using a workflow tool such as
AppTracker then you can setup a
discovery template so that the discovery team can record this information consistently. The bulk of applications'
discovery information should work well with this template. For very complex installations where large Word
documents are required to store the installation and configuration steps, these can be attached to the application in
AppTracker.
Storing the discovery data in a
templated format has one big
benefit: it can easily be reported
on. For example, it might be handy
to understand which applications
in our estate have a built-in autoupdate function. The screenshot
here shows a "Data Mining Report"
where I have queried the entire
application estate as to which
applications attempt to autoupdate. When managing a large
volume of applications this kind of
functionality can be a life-saver.
The final piece of the discovery jigsaw puzzle is for our discovery team to add some information on who the
application owner is and who is going to be in charge of signing off the User Acceptance Testing (UAT). Getting this
information up-front is going to save lots of waiting time further down the line. There is a dedicated tab in
AppTracker for adding these contacts. If you've used Active Directory as a data feed then we'll be able to
automatically email these contacts later in the process.
Let's assume our discovery is now complete, so we'll pop over and see the packaging team and let them know
there's a new piece of work ready for them to get started. If we are using AppTracker then we can simply move this
application into "Packaging". The Packaging team will get an instant notification that there's a new discovered
application ready for packaging with all the necessary documentation in place.
Value Add
Good quality discovery is an essential part of application management. Using a workflow tool won’t necessarily make
the discovery process more efficient, but it builds the foundations to provide efficiencies in subsequent processes.
Packaging
The packaging team are now aware that the discovery is complete for a new application and it's their job to build a
silently deployable package, be that a setup.exe with answer file, VBScript, MSI, or perhaps an App-V package. They
may also need to ensure that the application undergoes a basic runtime test to make sure it runs OK once packaged.
How do you capture and share all this packaging information? There are many possibilities ranging from simple text
files saved in the same folder as the package, to collaborative workflow such as AppTracker. We've been involved in
many projects where no packaging notes are retained whatsoever. This generally causes issues further down the line
when a rework of the application (update, patch, configuration change etc.) is required.
Here's a screenshot of the "Application Details" tab in AppTracker where the packaging information is recorded.
Note that AppTracker can be configured to collect custom data such as an internal application ID. This increases the
efficiency of the packaging team as it allows them to record packaging related data in the fields, plus add any
commentary in the Notes section. If they find any problems with the software they can be added and tracked in the
Defects tab. Compatibility testing results can be recorded in the Compatibility tab, and any dependencies can be
recorded in the Dependencies tab.
Once the packaging work is complete the QA team need to review this application. You may have a dedicated team,
or you may use "peer review". In workflow tools we move the application into the "QA" process and the relevant
team members are notified that the package is ready for QA.
Value Add
Why is this process more efficient with a workflow tool such as AppTracker?




Discovery information is instantly accessible for rapid package creation
Custom data (such as internal App ID) can be maintained alongside other application metadata
Centralised packaging information database and notes retained for updates/reworks etc
Dependencies and defects raised and tracked
Using a workflow tool for the packaging phase of application management allows you to save approximately 20% of
the time taken if you weren't using such a tool.
Quality Assurance (QA)
It's really important that organisations document and maintain guidelines for internal packaging standards. The
objective here is to deliver applications to the business which have a standard look and feel and which operate in a
predictable way. Here are the reasons we feel this is critical for all organisations:




It improves the user experience because shortcuts are presented in a consistent manner
It reduces support issues because there is a consistent approach to each application's look and feel
It eases support of applications as files will be installed into standardised folders
It allows you to locate and manage the application source files more easily due to standardised folder names
and structures

It can help to retain a clean user desktop reducing support issues
The internal packaging standards will differ for every organisation, but generally speaking they should cover:







Application package format (MSI? App-V? Setup.exe?)
Application naming standards (Include the vendor name? Include the version?)
Application shortcuts standards (Are desktop shortcuts allowed? Should readme.txt and Uninstall shortcuts
be removed?)
Application installation folder (Always install into "Program Files"?)
Automatic updates (Disable?)
Uninstallation cleanup (Is it OK for files to be left behind?)
Paths and settings (Should all paths and settings be variablised in MSI Properties?)
The key objective for the QA process is to ensure that the agreed standards have been met for every package before
it gets passed to User Acceptance Testing (UAT). It saves a lot of time if problems are identified during the QA phase
as they can be quickly remediated by the packaging team and re-run through QA. If however QA is skipped and the
application goes straight to UAT, there is a chance that the UAT person will miss one of the QA checks (eg. autoupdates weren't disabled). The application will then get deployed out to live machines, auto-update will run and
errors may start to appear as the users don't have local admin rights. This will cause support issues, and the
application will need reworking and updating on all the machines. That's a lot of unnecessary effort.
Most workflow tools provide a fully-customisable QA form which can be used by whoever is handling QA in the
organisation. When an application enters the QA process it's simply a matter of the QA person checking each item
on the form and filling in the results. They can then give an overall result (Pass/Fail) and move the application to UAT
(or return it to packaging). As always the relevant teams will be instantly notified of the change.
Value Add
Why is this process more efficient with a workflow tool such as AppTracker?




Standardised QA process which is visible to all
Customisable forms allow QA checks to be exactly as required by your organisation
Web-based forms allow the QA team to complete the QA checks rapidly
Dashboard provides "at a glance" QA performance historically
Managing the QA process using a workflow allows you to make a significant time saving of approximately one-third
for the reasons outlined above.
User Acceptance Testing (UAT)
Once an application has successfully passed through the Quality Assurance process we can arrange for the
application to be tested by the business (typically the application owner). Depending on your organisation's
processes this may involve adding the application to the deployment tool (eg. SCCM) or you may just manually install
the application on a test machine. If you are using AppTracker you could trigger a PowerShell script to auto-create
the required objects in your deployment tool.
Once we have the application ready for UAT we will need to engage with the business. It's quite typical for the
person who created the package to handle the communications with the application owner and oversee the entire
UAT process for that application. This has a number of downsides:





No centralised UAT calendar
No standardised form to record the outcome of the UAT
Tracking UAT progress is dependent on individual Application Team members
Application packaging technicians do not necessarily have the soft-skills required for managing UAT with the
business
Inconsistent approach to UAT communications (templated email? instant message? mentioned over lunch?)
There are ways we can overcome these problems. We may want to a) ask someone in the Applications Team to be
responsible for managing all the UAT, or b) have a dedicated person for this role. However both these are expensive
options as they either impact productivity (a) or require investment in a new team member (b).
A workflow tool such as AppTracker is another possible solution to this problem. Let's take a look at how AppTracker
helps with UAT:
1. DEFINE TEST SCRIPTS
Depending on the type of application being tested you may require different test scripts. A web application will
probably require a different test script than a standard desktop application. AppTracker allows you to create up to
six unique test scripts for UAT. Here's a screenshot showing how to build a test script.
2. SCHEDULE THE TEST
Now we are ready for our application to be tested by the business. If we need to add this application to a
deployment tool such as SCCM we might want to automate this via a PowerShell script. This script can be triggered
from AppTracker to further streamline the process.
To schedule the application for testing we change to the "App Testing" tab in AppTracker and click "New Test". We
are taken through a wizard where we can choose:







The test script required for this application (web application, desktop application etc)
The user who will be testing the application (if an application already has any contacts assigned you can pick
these from a list)
The Blueprint that this test applies to (a location, office or department typically)
The test start and end dates
The option to include a calendar file so the UAT dates can be added to the UAT person's calendar
The test machine name
The option to include an RDP file in the email so the user can connect directly to the test machine from their
own machine
3. END-USER TESTS THE APPLICATION
The end-user will receive a templated email from AppTracker notifying them that their application is ready for UAT.
Notice that an ICS file is included so the user can add this testing window directly to their calendar. Also note that an
RDP file is included which allows them to connect to the test machine and run their UAT without having to leave
their desk.
Let's assume that the user has connected to the test machine and is testing their application. To record the results of
the UAT they click on the "Sign Off" link in the email which will open this screen in AppTracker:
They can then submit the details of the testing, along with the UAT result which will ultimately be either pass or fail.
4. REVIEW THE RESULTS
The Applications Team can now review the submitted test results in AppTracker, including all notes added by the
UAT tester. They can view this result individually in the "App Testing" tab, or they can view the UAT results for all the
applications in the main Applications grid. Finally, the dashboard in AppTracker 4.5 and later contains widgets where
you can view success/failure rates for UAT.
Applications which pass UAT will be assigned the team responsible for deploying the application to the live business
machines. Where an application fails UAT it will be assigned back to the Applications Team for rework.
Some applications will require UAT by multiple areas within the organisation. This can get complex to track manually,
but AppTracker can help as shown below:
Here we can see that the application "Netxp SMSCreatorMini" has been UATed three times. One user passed it, and
two failed it. In a default instance of AppTracker we display this result as "Mixed", however we can easily change
this configuration so that this is a "Pass" or "Fail" if desired.
Summary
Managing UAT in using AppTracker overcomes all the issues previously listed:





No centralised UAT calendar. Solved with the AppTracker UAT calendar. Screenshot below.
No standardised form to record the outcome of the UAT. Solved with customisable test scripts.
Tracking UAT progress is dependent on individual Application Team members. Solved with centralised UAT
tracking in AppTracker.
Application packaging technicians do not necessarily have the soft-skills required for managing UAT with the
business. Solved with templated emails for UAT.
Inconsistent approach to UAT communications (templated email? instant message? mentioned over
lunch?). Solved with templated emails for UAT.
Value Add
Why is this process more efficient with a workflow tool such as AppTracker?




Centralised UAT scheduling and tracking
UAT email contains RDP file to allow instant access to the test machine from the user's normal machine
Multiple test scripts for different types of application
Web-based forms allow UAT feedback to be compiled quickly with just a web browser
Workflow tools introduces a significant increase in efficiency for the testing phase of applications. With AppTracker
you can save approximately 40% of the time vs manually scheduling and tracking UAT.
Live
If you haven't previously added the new application to our deployment tool then now is the time. Most workflow
tools can assist here in one of two ways:
1. By allowing us to trigger commands to run on a specific event, such as when an application is changed to the
"Deployment" phase. This script would typically create all the items in the deployment tool (and possibly
Active Directory too) so that the application is ready for deployment to live machines.
2. If the Deployment Team prefer to create the deployment objects manually then they can use the workflow
tool as an information source. What is the package name? What is the command line needed for install?
What are the prerequisites and dependencies? Workflow tools can answer all these questions without the
need for emails and phone calls to the packager (who happens to be on leave today).
At this point you may be interested in taking a look at your applications journey from request through to "Live" to
see how long it has spent in each process and identify any bottlenecks. In AppTracker we can do this using the builtin reports to create a pivot chart. Here we can see the amount of time (in minutes) that the application spent in each
process. It's clear that packaging took the most amount of time for this application.
Value Add
Why is this process more efficient with a workflow tool such as AppTracker?


Trigger creation of deployment objects (eg. SCCM Application etc) via PowerShell scripts
Centralised application knowledgebase provides deployment team access to all necessary information to
create deployment objects
In our experience you can save approximately 25% of the time getting the application into Live by using a workflow
tool such as AppTracker.
Retire
At some point applications will no longer be required. Managing standalone application retirements is not a complex
task, but it's important that everyone in the organisation has visibility of what is live, and what has been retired. This
is particularly useful when new applications are being requested as it may be that a retired application can be
reinstated, rather than it being created again from scratch.
One area where a workflow tool can add value to the retirement process is where application dependencies are
involved. Let's say we have a version of the Java Runtime which is a dependency for seven business critical Java
applications. How do we put controls in place to trigger alerts if someone decides to create a new package for the
latest version of Java Runtime, and retire the original Java Runtime package?
With AppTracker we can run custom scripts on a schedule. In this case we'd write a script which runs daily and looks
for applications with are:
a) A dependency
AND
b) Process is set to "Retired"
As soon as the original Java Runtime package is set to "Retired" in AppTracker, it will meet the above criteria an
email alert will be sent out to the relevant teams. This Java Runtime upgrade can hopefully be stopped before it goes
live, saving potential problems for those seven business critical Java applications.
Value Add
As described above, there are some real benefits to using a workflow tool when retiring applications, however in
most cases these do not result in a time-saving.
Conclusion
We have explored all the common phases an application passes through in its lifecycle. In six of the eight phases we
have shown how introducing a workflow tool can save anywhere between 20% and 40% of the time taken.
To get an idea of the real savings you can make please refer to our ROI Calculator: www.apptracker.co.uk/roi