Apps Mania 2: the building blocks of enterprise applications

Last time we took a top-level look at mobile applications, the get-rich-quick myth and the fundamental differences between applications for consumers and applications for the enterprise. In this item we examine in greater detail the practical questions which should be asked when developing an app for use in the enterprise.

Assessing skillsets and managing risk

When considering the development of an enterprise mobility application, it’s important to compare the capacity of in-house teams with third party suppliers.

The underlying objective should be to minimise risk in the development and rollout process so the solution can be completed on time, on budget and with the support of all its users. To achieve this it’s vital to discover whether an in-house department or supplier has adequate technical expertise and project management experience to ensure success.


Picking a platform
A primary consideration when writing a mobile application is selecting the correct platform. Currently there are five major mobile operating systems, and a further seven or eight less popular and more specialised on top of that. The majority of developers stick with the mainstream iOS, Android, or BlackBerry platforms.

Firstly it should be carefully considered whether an application is needed at all, or if requirements can be met through a mobile-optimised website.

While this is possible, it’s a common misconception that the mobile web is an easy programming platform to learn. A recent Vision Mobile report found that mobile web programming ranks sixth in terms of easy learning curve. It found that the need to learn a complex stack of languages and technology frameworks across client and server environments can be onerous, added to the battles of cross-browser portability.

Once committed to developing an application, the next decision concerns the choice of application type. There are currently three options available:

1. An HTML5 application which runs in a web browser on smartphone.
2. A Native application which is written using the official Software Development Kit (SDK) provided by an operating system provider.
3. A Hybrid application, which uses a combination of HTML5 and a native SDK.

HTML5 is ideal for general forms-based applications and will work on the majority of smartphones. However, since the HTML5 standard has not yet been ratified, mobile web browser functionality can vary from device to device, meaning that what works on one device may not necessarily work on another. An example would be the Windows Phone 7 browser, which does not support offline caching. Therefore if the browser loses connectivity, the app won’t work and data will be lost. To span this gap, HTML5 functions must be written with less capable devices in mind.

Writing native applications using official SDKs gives ultimate flexibility and performance which will enable the development of rich features. The down-side here is that the application will only work on one targeted operating system, meaning simply extending reach to a mixed estate of devices is not possible, leading to a level of inflexibility.

Hybrid applications effectively give the best of both worlds: the flexibility of using an HTML5 web browser together with the rich functionality of native applications. Added to this, they can be used across all smartphone platforms to give the ultimate flexibility. Here the challenge is volume and market immaturity. There are simply so many multi-platform SDKs and platforms which could be catered for, some of which will inevitably be fated not to survive current economic pressures, potentially leaving your application and your users in the lurch. Equally, consolidation in the market of multiplatform tools will threaten the continuity of development standards.


Application lifecycle

Another important focus is application lifecycle. Most manufacturers refresh their device inventory every 12 months, making upgrades and modifications to operating systems, and your application should be compatible with these changes. Most corporate contracts are also on a 24 month billing cycle, which will have similar implications. The changing pace of technology means that at least every two years your applications will need to undergo changes and modifications. Contingencies should be built in to accommodate for the changes.

With the existing number of variables and fluidity in the applications market, it’s vital to conduct an appropriate level of due diligence when creating enterprise apps. Once conducted, the major decision is whether to forge ahead with in-house resource or recruit a partner with the tools and expertise to reliably deploy enterprise class apps.


What happens next?
So you’ve built and deployed an enterprise application. Job done? In Part 3 of Apps Mania we’ll look at scale, change management, server and infrastructure strategies.