What is an application package and what is the difference between it and an application deployment object? This is a question that often causes confusion, including with technically minded people. One of the reasons is that the terms are often mashed together as “application packaging” for speed and brevity reasons. We may even be guilty of this ourselves on occasion.
But there is a difference and, semantics aside, the difference does matter. It matters to the people involved in application packaging (who are typically engineers) and the people who create application deployment objects (who are typically operational staff). It also matters to the integrity and functionality of the process of packaging an application and deploying it to the devices and end users who need it.
What is an Application Package?
We answered this question in a previous blog, including covering the different types of applications and application packages that exist in modern corporations (read LOB, COTS, and MOTS Application Packages – What the Heck’s the Difference?).
In brief, an application package is an output created by an engineer that contains everything that is needed to ensure a package can be installed and run wherever it is required within the organisation. The process a packaging engineer goes through to create an app package depends on the type of package, but the end result is a tangible asset.
What is an Application Deployment Object?
An application deployment object is not an asset or digital entity in the same way an application package is. Instead, an application deployment object is a set of rules that enable the deployment of an application package.
The rules cover where the application package can be installed, including the type of device, condition of the device, or category of end user. The rules also determine the dependencies to install when the application package is installed.
Application deployment objects are created in application management platforms such as SCCM, Intune, App-V Manager, or AppVolumes Manager.
A Typical Workflow
Outlining a typical workflow can help with understanding the differences between an application package and an application deployment object.
- A packaging engineer (or an automation platform like Access Capture overseen by a packaging engineer) creates the application package.
- Quality assurance checks (QA) and User acceptance testing (UAT) processes are completed on the app either in a QA/UAT or pre-production environment.
- A member of the operations team creates the application deployment object in the company’s preferred app management platform.
- When a user or device meets the rules set in the application deployment object, the application package is downloaded and installed.
Segregation of Responsibilities Ensures Control
Understanding the segregation of responsibilities between packaging engineers and operational staff also helps with understanding why the difference between application packages and application deployment objects is important.
A crucial element is the fact that the creation of application deployment objects doesn’t always get the respect or recognition it deserves. In the minds of many people, it gets bundled up in the application packaging process where the creation of an application deployment object is an add-on rather than a distinct and core part of the process.
The following are simplified definitions, but they are nonetheless effective at describing the different roles each has:
- Packaging engineers are concerned with ensuring applications can be successfully installed and launched on the company’s devices.
- Operational staff are responsible for creating application deployment objects and are concerned with ensuring the right people and the right devices get access to the application package. Their job is to ensure application deployments are controlled and managed.
Working App Package + Controlled Deployment = Application Success
Both roles and areas of responsibility as described above are important. That said, it is the distinction between the two that ensures your end users have access to the applications they need while ensuring the application landscape in your organisation doesn’t become the wild wild west where anything goes.
It is the combination of successful application packages and controlled deployments that leads to application success.
