Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Forming a strategy for mobile application services

The path to mobile development requires a look at native platforms, HTML5, application integration middleware and variations thereof.

Mobile application development has entered a new stage, largely driven by the advent of the highly influential Apple iPhone. Device and application abilities go far beyond email, the killer app of first-generation mobile development. There is more to come. In sales, smart mobile devices are outpacing conventional computer clients. For its part, Forrester Research calculates that the revenue from paid applications on smartphones and tablets was $2.2 billion worldwide for 2010, with 82% growth (CAGR) expected through 2015.

While mobile application development is still primarily the province of consumer applications, there are indications that enterprise development teams will need to prepare their applications to run on the new, more intelligent mobile devices. Application development managers and software architects of all types are taking note.

Each type of mobile development approach confronts the IT decision maker with a host of choices to navigate. Each decision is colored by the fact that the mobile client is different in composition from the enterprise's traditional desktop or laptop client.


RESTful SOA services tend often to be part of the server-side architecture of mobile application integrations. The server architecture in mobile applications differs in details from established three-tier architecture, but the differences are not as pronounced as the differences on the client-side of the mobile equation. There is an abundance of devices, and they act differently than the typical desktop or laptop PC. And they benefit – or suffer, take your choice – from a hurried pace of innovation.

In order to ride this tiger, development leaders need to quickly define a strategy that is both pragmatic and flexible. IT must ensure some mobile apps go to market rapidly, while taking into account the blinding pace of change in mobile tools and platforms, according to Jeffrey Hammond, Analyst, Forrester Research.  

Hammond highlights a few major categories of mobile application delivery today. Understanding these is a first step toward implementing a mobile application development strategy.

He lists the basic categories as: native types, running directly on the mobile device; Web-based types, employing the device's Web browser; a hybrid of native and Web-based types; and third-party mobile middleware services.  

Each type of mobile development approach confronts the IT decision maker with a host of choices to navigate. Each decision is colored by the fact that the mobile client is different in composition from the enterprise's traditional desktop or laptop client.

Overall, Forrester's Hammond sees the issues of cost; agility in application creation and updating; performance; and user experience as the key factors in deciding between mobile application developments alternatives. As you will see, choices are not mutually exclusive. As Hammond describes it, mobile application development ''is a balancing act.''

Native-type mobile development

Before Web browsers landed on smartphones, writing to devices' native operating systems was the means for developing applications. This meant that developers had to learn a distinct set of tools and tricks for each manufacturer's device.

Native development, using low level software languages, remains more akin to embedded system development than mainstream enterprise development. But mobile devices have evolved. The groundbreaking iPhone allowed teams to develop using a higher level language, Objective C – still, that language was not widely supported in mainstream developer ranks. Google firmly placed its Android mobile development platform on the popular Java language.

But development teams still faced special work for each mobile device using Android. That is because screen sizes, memory complements and other elements differ from Android phone to Android phone.

The manager's dilemma is further aggravated because Android and iPhone together only comprise a portion of the mobile device market.  To support a lot of end users, ports to many device types may be necessary. Besides the iPhone and the Androids, there are the Windows Phone, the Apple iPad, the Rim BlackBerry, Symbian and others.

''If you are mainly focused on delivering a great experience and you want to optimize, then you are probably going to be choosing native,'' said Hammond, speaking at Forrester's recent ADD Forum in Boston. Still, it is not cut and dried. Hammond added that some mobile middleware providers can deliver applications for highly-optimized user experiences.

Tip: When considering native mobile applications as a strategic path, you should especially weigh the importance of performance and user experience - ask how important these traits are to your application integration's success.

Web-type mobile development

The advent of Web browsers on mobile devices was welcome, especially as HTML5 came into being. HTML5 exploited the growing use of JavaScript for front-end development, and associated frameworks such as JQuery and Dojo were enhanced to better cope with mobile needs. Many development managers are likely to gravitate toward Web-type mobile development, because the of way the PC-based Web browser helped to standardize the client-side. But, as with most aspects of the mobile development dilemma, it is not that straightforward.

''If you are mainly interested in keeping the costs as low as possible or being able to update the application as frequently as possible...you are going to be looking at a Web based approach," said Hammond.

The upside for native mobile development is this: it is the best way to tap into the magical qualities of the smartphone. Native apps can exploit GPS and other device capabilities, and they work quickly.

Despite HTML 5 advances, the Web approach has a down side if, according to Hammond. your application needs offline support, advanced rich media and high-powered graphics rendering support - or if it needs to take advantage of cutting-edge platform features.

Hybrid and middleware mobile development.

The Web and native approaches are not mutually exclusive. Development managers can hedge their bets by creating hybrid applications based on composite integrations that take advantage of each approach, based on circumstances. The final application can use the Web approach for, say, content delivery, and use the native approach to tap on-board geo-location capabilities.

Hybrid approaches are particularly suited for B2E, B2C solutions with high-concurrency or performance-intensive applications, according to Hammond.

Moreover, the IT shop need not go it alone. Middleware services providers are able to pick up all or part of the load, providing a cloud-based middleware integration layer that teams can program to, and delivering the application to a wide assortment of device types.

Like the hybrid mobile development approach, mobile middleware can encompass both native and Web styles, notes expert Hammond. Often offered as Software as a Service or Platform as a Service, mobile middleware platforms are typically supported by vendors dedicated to mobile application delivery. As such, they provide middleware and APIs that customers can tap into. Their middleware layer is intended to ''abstract-up'' the details of individual device type.

The messaging middleware services vendor is expected to keep up with new releases of devices and device software, with new device capabilities (voice recognition, geo-location, and so on), and to be up to date with HTML5 libraries and browser improvements. When analyzing services, it is important to generally determine the extent of the vendor's resources.

Tips: Look for points in your architecture where you can segment the design for Web or native deployment. If you go to a third-party messaging middleware house, carefully gauge the APIs it offers The APIs should apply to your existing services architectural with minimal adjustment. You have to consider the effects of tying yourself into the vendor's messaging middleware platform.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.