How Long Will Your Mobile App Be State-of-the-Art?

Image

The images are small, so here is some historical context beginning on the top ROW: [from left} (1) Early DOS – all text based information – circa 1981. (2) Green screen DOS with pseudo boxes – which were often designed by outlining areas using font characters instead of real boxes – circa mid-1980. (3) Early Macintosh GUI screen – 1983. (4) Early Windows GUI Screen – 1985. Second ROW: (5) Windows Blue Screen of Death – if you don’t remember, ask someone older why it was dreaded – lurking about since 1985. (6) Windows XP GUI – circa 2001. (7) Mac GUI – circa 2008. (8) Mobile Apps Menu – now.

Aside from obviously being a montage of historical computer screen shots, what do these images of software have in common? For their day, they represent the state-of-the-art software technology.

Would your company go back to one of these state-of-the-art software platforms? Not likely.

Enterprise software and technology have a known destiny

Everyone in IT knows that all Enterprise software and hardware technology, over time, is inevitably destined to become obsolete.

One can install new operating systems; upgrade existing Enterprise applications; apply a variety of Band-Aids to help heal new tech problems; or, simply limp along with the status quo; but, eventually, software and/or technology will no longer efficiently support your business model needs, and, their time in the sun will end.

Studies report that most companies re-invest in new ERP systems and platforms every 5-8 years. What’s your policy for this and how will you incorporate this policy with your mobile app development?

What is the destiny for your mobile apps?

How long is your company expecting your newly deployed mobile app to be business or consumer relevant? Are you using the latest programming tools or technology to insure a quality user experience? Is your mobile app positioned to have a long-shelf life or was it delivered already bordering on being obsolete?

Lessons learned from others

As discussed in previous blog postings, audiences matter. Consumer-facing apps become brand extensions for your company. The same marketing effort used to promote your brand should be employed for your app. If one refreshes a brand image frequently, then, so should one refresh the consumer app. There are many excellent consumer-based app examples to reference that are frequently changing with market conditions, including Amazon, Lowes, Barnes & Noble, and Bank of America.

If your app is business-to- business or for only internal usage, then the user experience may be a driving force. Certainly, BYOD initiatives have had an impact on user experiences as each new mobile device strives to outdo their competition with new features. But, rather than IT departments trying to support each new OS system or new device immediately, one might simply have a scheduled refresh policy for your app of once a year or once every 18-months. A real challenge for BYOD is backwards compatible to support the newest desired user experience features while still supporting older technology.

Migration of mobile apps

Should your company be planning an Enterprise upgrade or replacement, remember to allow time to update or replace your mobile app, too. Your mobile application changes may turn out to be more back-end than front-end; but, the data integration will need to be completed and available in conjunction with your larger Enterprise project – especially if business users have grown accustomed to their functions and convenience.

Mobile Takeaway

The primary takeaway should be that your mobile apps are not completed, even though they may be deployed.  Keeping a mobile app in a state-of-the-art status is a never-ending IT process that requires resource planning and a refresh schedule to remain relevant.

Before You Start Any Mobile Software Development Project, You Must Do This First

Before your IT department or independent software developer starts cranking out Enterprise Mobile software code, there are two foundation core steps that first must be addressed.

You’ve probably already seen their core name acronyms elsewhere: MDM (mobile device management) and MAM (mobile application management). Simply put, MDM will be your rules on which mobile devices will be managed, controlled, and supported. MAM will be your rules on how the applications loaded on supported mobile devices will be managed, controlled, and supported. Your company should  discuss and agree in detail on what these two core steps will be – prior to any code being created or mobile software distributed.

There are too many Internet articles providing in-depth details and advice for both MDM and MAM to repeat their recommendations here.  A recent deep-dive and comprehensive article I recommend is by Galen Gruman, downloadable from InfoWorld:

http://www.infoworld.com/d/mobile-technology/infoworlds-guide-successful-byod-and-mobile-it-strategy-179111

Your intellectual property, in the form of Enterprise app content, has to be protected. This content is just as valuable as any other intellectual property your company creates or owns; but, it is at greater risk and perhaps the most vulnerable property category your company will ever create. That is because, by definition, mobile “property” can’t be easily locked down, tracked, traced, or deleted without a significant degree of upfront planning.

The proliferation of BYOD, in an age of a very mobile workforce, means that control of Enterprise apps loaded on personal devices will immediately be at jeopardy when trusted employees become former employees.  BYOD means the devices and all of their loaded software departs the premise when the former employee does.

As Galen points out in his deep dive article, common sense guidelines and employee usage policies may offer practical solutions; but, if the nature and use of specific apps is company sensitive – for executive use only, for example, nothing may protect your company interests better than company-issued devices that must be returned by departing employees. Ownership always remains with your company in this regard.

Your MAM and MDM rules should address as many business usage scenario specifics as one can imagine. And, don’t write any code until you can provide a basic framework for where and how your mobile apps are to be deployed, managed, updated, or revoked!