Editor's note: This is the last in a series of expert tips on creating and maintaining a corporate app store for...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
employees. Part one described how to determine whether your company needs an in-house app store. Part two offered advice on launching an in-house app store. Here, in part three, Tom Nolle describes how to maintain such a store.
Too often, companies operate under the assumption that once they've deployed their corporate app stores, they've finished the hardest part of the job.
Companies should treat their corporate app stores as they do their websites, keeping them fresh, attractive and responsive to the needs of the users they're designed to serve.
Ultimately, though, correctly maintaining that corporate app store may be even more important to long-term success than getting the initial deployment right. After all, if the app store works well, it will become a resource that users depend on -- and if it doesn't, that failure may immediately reflect on the bottom line.
Factors that may affect app-store maintenance include:
- Changes in the license policies of the app-store vendor or operator or the individual developers who provide the applications
- Changes in bring your own device, or BYOD, compliance and security policies
- Technical changes in the application program interfaces (APIs) of the app store or application sources
- Technical changes in the platforms that the corporate app store serves
- Business changes that drive a need for new or different apps
Managing change in a corporate app store
The first step in addressing any source of change in a corporate app store is to assess how it affects the original planning assumptions. Work from the top -- that is, the requirements and approaches level -- in assessing any changes before you commit to making them. It's important to ensure that the app store's business case, legal/compliance framework, and architecture assumptions are still intact. If not -- if there's been a fundamental change in requirements or environment -- the best strategy is to start the planning over and rebuild. (Fortunately, such situations are rare.)
When making changes to the corporate app store, it's important to alert users early on, even if it's not entirely clear how that change will be handled. Best practices include advising users that there will be a change coming; offering a rough time frame for when the change will take effect; and, most important, updating them about any changes in store policy or functionality that's more than simply cosmetic. Keep people posted, preferably by including progress reports on your app store storefront or home page.
If software changes are needed, the first thing to consider is whether the change is an indicator of changes to come -- such as the company or the device vendor making a basic business change. Dialogue is important here: If more app-store changes are coming, it's important to make sure that the underlying architecture can accommodate them.
The changes may also require a different graphical user interface (GUI) or a different design for the application server that links the corporate app store to the app store of the device vendor or carrier. If that's the case, consider making the changes now in anticipation of future requirements. Doing so will save money and minimize user impact in the long run.
Testing corporate app store changes
Testing changes to an operating app store is a more complicated process than prelaunch testing. For that reason, consider establishing a "pilot store" in a compartment of the company's virtual private network -- one that's accessible only to developers and testers, not to app users.
If the company's application lifecycle management processes don't include an established plan for such a testing ground, it's smart to put one in place the first time the app store needs a change.
The idea is to develop a test plan that will validate not only the changes being made, but the continuing correct operation of all app-store features as well. Keep in mind that such testing will, at some point, create calls to the vendor's or operator's app store for applications, so it's smart to conform to partners' test-mode interface requirements to avoid spurious purchases.
Making sure the app store manages new requirements is important, but so is promoting it. It's very difficult to force users to exclusively use an in-house corporate app store exclusively, which means it's especially important to ensure that people view the store as easy to use and valuable.
As store usage grows, watch for signs that users are finding the GUI less than friendly or that they're seeking information or apps that the store isn't currently providing. Then make changes accordingly.
One common approach: Ask whether users are going to naturally divide based on their devices, their job classifications or even the apps themselves. A high-level store GUI should allow users to get to apps based on any (and perhaps even many) such factors to ensure that they don't waste time looking for what they want. It takes a little extra effort to present apps in three or more ways, but doing so can pay off in keeping users on your own store rather than jumping off into a device vendor or operator store.
Another thing to look at as a store enhancement is user feedback on apps. When workers use specific apps in their jobs, providing a way for them to offer guidance on optimizing that app can be very valuable. Companies can also use the feedback mechanism to provide users with notices on changes in app policy or features.
Admittedly, that's tough to do just as the store first opens; there's no input available. But by collecting comments beginning early in the store's operations, managers can later post them to a feedback panel on the store's GUI, where they will be useful to others.
Bottom line: Companies should treat their corporate app stores as they do their websites, keeping them fresh, attractive and responsive to the needs of the users they're designed to serve. Those who don't will find that they've waste a lot of money and effort -- and have failed to meet the business objectives that drove them to create to an in-house app store in the first place.