Mobilizing applications has a number of costs and benefits associated with it, as does any strategic initiative your company undertakes. In this series, we'll discuss a framework for evaluating the costs inherent in mobilizing users and applications, and we'll look at some tools that are currently available to help you build and port applications to your mobile devices.
Evaluating the costs of mobilizing your applications
Building and porting applications to mobile devices
|Evaluating the costs of mobilizing your applications
In our previous series on the subject of mobile applications, we looked at the broad issues relating to strategies, networks and technologies that will affect this important element of IT over the next few years. A number of questions came up, however, calling for a little more detail on two related items: cost and middleware.
The first of these is top-of-mind today for anyone in business, let alone enterprise IT: cost, as in holding it to the absolute minimum without compromising quality. Mobilizing applications has costs and benefits associated with any strategic alternative, and we'll look at those first, discussing options for the cost-effective provisioning of IT services to a highly mobile audience. In the next section, we'll look at middleware technology in a little more detail. Middleware is one of the key alternatives for getting applications onto highly mobile platforms like handsets, and many good directions are today available for going mobile with a minimum of effort (and, for that matter, cost).
Financial concerns are clearly on everyone's mind these days. Ignoring the obvious issues relating to credit and the stock market (don't worry; I believe these will get sorted out this year), let's focus on the key cost elements involved in mobility:
- Strategy and planning: It's important, up front, to define what services and applications are going to be mobilized based on need and return on investment (ROI). In a nutshell, it's important to decide what information needs to be accessed by whom, when, where and under what circumstances (such as how often). Notice we've not yet said a word about computers, networks, devices, software or any other technical details. Assume at this stage that mobility is possible, but focus on the solution and its benefits, not the technology. Cost and ROI models should be built at this point and updated throughout the remainder of the process.
- Software: Next, think about applications. Which ones are required? Are they available from software firms or service providers, or are they homegrown? Will a port (moving the application to a new operating system or device) to a mobile platform be required? We'll cover this key cost area in detail in the next section, but for now, sketch out application and related software requirements. This will help to quantify the mobile devices and infrastructure (server and network) needed and, again, hold down costs for these elements as well. If you're writing or porting software, make sure you add in cost estimates for the design, programming, maintenance and support of any applications required.
- Hardware: OK, now it's time to spec out the whole solution, including servers, enterprise networks, service-provider (carrier) networks, and mobile devices. It's always advisable to hold the number of types of mobile devices to the bare minimum required for quality assurance, support, and security reasons (to say nothing of getting the best deal due to volume). Don't succumb to the temptation (or numerous requests) to support every handset your user base may have -- that's a sure way to drive up costs.
- Operations: Make sure the solution fits with your network operations, help desk, and other support functions. Make sure you have a strategy for mobile device management, especially with respect to configuration, functional verification, security, and procedures for what to do if, for example, a handset is lost or stolen.
- Policy: And, of course, make sure your acceptable-use and mobile security policies are up to date. It's a good idea to review these at least twice a year.
There's one final cost element, and this is the difficult one -- opportunity cost. This is the difference between what you plan to do and the next best option, which, in the case of wireless deployments, is usually doing nothing. And it's often difficult to evaluate in terms of return because the ultimate objective of mobility is productivity through convenience. But also consider the potential savings from lower real-estate (office expense) costs, which can be significant. Who needs an office (or even a cubical) when the road and customer sites are where the employee needs to be?
Finally, keep in mind that additions, upgrades and replacements need to be part of your cost planning. But there's nothing new here; high-tech is defined by progress and advances that always result in new products, services and options, and some of these will undoubtedly improve your cost-effectiveness even further.
|Building and porting applications to mobile devices
In the first section, we presented a framework for evaluating the costs inherent in mobilizing users and applications. In this section, we'll look at the tools available to help you with the really expensive part: building and porting applications to mobile devices. As it turns out, there's often no need for expensive device-specific code rewrites that, in the worst case, ultimately bind the port of an application to a specific handset that will (inevitably) become obsolete.
Many -- and I'm one of them -- believe that the future of IT is in Web services and cloud computing, ultimately virtualizing as much infrastructure and software as possible with unprecedented convenience and terrific cost savings. But this style of computing requires continuous connectivity -- and let's face it, we're not there yet. Despite significant investments by wireless carriers and operators of all types, few would argue that we have sufficient wireless access today for mission-critical broadband communications. So, while some IT services can indeed be provisioned entirely in a browser window, a hybrid local/remote strategy makes more sense for a lot of applications, most notably sales and service. This means that apps will need to be at least partially ported to handsets, with back-end synchronization and other access as required and available.
Today's handsets are by and large quite suitable for running a broad range of applications, and all major platforms provide developer tools. But writing code from scratch is no less expensive on a small device than it is in the data center, so a significant industry of mobile middleware providers has grown over the past 15 years. Mobile middleware in general refers to software tools that can be used to construct an application for (or port an application to) a mobile (and wireless) platform with a minimum of effort. Middleware originally handled such issues as dealing with all of the unique protocols in early wireless services, but, as we've now standardized on IP, contemporary middleware primarily simplifies the process of getting an application running on the many software environments present in the mobile world today. So the whole point of middleware is to hold down development costs, which ordinarily would constitute the bulk of the expense associated with a custom mobile solution.
There is a large number of firms in the middleware space, each having its own take on the subject. Most provide a local execution environment, as well as local and wireless security. Some have pre-packaged solutions for such apps as CRM, sales and service. A key feature to look for is integration with back-end applications and databases, as well as a management console to simplify deployment, management and operations. Some take advantage of write-once/run-anywhere tools like J2ME. It's not always easy to decide on the right product here, but mobile middleware can nevertheless greatly simplify application development and in the process dramatically lower costs. For a few examples of these tools, see Cascada Mobile, Dexterra and Vaultus.
A cautionary note: Rapid technological change will (unfortunately) be with us for quite a while yet. Wireless networks will achieve higher throughput while still being based on IP (and thus will not change much with respect to software interfaces), but local software environments will continue to evolve, necessitating handset migration strategies and the associated expense. It's likely that more features will be added to handsets, but a good middleware package will hide the specifics with no compromise in functionality. So, bottom line, the best way to minimize mobile apps costs for now is to pick the right middleware solution for your operations. In so doing, you'll get apps ported faster, users will be made productive with minimal effort, and you'll get a handle on the inevitable future expenses as they arise.
About the author: Craig J. Mathias is a principal with Farpoint Group, a wireless and mobile advisory firm based in Ashland, Mass. The company works with manufacturers, network operators, enterprises, and the financial community in technology assessment and analysis, strategy development, product specification and design, product marketing, program management, education and training, and the integration of emerging technologies into new and existing business operations, across a broad range of markets and applications. Craig is an internationally recognized expert on wireless communications and mobile computing technologies and has published numerous technical and overview articles on a variety of topics. He is a well-known industry analyst and frequent speaker at industry conferences and trade shows, and he is currently a member of the advisory boards for the Interop (Las Vegas and New York) and Mobile Internet World conferences. Craig is also the program chair for the Mobile Business Expo (MBX) conferences. He serves as a monthly columnist for SearchMobileComputing.com andComputerworld.com and is an ardent blogger ("Nearpoints") for networkworld.com. He holds a Sc.B. degree in applied mathematics/computer science from Brown University.
This was first published in March 2009