MaaS360™

Mobility Momentum: Optimizing the Mobile Workforce

Navigation

Inside Innovation: No more games

The maturing of mobile applications.

By Andy Peacock

We were first introduced to the concept of web applications aimed at mobile devices in 1999 thanks to i-Mode in Japan (the Mobile Web). These were truly revolutionary ideas. No longer would we be tied to our desks when we wanted to search for information or perform key tasks. However, the honeymoon was short-lived as issues with content incompatibility, limited bandwidth, short battery life, screen real estate, and usability problems left mobile users frustrated, disappointed, and longing for the rich content provided by their home computer or work machine. We have pretty much stuck to this path ever since with a distinct line being drawn between “mobile” and the core world of work, even with new mobile applications and mobile web solutions running on drastically improved hardware. 

“Mobile” applications are intended to allow us to carry out our day-to-day tasks from our mobile phones. Without wishing to be drawn into a discussion around semantics, the broader terms of “portable,” “wireless enabled,” or even “mobility” (a very subtle distinction) may be more suited to the ubiquitous notion of operating anytime, anywhere, regardless of any device considerations or constraints and specifically, where any reference to an end user device is being avoided. In most of the English-speaking world this use of the term “mobile,” being a mobile (cell) device specific subset of portable / wireless enabled (mobility) solutions is reasonably clear, but for those who are more familiar with the term “cell” (for cellular), “mobile” tends to take on the broader meaning. This article attempts to identify how the conjunction of Service Oriented

Architecture (SOA) and application “container” concepts may resolve many (if not all) of the very specific problems that mobile applications (in terms of the more limited meaning previously defined), which are meant to run on mobile phones, must overcome. Strangely enough, this approach (the bringing together of SOA and application container concepts to solve some specific problems – the means) is likely to also benefit those who see a world that avoids reference to, or distinction about, specific device platforms, aka the broader use of the term mobility (the ends).

So, back to the issue of applications designed to run on mobile device platforms. For these to be effective we need a slick interface where content is streamlined, not just thrown at the consumer of that content and not cut beyond all recognition or usefulness – an interface where the user experience is on a par with that offered by the desktop, and not complex and unwieldy. Typically what we get, however, is a hastily produced piece, which struggles to live up to the functionality of traditional web-based solutions and usability requirements of people on the go. Additionally, as devices change, compatibility issues broaden to the point where the results are often unusable, or so lacking in useful content and disconnected from crucial back end systems and the important data repositories of the corporation, that the solution is avoided by employees, customers, and corporate officers alike.

So what has changed? The current breed of smartphones including the Apple iPhone, Google Android devices, BlackBerry, Symbian and Windows Mobile devices offer more screen landscape, touch screen capabilities, and “focused” applications (currently best characterized by native / contained applications with the iPhone), and the growing importance of application stores where applications (commercial and corporate) can easily be deployed. This is all great news and has already led to some truly groundbreaking mobile applications, which allow businesses to work smarter. There is of course still the issue of keeping your business on the same page, whether you are looking at a web browser, a desktop solution or a mobile device solution, and this is where SOA comes in, along with the ideals behind the broader use of the term mobile (discussed previously).

SOA has been both the savior and the poison chalice, leading some to the promised land of simpler more manageable services, while driving others into insanity as they attempt to rationalize their organization to the nth degree to grapple unsuccessfully with the management issues of SOA implementations. One thing which all can agree on is the drive within SOA to a componentized service-based approach to systems as the way to breed success and encourage re-use. It is this core principle, which is of such value to the notion of mobile web application deployments. If we are going to fully realize the potential of the mobile web and the power afforded by native mobile applications, we must first address the back end and look at how SOA can make our lives easier.

As previously mentioned, there is a tendency for mobile applications to be developed similarly to mainstream web applications but as an afterthought, or simply driven by a desire to throw as much data as possible at an end user; these are issues which must be addressed. If we approach development in a service-oriented manner, whereby we identify a key function such as address validation, then expose that function as a service across the enterprise, that new service can be accessed by whatever medium we deem necessary.

The relevance of this can be seen through a simple example. Stock prices can be gained in a number of ways and from numerous places. By dealing with mobile, web, and internal systems separately, it is possible you may end up with three incompatible prices. Alternatively, providing a stock service which is called by all ensures we are consistent across the board, and consistency is important to any company.

The diagram highlights how we might strive to utilize services exposed as part of an SOA-enabled back end to ensure consistency and access to useful data through mobile web applications and native mobile applications.

The SOA model allows us to construct services which may be accessed via a number of protocols and where the consumer is less important than the content. This does not mean we need to alter the way we go about producing mobile solutions. It does, however, mean that those solutions can be more feature rich and capable of providing the user with a more familiar environment.

Once we have our back end systems in order it is time to take our case to the mobile content itself. Again SOA can help us. By containerizing our functionality by service it gives us the ability to span multiple device types because we can identify what we are trying to achieve and call upon the correct service rather than trying to cram functionality in without truly focusing on the end goal. Services allow us to have a fully functional web application which can be used cross platform alongside native apps with a similar look and feel providing the same core functionality.

It is fair to say the evidence is already clear why SOA can help enable a more consistent mobile world within the enterprise. Now we come to probably the most important element of any mobile app or web app: the user experience. While SOA may not normally be associated with human– computer interaction, the principles of componentization stand true in any good interface. This is especially important when it comes to mobile delivery. Services promote the idea of less is more. We focus upon what we need to achieve then try to sort the wheat from the chaff in our data. Our mobile interfaces need to abide by these principles; bombarding a user with information on a single screen may work if you are viewing it on a 24-inch monitor. However, on a 7-inch screen it is a different story. The mobile web apps and native apps must focus on grouping key functions and providing them in a usable way. It is not necessarily a bad thing that you cannot see everything all at once. If the information is important, make it available but do not worry about it all being on the same screen. By following the container-based principles and only showing the information we need, it becomes a solution which people will actually use.

By following a containerized approach to mobile development, the improved results gained may yield the growth of a new business model where customers become willing to purchase mobile services that in the past were delivered for free, but in an inadequate way. This could be the point where enterprise level services begin to drive consumer demand and adoption.

It is easy to consider your mobile deployments as a completely separate element from the rest of your enterprise, but the benefits of being inclusive are clear to see. You can expect a more usable solution, providing the right data where and when it is needed. So let us embrace the lessons of SOA and help mobile web and native apps grow up to become essential for employees and customers alike. 360

Andy Peacock works as a Solution Architect for CSC in the UK. He specializes in mobile and emerging technologies.

Smarter Smartphones

“We have steadily grown and improved our capabilities in the Enterprise Mobilityspace, nowhere more so than in the area of smartphones. From this strong starting point we have incrementally added in comprehensive wireless networking and application development communities and targeted these integrated capabilities at our core industry verticals and the key customers within them.”

- Leonard Simmons, Mobile Themed Solutions and Service Program Lead, CSC

| 2 of 3

Your Comments

Poll: Data Limits

How do you currently manage and prevent users from exceeding mobile broadband data limits?

    Circle_unselected Tool that tracks usage and stops users when they reach set limits
    Circle_unselected Tool that doesn’t allow capture of information for roaming networks
    Circle_unselected We track usage only after the fact through carrier billing records
    Circle_unselected We view reports on data usage but have no way to enforce limits

Sponsor Content