Application Management Challenges - An Application Packaging Perspective

Introduction

Application Packaging itself is just a small step within the whole process, starting with the application being requested by the business, and resulting in a finished product that is rolled out to production devices.

To be successful, it is indispensable for all the people involved to have a clear understanding of the whole process.

For more details on steps and best practices, you can read The End-to-End Application Packaging Process. Industry best practices and insights article.

As an Application Packager consultant for over a decade, I have been involved in many migration projects with a wide range of customers. Fortunately, my experience has included serving different sectors of the economy - from industries such as pharma and food to telecommunications and finance.

Something interesting I've seen is that regardless of the sector, most of the time I encountered a similar situation. The result of the initial audit I conduct of the available infrastructure to determine the number of packaged applications that need assessment or reworking, is almost always the same:

Organizations spend a significant amount of money maintaining and supporting applications that are outdated or no longer useful.

In this article, I want to point out a few simple recommendations that have had a significant effect with my customers when it comes to application management.

But first, I think it would be useful to see what's new in Windows 10 and how this is going to influence you, as an enterprise, from an Application Packaging perspective.

What is new on Windows 10 and how does it affect the application life cycle?

Starting with Windows 10, Microsoft introduced Windows as a Service (WaaS), a new model to build, deploy, and service Windows.

With WaaS, you get incremental cumulative updates (twice a year for Windows Feature Updates and once a month for Windows Quality updates) instead of getting a dozen of small updates each month and a new version of Windows every couple of years.

In the Windows 7 world, most organizations focused on deploying essential security fixes. As security is a very important aspect of every organization, I can understand the reasoning behind it. In practice, only a few organizations used non-security related fixes which led to a strong fragmented platform among Windows 7 users.

Going forward, this is no longer the case with Windows 10. Organizations are not able to handpick only the updates they want to install as they did on Windows 7. They now have two options: either choose a Windows update or postpone it for later.

Another thing to note is that they will not be able to continuously postpone or ignore updates indefinitely. There's no way to skip an update. Also, as they are cumulative updates, each one includes the improvements and fixes that were rolled out in previous versions.

Windows 10 Updates - Servicing and Support

According to the Microsoft Windows lifecycle fact sheet, the Windows 10 Enterprise Feature Updates released in March will be serviced for 18 months from the release date; whereas the ones released in September will be serviced for 30 months.

This is the amount of time each company will have to test and fix their applications. Testing an update, or better said, testing your applications with the latest Windows 10 Updates as soon as possible is now even more important than it was with Windows 7.

To understand how WaaS has worked for others, you can find some feedback here from Astra Zeneca – a company with 70k+ Windows clients.

Now, from an application perspective, the responsibility of fixing the issues relies mainly on vendors and app owners, and it involves IT Pros to remediate the existing packages that stopped working.

It is important to manage this process correctly, as failing to do so, and not considering the application life cycle, could become a burden to the organization - causing package portfolios to significantly grow.

As you can see, organizations need to act quickly, become aware of the changes and find the most convenient solutions to mitigate the risks ahead of time.

On the other hand, getting a Windows Feature Update twice a year, will ultimately replace the need for traditional Window migration projects - which tend to be costly and disruptive.

Basically, you can think of it as another way to fit all the effort required into the continuous updating process.

Isn’t that convenient? Honestly, if you go for the September Windows Feature Update release, the 30 months of servicing and support should give you plenty of time in case any issues arise.

Now that we’ve gone through the WaaS model, let’s lay out some of the small challenges you may encounter as a packager, with a significant effect on your application portfolio, especially for Windows 10.

The Current Application Management Challenges

Reworking the existing package

There are various causes that could lead to the failure of an existing packaged application and the need for reworking a package.

From a high-level perspective, many of these causes are related to installation and functionality issues. Some other scenarios include "changing requirements of the packaged application" that may result in the need to rework it and include the newly added conditions.

Whatever reason you might have to change an existing packaged application, you should first consider reworking and creating a new package revision before creating a separate packaged application to include the changes.

This way, you will carry on having one single packaged application for each product software - making your life easier when managing and deploying applications.

What does this mean in practice?
Let's assume you create an extra package for a fix you need to apply. With the new changes, you will have to manage and deploy two packages- doubling your work. And if you have two fixes and you create a package for each of them, that could triplicate your work.

There's a common question I have gotten from customers over the years - and one of the most valid ones I usually get. It goes something like this:

"But Horatiu, our application is over 3GB in size. Is it really necessary to follow this approach if the fix is only a few KB in size?"

There's not a one-size-fits-all response for this question.It depends on the circumstances, and there are exceptions to the rule. For those situations where it's not practical to redeploy a new version of a packaged application to all existing devices that have the old version installed, instead you might want to consider the following options:

• Having a separate package (or GPO) which caters only for the fix – this is meant to be used on existing devices where the original packaged application is already installed.
• Having a new revision of the original packaged application which includes both the original packaged application and the fix(es) – this is meant to be used on new devices.

Having an application and its fixes split all over the place (split in separate package(s) or pushed out via whatever other mechanisms such as Group Policy) could also add more workload to your deployment team. It depends on how you carry out the deployment.

Remember that if you don't have a mechanism in place to automatically push fixes on the devices when an original packaged application is installed, your deployment team will have to do it manually. Otherwise, without the fix, the application will not work.

Most enterprises use the Configuration Manager (MEMCM) to deploy their software to target users/devices. Although MEMCM has evolved a lot in the last couple of years, and is a robust deployment tool nowadays, application packagers should simplify the deployment process as much as they can and find the easiest way to get a fix or fixes pushed out.

Application housekeeping

With the new Waas model, it is expected from vendors and app owners to be hands on and act quickly in case any Windows Update breaks their application. This will probably lead to having more release versions per year than before.

But what does this mean for your organization?

That you should keep your applications up to date. And as you already know, if you run into a problem and you have to raise the issue with the vendor, the first questions they will ask are "What version are you on?" and "Are you using the latest version?"

If you are used to maintaining your applications up to date, then you won't have to worry. But if you're not keeping your apps up to date, this could impact the workload of your application packaging team, as each application must be packaged first before it is pushed to production.

What about the old versions of packaged applications? What happens with them once a new version comes in? Well, it would be ideal to try to get rid of them as soon as you can. In practice, this means:

• Retiring the old version of the packaged application from the Configuration Manager so that you prevent it from being deployed to any new devices (if you use the “application model").
• Upgrading all the existing devices to the new packaged version.
• Updating any other references to the old version of the packaged application (e.g. Task Sequences).

After following these steps, you can safely remove the old packaged version from the Configuration Manager. If you want to be even safer, you can also wait to get rid of it so that if there are any issues with the new version (not identified during the UAT), you can still roll the devices back to the previous version.

Still, there may be exceptions where you will have to keep two or more versions of the same packaged applications.

It may sound funny but I do recall one time when the deployment team approached me and told me: "Horatiu, we’ve got some bad news. Application X does not work with the new version of Adobe Reader which we are now in the process of rolling out to all devices".

In this situation, the customer didn't want to stop the rollout of the new version of Adobe Reader. What we did was exclude those devices/users from the upgrade list while the issue was raised to the app owner (or the vendor for an off the shelf application) to find a fix.

Once they fixed it, the deployment team upgraded the remaining devices to the latest version of Adobe Reader.

Application Rationalization

Periodic housekeeping is the bare minimum that each organization should do.

Also, companies should consider Application rationalization.

Application rationalization is the process of assessing all business applications within an organization to identify which ones should be retained, replaced, retired, or consolidated.

If we take into account that over 75% of the IT budget is allocated to operating and managing applications, this process could help in reducing the costs.

Application rationalization in its true sense requires an experienced team of stakeholders and SMEs with the right mix of skills and knowledge. This usually involves additional resources and budget, but in the long term, it leads to cost savings and business benefits.

Two of the main benefits it provides are:

• Reducing complexity – the application portfolio becomes less complex and easier to manage, offering business continuity.
• Lowering costs – the application portfolio becomes less costly, leading to cost savings or reallocation of the existing budget to other IT projects.

To get the most out of it, Application Rationalization must be an ongoing process with regular assessments of each software product needed. And it must take place at a very early stage - as soon as the application request is raised.

In contrast, many organizations put their employees’ user experience first, or at least above costs - relying on the familiarity with the product and deducing that it will help increase productivity. Sometimes organizations spend more budget in delivering what employees ask for without reviewing other readily available applications with similar functionalities.

There is no standard approach for this and it’s pretty much up to each organization to decide what’s best for them in terms of the application rationalization process.

Conclusion

Although it might look simple, application management is not a straightforward process.

On top of that, without being able to cherry-pick which updates get installed on which devices, organizations will have to be extra cautious to ensure their applications get tested as soon and possible and that they still work with the latest Windows 10 updates.

In retrospect, failing to recognize the challenges in advance could have a serious impact on organizations that use legacy applications.

I think organizations should review processes and update them accordingly so that they fit in this new Evergreen IT world introduced by the Windows 10 - WaaS model.