Sybase Business Intelligence Solutions - Database Management, Data Warehousing Software, Mobile Enterprise Applications and Messaging
Sybase Brand Color Bar
  blank
 
 
 
 
 
 
 
 
 
 

Posts Tagged ‘developers’

How Top 3 Mobile OSs Will Keep Innovation Alive

January 25, 2012 in Uncategorized | Comments (0)

Tags: , , , , , , , , , , , , ,

Its always tempting, at the beginning of a calendar year, to cast a glace over the last twelve months and see what another trip around the sun has brought us. When I read this article about global smartphone adoption, I definitely got something that has been on my 2012 forecast: We are on the way to having a few strong players in mobile OS race.

The jury is in after Monday’s news. RIM has taken a tumble and is unlikely to regain market share or its formerly decisive position of leadership in smartphones. The company’s recent misadventure with their Playbook tablet device cost nearly half a billion in write downs. Even more seriously, RIM’s smartphone market share is off by two thirds over the last year, with Android eating most of their lunch. At the same time, Nokia and Intel have abandoned efforts to create a Linux-based mobile OS. Don’t misunderstand. I don’t dislike Linux and have owned several BlackBerrys (which were great devices in their time). I find no personal pleasure in RIM’s misfortunes. However, the enterprise mobile space desperately needed a shakeout in mobile OSs.

Together, Android and Apple’s iOS have amassed sufficient share to exercise a beneficial kind of dominance. As software developers and device innovators organize around these two OSs, de facto standards can emerge. This coalescence creates a rational, sustainable tech market landscape. Having a couple of strong mobile OS players will keep innovation alive, hold prices in check, and let consumer demands drive device development. By the same token, having only a couple of strong mobile OS players concentrates software development talent and allows skilled labor pools to grow. This will provide enterprise much greater opportunity to attract in-house mobile app development professionals. And building in-house enterprise app development resources allow a line-of-business manager or IT group can put forth mobile initiatives that cover 70% or more of the US smartphone installed base and can be accurately scheduled and costed. This may be a watershed moment for enterprise mobility.

All I Want for Christmas is A Million Mobile Apps

December 19, 2011 in Uncategorized | Comments (0)

Tags: , , , , , , , , , , , , ,

According to India’s Financial Chronicle, somewhere about the end of December 2011, there will be over 1 million mobile apps available in the public marketplace. India’s largest mobile app store, Mobilewalla, says that currently about 15,000 mobile apps are released weekly. Just to put this in perspective, there are something like 3.2 million physical books in print as of today. If you use the beginning of Johann Gutenberg’s printing operation in the 1480’s as T=0, the weekly average for global print book publication over the intervening 530 years comes out to about 115 per week.

This is one case where no one is going to say “You do the math”. It’s a complete waste of time to do the math. There is very obviously a tsunami of mobile apps washing over the globe, literally the biggest worldwide personal empowerment movement in the history of life on earth.

If that assertion seemed a little bit breathless, fear not. I am about to take a step back from it. First, I will heartily acknowledge that, far and away, the largest app category is comprised of games and entertainment. Don’t be fooled by this. While it may not be of tremendous enterprise import that 15,000 apps a week are being released if 14, 550 of them are a variation on Angry Birds, here’s what is important. Mobile apps are occupying a place in popular culture that can’t be ignored or dismissed by IT professionals, because they represent a complete shift in people’s expectations about connection and engagement.

If you doubt this, remember that we have seen the same communication technology paradigm shift play out several times before: Recall once-novel capabilities like voice mail, fax machines, email and web presence. The tipping point for business occurred when similar technology became available to consumers. If people had access to a technology at home, it automatically became unthinkable to them that businesses wouldn’t provide voice mail, fax numbers, email and web portals to help speed business transactions. We are very rapidly approaching a frontier where both employees and customers will demand that businesses and institutions interact with them using mobile devices and special purpose apps. Failing to foresee and prepare for this is extraordinarily shortsighted, and could cost laggards dearly.

Demand for Mobile Coupon Support Will Hit Enterprise App Developers Soon

December 13, 2011 in Uncategorized | Comments (0)

Tags: , , , , , , , , , , ,

It’s always good to lift our eyes to the horizon and check out what is coming over it. For enterprise mobile app developers, this is it and it’s moving fast: Mobile coupon support. A recent study by Juniper Research forecasts that mobile coupon redemptions will top $43 billion within five years, which amounts to something like an eight fold increase over today’s numbers. This is a key development for brick-and-mortar retailers, and is the lifeline that may help drag them back across some of the ground they’ve lost to online competitors.

The simple fact of the matter is that people like to shop. They like to see and feel the things they buy before they make purchasing decisions. They like to do the ‘passeggiatta’ in the mall on a cold windy day. The intelligent use of mobile coupons is turning out to be a solid, reliable way of getting them back, particularly when coupled with advances in data science that make it possible to target specific tailored incentives and for merchants, restaurants and service providers to partner in deal making. In a way, retailers are coming a little late to this party. The travel industry figured it out a decade ago: People who buy airline tickets also book hotel rooms and rent cars. Likewise, people who shop on Saturday will probably eat lunch around noon, and by five may be entirely susceptible to a nice offer on a pedicure or a late matinee.

Given the documented success of location aware mobile couponing, enterprise mobile developers can expect to see it take up a strong position on executive wish lists soon. Here are a few talking points to have in hand when working to develop a strategy for using this marketing tool to best advantage:

• Juniper and analysts have found that it is very important to treat your mobile customers to coupons only on an opt-in basis. Sending unwanted promotional material to a customer’s mobile device can be very alienating and destructive to brand reputation.

• Make early evaluations of how data science can help target promotions, based on purchase history, demographics, behavior patterns and the like.

• Start small, but don’t postpone getting started. This is a real phenomenon and may well eclipse many other forms of customer engagement.

• Don’t forget the social media piece. Location aware coupons’ effectiveness can multiply when customers broadcast your deal to their social networks

Managing Android in the Enterprise

December 7, 2011 in Uncategorized | Comments (0)

Tags: , , , , , , , ,

Android devices are coming on strong with consumers. In Q3, it claimed a remarkable 27% of tablet device sales worldwide, which is a stunning result, given that all of the buzz was in the iPad camp. Even more impressive, AT&T, original home of the iPhone, reportedly doubled its Android phone sales in the same quarter. Despite fears that Google would spook its partners by jumping into the Android hardware space, consumers seem to be beating a path to their collective doorways. Given this, it is worth getting ahead of the impacts of a likely population explosion of enterprise user supplied devices of the Android persuasion.

It is for this very reason that a recent article in Network World about Android’s potential issues for the enterprise mobile device management caught my eye. If you are responsible for managing mobile IT infrastructure, chances are you already appreciate that Android isn’t just one thing, or even a closely related series of individual things. Rather, it is a basic mobile OS framework upon which device vendors can build, allowing full customization and ample opportunities for the device vendor to differentiate and position products. A lot of popular, relatively low cost Android consumer devices are very light on security features. This stands to reason, because for most consumers, beyond a certain fairly fundamental level, security is just inconvenient. Device manufacturers would far rather build in features that attract customers

In terms of managing and securing Android device access to enterprise assets and infrastructure, relying on well hardened perimeters is probably going to be less successful and efficient than prioritizing and addressing critical threat scenarios. If I had to choose one threat scenario as a place to start fortifying Android device defenses, it would be creating strong privacy and security for mobile messaging streams. Here’s why:

Recently, I’ve been hearing more and more about a mobile hacking technique known as ‘spearphishing’. Unlike older phishing techniques which broadcast malware-laden spam in hopes of snaring the naïve, spearphishers use sophisticated mechanisms to steal personal information, accrete enough of it to concoct highly authentic looking bait, and then approach a specific target impersonating a highly trusted source. Some documented spearphishing incidents have achieved large scale, effectively infiltrating entire institutions’ IT infrastructure. Moreover, they can go undetected for long periods of time if their activities are not aimed at causing disruption, but instead at harvesting valuable data. Before a facing management of a significant crowd of weakly protected BYOD Android devices, have some built in precautions that keep enterprise messaging streams from becoming a playground for spearphishers.

Application Interoperability and the Mobile Enterprise

October 31, 2011 in Uncategorized | Comments (0)

Tags: , , , , ,

Recently I happened upon an interesting blog that was posted several months ago by a developer commenting on the use of specialized mobile apps. In his post, called The App Interoperability Conundrum, he makes the following observation about using his iPhone:

“It is without question that mobile devices will continue to proliferate in the consumer market with improvements in mobile infrastructure, device affordability and cultural acceptance. However I see an uneasy trend in mobile applications, that is, mobile applications are becoming increasingly focused but less interoperability.

To illustrate this point, consider the following hypothetical example. I am in downtown Los Angeles, I’m hungry and need nourishment from a reputable establishment. On my iPhone I can use:
1. Google Maps to find a nearby restaurant,
2. MapQuest to get voice guided routing directions,
3. Built-in camera to record my memorable meal,
4. FourSquare to “check-in” and recommend this restaurant to my friends, and
5. Yelp to post a review (and snapshot) of my dining experience.

In this workflow, the only interoperable elements were the street address I copied from (1) to (2) and the photo created in (3) and shared with (5).

Obviously this workflow could be optimized by using one app to perform two or more tasks like using Google Map to a find a restaurant and driving directions. But these five apps, in my hypothetical opinion, were the best in each task.

My criticism is not targeted at the number of app used during my lunch break but the lack of interoperability between them. For example:
1. From Google Map, why is it not possible to send the restaurant address directly to my favorite routing apps?
2. From the camera app, why is it not possible to share a photo directly with Yelp.
3. From MapQuest, can I send the “route” to my friends so that they know where I am driving from?
4. To rate (or “check-in” at) the restaurant with FourSquare and Yelp why did I have to locate the restaurant in each app?

Why not just click the “get current establishment” button in each app?

These comments may seem like iPhone-bashing, but they are not. I am just bringing your attention the unintentional ‘stovepiping’ caused by increasingly focused mobile apps.”
For a consumer, this lack of interoperability between applications is an inconvenience. However when it comes to enterprise mobility, the interoperability conundrum can become a serious impediment to efficient business operations. People make decisions based on the information that is available to them. Sales data informs business planning. Marketing and sales information combined with supply chain data impacts production. An intelligent organization’s operations depend on shared information.

That ability to collaborate and share information in real time is a major reason why mobility has become essential to business operations. Yet what happens if mobility is pursued in a non-strategic way? What happens if every work group adopts its own mobile applications without regard to other operational dependencies? The result will be “stovepiping” of business operations caused by a lack of application interoperability.

As you build a mobility strategy, it is critically important that you do so in a way that enables application interoperability. You may not know how tomorrow’s applications will depend on today’s or yesterday’s data, but you need to have a mobility infrastructure that gives you the flexibility to share information between applications. This is what a mobile application platform like Sybase Unwired Platform does.

Top 2 Hybrid App Management Scenarios

September 15, 2011 in Uncategorized | Comments (0)

Tags: , , , , , , , , , ,

Continuing the Hybrid container application development conversation, let’s consider application management. Hybrid applications are also easier to install on workers phones. Consider these application management scenarios:

First, let us say your company has developed a mobile travel approval application you want all employees to use. This application will streamline and accelerate travel approvals, enabling travelers to make arrangements earlier and reduce their spending on last-minute bookings. Your company permits users to bring their own phones to work, though you limit them to a list of approved devices that covers four different mobile operating systems.

The native application approach would be to build four versions of this application – one for each supported mobile operating system. When it comes time to deploy the application, it is necessary to interrogate each device to see which operating system it is running, and then install the appropriate version of the travel approval app.

Using a hybrid application strategy, you would build the travel approval application once. It would be the same for all devices. When it is time to deploy the application, you would provision it over the air to all company employees and it would immediately become a functioning app on their devices.

Note that company enabled devices would already have containers installed. This would likely happen when the phone was initially enabled for business use. For instance part of the “business enablement” process might include installing a basic company app like email or a company directory. That app would include a device specific container. Once the container is installed, that device will run other company developed hybrid apps that are installed over the air by IT management or downloaded from the company app store.

Second, let’s say your company has set up an app store where employees can download business applications. The process for downloading a hybrid application would be simpler.

When workers go to the app store to download a native app, they will encounter a step requiring them to indicate the type of device they are using, or to select the device specific version of the application they are looking for. Once the application installs, they may need to do some device specific configuration. If they select the wrong download, the application will not work.
With a hybrid application on the other hand, workers would simply go to the app store and select the application they want. The application will download and run every time.

Using container dependent hybrid applications makes it easier to segregate business and personal use functions on a dual-use device. That is a valuable capability at a time when employees are increasingly bringing their own devices into the work place.
Hybrid applications also provide an inherent layer of security. The hybrid applications only work in a compatible container. If by chance someone had access to the web app component of a hybrid app from our company, unless their mobile device was enabled for use in your company and had a device specific container installed on it, the web app component would not function.

There is great business value in simplifying mobile application deployments. To get the most out of a hybrid application strategy, applications should be built on a mobile application development platform that enables you to easily customize containers for the devices and data sources your organization uses. That way you not only have containers that are custom fitted to your operational environment, but you can create a standard container architecture that makes hybrid apps easy to build and deploy. Hybrid applications are also easier to update so that you can quickly change or adjust software driven business operations.

In this kind of mobile business environment, workers see new functions and applications appear on their devices, ready to run. Also, the task of worker initiated downloads and configuring a new application becomes much easier. This reduces the load on tech support, and it increases the adoption rate of new applications designed to make business operations more efficient and workers more productive.

How Hybrid Apps Simplify App Development and Maintenance

September 1, 2011 in Uncategorized | Comments (0)

Tags: , , , , , , , , ,

As promised here is more to think about and apply to the cost of building and maintaining mobile apps!
There has been a lot of interest recently in building browser based web applications as mobile business apps. This approach would greatly simplify mobile application development. Any smartphone or tablet that can browse the internet would be able to run a web app. This means it would only be necessary to build and maintain one version of these applications.

Although this approach works for simple applications, mobile applications built this way have a number of limitations, including:
• Web applications have no direct access to device specific hardware. This limits theretheir ability to use device specific features like cameras and GPS, and it also gives developers less control over how data is handled on the devices, which could lead to security issues. Also, web applications have limited ability to process large data volumes.
• Web applications do not provide any control over which devices are connecting to the enterprise’s web server.
• With web applications, end users must self-provision apps & bookmark links. It is not possible to send one app to all device users at one time. It is also not possible to use push messaging to distribute notifications and content to employees.
• It is not possible to customize the look and feel of HTML web pages for different devices; each page needs to be changed individually for this to occur.
• Web applications are slower than native apps, which makes it more difficult to give the “on device” application user experience.

There is, however, a different approach to web applications which gives them all the performance advantages of native apps while retaining the development and maintenance advantages of web applications. This involves the use of a native app “container” which becomes the environment in which a web app runs on the mobile device. These are called hybrid applications.

A web app container is a native application designed to process generic function calls from a web application. The container itself has device specific hardware controls and hooks to back end corporate databases. Each mobile device type supported by the company would have its own version of a container, which would be installed on the device when it is enabled for business use. Web apps operate within the containers so that the same generic function calls would work appropriately on the different mobile devices. For instance a web app that called for a GPS function would work the same on an Android, iPhone, or Blackberry once those devices had containers installed on them.

Hybrid applications offer a tremendous opportunity to lower the cost of mobile application development and maintenance. This is another piece of the cost of mobile apps conversation. There is more to come.

The Cost of Building and Maintaining Mobile Apps

August 25, 2011 in Uncategorized | Comments (0)

Tags: , , , , ,

How much does it cost to build a mobile application? Of course that depends on a many factors, such as how complex the application is going to be, and how many different mobile devices will be running it.
Industry analysts provide cost estimates that range from $20,000 to build a simple mobile app, to $150,000 or more for a complex application. These costs are largely replicated for each mobile operating system the application must support.
For instance if an organization decides to build a native application that facilitates a particular business operation, and workers using that application will be running it on iPhones, Android phones, and Blackberries, this company will need to build three versions of that application. This would entail hiring developers who know these different mobile operating systems. Most developers are specialists, which means that different developers would need to work on the different versions of this application. In effect, the application would need to be built three times.
Initial development costs are not the only cost associated with traditional native application development. Once an application is build and distributed to those workers who will be using it, it may need to be revised from time to time. Perhaps there is an update in an operational procedure that needs to be addressed in the mobile application. Each time there is an application update, all versions of the software need to be updated so that business operations remain consistent among all workers, regardless of the mobile device they are using.
It may also happen that over time, new device types come into use. If a new mobile device comes to market, like a tablet for instance, and company policy changes to support these new devices, then the application will need to be rebuilt for this new device. Also, it will become necessary to include this new version of the application when any subsequent application updates become necessary.
These costs can be just as significant for out-of-the-box mobile applications. Research shows that companies who avoid development costs by buying out-of-the box solutions customize those apps 70% of the time (Frost & Sullivan. “Adoption of Premium Mobile Enterprise Applications – The U.S .Perspective in 2010.” April 6, 2011). Those customization costs can be very high, and they would need to be replicated for each supported mobile operating system.
It is no wonder companies are cautious about committing to new mobile apps that support their business operations, even when the operational advantages to mobilizing workers is obvious and well documented. This is just the beginning of the cost of mobile apps conversation. There is more to come.