The mobile market is an environment where variability is, ironically, the only constant. From the continuous flux of user locations, to the increasing variety of devices and the corresponding OS permutations — the challenge of how to monitor, manage and update mobile applications is front and center.

It’s the epitome of an uncontrolled environment, and one that demands we shake off the comfortable protocols shaped by working with servers and desktops. Those quintessential controlled application environments are defined by readily known variables. It’s easy, to cite an obvious example, to push an OS update out over a network of desktops. With just a little attention, everyone is on the same page.

Enter mobility, which has completely (for lack of a better term) reconfigured what constitutes configuration management. Variation is the rule rather than the exception and you can forget the idea of a level playing field.

How is this changing the mobile application management mentality?

We think the answer begins with an essential premise: You can’t force personal device updates — be it at the organizational, team or even individual level. We have to break the controlled server/desktop mindset and that requires thinking about configuration in a dynamic, policy-driven way. And how do we do that?

Let’s begin with what’s understood. Every app is made of code and configuration. Now apply that understanding to the inherently dynamic nature of mobile devices. Standby strategies that work in a controlled environment have to go, e.g. configuration parameters such as setting the server to communicate with backend systems, dynamic A or B testing of user interfaces and then making usability and performance comparisons. Traditionally, these have been done by submitting an entirely new app, or even creating the infrastructure yourself.

If you think that way in mobile application configuration, you would set the IP address to the server you want to communicate with on the back end in the app. And if you want to make a change in the app, you would have to recompile and then ship it out to everyone who has downloaded it. But as anyone who has ever updated an application on their smartphone can attest, it’s hard to force that action! You’re at the mercy of everyone taking their time to download the latest version so they can work against the new IP address.

A better approach entails working out from within the application itself. It’s actually possible to reconfigure the app to fetch data while adding value beyond that configuration itself. We can manage it with good policy, that can be specific enough to manage what apps get what update. Instead of every app getting the same configuration block, you now have the power to change based on the device model, the OS, user location, etc. Configuration is, in other words, based on contextual awareness of the app.

That’s the mindset breakthrough we’re pursuing. We’re finding comprehensive awareness of the application’s users is the best driver of remote application configuration. We can layer sets of rules that filter by user type, their location, their permissions with the app, etc. Every app is made of code, and when you view that from a user profile perspective, you realize the extensive variables you can manipulate and test. It affords a remarkable level of customization and control.

And while that breakthrough is welcome, it’s just the beginning. The true advantage of user-driven remote mobile application configuration is how it informs policy management. You suddenly have previously unavailable levels of control and enforcement, down to data and function access, time of day, location, etc.

Remote configuration then is no longer just about command and control of the app itself; it’s the means to truly dynamic policy-driven application configuration that can drive an app’s acceptance, enculturation and bottom-line benefit.