Unfortunately, complex applications are a fact of life when managing any application estate. However, sometimes it is hard to know what exactly makes an application complex, what challenges you will face with those particular apps, and what percentage of your app landscape you can still expect to automate for packaging and testing.
What Makes An Application Complex?
A lot of large enterprises categorize their applications into simple, medium, and complex based on their size, their reputation for being historically difficult and the perceived complexity. While there are some obvious cases, you often have to dig a little deeper to find the really complex ones. For example, large applications (based on file size) are often categorized as complex simply because they are large, but we could have a very straightforward video player app that has 100 videos embedded that isn't really complex at all.
On the other hand, simple-looking packages that seem to be a good fit for automation could turn out to have a specific requirement (like a machine-specific license key that has to be entered) that makes them that much more complex. So, what makes an application complex? While there are too many criteria to list exhaustively, we can cover the vast majority with a few scenarios:
Scenario 1: Old Legacy Applications
Older legacy applications are a headache for numerous reasons. For one, they are usually configured and installed on an older platform that isn't necessarily supported anymore. Maybe requiring a version of Java for example. Secondly, they are usually larger applications that have multiple ways to configure them, which makes them more user- than machine-specific. This can often cause a lot of problems.
Examples of applications that can require a lot of configuration are:
- Reuters which can require specific configurations per country,
- Microsoft Office which could possibly contain hundreds of MSIs and transforms,
- AS/400 terminal emulators which often have hundreds of launch configurations, and
- Visual Studio, AutoCAD, and AutoDesk which all have a huge number of components.
Scenario 2: Apps Requiring Machine-Specific Licensing
In this scenario, even the tiniest applications could be locked down to specific nodes. When you install it, that package might require a machine-specific license key that would usually be entered by the user installing it, and then the application gets locked down to that node or machine. When you package an application, you essentially are creating a snapshot of what the original installer does. When you package an application that requires a license key and then deploy it to a different machine, it creates a conflict for the machine it is being installed on as the license doesn't match the new machine. Your application might be nicely packaged but it won't work!
A great example of this is the Bloomberg app which has a lot of machine specific license requirements.
Scenario 3: Modernizing Certain Applications
Modernizing and containerizing will often simplify application management tremendously — especially from a deployment standpoint, but also sometimes from a packaging point of view.
Yet there are certain scenarios where this could make it more difficult. For example, old legacy applications that write runtime files into specified locations rather than environments-specific locations in the OS can cause issues once you start containerizing them into App-V or MSIX. Also, virtualizing applications that have specific drivers or other system services that need to be shared with other apps could become problematic. When you containerize these, you are essentially sandboxing them which can cause a problem with shared resources.
How Much Automation Can You Expect With Application Packaging?
Regardless of how good your automation is (whether it is application packaging, testing, or any other automation), you will never fully be able to automate one hundred percent. On average, if you are able to automate 80%, you are doing really well. But when it comes to application packaging, it is really hard to say from the get-go what you can and cannot automate.
Initially, AppM was specifically designed to automate all the mundane tasks when packaging and testing, as an application packager will spend the vast majority of their day doing repetitive tasks. Automation frees them up to focus on really complex cases. As appM has matured, we have been able to tackle the more complex types of applications like, for example, the ones that have embedded MSIs in their vendor-shipped installers. By identifying those traditionally complex apps and analyzing what makes them complex, we have focused on outcomes that are achievable with automation, especially those that take a long time, and usually put a lot of pressure on the (often specialized) packager.
As a result, our customers can automate about 80 to 85 percent of their application packaging with AppM, Juriba's application packaging and testing solution. In the future, we believe that the number of complex packages will decrease significantly as organizations over time remove legacy applications from platforms they were never designed to run on and complex applications become more web-based as they go Software-as-a-Service. This leaves the fat applications that remain on-premise, which will become more suitable for automated packaging.
