<img src="https://secure.leadforensics.com/51024.png" style="display:none;">

Why Self-Service Is The Future Of App Packaging & Testing

Application packaging and testing hasn't changed much over the past twenty years — until now. Last month, we detailed some of the major historical changes up until the present, from MSI Installer to MSIX and beyond. Today, I want to walk you through why self-service is intrinsically linked with the future of app packaging and testing and how Juriba's AppM Platform enables you to do this right now.


The Traditional Application Packaging & Testing Process Is Long, Labor-Intensive, And Costly 

Traditionally, if you needed a new application within your business unit you typically start by manually raising a service request for a new application package within the appropriate system, i.e., ServiceNow. This request would be picked up by a special IT team (back at JPMorganChase, this was called the initiation team) to start a discovery process. The team would go back to the original requester and ask for things like the the source code / installer files, install instructions, the license key, how they want it installed, and more.

Only after the discovery process was finished, the application package would go into the packaging factory. Here, the application would be either re-packaged, or a .MST file created to transform the appropriate organizational settings). The package might be required in MSI, AppV and possibly Citrix formats. These days, you can also add Appx, MSIX and platforms like Numecent to the mix. After they completed the packaging process, the factory then would come back and ask the application owner to perform a User Acceptance Testing (UAT). Quite regularly, this step would fail because of improper installation or documentation — leading to a period of back and forth. Eventually, after passing UAT, the application would finally go to quality review and if passed, get published into the SCCM environment.

This traditional approach to application packaging and testing has several downsides. For one, the entire process, from request submission to publishing, would take somewhere between four and six weeks and quite often, much longer depending on team capacity. Lack of workflow management tooling also regularly left subsequent projects with no source code or a maintained list of application owners. Because of the number of touch points, getting an application from request to deployment was an involved, lengthy process and the costs per application were very high. This in turn meant that organizations might decide not to package every application, driving up the volume of shadow IT, and creating further security and compliance issues down the road.

Faster Technology Change & Evergreen IT Rely On Constant Application (Re-) Testing

The average IT Transformation project touches anywhere between 1,500 to 3,000 applications. For most organizations, application readiness has been the major roadblock to achieving velocity for change projects. Now, the situation is arguably much worse. Rather than running one big bang IT Transformation project every two to three years, technology change now happens constantly. Enterprises are bringing their entire user base to the latest Windows 10 and Office 365 ProPlus version every six to twelve months. Many business applications, like Bloomberg, require weekly or monthly updates. In other words, the only constant in IT environments nowadays is change. 

This philosophy shift requires constant on-the-spot testing and re-testing on various levels. For example, we might want to quickly run a batch of in-scope applications through some basic launch-and-load or smoke testing to determine their suitability and compatibility in a new Windows 10 update environment. Or we might want to re-package a number of applications to run virtually or within a new platform such as Intune as part of a platform shift.

The number of use cases for Evergreen IT testing is huge, but they all have one thing in common: it must be fast and easy. The only way to accomplish this is by empowering application owners to self-service the application packaging and testing process, automate and centrally manage it wherever possible, and seamlessly integrate it with the rest of the transformation / Evergreen IT management process.

How Juriba's AppM Platform Empowers Application Owners

Juriba is setting out to change the outdated ways with AppM. Our primary goal is to empower the application owner to manage the entire process themselves from start to finish using self-service — regardless of which format for input they have and which output they require. This is achieved by:

  • Enabling the application owners to truly take ownership of their application. Should they leave or move onto a new position within the company, all relevant people get notified — eliminating the problem of orphaned applications.
  • Making the entire process more automated, flexible, and future-proof. For example, non-technical product owners can automatically package applications to formats that we need for the future, like MSIX and IntuneWin, without needing to push this through the factory. 
  • Streamlining the end-to-end process — especially the difficult aspects. The actual application packaging part is not difficult. The difficult parts are all the surrounding processes of discovery, UAT management, and deployment. That's where the bigger cost challenge lies and that's what we're trying to fix with the self-service element. By automating the entire end to end process, you can drive significant time and cost savings into the environment.
  • Capturing functional application tests at point of entry. Time consuming, repetitive test management can become a thing of the past. By capturing functional tests during the packaging process, applications can be repeatably tested against a myriad of new OS versions, platforms and delivery mechanisms without any human involvement.
  • Seamlessly integrating it into Dashworks. Application packaging and testing should not be an isolated process but rather a determining factor in choosing migration strategies. For example, knowing which users are able to proceed because all their apps are ready to go ("green") can significantly accelerate the transformation. 

In conclusion, application packaging and testing is going to undergo major changes in the coming months. One of the most notable non-technical changes is the shift toward true application ownership by the appropriate end users who will need to be empowered to manage the entire process using self-service. Only then will we be able to keep up with the current pace of technology change. 

Automate Application Testing and Packaging Process