Developing a mobile solution
Thinking About Developing a Mobile Solution?
High-performance mobile applications are clearly the wave of the near future; however, there are numerous mobile development and deployment obstacles that defy simple work-arounds. This is why even the most skilled enterprise development teams often perilously underestimate the actual time and expense of developing robust mobile solutions.
Candid answers to four probing questions can help you better understand the true scope of your next mobile initiative. The same questions apply whether you're extending an existing business solution to mobile devices or developing an entirely new mobile solution.
Four Questions to Ask Yourself Before Committing to a Budget or Completion Date
- Will your solution overwhelm the handheld device?
- How many different mobile devices must your solution support?
- What are your security requirements?
- What are your architecture requirements?
1. Will your solution overwhelm the handheld device?
There are several tell-tale signs that the answer here will be "yes":
- The solution involves complicated business logic.
- The solution needs to securely and reliably accommodate intermittent mobile connections.
- The solution needs to leverage device-specific functionality (e.g., voice, image and video capture).
- Even today's most powerful mobile phones and PDAs still present inherent limitations that are very distinct from PCs and laptops. The most obvious are the severely miniaturized "monitor" and "keyboard."
- Somewhat less obvious are the limitations of mobile device web browsers as client end points. Mobile browser behavior and performance vary widely between devices; however, as a class, they tend toward poor presentation layout, can be very slow and are often unreliable. They typically do not maintain state and struggle with maintaining local data, so lost signals during a transaction are very problematic. And, ironically, phone browsers often have difficulty accessing the devices' unique voice, image and video capture features.
- Another less obvious development obstacle is the phones' limited remote capabilities, i.e., their relative inability to programmatically access server-based information and web services. The APIs to consume these services typically do not exist, leaving the developers to build these low-level capabilities themselves. Be sure to budget for that.
- A final set of mobile device limitations are the runtime environments themselves, including CPU power, memory and storage capacity and, importantly, battery life. It is surprising how much of a toll even simple XML processing takes on the battery.
2. How many different mobile devices must your solution support?
Most solutions require support for multiple mobile device technologies, including .NET™, Java and PalmOne®. This has obvious consequences on the composite skills required by your development team. But this issue goes further than that. The unfortunate truth is that there are typically no APIs available and adherence to industry standards is very inconsistent. Be prepared to devote a substantial amount of time dealing with these issues.
3. What are your security requirements?
Because mobile devices are easily lost or stolen, storing sensitive information on the device itself is simply not an option. Neither, in most cases, is direct mobile access to secured back-end systems. Server components are required for either of these solution scenarios.
The mobile development team must therefore budget sufficient time to develop the services for user authentication and administration, secure transaction processing, data caching, store-and-forward, etc.
The thing to keep in mind here, as previously mentioned, is that mobile devices have limited server access capabilities built in, and the manufacturers don't provide API libraries.
This yet another hidden time drain that needs to be factored into your budget and project plan.
4. What are your architecture requirements?
Because no two development projects are alike, this question breaks down into several sub-questions, including:
- Is this a one-off project?
If the answer is no, then architectural standardization and component reuse become essential for subsequent development projects. You will surely want the same tools, libraries, methods, and deployment platform are used for all of them.
- Will the solution be deployed as a subscription-based service?
If yes, then you will need to develop robust account provisioning, metering and billing facilities.
- Must the solution orchestrate or federate data and functionality from multiple back-end systems?
If yes, then you already know you're in for some challenging integration work. Traditional EAI products are very helpful, but be aware that they are general-purpose products that are not tailored for mobile or for subscription-based environments.
- Will the solution need to invoke other applications as services?
If yes, then you will once again run into the remote limitations mentioned above.
- Are routing and load balancing are required for scalability?
If yes, then be sure to budget sufficient resources for these overhead functions. Of course there never seems to be enough time and money for any development project. But the mobile environment presents many new issues that cannot be ignored. If your time-to-market and/or budget pressures do not give your development team the bandwidth to develop all the middleware facets of your mobile solution, you will need to investigate your "build versus buy" options very carefully.
|
