The information technology field in an enterprise means constant change. It means that new gadgets come and go on an almost annual basis and that we frequently have to look at industry-wide changes. Many IT departments are built around the idea that a solid command and control structure can keep users from harming their devices and therefore keep support costs down.
Picturing the infrastructure
The iPhone is cool. Apple has spent a lot of time developing a device that is both a feature-rich platform and simple to use. The iPod touch enables you to use many of the same features of the iPhone, but you can use it without the monthly charges from a cellular provider. And then there is the iPad. The iPad goes above and beyond anything available on the iPod Touch or iPhone by giving you a faster processor and a larger screen, allowing for more productivity and even cooler applications. But if you are reading this article, you aren't likely interested in cool; you are likely more interested in productivity.
Application Sandboxing
One of the main differences between the iPhone and other platforms is the implementation of "application sandboxing," a term that means that applications are not able to communicate with one another. The most recent release of iOS—version 4—provides more options for developers to integrate solutions that can work with one another. However, the options are still few, and many are still untapped.
What this means is that each application is almost always a silo (memory, processing, and data) unto itself. That sandbox protects the device from many of the problems plaguing other platforms, such as malware. The sandbox extends to multitasking. Although iOS 4 also introduces more options for developers to determine how their application runs in the background, it is still best to use push technologies to communicate with applications that are not the foreground application. Most applications ask servers for data, but push means that data is sent to the application instead. A great example of this is any application that can put a red number over its icon, or badge, even when the application is not open. This number represents data that is waiting for the user to use. Push technology means that applications do not have to be open to receive data, limiting the resource intensity that the application has.
Long-Term Implications
Every device that is used in an enterprise comes with its own total cost of ownership. Depending on the size of your deployment, you will likely spend as much time planning the deployment as you will spend on the deployment itself (if not more). As the old saying goes; measure twice, cut once. But consider the recent adoption in the enterprise of these devices, and know that you need to maintain a certain level of agility with your infrastructure.
Before you deploy your mobile devices, there are some considerations that you will want to address, even if your design requirements will change drastically over the course of the next 18 months:
- What settings will go on each device?
- How much automation will we leverage?
- How will we manage our policies?
- How will we track our assets?
- What written policies do we need to ratify in anticipation of our deployment?
- How much user interaction do we require, and what kind of zero-tier assets can we provide to users for that interaction?
- What kind of data will users need to access, and how will they access that data when they are in the office?
- How will users access data remotely?
Every iOS device that gets deployed in an environment has an amount of automation that can simplify and streamline the deployment. For each click that can be saved, you will reduce the deployment time by a number of seconds. The more devices that you will be pushing out, the more significant these click-saving automations will be. Devices also need support, and the traditional thought behind support is that the more freedom you give users, the more per user you will pay in support. But given that Apple has a different way of doing things than you may be used to with other solutions, prepare to think a little differently!
Mobile Integration Strategies
Each mobile platform is unique and requires a unique integration strategy. For example, the BlackBerry from Research In Motion has BlackBerry Enterprise Server, capable of managing a fleet of BlackBerrys. Android, iPhone, iPod Touch, and Windows Mobile devices are capable of using ActiveSync for connecting to an Exchange server. From the Exchange server, policies can be applied and users can access mail, contacts, and calendars.
All of these devices will need to be activated, and all will need to be configured to work with your server. Of these, the BlackBerry is likely one of the easiest to deploy en masse for an enterprise. However, the gap narrows each year and can become even narrower with some strategies and third-party software. One of the core concepts is to provide choice to the users. If you are going to be supporting different types of devices, look for commonalities across platforms. Many support policies are handed down from ActiveSync, most come with a standard web browser, and almost all support groupware access through Microsoft Exchange or Google Apps.
By focusing on how you can provide the maximum number of services to devices with the least amount of integration, you will most likely maximize the return on investment of every dime of your infrastructure. This may seem obvious, but keep in mind that most devices are compliant to certain standards. This compliance enables you to extend support to additional platforms in some cases with absolutely no additional infrastructure.
Although device standards are important, each device will have its own specific design requirements, in many cases because most have their own unique development environment. This book focuses on minimizing these, and when possible provides recommendations for things you can do with infrastructure built for iOS that will also allow for tighter integration with other mobile devices.
The Paradigm Shift
The unique development environment is only one way that iOS-based devices are different from what you encounter with other platforms. The iPad and iPhone represent a new challenge to many environments. Many of the devices are owned by end users. There isn't a historical evolution of products and processes around iOS given its rapid adoption in many enterprises. In addition, the management options (including third-party options) aren't yet as mature as those for many other brands and operating systems of mobile devices. iOS-based devices aren't waiting for most enterprises or the systems administration community to come up with a solid plan, though, because—to put it simply—users love them.
Impact to Infrastructure
Users love iOS-based devices (and many of those users sit in the C-level suites of enterprises) because they are powerful. Most enterprises already have such devices, whether the devices are officially acknowledged or not. Many organizations support these devices, and others do not. Either way, the enterprise needs to formulate a plan of embracing the iOS devices, before business units split the centralized support structure of your organization and do so themselves.
For many organizations, centralized management is one of the most critical aspects when deploying any device to the enterprise en masse. Apple has not yet communicated a comprehensive strategy for centrally managing these devices. However, several third-party products have emerged to allow for centralized management. For example, JAMF Software has built management features for iOS-based devices into their Casper Suite of products for centrally managing Mac OS X. The companies Equinux (TARMAC) and Dell (KACE) have released management tools as well. All of these tools will allow for deployment, management, and reporting, providing a granular level of control over the devices that is not available using Apple tools alone.
All of the third-party products for deploying the iPhone, iPad, and iPod Touch use the same basic underlying technology that is provided by Apple. Basically, you start with creating a configuration profile in the iPhone Configuration Utility. You attach those profiles to groups of devices. You then load the application from the App Store or push the applications on each device, and you finally deploy the profiles to the devices. Given that all of the devices share an affinity for profiles generated using the iPhone Configuration Utility, it is critical to understand how to use the utility. It is also important to know how the profiles are interpreted and—according to the size of the deployment—how to tap into some of the options that can be manually added to profiles that have not yet been exposed.
Integration with the Enterprise
Most IT departments are going to be concerned about the items listed in the previous section: deployment, patch management, reporting, groupware, and so forth. But most important is user productivity. In order to maximize the return on investment in these devices, users need to be able to access the various services offered in the enterprise. These include file services, application publishing, web services, and logging into the network (on-site and remotely). Accessing files is the most common need most people have when interacting with networks. With a standard computer, you can read, edit, save, copy, e-mail, and delete many types of files out of the box. You can also purchase more software to allow you to interact with other types of files, such as Microsoft Office, the Adobe Creative Suite, and iWork. With iOS-based devices, most file types can be accessed in a read-only capacity by default. Third-party applications (and iWork for iOS) step in to fill this void by allowing you to edit documents. Those third-party applications can be purchased, or even built if you have a team capable of such a task.
Most third-party applications allow you to synchronize documents to devices by using a wire or another specific application, such as Google. However, for most applications, getting the documents to the devices can also be a challenge over the air. Applications cannot communicate with one another, but there are some tools that enable you to access documents as files. However, you cannot then edit them with another application unless you copy them to the local device, which can be done with the clipboard or through an application. This requires an almost scripted workflow design, rather than allowing users to interact with files through the Finder or Windows Explorer, as they would traditionally do in Mac OS X or Microsoft Windows. Although Google Apps and Dropbox have made this process much more seamless, not all organizations maintain their data in the cloud. Also, the devices will drain battery power and be under high CPU load with what would be a minor operation on an actual computer.
Although working with documents represents a common aspect of computer use, it is obviously not the only thing that computers are used for. In many enterprises, people also need to access intranets and business applications—most of which have no client specific to iOS. Many that are web based also will not work with the devices, given browser incompatibilities. Of those that do work with the devices, you then have issues with screen resolution, size of the text on the screen, and accessing data remotely. But the lion's share of IT budgets are geared toward building these enterprise-line business tools, such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Human Resources (HR) applications.
Luckily, many of these tools (after all, that's what ERP, CRM and other business applications are: tools to help people do their jobs more efficiently) will have an application programming interface, or API. An API enables developers to effectively build custom solutions that work with their tools. One such custom solution could be a web portal that aggregates content from various business tools, or allows end users to interact with data aggregated from those tools—for example, a portal that pulls certain fields from databases to show an executive a dashboard for a company's performance. Another would be a custom application that allows for meaningful interaction with this data built in Objective-C, the native programming language for iOS. That tool would then be sending data back up to the database, rather than just displaying figures from it.
Finally, applications can be provided to iOS-based devices via a thin client. A thin client is an application that runs on iOS and allows access to a client application or to a full operating system environment running on Microsoft Windows or on Mac OS X. In this book, you will look at leveraging the following standards for communicating with iOS-based devices:
- Remote Desktop Protocol (RDP): The proprietary Microsoft protocol for providing a remote graphical user interface (GUI) to another computer
- Virtual Network Computing (VNC): A cross-platform desktop-sharing system, more common in Mac OS X and Linux
- Independent Computing Architecture (ICA): The proprietary Citrix Systems client for accessing their application server environment
Although there are other tools that will allow you to leverage a thin-client environment, these are the most common in use in the enterprise. Thin-client solutions offer a method to access applications remotely without developing software, but can be the quickest solution to deploy when you need to stand up an application infrastructure quickly.
Addressing these challenges practically
In this excerpt, I've addressed the challenges that you will face when trying to integrate iOS-based devices into an enterprise. I've also discussed how this unique mobile platform fits into most environments and answered some of the burning questions that need to be answered quickly and up front.
The full book includes a tactical description of how to carry out what has been discussed here. It covers the questions that an enterprise level organization might ask, given an upcoming mass deployment and integration project.
