App Release Management - what’s behind it in detail

This article is the first in a multi-part series on the topic Application Lifecycle Management. It explains the underlying processes, introduces the stakeholders involved and highlights the challenges that need to be overcome.

There are basically two different types of applications: public or 3rd party apps, which can be found in the standard Apple or Google app stores and appeal to a broad target group, and self-developed or in-house apps, which are made available in the company’s own app store. Apps that are provided by companies for specific target groups, such as partners or customers, in public app stores are considered in-house apps in the following.

Several stakeholders are involved in app release management. These usually belong to different organizational units, and external service providers are often also involved. The following roles are usually involved:

The developers deliver the finished app with the required metadata to the product manager. Graphic artists and designers are often also involved, who create the necessary icons, logos and screenshots. The product owner aggregates texts, visuals and the code of the app and sends these elements to the publishing team.

The publishing team performs a series of special steps to make apps functional. For example, apps are signed with the company’s certificate and certain technical settings are made. We will go into this topic in more detail in one of the following articles. Figuratively speaking, the publishing team creates a “package” and hands it over to the UEM/EMM team (Unified Endpoint Management / Enterprise Mobile Management) for internal company apps, or to the app store team if the app is to be made available in the public app stores of Apple or Google. It should be noted that these activities for iOS apps can only be carried out on an Apple computer.

The UEM or EMM team is responsible for managing the smartphones. In this role, the team also takes care of the distribution of apps to users’ end devices in accordance with the specifications of the product owner. The app is subjected to various tests and the technical rollout is planned and carried out.
As all apps pass through the hands of the UEM team, it often performs other tasks in the context of the app release process. This is because the management of end devices is linked to corporate IT in many places. This team therefore often advises both developers and specialist departments on how apps can be efficiently integrated into companies, explains the necessary requirements and also provides support with troubleshooting. It also provides product managers with important metrics on the use of apps, although this data often has to be collected and aggregated manually.

As a result, the app is ready for use by the user. This quickly shows how well the previous steps have been carried out. The UEM team also has another important role in the life cycle of the app. It provides support and mediates at various points in the support process, as the specialist department, developer, product manager and publishing team are rarely involved in user support.

Business apps caught between careful testing and agile deployment

Due to high complexity and a lack of transparency, a release often takes several days to be published. Even the smallest errors, such as an incorrect version number or incorrect dimensions of logos, can lead to considerable delays, as the outlined process has to be run through again in full for each version of the app. Rapid feature releases, bug fixes and security updates therefore often tie up significant resources within the organization. External influences, such as regularly changing terms and conditions of the app stores or new versions of iOS, Android or specific software development kits, make things even more difficult. Necessary security, data protection and compliance audits can also delay the release process.

When does app release management make sense?

The typical application scenario starts with five to ten apps developed in-house in the company. Larger organizations may well have several hundred to over 1,000 apps in use. Each app needs to be maintained and developed further. In view of digitalization and agile methods, four feature releases per year is a rather conservative estimate. Some companies update business-critical applications every week. Then there are bug fixes and security updates.

Assuming 100 apps and a process run of 1.5 hours per stakeholder, this results in an annual effort of around 7,200 hours for the app release process alone and, assuming an hourly rate of EUR 50, costs of just under EUR 360,000. Simplifying and accelerating the processes therefore has great savings potential in purely monetary terms. This does not even take into account the positive effects of making new functions available to users more quickly.

Different internal teams, external service providers, different time zones, a lack of standards, a lack of security functions and frequent media disruptions are just a few examples of the many challenges that accompany the app release process. We explain how these can be designed securely and managed efficiently in Part 2 Deploying apps faster - but how?.