Archive for the ‘mobile’ Category

Beyond the walls of the enterprise

April 12, 2012

Most in IT understand that mobile applications are unique. In terms of development, delivery, and management things just are not quite the same as compared to your typical enterprise application. There are many reasons for these differences including new and different programming models and languages, different application packaging and delivery, different development and testing methodologies, and more. While all of these are interesting and have profound effects, in talking to enterprise IT shops there is one major difference that sticks out a little more than most: mobile applications live beyond the walls of the enterprise.

Enterprise IT is all about the application, or perhaps better put, it is all about the services offered up via applications. If you look at just about any instance of enterprise infrastructure technology, you can usually talk about how it helps one to develop or deploy or manage applications (sometimes all three). To be fair, the types of applications and their purposes may vary widely, but they typically share an important characteristic. That common thread is that these applications are usually deployed to and managed from a datacenter that is under the control of the enterprise or a third-party provider. This is usually not the case, or at least not the whole story, with mobile applications.

If you consider anything beyond a simple mobile application that is nothing more than launching the device browser and pointing to a ‘mobilized’ web page, the difference in mobile applications probably sticks out to you. The application is in the hands of the end-user. More specifically, all or some portion of the application is installed on the user’s device. Does this really matter? I contend that it does, and I believe it warrants a number of considerations for the enterprise when evaluating technology that helps to manage mobile applications. In my mind, this includes at least the following:

Managing application versions: With mobile applications, the process of updating an application is not the same as with traditional applications. It is not a matter of only updating content deployed on some server within the management domain of the organization. In all likelihood, portions of the application are installed on the user’s device, so the enterprise must have some control over that aspect of the application. This entails many capabilities such as the ability to directly push application updates to user devices as well as the ability to disable applications and force application upgrades.

Managing application access and distribution: This is especially pressing in the scenario where organizations are creating mobile applications for use within the enterprise. In this case, organizations need to be able to control user access to applications. For instance, an organization may want to restrict access to certain applications until a user protects their device with a suitably strong password. Additionally, enterprises need the flexibility to distribute applications to their internal users. As an example, a company may want to distribute a particular anti-virus application to all users that connect to the company intranet with their mobile devices. The management of application access and distribution will only increase in importance as the Bring Your Own Device (BYOD) trend continues.

Managing application security: This actually seems to be one of the biggest concerns enterprises voice today in the mobile application realm. Any sort of mobile application technology must provide a means to secure all aspects of the environment. This means the enterprise needs mechanisms to secure application artifacts on the device, secure application data on the device, and secure mobile application access to existing enterprise information systems. Absent these measures, mobile applications present a huge vulnerability and expose an organization to a level of risk that is simply not acceptable for their brand.

These are just a few of the management considerations which I believe take on a slightly different context in the mobile application realm. But that is enough from me! What do you think? How is your organization addressing some of these unique mobile application needs? Connect with me @damrhein.

IBM acquires Worklight

February 29, 2012

How about we start this post off with some facts?

– Mobile data traffic exceeded voice traffic in 2010 (Wireless Industry News, August 26, 2010)

– Shipments of smartphones exceeded the shipment of PCs for the first time in 2011 (2011 Economist)

– Ten billion mobile connected devices are expected to be in use by 2020 (2011 Economist)

– 74% of surveyed CIOs indicated mobile capabilities were a top investment priority over the next three to five years (2011 IBM Global CIO Study)

As you may surmise from the above, the mobile computing space is hot. Companies are already doing mobile, and many have already or are looking to define their three to five year strategy. In that respect, this month’s acquisition of Worklight by my employer, IBM, is not at all surprising. Let’s take a little closer look at exactly what Worklight is and what it delivers.

A quick perusal of existing Worklight material provides us with the simplest explanation of the solution:

Worklight is an open, complete and advanced mobile application platform for HTML5, hybrid and native apps.

While I grant you that the above statement sounds like something right out of a product brochure that does not mean it is not accurate. We need to go a bit deeper than that though, and the best place to start is with an architectural diagram of the Worklight solution:

As you can see, the Worklight solution is made up of four primary components. These include the Worklight Studio, Worklight Server, Device Runtime, and Worklight Console. Let’s tackle each one of these in turn, starting with the Worklight Studio.

The Worklight Studio is first and foremost and Eclipse-based IDE. When installed, it augments your Eclipse runtime with a powerful set of tools focused on helping you to develop every aspect of your mobile enterprise applications. Worklight Studio embraces open web technology such as HTML5, CSS3, and JavaScript by proffering a model where developers start with a common, shared code base for their application. From that common code base, Worklight Studio makes it easy to create subcomponents of the main application that are optimized for specific platforms. This makes it quite simple to start with a common code base and build a deployable application for Android, Blackberry, iPhone, WinPhone, and more.

All of this is not to say that you cannot create rich mobile applications that access native device functionality. Worklight Studio includes the PhoneGap library that provides a device-agnostic JavaScript bridge to native device functionality such as the camera, accelerometer, and geolocation facilities. Furthermore, Worklight Studio provides native device SDK integration as well as the ability to develop applications that freely move between native and non-native screens.

Next up is the Worklight Server. First and foremost, the Worklight Server provides a central distribution point for your mobile applications. You deploy your mobile application assets to the Worklight Server, and you have a central point where you can manage application versions, push direct application updates, and handle application versioning, up to and including disabling old versions. Beyond these capabilities, the Worklight Server facilitates many mobile application security aspects. It provides the means to enforce secure connectivity from client devices, and it is capable of checking the authenticity of applications with which it is communicating.

There are a few other capabilities worth pointing out in regards to the Worklight Server. First, the Worklight Server plays host to what Worklight refers to as ‘adapters’.  Adapters are JavaScript code that provide connectivity from mobile applications to backend enterprise information systems such as REST-based services, web services, databases, or just about anything else to which you need to connect. Seeing as these adapters run in the Worklight Server (within a Rhino container), you have the means to secure these as is necessary for services that reach into your Enterprise Information Systems. Secondly, the Worklight Server delivers a unified push architecture that makes it simpler to send push notifications to applications running on a number of different client device types. Effectively, this unified push architecture serves to hide the complexities associated with pushing messages across the different mobile platforms and lets administrators focus on simply reaching their application users.

Next up in the breakdown of the big four is the Device Runtime component. Worklight provides a client-side shell within which your mobile applications run. This shell provides several features and qualities of service, starting with cross-platform compatibility. The shell ensures that your applications have ready access to JavaScript bridges that enable accessing native device capabilities (PhoneGap) and that integrate with native display capabilities like tabs, badges, etc. (part of the Worklight client API). Another important part of the Device Runtime is the ability to create an encrypted, client-side cache. The Worklight shell extends the concept of local storage in HTML5, to provide a secure manner with which to store application data that can later be retrieved to avoid unnecessary service calls or support offline access.

In addition to all of this, the Worklight client API that is part of the Device Runtime component provides integration capabilities with the Worklight Server to enforce user authentication, check network connectivity, log user actions for reporting and analytics, integrate with the push notification capability of the Worklight Server, and much more. Finally, the Device Runtime enables the unique notion of skins. Skins allow you to apply different views for mobile applications that run on different device types within the same device family (e.g. iPhone and iPad). This means that you can reuse nearly all application artifacts across a wide array of devices in the same family, thereby significantly reducing development costs.

Our brief and I mean very brief, overview of the Worklight solution concludes with a look at the Worklight Console.  The console provides a web user interface through which you can manage many aspects of your mobile applications. First, you can manage application versions and easily take advantage of the capability provided by the Worklight Server to disable application versions. Through the console you can also manage push notifications to various applications across various devices, thereby taking advantage of the unified push architecture provided by the server. Finally, the console provides a central view of reports on mobile application usage and activity per the out-of-the-box statistics provided by Worklight as well as what your mobile applications report via the Worklight client API.

I hope this gives you a good, if not high-level overview of the Worklight solution that is new to the IBM family. I want to reiterate that this is in no means an exhaustive explanation, but more of a primer. I am sure I will be writing more on this topic in the coming weeks and months, but until then I hope to hear from you. If you have questions, let me know right here or on Twitter @damrhein. Until next time!