Skip to content

Top 10 tips for developing Enterprise Mobile Apps

NormanChiflen edited this page Feb 14, 2012 · 1 revision
  1. Make sure you really need it. First of all, make sure the app doesn’t already exist! After that, check to see if an app is the right way to do it. For the vast majority of use cases, it’s easier, cheaper and faster to develop an HTML 5 version of the current online website specifically for mobile. You only need a native app if you require access to device specific controls or inputs; for example GPS location data, accelerometer data, multi-touch screen, camera, working offline, etc. If you’re just pushing reports to your sales force in the field, you can do that with a HTML 5 site. But if you want to show a map of your sales rep’s customer accounts within a few miles of her current location filtered for those that are large but haven’t had a recent touch and make the experience interactive…you’re going to want to do that in a native app.

  2. Decide which devices and OSs you will support. Looking at the market place for tablets, iOS (iPad) is forecast to remain the dominant player through 2015, but still there are many firms looking to support Android, Windows and RIM. Our view is that if you’re looking primarily at enterprise mobile as a platform for workforce efficiency and enablement then iOS/iPad should be your top priority. However, if you’re looking to support customers, vendors and other partners as well (e.g. mobile banking) then you need to look at Android smart phones, Windows, etc. If you have a plan up front and design to support it, your long term development and maintenance costs will be lower than if you adjust on the fly.

  3. Invest in user experience. Because of the ubiquity of the iPhones and iPads in particular, every employee who will be using your app has expectations for what amounts to a good user experience and ultimately a good app. They’re already familiar with apps like Pandora, Twitterific, Angry Birds and Zillow. Make sure you build the app to included “expected” features like nice splash page graphic on launch, landscape/portrait orientation for iPads, pinch and swipe for zoom and pan and you should use “standard” look and feel unless you have a good reason. It’s pretty hard to win praise for truly novel features, but it’s very easy to generate some groans if you fail to meet UX expectations. In our experience UX is frequently the area most overlooked by clients for want of a few thousand dollars to engage an experienced UX designer.

  4. Understand costs to build. Whether you develop your app internally or outsource it to one or more vendors, the tasks required to build your app are always the same: product development, design, coding, integration, testing and project management. Let’s look at each one of these in turn:

    Product Development. This task involves defining what the app will do at a very detailed level, the overall architecture, what systems within your organization will be connected, etc. It’s important to think about things like who are the user types, how to credential users, what features of the device(s) you want to utilize and most importantly what is the business problem(s) you’re attempting to solve. The output of this task is an app architecture, app features list, wire frames and other requirements. For example, if you’re deploying an app for your sales team and your business goal is to increase sales to current customers, then you will want the app to help your sales people find and close opportunities with current accounts. This step is probably the most important one in developing a successful app. It’s also one of the trickiest steps to staff because often an enterprise won’t have the mobile experience internally but many technology vendors don’t have the business experience. In fact, this is an area where extensionEngine excels because we do have deep experience in mobile AND we have very strong business strategy expertise. Depending upon the complexity of the app/platform, if outsourced, this task usually bills at $150+ per hour and can cost anywhere from a few thousand dollars to low tens of thousands.

    Design. Design is the task of taking the requirements from the product development task and turning them into the look and feel plus user experience of the actual application. Almost every enterprise will want to outsource this and the rates for design vary from as low as $75 per hour up to $150. At the lower end you can expect a “converted web designer” and the higher end will be someone with expertise in mobile user experience and exploiting all of the mobile specific features (multi-touch, genstures, GPS, camera(s), accelerometers, off-line synchronization, etc. Typically you’ll do two or three iterations on various aspects of the UX/design and depending upon the complexity of the app you can expect costs to range from $5-10K up to mid-five-figures for very complex apps with many pages, animation, etc.

    Coding. The actual coding of the application on the devices is pretty straight forward and typically takes 1-2 experienced programmers anywhere from a few weeks to a few months, again depending upon complexity. In addition, you’ll need to build connectivity between the apps and legacy systems within your enterprise. This can often end up being the biggest expense. Another common question about coding is how to handle multiple devices/OSs and whether to use platforms such as Pyxis Mobile, Worklight, Shumbi or one of the many other similar development environments or to use the OS specific SDK. Our experience to date is that for most enterprise applications, the multi-platform development environments are still too immature and require lots of extra testing. Programmers often describe them as “write once, test many” platforms. Our long term view, however, is that these multi-platform environments will mature and there will eventually be one or two winners that will make sense to adopt. Until then, it’s faster and cheaper to use the native platforms. If you outsource coding, you can expect to spend anywhere from low tens-of thousands to low six figures where most of that variability depends upon legacy system integration.

    Integration. As mentioned above, integration with legacy systems can be a big task. The ideal approach for integrating with enterprise systems is to use a 3-tier architecture with a custom API in the middle that will abstract the presentation layer (e.g. your new app) from the data layer. Done well, this API will allow you to add new mobile apps on new devices / OSs as they become available and to even use this same API for your web and mobile web clients. That way your user base will be seeing the same data / experience where ever they access it.

    Testing. Just because you won’t be rolling your app out to hundreds of thousands or even millions of users on the iTunes App Store, you still need to do lots of testing. You also need to remember to test your app on the various version of the OSs for the devices you support. Testing can take as little as a few weeks to a month or more.

  5. Don’t forget about supporting infrastructure. Often to deliver the solution to your original business problem, you need to build some supporting infrastructure. For example, one of our clients wanted to develop an app for their sales force. But before they could do that, we helped them build a data warehouse to consolidate data from a couple of dozen different systems which were then put into a data cube and finally pushed to the new iPad application. As you can imagine, the enabling infrastructure investment in this case far outweighed that for the actual mobile app.

  6. Have a plan for distribution. You could, but you probably don’t want to distribute your app through the App Store. Instead, you’ll want to sign up for Apple’s Enterprise Program which allows you to distribute your proprietary apps to employees and other members of your organization. But if you’re going to be deploying the app to more than 100 or so users, then you should consider some of the more robust tools like those from Apperian or AppCentral. These proprietary platforms will afford you more control and feedback on the distribution of your apps.

  7. Plan for long term support and maintenance. iOS, Android and the other OSs have updates on a frequent basis; typically every few months. There are major releases once or more annually and your enterprise app needs to be updated and tested on these new versions. What’s more, your enterprise systems will go through changes as well so the connectivity with the mobile apps needs to be monitored and supported. Since this isn’t typically a full time job and many enterprise IT departments don’t have iOS and Android expertise internally, they look to an outside firm for long term support an maintenance. At extensionEngine, this is a core part of our offering. Having been around for more than 11 years (and with clients spanning nearly that entire length), we know it’s important to support our clients in the long run. Depending upon the type and amount of support required, it can cost as little as a few hundred dollars per month to as much as low thousands per month.

Sample Keynotopia Template

  1. Build a mockup. When you’re selling the idea of enterprise mobile within your organization, having some visuals to show your colleagues and the decision makers is very helpful. One of the easiest ways to build a demo is to use Keynote on a Mac and the Keynotopia templates to build a mockup. What’s really cool about this is that you can quickly create 5 or 10 key pages of your app using simple cut/paste and then you can hotlink areas of each page to other pages. In presentation mode this makes the app look like it’s moving from page to page so the users can see what it looks like and get an idea of the user experience. And even better, you can get Keynote for the iPad ($9.99) and show the demo on an actual device. Lastly, if you use the video dongle to mirror your presentation, you’ll be able to convey your vision easily and clearly.

  2. Iterate. For your first launch, you should be focused on the minimum viable product (“MVP”). The MVP should be simple and provide enough value to justify the project. Once you have the basic infrastructure in place to support your mobile applications, you can rapidly iterate to fix bugs and add features. If you have things set up properly it’s easy to push out updates. What’s more, every app should have a feature to report bugs and provide suggestions. You’ll find this a brilliant source of future features. More than ever before, your user base is expecting frequent updates and enhancements so you should build into your plan support for this.

  3. Have no fear. Unlike many IT projects which often have little upside and lots of downside, enterprise mobile apps afford one of the best ROIs for IT projects you’ll come across. For low six figures you will be able to design, build, deliver and support a platform that will garner praise and deliver tangible business benefits. Your user base will be delighted to see you and will have positive things to say. After delivery of an enterprise mobile project for one of our clients, the head of sales sent a note to the CEO with a copy to the head of IT that this project, “was the best thing he had seen come out of IT in the past 10 years.”