Way to Mobile

Mobility has an important place in the Enterprise Architecture roadmap of all enterprises. Every enterprise is seriously looking at the mobility space and defining strategy and business plans based on mobility. Demand is rapidly growing from both workers and consumers to access corporate and business applications from their mobile devices.

In this article, I will highlight trends and analyst predictions in the mobility space, study various options available for enterprises and define a method to strategically build mobility initiatives based on experience gained from rolling out mobile applications.

Imperative for Mobility

What analysts have to say on mobility:

Gartner

• By 2013, mobile phones will overtake PCs as the most common web access device worldwide.
• By 2014, more than 3 bn of the world's adult population will be able to transact electronically via mobile and Internet technology.
• By 2015, context will be as influential to mobile consumer services and relationships as search engines are to the web.

These highlights indicate how important it is for every enterprise to have a strategy in place for getting their enterprise/consumer facing applications onto mobile devices. Even though there is a debate on whether native mobile apps or mobile web apps are best, enterprises cannot ignore the need for existing applications to be web enabled as it ensures a wider reach.

The Mobile Landscape

Unlike desktops, the mobile landscape is unique and encompasses different types of players and forces.

Challenges and opportunities posed by these players and forces should be well understood to ensure optimal delivery of business value for an enterprise through the mobile channel.

The key players like Mobile Network Operators (MNOs), networks, mobile devices (hardware), mobile operating systems (software) etc have significant impact on an enterprise's mobility strategy.

Transcoder/Proxies are the other key players in the game who pose significant challenges to mobile applications when it comes to delivering a homogenous user experience.

Mobile Devices: These are the devices that may or may not be able to make phone calls and they rely on MNOs.

The devices that can make phone calls are called 'Mobile Phones'. Mobile applications can even target devices that may not be able to make phone calls (like the iPad). There are different categories of mobile phones: feature phones, smart phones & legacy, and WAP phones. Feature phones constitute a major portion of the market. But with the rise of  iPhones and Androids, smartphones market share is increasing day by day.

Networks: There are multiple types of networks available each with different levels of capacity to transfer data.

The type of network on which a mobile application is deployed impacts the level of sophistication of the application and its efficiency. GSM in 2G with GPRS/GPRS EDGE or 3G, CDMA etc are examples of networks. An application that is deployed on a 3G network can support efficient video/audio streaming while a 2G application will have limitations on its data consumption.

Mobile Network Operators (MNO): These are the channels through which mobile applications connect to the rest of the world. Irrespective of the nature of the mobile application, if an application needs to consume external services or data/content, then applications dependency on MNOs become significant. Vodafone, AT&T, T-Mobile, Verizon, and Airtel are examples of MNOs.

Mobile Operating Systems: Like desktops, mobile phones have operating systems (OS). iOS, Android, Windows Mobile and Symbian, are examples of popular mobile operating systems.

When an enterprise plans to develop native apps, the OS will have a huge impact on the plan.

Transcoder: A Transcoder is an interceptor placed between mobile devices and mobile web applications by MNOs. They are supposed to optimize mobile web application delivery to mobile devices but often result in an impaired end-user experience.

Other factors like screen size, layout, resolution, mobile device computing capabilities etc put constraints on the capabilities that can be delivered through mobile devices. It will not be the same as what is possible in desktops. So, planning for mobile apps should factor in these constraints while taking advantage of special features like accelerometers, GPS/AGPS; etc that are not available on desktops. Unless these apps, leverage these special features, it may fail to deliver the value that is expected by consumers.

Key categories of mobile apps are:

Native Apps: These are the thick client mobile apps developed by using the SDKs/app development frameworks targeted to a particular mobile OS based phones like iPhone, Android, Windows Mobile etc. These apps will be installed on the device and they will leverage local device and OS capabilities.

Mobile Web Apps: These are web applications that are accessible from the mobile browsers. The content will be optimized for mobile devices and can leverage local mobile device capabilities to some extent and depend on a network connection.

There are other categories of apps like thick-thin client apps (where a thin installable application acts as a browser but always depends on server side resources), SMS based applications (which are basic and very limited in terms of providing a good user experience), mobile widgets (web based single purpose apps that can run outside browsers; only few widget platforms are available as of now).

With the growing maturity in mobile browser technology, more sophisticated mobile web apps are possible. Browsers allow apps to access a device's GPS capability allowing us to build location aware mobile web apps; they even allow users to zoom, change display based on device position (either portrait or landscape). With the advancements in markups like HTML5, it is also possible to have offline mobile web apps (but it is in the early stage of adoption). All of this may overshadow the mobile widget option.

The fact is that lots of things are happening at a rapid pace in the mobile arena just like what happened to desktops over the past decades.

Planning a Mobility Initiative

In light of the availability of different mobile path options, it is important for an enterprise to perform extensive due diligence and make an intelligent decision on which path it should adopt, based on various factors like business it expects to generate, its target audience, mobile device market share etc.

For example, unless there are compelling reasons, it should not go for native apps, that will result in supporting lots of product life cycles. If an enterprise is a financial institution and is planning to build a personal financial management app targeting only selective high net worth individuals, then it can build sophisticated native apps for iPhone, Android, and Windows Phone like smartphones only. But if it is an e-commerce company that want to allow its customers worldwide to order products through mobile devices, then the right option will be to go for a mobile web app as it can cover a wider range of mobile devices including feature phones and WAP devices in order to expand reach.

With this background, let us look into a method that will help in planning for a mobile initiative. This method will focus on mobile web app as it is one of the prominent modes used when there is a need to mobile enable business services and operations on a wider range of mobile devices; the method involves the following steps:

The first step in planning for a mobile initiative is to arrive at a geography-wise target consumer matrix.

• This will help in testing the mobile maps on its performance and other aspects on the different carriers of the respective geographical location.
• Also, to plan the enterprise infrastructure according to the user base to ensure optimal performance.
• In addition to this, collecting info related to end users dynamics will help in planning.

If it is consumers, then it will become a must to support a wider range of devices as info on end user mobile devices market share will not be available upfront; after deploying applications, maybe after a year or 2, conclusions can be derived based on usage. But info on general mobile device market share will help. If it is for enterprise mobile users, then target devices will be based on corporate IT policy. Not every enterprise will support a wider range of devices for its employees; usually employees will be provided with a mobile device and in that case enterprises will always narrow down to a particular mobile device based on various factors.

The next step is to identify the functions of existing apps that are to be made available on a mobile; if enterprise apps are already SOA enabled, then an exercise to identify those services that are accessible from mobile devices will help in planning. As the mobile channel brings additional traffic to services in addition to other channels, services should either be scaled-up or scaled-out. Like the sample table shown below, listing of services that are accessible from mobile devices either directly or indirectly should be derived.

Another way of performing this exercise is to list functionality that needs to be mobile enabled and the respective services that are used from the service repository. Sometimes, a service (fine grained method) could be a part of another façade service (coarse grained). In this case, listing those dependent services will also help in planning. The fine grained/dependent services will also include infrastructure services like the services that are meant for performing audit logging, sending mail etc.

Device Families Matrix: This step is an important step since it has an impact on the overall roadmap, time-to-market and cost. Arriving at a device plan will help you get a sense of how large the initiative is going to be and hence the budget. Arriving at a conclusion on what devices are to be supported; listing the capabilities (like AJAX, JavaScript, XHTML-MP, CSS2, CSS3 etc) that are to be leveraged for the mobile applications, and accordingly arriving at different device families.

Planning a mobile application based on a mobile device is not a good idea and is not a scalable model; instead, planning should be based on device families. Device families are logical groups based on device capabilities. The highest group can be most sophisticated while the lowest is a group of low end, legacy devices; so that there can be a separate 'text' only version of the mobile app for low-end devices.

Like this, device families can be derived so that a version of the application targeting a particular device group can be designed in such a way that it can leverage the capabilities exhibited by a respective device group. For example, in the case of orientation changes, some devices support it through JavaScript 'onresize' events while some devices support it through 'onorientationchange'. So, based on the device support, the version of the application that is targeting a specific device group should be designed and developed.

Functionality/Device Family Matrix: After finalizing the target device families, arrive at a matrix highlighting which functionality should be made available on each target device family.

'Device Family' matrix helps in high level planning, while 'Functionality/Device Family' matrix will help in planning at the functional level. Functionality may be made available in one or more device families. Some functionality like login may be made available across device families because of security requirements.

Also, some functionality can be built in multiple variations. In the above sample matrix, if 'Simple Search' functionality is to be made available for a 'ClassA' device family, then it can be built based on Ajax. So that search will happen faster and it will add richness to the application. However this is not possible for the 'ClassD' device family. Accordingly, testing plans can be created and hence effort can also be estimated. This will also set expectations for different stakeholders on the mobile application. In addition, this matrix will also help in planning information architecture of the target mobile application and will ensure an optimized experience for different device customers.

These steps can be carried out repeatedly to refine the mobility plan based on various factors like changing market demands, mobile market share , business priorities etc.

Mobility should be considered as one of the key aspects of every initiative that an enterprise is embarking in adding more value to the services it offers to its customers. Having a method to finalize a target device plan will help an enterprise to have more clarity on its mobility journey in terms of time-to-market, budget and availability of its service to customers across different geographies.

Balvariyam, VP, Collabera
Gnanasekaran V, senior technical architect, Collabera
vadmail@cybermedia.co.in