The content on this site is my own and does not necessarily represent my employer’s positions, strategies or opinions.
- I’ve been playing around with Swift, the new programming language from Apple, for a few days and I’ve been quite …
- The Supermoon over Cranberry Lake, New York, in the New York Adirondack Mountains on 11 July, 2014.
- Yesterday IBM and Apple made an important announcement about partnering to significantly growth the use of mobile via Apple devices …
What are the main considerations when designing a math system or library that can do symbolic computation on mobile devices?
I’ve written several times about math apps on mobile devices but, inspired by a blog post by Ismael Ghalimi, I want to comment a bit about how one might do symbolic computation on a small, probably mobile device.
What do I mean by symbolic computation? Some examples will probably make it clear. Unlike in a spreadsheet where you are concerned primarily with manipulating floating point numbers and text (e.g., 3.4 + 2.1 = 5.5), in symbolic computation you can also compute with expressions involving variables.
So in such a system you could compute that (x + 1)2 = x2 + 2x + 1 and the derivative of the result is 2x + 2. You can easily manipulate arbitrarily large integers and fractions of such numbers. There’s probably some capability for manipulating expressions involving trigonometric and other functions. You can both express sin2(z) + cos2(z) and the system will simplify it to 1. So you can manipulate and compute with basic expressions but also use structures like lists and mathematical vectors and matrices. With these you can then do linear algebra along with single and multivariable calculus.
I’ve oversimplified here and not mentioned all capabilities of such systems, but you should have an idea of how symbolic computation differs from what you can do in a spreadsheet. The two most successful commercial systems are Mathematica and Maple. Wolfram Research also provides Wolfram Alpha which allows you to use many of the computational capabilities of via the web and on mobile devices.
Though Axiom system at in the 1980s and 1990s, and it was built radically differently from the other two. In particular, it was ultimately built on Lisp which provided both bignum (large integers) and garbage college for the storage used. Yet another approach is that employed by the open source Sage application which collects together various implementations under one tent.and Mathematica share similar functionality and have very sophisticated computational and graphical features, they are implemented very differently under the covers. I was involved with creating the
Since you have different ways of building such systems and representing the computational objects in them, what are the considerations for using symbolic capabilities on a mobile device?
- Space: (x + 1)2 expands to just three terms, but the expression (x + 1)200000 expands to 200,001 terms, which will take up quite a bit of space, probably well more than 1Mb. So small things can get big quickly once you start computing with them.
- Time: Expanding the above polynomial can be done in a few seconds, but factoring it could take many minutes or hours, depending on your heuristics and algorithms. What will your mobile user be doing while he or she waits for an answer? Similarly, taking the derivative of an expression is relatively straightforward, though simplification can be time consuming. Integration can take considerably more time, if you can do it at all.
- Formatting: These days users expect beautiful output. So while sin(x2 + 2x + 1) looks fine, older style output like sin(x^2 + 2*x + 1) is just ugly. If you are just computing with a symbolic expression as part of a larger action, you may never need to show fancily formatted math expressions. By the way, once you get very large expressions that need to span multiple lines or large two-dimensional ones, formatting becomes much harder. See TeX and LaTeX to learn about how to handle the complexity in its most general form. In practice, you’ll do something simpler.
- Client vs. Server: How much work is done on the device versus on a big server somewhere? You can compute faster on the server, but what’s the delay in communicating back and forth with it and sending data? What do you do if you have no or limited bandwidth? Personally, I think a hybrid scheme where some things are done locally and others can be offloaded to a server probably makes the most sense, but it does complicate processing.
- Library: Do you want this code to be wrapped up in a library that can be linked to multiple apps? If so, you need to design your interfaces very carefully. If the library will be used by different parts of the same app, make sure it is thread safe, so you don’t mess up one computation that’s going on when you request another.
- Portability: If you could use languages like , Lisp, or Scheme, you would get bignums and memory management for free. If you use C++, you’ll have to do those things yourself, perhaps by using open source libraries to help you. On iOS devices, it’s perfectly fine to use Objective-C for the interface components and C++ for your computational back-end. You could also use that C++ code on an or Windows 8 Mobile device. I suppose you could use a subset of a Lisp interpreter written in C++ and then build your math code on top of that.
- Legal: has very specific rules about when you can download a script and run it on your iOS device. If you plan to download a file that contains a list of computations to be executed, make sure you are not running afoul of Apple’s terms and conditions.
- Extensibility: The big systems are all designed so users can add more capabilities to them. Depending on the system, the new things might run just as fast as what is built in, or somewhat slower if the expressions are interpreted. For mobile, I think this is mostly a core developer question: How do I construct the libraries at the center of the system so that I can easily add new mathematical objects with which to compute? The basic objects are probably integers, rational numbers, floating point numbers, polynomials, rational functions, general expressions that can include trig functions and integrals, lists, vectors, and matrices. How might you later add partial differential equations? I think you need a design that allows you to build new objects, register them in the system, and then compute with them as if they were there all along. This is more computer science than math, but you’ll quickly see the value in being able to extend the system.
In various Impact conference at the end of April, we’ve been using a slide that looks like this:presentations about mobile starting at the
I’m going to give a quick introduction to some of the terms on the slide and what we mean by them.
Client Mobile Initiatives
From IBM’s perspective, what is the client trying to do with mobile and why might they want to talk to IBM about it? In an earlier draft of this we used the phrase “client mobile entry points.” This wasn’t always clear to people, but it did convey the idea that a customer is starting from one very specific aspect of mobile and wants to have a discussion about that. The three areas on the slide intersect all parts of the mobile lifecycle.
Now let’s start in the upper right corner and move clockwise.
Build and Connect
It is often the development or IT staff that begins here.
Where do mobile apps come from? What is necessary to construct the part of the app that lives on the device, smartphone or tablet, and the part that lives on the server on the backend? What tools are available for the developer for the full application lifecycle? How about testing for all the mobile operating systems and devices? For the device, what framework will allow you to have exactly the right balance of native code and HTML5 to give you the functionality, performance, and portability you need? How will you handle having apps for at least iOS and ? On the server side, can you use Java to create the code to support whatever you mobile app is supposed to do?
Regarding connectivity, this includes from the device to the backend and then also among the backend systems, applications, and databases to which you need to communicate. Having a system that can talk primarily to only one kind of backend system might seem expedient today but will possibly not support everything you want to do with future mobile apps. Having a mobile server that sits in the corner and has only weak integration with your services, messaging systems, and enterprise services busses is not really being enterprise-ready.
Manage and Secure
It is often the operational IT staff or CIO’s office that begins here.
It can be very hard at times to separate all the capabilities needed for security, application management, and device management. I think it is a very smart career move to become highly proficient in all the elements of mobile security.
Almost everything you can use for security for the web, you can use for mobile. You need to manage security at the device level, at the individual app level, over the network, and within the enterprise infrastructure. Since mobile devices will increasingly be used for portions of sophisticated attacks from many directions and sources, you’ll need security intelligence based on analytics that can correlate, detect, and shutdown such attacks.
The area of data separation is getting a lot of attention these days through techniques like partitioning, containerization, and virtualization. We’ve seen many ways of doing this, especially for Android, and I’m waiting to see what Apple might do in this area.
It’s best to catch security problems before your app goes out the door.
At Impact I heard an estimate that there were close to 100 Mobile Device Management vendors out there. Choose carefully for the long term, especially if this is your most important and earliest mobile project.
Extend and Transform
This is place where the business side usually starts. Geolocation from the mobile device is frequently necessary for these apps to differentiate themselves from laptop alternatives.
Many customers are extending existing applications or channels to mobile. Have an online retail website? Create, or have someone else create, a dedicated and branded mobile app that allows catalog browsing and purchases.
If you are a bank, similarly create a mobile app but decide what functionality should be in there. I might apply for a mortgage from within my laptop’s browser but I won’t be doing it from my smartphone.
So extend means to take what you’ve got and add a mobile dimension. This is increasingly becoming table stakes, or required, for B2C enterprises. Many companies are focusing on doing this and many people are getting paid to help them do it.
For me, “transform” is the really interesting one of these two, however essential “extend” is. This means combining multiple services to create significant added value. Put another way,
a transformational mobile app is one that significantly improves the quality of your personal or business life, allowing you to do things you have never done before, and permitting you to be more effective and productive in an especially seamless way.
Transformational apps often pull in social and commerce aspects, backed by analytics. They may involve partnering between players in difference industries such as financial services, hospitality, retail, healthcare, government, and travel and transportation.
The hybrid approach to developing mobile apps offers advantages for those wishing to produce pure native apps or those that have HTML5 content.
Earlier in 2012, on January 31, acquisition of Worklight, a provider of a mobile application development platform. Several weeks later the deal closed. There’s a lot of discussion of Worklight and IBM’s Mobile Enterprise strategy here at the IBM Impact Conference in Las Vegas this week.announced its planned
Worklight’s components include a Java-based server that can run on the WebSphere Application Server, developer tools that can integrate with app lifecycle products from IBM Rational, a runtime monitoring and application management console, and multi-device runtime support. For this last part, Worklight uses a hybrid approach based on PhoneGap (now incubating in the Software Foundation as the Cordova project).
A hybrid approach like this is an elegant way of using open technologies and standards to span the full spectrum of mobile application development.
If you can build your app entirely using HTML5, do it. You can place it on the web or your intranet and your users can access it anytime they want. You can also update it when you wish. You can also skip the whole app store experience. This approach is based on open standards, the best way we have found to handle interoperability.
At the other end, we have Native. This uses the low level APIs and programming languages for specific devices. For example, for Apple iPhones and iPads you would usually code your app in Objective-C and link in any other libraries you need. The full power of the SDK and device is available to you.
It is also completely non-portable, albeit powerful. When you need to produce an Android version, be prepared to code the app all over again. Each version will look completely native to the device, and this is an advantage to multiplatform approaches that force apps to have a common but non-native look everywhere. (“Our app works the same and looks ugly everywhere.”)
Here’s something important that a lot of people miss about the hybrid approach. If you use no HTML5 content whatsoever, you still get the app manageability, push notification framework, and security from Worklight. So you get a pure native app that is nevertheless in the same “family” as your mobile apps that do include HTML5.
At the other other extreme, even if you use no special native features and try to have your app being almost completely HTML5, you get to put your app in an app store, and you, once again, get the app manageability, push notification framework, and security from Worklight.
So Worklight and its hybrid approach covers almost the entire range from pure HTML5 to pure Native.
This also means that your developers’ web programming skills are usable when building Worklight hybrid mobile apps. If you are a software developer, this is a very effective way to quickly add mobile app development to your portfolio of skills.
Some apps will use a lot of HTML5, some will use very little. With Worklight’s hybrid approach, your skills are applicable across many different kinds of mobile apps. This is important, trust me, because you won’t be building just one mobile app in the future.
I’ve been giving many talks lately to customers and partners about Worklight acquisition and the presentation I gave at Mobile World Congress 2012. Here are some more detail on one of the slides, the mobile lifecycle.‘s mobile strategy and recent moves in our product portfolios. See, for example, the news of the
Let’s go through the bullets one by one.
Strong demand by LoB
Mobile is personal: people have and use smartphones and tablets in their everyday lives. It makes it much easier for business people to imagine how mobile apps can affect and improve their effectiveness, customer loyalty, and revenue. This then drives the CIO, CTO, and the IT staff to decide how to create and distribute the apps. Their decisions include choosing a platform on which they can can consistently build the 5, 10 or more apps they will create in the next 3 to 5 years.
Higher expectations of user experience with mobile apps
Since people have so much experience with personal use of mobile apps, even games, they expect very high quality user experiences from apps provided by enterprises such as banks, insurance companies, healthcare providers, and governments. They have similar high expectations for any apps they use to get their jobs done, such as business analytics, workflow, supply chain, commerce, and social business.
Lack of best practices guidance on how to deliver mobile applications
There’s been a lot of mobile app building experimentation by businesses in the last two years. Many of the apps were outsourced and, while they may look good, came in much more expensively than expected. Some of the apps were native, some were HTML5, and some were done in “interesting” ways. Businesses need to control the costs in building and maintaining the apps, while getting maximal reuse of current staff technical knowledge. This means you take what you know and apply it to creating your first mobile app, but also use the same information and technologies to build many mobile apps after that.
More direct involvement from users/stakeholders in design
It’s not up to the IT team to figure out all the technology to build, run, connect, manage, and secure mobile apps as well as to define the user experience. People who will be using the apps want to influence the interface design, and in many cases insist upon it.
Native programming models are not portable across devices
You can create amazing beautiful and functional apps using pure native methods with theiOS and SDKs. Whichever one you pick, you can then do it all over again for the other one. This may be what you have to do, but recognize the difficulty and the expense. While some companies offer on-device environments to try to make apps work and look the same across devices, I think a much better approach is to maximize the use of open standards like HTML5. You also need to balance optimizing for a particular device, maximizing cross-platform code, and not having your app behave in a “least common denominator” manner.
Highly fragmented set of mobile devices and platforms
Raise your hand if you think we won’t see any more mobile operating systems in the next five years. Anybody? Nobody? Apple is different from Android which is different from BlackBerry which is different from Windows Phone. Android? Which version of Android? You need a mobile development and management platform that can handle mobile devices that exist today and will be introduced in the next few years.
Very large number of configurations of devices, platforms, carriers, etc. to test
Not only do we have many mobile operating systems, we have many handset providers and they may tweak the operating system and the applications available on it. The same goes for telcos. So you need a testing strategy that helps you cover the range of platforms you want to support. By the way, it is ok to say that you won’t cover all possible combinations. Pick the ones you absolutely must support and choose a mobile development and management platform that can handle those and the ones on your immediate roadmap.
Mobile landscape evolves at a much faster pace
New handsets come out every year, as well as major versions of mobile operating systems. Point releases of the operating systems come out every few months. For smartphones and tablets, many parts of the world are shifting from 3G to 4G. If you take too long to develop your mobile application or solution, you will be a generation or two behind by the time it gets to market.
More frequent releases and updates for apps with more urgent time-to-market demands
Not only do you have to get your app to market to match the hardware and software used by your consumers, you have to update and distribute your app as frequently as necessary to address bug and security fixes and competitive feature additions. Backward compatibility is important, but you need to evolve your app as fast as necessary to deliver what your users need to be productive and to stay your users.
Todayannounced some important enhancements to its Mobile strategy for supporting customers looking to grow and transform their businesses, whether they are B2C, B2B, or B2E.
IBM Advances Mobile Capabilities with Acquisition of Worklight
From the press release:
In a move that will help expand the enterprise mobile capabilities it offers to clients, IBM today announced a definitive agreement to acquire Worklight, a privately held Israeli-based provider of mobile software for smartphones and tablets. Financial terms were not disclosed.
With this acquisition, IBM’s mobile offerings will span mobile application development, integration, security and management. Worklight will become an important piece of IBM’s mobility strategy, offering clients an open platform that helps speed the delivery of existing and new mobile applications to multiple devices. It also helps enable secure connections between smartphone and tablet applications with enterprise IT systems.
IBM Announces New Software to Manage and Secure the Influx of Mobile Devices to the Workplace
From the press release:
IBM today introduced new software to help organizations better manage and secure the explosion of smartphones and tablets in the workplace, while also managing laptops, desktops and servers.
IBM Endpoint Manager for Mobile Devices helps organizations support and protect the growing mobile workforce. Through this software, firms can use a single solution to secure and manage smartphones and tablets, as well as laptops, desktop PCs, and servers. It managesiOS, , Nokia Symbian, and Windows Mobile and Windows Phone devices.
The software extends security intelligence to deal with the growing threats from mainstream adoption of the BYOD trend. Organizations can install the IBM software in hours, remotely set policies, identify potential data compromises and wipe data off the devices if they are lost or stolen. The software helps configure and enforce passcode policies, encryption and virtual private network settings.
Why I think this is important
After spending the last several months speaking with customers, I’ve concluded that 2012 will be a very significant year for Mobile in the enterprise. I think this is the year when customers will decide on the mobile platforms and tools that will carry them into the middle of the decade, and begin to discard earlier experiments.
The old category of MAP or MEAP (Mobile Application Platform or Mobile Enterprise Application Platform) is not sufficient anymore. Customers need everything to build, run, connect, manage, and secure mobile applications. Remember that we’re not just talking about the apps on the devices (and there are many devices), but also the backend server infrastructure necessary, and this needs to be enterprise-ready. By this I mean that it needs to scale and you must be able to integrate it with the services, applications, processes and data that are essential to your organization.
Therefore the modern Mobile platform needs device-side and server-side application development and lifecycle tools; support for multiple devices and mobile operating systems; mobile application an device management; security capabilities from the devices all the way to the back-end; and scalable, transaction-capable connections to the IT systems on which your organization depends for its business. This is what IBM is demonstrating today in these strategic announcements in addition to its existing products and solutions.
Join me today in Tweetchats
I’ll be using Twiiter today for 2 one hour sessions to discuss these announcements with Scott Hebner, VP of Marketing and Channel Management for IBM Tivoli.
The first session is planned for 10:30 to 11:30 AM ET and the second for 1:00 to 2:00 PM ET.
Both sessions will use the hashtag #ibmmobile. Myname is @bob_sutor and Scott’s is @SLHebner.
You can follow us via your usual Twitter client or else use the Tweetchat tool at http://tweetchat.com/room/ibmmobile.
Also see these blog entries
- Thoughts on mobile management
- Mobile BYOD is not unbounded
- 10 predictions for enterprise mobile for 2012
- Employee mobile device + work = potential security problem
What does it mean to manage a mobile device, say a smartphone like aniPhone or one with ‘s operating system?
At the lowest level, the device level, you might want to
- establish a policy for length and structure of passwords
- set or reset a password
- detect whether the phone had been jail-broken or rooted
- configure device-wide VPN
- set power management policies
- manage the low level security of the filesystem or other local storage
- wipe the device entirely or reset it to factory settings
Above that, at the application level, you might want to
- inventory the device for installed applications
- install or update applications
- set security policies for use of the applications, their data, and their network connections
- selectively remove an application or its data
- configure application-specific VPN
- manage anti-virus and other security tools for browsers and other applications that access the web
- manage installation and use of an enterprise application store behind a firewall, private hosted outside, or via external sites like the Apple iTunes Store or the Android Marketplace
The first list of items, with additional functions, is part of Mobile Device Management, or MDM. Note that people do sometimes confuse “MDM” in this context with “Master Data Management.”
The second collection is part of Mobile Application Management, sometimes shortened to MAM.
The first thing to notice is that what I deemed “management” often has a lot to do with security, especially when the phone is used to access enterprise data and systems.
Second, in practice, those who provide MDM functionality often provide some MAM functionality, and vice-versa. That is, a vendor might say “I can give you an enterprise app store but can also wipe devices.”
BYOD, or “bring your own device” complicates things because I probably do not want the organization for which I work to impose overbearing policies that affect my personal use of my phone. I certainly don’t want them to wipe my entire device if I leave the organization juto remove all traces of enterprise data or network access.
So the line is blurry between MDM and MAM, and I think we should get rid of the distinction altogether. That is, let’s just talk about Mobile Management and combine the two categories above. It will simplify things, remove the imprecision of the definitions, and bring better clarity to what vendors do and do not offer.
So if we can agree that Mobile Management consists of 27 common capabilities (for example), a vendor that offers 5 of them can be more fairly compared with one that offers 25.
No doubt that vendor proving minimum capability will embellish the description by adding “but we do it from the cloud!” (grin)
BYOD, or “bring your own device,” is an important topic in today’s discussion of mobile in the enterprise. Employees buy their own smartphones or tablets, love them, then bring them to work and want to use them to access company data, systems, and applications.
For the CIO, this represents an opportunity to save money by not having to pay for and provide devices, but opens up many questions about how to allow secure access and management of the enterprise portions of those devices. I’m here at the Lotusphere conference in Orlando, so it shouldn’t surprise you when I say that many of Lotus Traveler for secure access to email, calendar, and contacts on mobile devices, for example.‘s customers are looking at
BYOD does not mean that any employee can bring any device to the office and demand that it be allowed access to the company’s digital infrastructure. That said, if the CEO brings in his or her sexy new smartphone, the CIO may feel more inclined to make that work.
In practice, CIOs will say that certain devices running specific mobile operating system versions, augmented by security and management software and policies will be allowed access to the company’s network. That is, “bring your own device” really means “bring your own device as long as it is one of the following.”
Many enterprises already support Blackberrys, so that will be relatively easy. There’s not too much variation amongiPhones and iPads beyond the major version numbers. So while a 3g phone might work, I think many enterprises will insist on a 4 or 4s phone, probably running the latest version of iOS.
is more problematic because there are many handset providers and many versions of the operating system. Expect individual handset vendors to negotiate directly with CIOs to allow use of their devices in the CIOs’ companies, even if those devices are bought by the employees.
The wildcard here will be Windows Phone and the devices that support it. While Apple iOS and Android are very different, both technically and culturally, Windows Phone is different yet. While Mango is quite nice looking, as I saw from the Nokia team at Lotusphere, will individual purchasers and CIOs wait until Windows Phone 8? Will the rate of adoption allow it to be accepted into the enterprise any time in 2012 or might it even be 2014 before the demand is sufficient for supporting it inside companies?
My advice to CIOs is this: if you support Blackberrys, you will need to support them for the foreseeable future. The newer iPhone and iPads will need to be given enterprise access because of their marketshare and the demands of senior management. For Android, pick a couple of handset vendors, perhaps based on a survey of your current employee users, and settle on the level of the operating system you will support. Educate yourself about Windows Phone, but the above combinations are probably of more immediate and higher priority.
This release includes updates to the mobile application manager with social feedback, SMS support, tools, and, perhaps most important, support for‘s iOS mobile operating system. The first two releases supported only.
This drop also includes the latest version of the Liberty Profile for the WebSphere Application Server. It’s a great example of how we think customers will use the Liberty Profile and OSGI in action.
The Mobile Tech Preview is our way of giving you a glimpse of what is going on in the IBM labs around the area of mobile application development, tooling, security, and management.
Yes, it’s that time of year of for predictions for what we might see in the next twelve months. Being in the IT business and in a company like, I’m somewhat hamstrung in what I can say regarding the future because of confidentiality, but here’s my attempt at some prognostications that won’t be giving away anything secret.
These are my personal predictions and not those of IBM.
- There will be a huge rush to fill the developing void being left by RIM and Blackberry, and smart enterprise CIOs will focus on security and management issues first.
- Although there seem to be 1 or 2 new entrants in the mobile device management area every week, potential customers will learn that it takes more than being able to call an API to wipe a device to give you enterprise credibility.
- The differences between mobile application management and mobile device management will become clear.
- Companies that develop multiple applications will understand that some will be web/HTML5 based, some will be native, and some will be hybrid. You don’t need to support just one kind and your application platform vendors shouldn’t force you to do so.
- CIOs will realize that the connection between mobile and cloud is overhyped. CIOs will realize that the connection between mobile and cloud is underhyped. That is, your use of cloud for mobile applications may not be in the way you expect today.
- Traditional networks that support web applications will need to be reconfigured and re-optimized to support an increasing amount of traffic from mobile devices. The number of interactions will dramatically increase, their length will be shorter, and significantly more asynchronous notifications from the server side will all drive a lot of R&D.
- While fans continue to claim world domination and keeps selling more and more iPhones and iPads, look for ‘s relative marketshare to start inching up.
- WebOS is done, but look for a new smartphone/tablet operating system to arise by late 2012 that will start to challenge RIM and Microsoft for the number 3 and 4 market positions.
- will have a serious tablet in the market by mid-2012 that will start to get some enterprise interest. The connection between that and the Amazon cloud will become clearer. The device may not be running Android.
- Apple will make changes to iOS to make it easier to support both personal and enterprise secure personalities on the same device. Yes, I know you can do this on Android today, but we weren’t talking about Android, were we?
Bonus: I will give up my Blackberry and get an Android smartphone for the first time (to complement my personal iPhone and).
Over the last 15 years of my career, I’ve seen several ideas or technology trends capture a significant amount of customer, press, and analyst attention. There was Java, XML, web services, SOA, and cloud. In and around all those were standards and open source. To me, the unquestionably hot technology today is mobile.
To be clear, I’m not talking about what happens in cell phone towers or the so called machine-to-machine communication. I mean smartphones and tablets. Those other areas are important as well, but devices are so front of mind because so many people have them.
is obviously playing a big role with its iPhone and , not to mention the half million apps in their App Store. and the ecosystem have produced even more smartphones and a whole lot of apps as well. Then there’s been the drama around HP and webOS, plus RIM and the PlayBook and outages. So we’ve got competition, winners and losers, closed ecosystems, and sometimes open ones. What’s not to love about mobile?
It can get confusing, especially for people trying to figure out their enterprise mobile strategy. They are looking for strong statements, for “points of view,” that will help them take advantage of mobile quickly but also aid them in avoiding the biggest risks. This is made even more interesting by employees bringing their own devices to work, the “BYOD” movement.
Not every employee is issued an official company smartphone and the devices they buy themselves are often better than what the company might provide. So they are saying “I’ll pay for my phone and my contract, let me have access to work systems so I can do my job better.” The recent ComputerWorld article “IBM opens up smartphone, tablet support for its workers” discusses some of what’s happening in this space at , my employer.
Next there is the whole web vs. hybrid vs. native discussion regarding how to build apps on the device itself. Should you write it to the core SDK on the device (native), stick to developing standards for continuity and interoperability reasons (web), or something in between (hybrid)? Which is faster and for what kinds of apps? Does the app cause a lot of network traffic or does it require great graphics? Are you willing to bet that HTML5 will get better and better? I’ve started discussing this in a series of blog entries called “Mobile app development: Native vs. hybrid vs. HTML5″ (part 1 and part 2). Your choice will involve tradeoffs among expense, time to market, reuse of web skills, portability, and maintainability.
What about management? If I bring my own device to work, how do the company’s apps get onto it in the first place and then get updated? Is there an enterprise app store? If I leave the company, do they zap my whole phone or just the apps they put on it? There are differences between Mobile Application Management (MAM?) and Mobile Device Management (MDM) that you need to understand.
Let’s not forget security, as if we could. A colleague of mine, Nataraj Nagaratnam, CTO of IBM Security Systems, told me the way to start thinking about that for mobile is that “a secure device is a managed device.” That doesn’t mean that all security falls under management, but rather you need to have device management to have a complete mobile security strategy. You also need to be handle identity management, authorization and authentication, single sign-on across apps, data loss protection, and all the things you need to worry about with the web today such as phishing, viruses, worms, social networking, VPN, etc. Security must be there but it also needs to be unobtrusive. Most mobile users will not know what a certificate is nor whether they should accept it.
Fundamental to managing and securing mobile devices compared to laptops is that people tend to lose their phones a lot more often than they lose their laptops. That’s a good starting point for thinking about the differences.
The Mobile Technology Preview encapsulates several technologies we’ve been working on in the labs. We’re making it available for you to experiment with it, comment on it, share your requirements for your mobile platform, discuss the pros and cons of different approaches to mobile app development on both the device and server side, and join the community to make it better.
We plan to update the Technology Preview as we add or change the feature set, ideally because of your stated requirements. In this release we’ve included
- an application server runtime that uses the WebSphere Liberty Profile of the WebSphere Application Server 8.5 Alpha (runs on Linux, Mac, and Windows)
- a notification framework
- basic management functions
- location-based security
- several samples featuring notifications, Dojo, PhoneGap, and a starter insurance app for handling car accidents.
The Mobile Technology Preview is available for Android devices.
I plan to use the tech preview from time to time to illustrate some of my discussions of mobile in my blog. I encourage you to try it out, track its progress, and influence its roadmap.
Employee: “I lost my.”
Corporate security: “Why are you telling me?”
“I had company documents on it.”
“But you had the mobile security package installed, right?”
“I would have thought the company president would have known better …”
With the BYOD, or Bring Your Own Device to work, movement rapidly picking up steam, more and more employees are taking their smartphones and tablets to the office. This can be a boon to the CIO’s office if it no longer needs to foot the bill for those fancy new devices, but opens up all sorts of security problems.
The great thing about the current generation of phones and tablets is that they are so usable. Even forgetting apps, having mobile browser access wherever you are gives you access to information and processes that can help you do your work more efficiently and in a more time sensitive way.
Of course, being so convenient and light, it is also easy to lose them. This is why you can’t just tell your people to use their phones for work. You need to manage the access and resources they have, and be able to shut it down or delete them if the case arises. This could because because of a lost or stolen phone, but also because the employee should no longer be able to get to company data. There are levels of security access and people who are former employees should have no access at all.
All of this is on top of the security problems we already recognize and handle on laptops, such as phishing, viruses, and data loss protection.
And now a word from my sponsor …
announcing the Hosted Mobile Device Security Management service. Capabilities in the new mobile security service include:is today
- Configuring employee devices to comply with security policies and actively monitoring to help ensure compliance over time
- Securing data in the event that a device is lost or stolen
- Helping to find a lost or stolen device – wherever it is
- Protecting against spyware and viruses
- Detecting and removing malicious and unapproved applications
- Monitoring and tracking user activity
- Enabling more secure connectivity
And now back to me …
Seriously, this is a big but I believe containable problem if you take the necessary steps to understand the security exposures of employee devices in the enterprise and take steps now to provide the necessary security. Many people are familiar with the security and management capabilities of RIM and Blackberries, and they are now asking for the same level of comfort for iPhones, iPads, anddevices.
If you don’t have a security policy in place for mobile devices in your company, you should start putting one together and implementing it now. Think about how many devices will need to be supported, what kinds, to what they will need access in terms of processes and data, and what you need to do when something goes wrong.
An employee need to understand that if he or she wants to use that cool new tablet for company work then he or she will need to live by the rules and policies set down to protect the organization’s assets. There’s a spectrum of possibilities between “you can’t use your own to device” to “you can do whatever you want.”
As an industry we’re trying to help companies move from the first situation to something in the balanced middle that provides the right level of security while maintaining the convenience, usability, and power of the devices.
- Press release: “IBM Unveils Mobile Security Service to Protect Sensitive Corporate Data”
- Press release: “IBM X-Force Report Reveals Mobile Security Exploits to Double in 2011″
- All Things Digital: “IBM Launches Service to Secure Smart Phones at the Office”
- TechCrunch: “IBM Debuts Mobile Security Service For Smartphone And Tablet Use In The Enterprise”
- InformationWeek: “IBM Launches ‘Bring Your Own Device’ Security”
I read with interest the recent announcement by AppMobi that they are producing a browser foriOS and eventually that will go beyond the basic HTML5 capabilities.
- InfoWorld: “Have your HTML5 and native app too”
- Press Release: “MobiUs is Here; the World of Web Apps Will Never Be the Same”
Hybrid apps are not pure native and not pure web, but bridge the gap in between. There are several ways of doing hybrid. PhoneGap is a popular open source technology for building hybrid apps, but there are others as well. You get to have all the display capabilities of a browser with the functionality of the underlying device.
Hybrid apps are not for every application design, but can do very well if there is a lot of network interaction, not too much necessary graphic performance, and whatever UI design you can handle in a browser with widgets coming from Dojo, jQuery, Sencha, or similar technologies.
The idea of this new browser is to include the PhoneGap and other APIs so you can write enhanced HTML5 apps with more access to the underlying features.
Is this interesting? Yes.
Does it cause people to think through the implications of native vs. hybrid vs. web? Yes.
Will people rethink app stores and how you can collect and manage apps that run in a browser? Yes.
Will it speed up development of HTML5 and mainline browser support for additional device features? Maybe.
Will this be the browser we are all using in 2 years? I really doubt it.
The web became successful because browsers became standardized. In the early days we had different browser functionality asInternet Explorer tried to set de facto standards and Netscape tried to use real ones. Eventually , Chrome, and Safari all supported web standards, more or less, and competed on speed and quality of rendering. IE eventually caught up though it is losing share as we speak.
So I applaud AppMobi’s attempt to push the envelope here on what can be done in a mobile browser, but I think the mainline mobile browsers will eventually set the standard for how HTML5 and agreed upon extensions work.
We don’t need certain apps to require particular browsers to work. Check out this story from 2005 where the US Federal Emergency Response Agency required people to use IE to apply for aid after Hurricane Katrina.
Also see: Ars Technica – “The end of an era: Internet Explorer drops below 50% of Web usage”
I’ve seen and heard a lot of discussion about how people build applications for mobile devices. While there are literally hundreds of thousands of apps out there for, , Blackberry and other smartphones, I can’t help but think the majority of these are one-off efforts. In this series in the blog, I’m going to tackle some of the issues with developing mobile apps, especially for enterprise use, and along the way propose some ideas for making the process easier and more repeatable.
In the last entry I spoke about the attraction of writing pure Native applications for mobile devices. They’re fast, have full access to all the device features, and can be made as beautiful and functional as your software development skill allows. They’re also non-portable and can take more people, time, and money to develop.
Wouldn’t it be nice to be able to develop applications using open industry standards that run in many different environments? You know, applications that allow text content, great formatting, images, video, forms, and interaction with backend systems?
While there have been many motivations for developing HTML5 given the experience of people creating billions of web pages, I think it’s safe to say that creating a standards-based cross-platform environment for mobile devices was an important reason. That is, don’t think of a web page as just something you read, but rather consider it an application with which you are interacting.
I won’t go into all the features of HTML5 but there are several good references on the web in addition to the spec to which I linked above. In particular:
- IBM developerWorks HTML5 Fundamentals
- Wikipedia HTML entry
- Apple’s HTM5 page (very glitzy)
- HTML5 Rocks
Generally, HTML5 allows much better and more consistent ways of embedding multimedia in web pages. It also adds new elements to help you structure the document. The Document Object Model, something I worked on in ancient history, is now considered core to the specification and the programming model.
These are nice things for web pages, but does HTML5 give you anything new that makes its especially attractive for mobile devices? One of these is the geolocation application programming interface. In short, this allows you to programmatically determine your location, and then do something with it. That “something” might be to pinpoint your location on a map, provide a starting point for map directions, determine what weather forecast to show you, or display ads for local businesses, for example.
You can also store information locally on your device, though that opens up the question of security if you happen to lose it or you somehow get hacked.
What about access to other core features on your device? Using pure HTML5, can you snap a picture? How about use the compass or receive a notification? You can’t, but remember that you can still do all the interactions that you’ve been doing for years in your browser. You can read all sorts of information, do searches, buy things, access FaceBook, and so forth.
So HTML5 provides a richer interactive environment than we’ve had before and is starting to allow programmatic access to some device features.
If HTML5 does everything you need for your planned application, then use it.
HTML5 is still under development and you are seeing support for it from the big industry names that supply browsers or content, companies like, Apple, , and FaceBook. , of course, has been and continues to be a huge supporter of open Internet and Web standards.
You do need to understand which HTML5 features are considered solid and which are experimental. You should also experiment with formatting on multiple devices to make sure that your app looks right (not too skinny, not too wide, just right) on the smartphones or tablets that are important to you.
Note that an HTML5 app is really just a web page, so you don’t need anyone’s permission to put it into an app store. For many people, that is more than enough reason to try really hard to make HTML5 work.
Also, even if you are developing some native applications, you might decide to do some HTML5 ones as well. The more experience you get in creating apps with different capabilities, the better you will get at economically providing apps faster to your consumers, customers, or employees.
So Native gives you everything, but is non-portable. HTML5 is portable and standards-based, though it is still under development and does not give you full access to the device. What do you do if you want the best of both worlds?
Hybrid is this weird middle ground between Native and HTML5. Over time, this gap between them will get smaller. There are several approaches for both development and runtime of Hybrid apps, and I’ll discuss them next.
I’ve seen and heard a lot of discussion about how people build applications for mobile devices. While there are literally hundreds of thousands of apps out there for, , Blackberry and other smartphones, I can’t help but think the majority of these are one-off efforts. In this series in the blog, I’m going to tackle some of the issues with developing mobile apps, especially for enterprise use, and along the way propose some ideas for making the process easier and more repeatable.
I’m going to start this series by discussing the basic concepts of how you might develop an application for a smartphone or a tablet. I’m scoping it at this high functionality level and not looking at feature phones, at least not right now. I’ll use Apple as my primary example, but things are similar for other devices and mobile operating environments.
If you have an Apple Apple’s developer website and contains almost everything you need to start creating apps. Like any software you plan to use, make sure you read all the legal terms and conditions before you agree to them. If you work for a company, make sure your manager and local attorney also agree that you can use the SDK. This goes not only for Apple, but for , Blackberry, , or any other SDK provider.or an iPhone, many of the apps use the native software development kit, or SDK. It is available from
Most native apps on Apple devices are written in Objective-C, an object-oriented language. If you’ve developed software using C++, C#, or Java, Objective-C might take some getting used to. If you are comfortable with SmallTalk, however, it should seem much more familiar.
An Objective-C application is developed using the traditional write-compile-link-run-debug iteration, though the Apple XCode environment is quite powerful and makes this loop straighforward. Nevertheless, it is not a whole lot different from what programmers did 10 or 15 years ago. Objective-C is not a scripting language, is not interpreted, and on mobile devices you need to do your own memory management.
That said, when you create an app with a native SDK, you can use the very best and most powerful features on the device. You can optimize your app as much as you want and you have maximum control. This is very important for many software engineers. The app will be as functional, as beautiful, as secure, as bug-free, and as fast as you and your team can make it. It may also take you much longer to develop the app because you need to do all these things yourself.
Yes, the SDK makes your life easier, but it is still the case that when you go the native route you need to do more of the basic development yourself.
Here’s another important issue: if you write an app using a native SDK directly, you will essentially need to completely rewrite it when you use native SDKs for other devices. I say essentially because you may be able to write some of your apps non-UI program logic in C++ and re-use that for Apple, Android, and some other environments. There are some additional but similar tricks available.
To be on the safe side planning-wise, if you decide that you need to support multiple devices and you are using the native SDKs, assume that you or someone else will rewrite the app as many times as necessary to get the broad support you need. It is not uncommon to develop the first app for the iPhone and then outsource the creation of versions for other devices based on the original reference implementation. This can be expensive and time-consuming because you need a lot of people to get this done.
For some apps you will need to go the native SDK route for the reasons I stated above. If you do not have extreme requirements for look-and-feel, device functionality, or performance there are some other choices.
In future entries I’ll look are extending the native approach with libraries, something I call, oddly enough, “Extended Native.” I’ll also discuss the pure HTML5 web approach, and poke at the strange middle ground between Native and HTML5 called “Hybrid.” Tools that target multiple devices such as cross-compilers can also work, and I’ll get to them as well.
Next up: HTML5