Date: Wednesday, October 17, 2012
This session will discuss the special characteristics of the mobile application development lifecycle and the challenges that they introduce, such as fragmentation, security concerns and importance of great user-experience. Then we will explore the best practices and capabilities from IBM that address these challenges. We will also introduce the "5 ALM Imperatives" that are crucial for you to take control of your development process and accelerate delivery of high quality mobile applications.
The Mobile Frontier
Matching: security X
ParidhiVerma 2700008QKP Tags:  management security multiple alm ibm lifecycle application mobile development rational platform clm collaborative agaile 5,514 Views
Join the Webcast:
MartinKeen 1200007VU3 Tags:  bas-pluim security mobile-security mobile-development 7,900 Views
Using a mobile device is like going camping with a tent and backpack: The freedom to go anywhere is nice, but it's somewhat lacking in facilities and comfort. One thing I learned from camping is that you can make perfectly good coffee by boiling water in a kettle. You don't need one of those fancy machines. This came in pretty handy at home when there was a power outage last year. Likewise, mobile application development can teach us several things that also apply to web- and desktop applications.
1. Security is more than passwords
Entering long, complicated passwords like Qre56Z!ko8a22 with a full size keyboard is bad enough, but on a mobile device, it's twice as hard. Plus, there is no good place to stick that little yellow memo with all your passwords to the screen. Instead, mobile applications make increasingly use of other information for authentication, such as the network ID and geographic location. For example, a nurse working in the Emergency Room (ER) can access a patient's record on a tablet without a password, because the tablet is connected to the hospital's Wifi and is physically located within the ER. But when that same nurse takes the tablet to the coffee shop across the street, he has to enter a password before gaining access to any patient information.
Desktops and laptops typically do not provide a geolocation for an application to use. But there are other options, such as verifying the user's IP address, and checking the time of day. Not every application is used 24x7 world wide. For example, a web application to schedule court appearances would typically only be used within one country, during regular business hours. That doesn't mean the application should be unavailable at midnight, and a lawyer on vacation abroad should still be able to schedule a case. For those users, an elegant solution is to use a second method of authentication. After entering an ID and password, the user must also answer a security question ("What was the make and model of your first car?"). Some web sites already do this when a user authenticates for the first time from a different computer, which can be detected through the absence of a permanent cookie.
2. Laptops get stolen too
According to a study by McAfee and the Ponemon Institute, close to 5% of smartphones are lost or stolen every year. With a typical life span of just over two years, the cumulative chance a phone going missing is almost 9%. More than half of these phones have no protection at all, and only one in five has local storage encryption. It's no wonder security is a major concern for businesses trying to adopt mobile devices.
But the numbers are almost as bad for laptops. A study by Intel in 2010 showed that the chance of a laptop being stolen during its three year life is around 7%, with 70% of them lacking basic precautions such as encryption, back-up and anti-theft technologies. A laptop has a lot more storage than a smartphone, which means a single incident could be disastrous. Mobile devices deserve some leeway, given that they're relatively new and the challenges associated with using a personal device for company business. But these excuses don't apply to laptops. It's mind-boggling that security hasn't improved in this area.
3. You don't need to see that
One advantage of a small screen is that developers are motivated to limit the amount of information to display. If a data attribute is not essential to the task at hand, it is simply left out. And while accidental, this approach has also improved data privacy. It wouldn't hurt to apply this principle to other applications as well. Some of the administrative applications I've seen appear to be a cross between a spreadsheet and a teenager's bedroom. Fields are stacked haphazardly on massive data entry forms, using a one-size-fits-all approach. Sensitive data regarding finances and family members is placed right below the question on whether you'd like to receive the company newsletter. Just because we can cram everything onto the screen doesn't mean we should.
4. You don't need to see all of them
A good friend of mine has owned an iPhone since they first came out. He probably has accumulated several thousand pictures over the years. Whenever he wants to show you a really funny photo from a couple of years ago, the conversation stagnates as he furiously scrolls through screen after screen of thumbnails. If screen swiping was an Olympic sport, he'd win a gold medal every time. To his credit, he does always find it, and the photo is usually funny enough it was worth the wait. Regardless, mobile devices are not good at handling large volumes of data. Even the most humble laptop will eat a spreadsheet with 28,000 rows for breakfast, but give most smartphones a bad case of indigestion. Better search features such as type-ahead have helped developers limit the amount of data to return, which is also beneficial when the device has a slow data connection.
A positive side effect of limiting the number of records that can be accessed is security. Even if the device falls in the wrong hands, records can only be accessed one at a time. By contrast, some web applications allow users to dump the entire database and download it as a spreadsheet. Application designers should not only consider which data elements a user should have access to, but also think about volume. A call taker answering questions from clients only needs to access one record at a time. On the other hand, the financial analyst computing the average profit per policyholder does need all the records, but probably doesn't need sensitive items such as birth dates or social security numbers. The step-up authentication described under point (1) can also be used here. Whenever you want more records than is normal, answer a security question first.
5. The more, the merrier
The best mobile applications are the ones that are dedicated to a single task. Do one thing, and do it well. Unfortunately, there is a lot of desktop software that does a lot of things poorly. These so called "productivity suites" are usually bloatware by consensus: A bunch of features crammed together because nobody told the customer they couldn't have everything. Mobile apps on the other hand are entirely task based. If I want to look up someone's phone number, I get a phone number. I don't get someone's social media page with their latest Tweets and Pinterest photos carelessly strewn around their contact information. This doesn't mean there shouldn't be consolidation. Deep inside the corporate Cloud, you still want a single (federated) database and centralized business logic. But it is perfectly acceptable to have multiple applications that access the same data and services if it helps people be more productive.
Mobile applications are changing the way traditional software works. Overall, I think this is a good thing. When you're going camping in the woods, you quickly discover that items such as an electric razor just aren't worth the weight. And you can actually survive for a week without an espresso machine, panini grill or electric can opener. Less is more.
Bas Pluim is an architect for the Development Support Team, which provides cloud computing services to development and test teams. His focus is on mobile solutions using IBM Worklight. Bas is also a member of the IT Specialist certification board, and helps maintain the ITS Wiki. Follow Bas on Twitter at @baspluim.
Bas is an IBM Redbooks thought leader