Creating and maintaining a corporate app store: Strategies for success
A comprehensive collection of articles, videos and more, hand-picked by our editors
Editor's note: This is the second in a series of expert tips on creating and maintaining a corporate app store...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
for employees. Part 1 described how to determine whether your company needs an in-house app store. Here, in Part 2, contributor Tom Nolle describes steps for planning and launching such a store.
So you've decided to launch your own corporate app store and you've carefully reviewed the issues involved. Now it's time to begin the real planning and deployment.
To ensure your corporate app store's success and to capture the benefits you've identified, you must:
- Set policies
- Obtain licenses and application program interfaces (APIs)
- Design the user interface
- Work with your app providers to test the interfaces and graphical user interface (GUI) in concert
- Establish your enforcement framework
Initial corporate app store steps
When planning and deploying an in-house app store, it's important to touch base with all employees affected by the decision. In addition, of course, you should update personnel polices to cover the store's use. Doing so goes a long way toward eliminating potential sources of employee friction and reduces the risk of potential legal challenges to your practices. Be sure to enlist human resources and your legal department in this process -- this isn't a task an information technology team should tackle alone.
You'll never anticipate every possible problem during testing, so expect app store maintenance to be an ongoing task.
Next, connect with each of the app sources you've identified and obtain the relevant retail licenses and documentation governing use. Forward this information to your legal department for review, but keep a copy for yourself. It's smart to do a quick review with your in-house legal counsel to make sure you understand what the license commits you to doing and what you need to do to enforce license requirements.
This is also the point to obtain documentation on each app store API. Generally, these APIs will provide options for selecting apps by name, provider, type, etc. Meeting corporate app store goals will involve selecting or excluding applications, so your app store will employ filtering between app store APIs and your GUI, presenting users with the options your policies permit. Careful review of this filtering process is essential for controlling which apps your users see.
Another issue to address with APIs: updating applications. Most app stores will provide a way to scan installed applications against available updates, which is important for ensuring applications are up to date and bugs have been fixed. In some cases, you can use this same set of update APIs to provide an inventory of installed applications, which can be helpful in ensuring users aren't circumventing restrictions on application use. In other cases, though, you'll need a different set of APIs, because while all commercial app stores interface through APIs, the API structure differs from store to store. Sometimes the same APIs support updating apps, as well as adding and deleting them, but in other cases, you'll need to use a different API for updates.
Next up: hosting decisions. You'll need to host your corporate app store on something -- most often your own virtual private network. Implementation is a matter of creating an application server that will provide a link to vendors/providers app stores, and then connect to a Web server to present an attractive and useful interface to users. If you have multiple in-house app stores -- for instance, because of restrictions in your bring-your-own-device (BYOD) policy -- you may want to have an application server for each store to keep the logic separate. Use separate virtual machines or a cloud process if utilization doesn't justify a dedicated server.
Designing and testing corporate app stores
In designing the flow between the GUI and the app store you are avoiding the risk of users placing orders unintentionally or orders not being followed through to installation. Generally, the intermediary application server will be responsible for ensuring each order from your users is properly completed. Obtaining positive feedback on success and installation through your GUI is important for avoiding confusion.
Testing the corporate app store requires coordination with the device vendor or operator that owns the underlying application store resources you're using. These providers will offer a "test mode" operation to permit you to validate the application without placing orders. Be sure to follow this process.
In fact, it's safest to invoke this test mode in the intermediary application server to ensure the entire corporate app store is in test mode and can't be used to place orders by accident. Don't rely on test mode indicators from users.
When you've completed testing with a test mode interface, validate the application by doing a small-scale pilot test with users. The goal: ensuring "normal" application browsing and ordering and special conditions, such as order abandonment, are properly handled. The most difficult thing to test fully is the set of conditions relating to loss of a mobile device signal during ordering or delivery. It's easiest to test this in Wi-Fi mode, if available, because you can turn off the hub to simulate loss of service.
Because application updating is important, find out whether a test mode update function is available from the device vendor or operator you're using. Then exercise the update function in this mode, if available. If you can't test updating this way, you'll have to run your pilot test long enough to have multiple real updates available in order to properly validate the process.
Options for corporate app store development
If your internal development processes and skills won't support in-house store development, you may be able to get customized store facilities through the device vendor or operator, or at least get recommendations about app store developers and integrators who are certified to work with the vendor or operator. In our experience, users who elect this option still report better results if they follow the planning guidelines we've discussed, and if they brought in outside development when they've reviewed licensing, API and GUI design options and made preliminary selections.
Users also report that in-house app store issues can crop up any time during the first year of the operation. For that reason, be sure in-house or outside developers are prepared to diagnose and fix problems. Mobile devices are exposed to many unusual service and usage patterns, so some issues will take time to develop. You'll never anticipate every possible problem during testing, so expect maintenance to be an ongoing task. Because you'll probably need to modify your corporate app store's inventory, you can assign the same team to handle that and manage corrections to the applications involved.
A final point to consider involves evolving the app store that your device vendor or network operator provides. APIs may change, and some vendors and operators may start providing a kind of "private label" or "virtual app" store that may supersede what you've done. Don't be afraid to move to a new strategy if it makes sense in terms of meeting your goals and controlling costs. Those are the metrics that will count in the end.