I am heading to NYC this morning to attend the Mobile Business Expo (part of Interop 2009). I am moderating a panel that discusses use of the iPhone in the enterprise. See panel members and description here. I will upload my slides later today.
|
|||||
|
Enterprises often ask me about the technology solutions that will help them mitigate the risks associated with supporting the iPhone. Most of the conversations inevitably start with the same questions, discuss the same answers, but, interestingly, lead to different conclusions. As I contemplate why this occurs, I am struck with the notion that when enterprises ask me about the iPhone they are really asking me to help them figure out their iPhone policies. Policy defines things such as who owns the iPhone (i.e., ownership policy), how the iPhone can be used (i.e., usage policy), and what level of risk they will tolerate by using the iPhone (i.e., risk policy). Well, if iPhone deployment is a question of policy, then what drives policy? More often than not, I observe that policy is driven by corporate culture and by the regulatory environment within which the enterprise must operate. Some enterprises have a very permissive culture. They assume that employees usually try to do “the right thing” and that allowing them to use the iPhone will improve their productivity. Others, are more restrictive and do not feel comfortable with the lack of enterprise control over the iPhone. This restrictive perspective is especially true in highly regulated industries such as financial services. In a “perfect” world, business requirements should drive technology decisions. But, my observation is that corporate culture has an enormous influence on controversial technology decisions, such as enterprise iPhone support. Given the fact that there is no technology that will mitigate all iPhone risk, enterprises should spend more time trying to define policies that they can live with, and less time trying to find a perfect technological solution. Introduction This post continues a three part series on maximizing ROI for mobile applications. Part 1 explained why mobile application development is so difficult and introduced three common deployment approaches. Part 2 discussed the pros and cons of each technique. This post provides specific tips to help enterprises maximize their mobile application return on investment (ROI). Tips to maximize ROI
Conclusion This three part series reviewed the most common approaches to mobile application development. The thin client approach uses a mobile browser to access a server resident enterprise application. The thick client approach is built upon full-featured, smartphone-resident software. Finally, the mobile middleware approach uses an abstraction layer that sits between the native mobile phone hardware/software and the enterprise application. Each has their challenges and benefits. However, by following the tips outlined in this post, enterprises can maximize their mobile application development ROI. This blog post was originally written by me and published on www.searchmobilecomputing.com. It is posted here with permission from TechTaget. Does anyone really care that the IEEE finally ratified the 802.11n wireless standard…anyone…anyone…Bueller? The sorry fact is that the final ratification will have virtually no impact on the wireless industry. This is because what customers care about most is product interoperability. The Wi-Fi Alliance stepped into the standards void in 2007 and began certifying product interoperability based upon IEEE 802.11n draft 2.0. The fact of the matter is that the Wi-Fi Alliance did such a great job with their 802.11n certification program as to make the final IEEE standard a non-event. The evidence for my statement is that the wireless industry currently ships over 1 million Wi-Fi products PER DAY, and well over 50% of those products are based upon 802.11n! You can relax in knowing that no driver updates (or hardware changes!) are required for compatibility with the 802.11n standard. This is because the Wi-Fi alliance announced that they would not need to make any changes to the baseline requirements of its 802.11n certification program. So, any Wi-Fi CERTIFIED products based upon 802.11n draft 2.0 are automatically certified as interoperable with products based upon the final 802.11n standard. … I’m still waiting…Bueller? Introduction Back in November of 2008 I wrote about the Wi-Fi Protected Access (WPA) attack by the German graduate students Erik Tews and Martin Beck. They discovered a limited method to crack WPA, or more specifically, to crack the TKIP component of WPA. Their paper describes the attack and their tkiptun-ng tool carries out the attack. Now, Japanese researchers Toshihiro Ohigashi and Masakatu Morii have taken the Tews-Beck attack one step further. Their paper describe how they can reduce the attack time from 12-15 minutes down to 1 minute and how they can eliminate the requirement that the station under attack support the IEEE 802.11e QoS mechanism. Some articles have sensationalized this attack and have even implied that AES-CCMP could be next. Bottom line:
Recommendations:
Terminology There is some confusion over the difference between the Wi-Fi Alliance certification and the actual features supported by the vendor equipment. WPA certification: The older Wi-Fi Alliance WPA certification designation means that the equipment was certified to support: 802.1X, EAP, TKIP, and RC4. WPA2 certification: The newer (and now mandatory) WPA2 certification designation means that the equipment was certified to support: 802.1X, EAP, and AES-CCMP. Vendor equipment: Some vendors chose to support both TKIP-RC4 and AES-CCMP irrespective of how the equipment was certified. It is therefore possible to configure some WPA-certified equipment to support AES-CCMP. It is also possible to configure WPA2-certified equipment to support TKIP-RC4. More detailed information:
Introduction Enterprises use many different approaches to develop applications on mobile devices. This post continues a three part series on maximizing return on investment (ROI) for mobile application development. Part 1 explained why mobile application development is so difficult and introduced three common deployment approaches. This post discusses the pros and cons of each approach. Finally, Part 3 will provide specific tips to help enterprises maximize mobile application ROI. Thin client The thin client approach uses a mobile browser to access a server resident enterprise application. This approach has the following benefits and challenges. Pros
Cons
Thick client The thick client approach deploys a full-featured smartphone-resident application. This approach has the following benefits and challenges. Pros
Cons
Mobile middleware The mobile middleware approach uses an abstraction layer that sits between the native mobile phone hardware/software and the enterprise application. This approach has the following benefits and challenges Pros
Cons
Next time This post reviewed the pros and cons for each approach. In part 3, we look at specific tips to maximize the return on your investment. This blog post was originally written by me and published on searchmobilecomputing.com. It is posted here with permission from TechTaget. Introduction Thousands of ingenious, and sometimes frivolous, Apple iPhone applications have inspired developers to imagine new enterprise mobile applications. Inspiration is nice. But in this challenging economic environment, enterprises need to ask themselves how deployment of mobile applications will solve practical business problems and how they can maximize the return on investment (ROI) when developing mobile applications. This post begins a three part series on maximizing ROI for mobile applications. Part 1 explains why mobile application development is so difficult and introduces three common deployment approaches. Part 2 will discuss the challenges and benefits of each approach. Finally, Part 3 will provide specific tips to help enterprises maximize mobile application ROI. Mobile application deployment challenges The worn out cliché that we live in a mobile world is nonetheless true. The executive road warrior, multitasking medical doctor, and airport hopping sales executive need continuous access to information. Whereas mobile workers once hoped for ubiquitous information access, they now demand it. Unfortunately, satisfying these user demands is quite challenging. Mobile workers often need access to applications that require access to diverse back-end database systems and servers. Mobile cellular services have different throughput and latency performance characteristics that vary as the worker roams from place to place. Mobile device security and management capabilities are oftentimes insufficient to satisfy enterprise security policies. And finally, mobile device processors, form factors, graphical interfaces, operating systems, and development environments vary widely. Thin client There are three broadly defined approaches that enterprises commonly use to develop mobile applications. The most straightforward is the thin clientapproach. The thin client uses a mobile browser to access a server-resident enterprise application. The application relies upon the server’s hardware and software resources (CPU, memory, and operating system etc.). The mobile phone browser simply provides an interface to the application. The thin client requires a continuously active network connection in order to operate. A related approach is to use a rich Internet application (RIA) framework on the mobile phone such as Java FX, Flash, mobile AJAX or Silverlight. Such frameworks provide an environment on the mobile phone within which developers can deploy more sophisticated applications. This approach blurs the distinction between a simple thin client application and a full-featured thick client application. Thick client The thick client approach is built upon full-featured, smartphone-resident software. The application relies upon the hardware and software resources of the mobile phone. The look and feel of the application is highly dependent upon the mobile device software development kit (SDK). The client uses the network to communicate with remotes servers and databases but it can function without a continuously active network connection using locally stored information. The enterpris must develop server side software that interacts with the smartphone resident thick client. Enterprises develop thick client applications by using the development environment provided by mobile device manufacturers such as the RIM BlackBerry MDS, the Nokia Symbian OS, and the Apple SDK or by using mobile operating system vendors such as the Microsoft .NET CF for Windows Mobile. Mobile middleware The mobile middleware approach uses an abstraction layer that sits between the native mobile phone hardware/software and the enterprise application. Developers write their application using middleware application programming interfaces (APIs) instead of the native smartphone APIs. This approach improves application portability because the middleware APIs support a broad set of mobile hardware and software environments. The middleware also provides support for diverse back-end servers, databases, and communication systems. Many of these mobile middleware solutions from companies such as Sybase iAnywhere, Dexterra, and Antenna software provide more than just an abstraction layer. They can also provide cross-platform security and device management features and may also package their own mobile applications (e.g., mobile email and instant messaging). Next time This post introduced three common approaches to mobile phone development. Each of the three approaches has their challenges and benefits. Part 2 of this series will analyze the challenges and benefits of each approach. This blog post was originally written by me and published on searchmobilecomputing.com. It is posted here with permission from TechTaget. Introduction The growth of mobile phone usage and the availability of desktop unified communication (UC) solutions has created an opportunity for vendors and service providers to introduce products and services that enable mobile users to access many of the same features that previously could only be accessed through a PC or fully-featured desktop IP telephone. These products and services enable enterprises to extend telephony features to their mobile users, while making mobile users more productive regardless of location. In part one of this post we discussed the capabilities and issues with mobile UC products. In part two, we focus on mobile UC services. PBX as a service PBX as a service provides similar features as mobile extension products but are offered as hosted services that enable incoming call routing based on predefined rules. (Mobile extension products, discussed in part one, treat the mobile phone as if it were an enterprise phone extension and simply route calls to the mobile device.) Users sign up for the service, obtain telephone numbers that become their personal phone numbers, and then use web portals to manage how calls are routed. PBX as a service solutions are telephony-system and phone independent, meaning that they can function in an enterprise environment regardless of the type of telephony system or the type of mobile phone. The value of this approach is that a customer can use a single number for all inbound calls, and the service then gives incoming callers instructions to ensure calls are routed properly to the mobile or desktop phone. Solutions such as Grasshopper, RingCentral, VirtualPBX, and Onebox are targeted at small and medium sized businesses. They provide enterprise telephony features without the need to buy and maintain equipment and hire IT staff. Calls that use the service consume monthly minutes of use, similar to a mobile cellular plan. The Grasshopper’s high-end “Max” plan provides three toll free numbers, two local numbers and 10,000 minutes of use. This plan would enable 50 employees to consume 200 minutes of use every month. Managed Mobile UC Network operators have begun to offer a limited set of mobile UC managed services. Verizon’s Managed Unified Communication and Collaboration service is based on Cisco’s Unified Communications System. British Telecom (BT) has partnered with Cisco, Avaya, and OnRelay to offer several UC services. Orange’s Business Together service provides a managed Microsoft Office Communications Server plan. Some operators provide special rate plans and call routing for mobile phones. AT&T’s OfficeReach solution can extend an enterprise dialing plan to mobile phones (e.g., four-digit dialing) and can also designate a geographical region (e.g., United States) as a single calling zone. Sprint’s Mobile Integration Service provides unlimited enterprise calling for mobile phones and can route international mobile calls through trunks off the premises-based PBX, saving per-minute international roaming costs. Many of the network operators offer a mobile extension service (e.g., Verizon PBX mobile extension, Sprint mobile extension, and AT&T mobile extension services). These services extend the enterprises’s PBX capabilities in much the same way that PBX vendors extend their premises systems, except that the network operator manages the solution. The service is a natural extension for enterprises that already use one or more of the operator’s other managed services. Mobile UC Issues The challenge with mobile operator services is three-fold. First, the service is under the control of the network operator and many large enterprises will want to fully control a technology as critical as mobile UC. Secondly, recent Burton Group research found that many enterprises view network operators as unresponsive and inflexible. Lastly, many enterprises can save money by operating their own equipment because large enterprises often have the same economies of scale as network operators. Conclusion Mobile unified communications (UC) products and services enable enterprises to extend the benefits of UC to mobile users. Mobile UC capabilities vary widely and are highly dependent on which product, service, and mobile phone the enterprise selects. Enterprises should carefully evaluate mobile UC products and services in order to make informed decisions as to which solutions are most appropriate for them. This blog post was originally written by me and published on searchmobilecomputing.com. It is posted here with permission from TechTaget. Individuals increasingly work from nontraditional office environments and expect to use their mobile phones wherever they work. At the same time that the mobile workforce is growing, enterprises are deploying Internet Protocol (IP) Telephony (IPT) and unified communications (UC) solutions. IPT systems provide new capabilities to virtualize communications across the enterprise, breaking the linkage between a user and a single physical telephone. UC integrates many forms of communication such as email, voice, instant messaging, and presence across various hardware and software platforms and also integrates communication into business applications and processes. Many organizations have begun the process of integrating their various communications applications and services. Isolated Mobile Users Unfortunately, the mobile phone user still largely operates outside of this environment. For most people, the mobile telephone is simply a means to make and receive phone calls, nothing more. Smartphones—such as the iPhone, BlackBerry Storm, or those based on Windows Mobile—may offer additional features such as mobile messaging and calendar synchronization, but they lack the ability to offer mobile users the same access to communications services offered by a desktop phone in their office. In effect, the mobile phone operates outside of the enterprise private branch exchange (PBX) or telephony service. These mobile users must endure numerous inconveniences that include dependence upon two phones (desktop and mobile), two phone numbers, two voice mailboxes, and two contact directories. When a user is away from their desk, a call to the desktop phone can result in a missed call, voice mail, and caller frustration. Similarly, a call to the mobile phone when the user is busy can result in voice mail, but in a different voice mail system, frustrating both caller and user. In addition, mobile users do not have access to corporate phone directories and they must often use full 10-digit dialing when calling another employee who may only be down the hall. Emergence of Mobile UC Products Numerous vendors are introducing products to enable mobile users to access many of the same features and services that previously could only be accessed through a PC or fully-featured desktop IP telephone. The goal is to enable enterprises to extend telephony features to their mobile users, while making mobile users more productive regardless of location. Some products take advantage of the increasing intelligence of the mobile phone, while others insert themselves between the public switched telephone network (PSTN) and users’ various communications services. Current product offerings in the mobile UC space are widely disparate. Some products provide a high level of integration between mobile phones and enterprise communications applications (such as presence management, voicemail, and conferencing systems), while others are simply designed to give users more options in how they receive incoming calls. Three well-defined classes of products have emerged, though specific product capabilities within each class vary by vendor (and by mobile platform within a particular vendor’s solution). The three classes are:
Mobile UC Issues Perhaps the biggest issue is the limitations of the products themselves. Mobile extension features are limited to the routing of phone calls; they do not provide for a phone-based client that can access applications such as a visual menu of voicemail messages, nor do they give users the ability to change their presence information via the phone. Mobile Client and Mobile Wi-Fi solutions generally provide a richer set of features, but capabilities among systems vary greatly and, perhaps more importantly, capabilities will vary based on both handset and service provider. For example, products like RIM’s Mobile Voice System Client only support BlackBerry devices. What these limitations mean is that it is difficult for an enterprise to deliver a service that supports all handsets that employees are likely to have. Rather, the enterprise can only support a limited number of user devices, meaning that at some level, the enterprise will likely have to dictate policies for mobile telephones. This will either limit user choice or require that users with nonstandard mobile phones obtain new devices. Conclusion Mobile unified communication (UC) products offer enterprises the ability to integrate mobile devices with their Internet Protocol Telephony (IPT) and UC systems. These solutions give employees the ability to enjoy many of the same features on their mobile phones that previously were only available on desktop phones and softphones. Products vary greatly among vendors and mobile devices. Over time, mobile UC will become a standard feature of enterprise IPT/UC systems. Enterprises should carefully evaluate mobile UC products in order to make informed decisions as to which solutions to deploy. This blog post was originally written by me and published on searchmobilecomputing.com. It is posted here with permission from TechTaget. I think that we are seeing the emergence of a new product category that expands the market for mobile computing (i.e., netbooks & laptops coexist) rather than a new product category that replaces the laptop. Netbooks are great for mobile computing and communication but their small disk size, limited internal memory, and relatively slow processing speeds make them underpowered for many users. Cost conscious enterprise users, that do not have heavy computing needs, will buy netbooks. We will also see enterprises move to data center computing with virtualized operating systems on netbooks as a way to provide greater control over data leakage. Lastly, mobile power users will own a laptop, netbook, and smartphone. For short trips, the laptop will remain in the office while the netbook/smartphone travels on the road. The netbook will be used for email, web browsing, light word processing and spreadsheet manipulating. The mobile phone will primarily be used voice, IM, email, twitter. The interesting question is whether or not the smart phone becomes powerful enough that it can replace the netbook. This might occur if projected keyboards and projected screens become popular on the smartphone. However, in the next few years, I don’t see this happening. Click here for more information on netbooks. |
|||||
|
Copyright © 2010 ClearChoice Advisors LLC - All Rights Reserved |
|||||
Recent Comments