The mobility market has been moving and shaking for years now with the focus changing as the market evolves. The most recent trend is a push for tools that allow you to write one application and deploy it across multiple device form factors. You often hear this mantra in the mobility industry but it means different things to different people and each vendor has a different twist on how they deliver this magical capability. Don’t confuse hype with reality though, many vendors claim to do it but it’s not completely accurate. We’re not going to talk about the how part of the equation in this post, we’ll talk about the why or why not factor that you need to consider before you actually design an application.
On the surface, the approach seems solid. You want to expend the least amount of effort to cover the largest audience with the core functionality. Simple plan. But how do you accomplish this and what sacrifices will you end up making? Are any of these sacrifices in your best interest? Do you really need one uber-app that works for everybody on everything? Do you have segregated audiences and a need for feature and functionality segregation? How do you maintain an all-encompassing application going forward and who sets the priorities for the application roadmap? I’m sure this list would be much longer if I really thought about it but, it’s a good start.
We have many customers who were drawn to us because of this capability. They read all the articles in the various trade rags and did their research on line and came to the conclusion that if everybody says this “write once, deploy to many” approach is a good thing then I must need it too. They come to us and ask us for a presentation about our offerings and we give them one. Our platform supports this very well and has some cool tools and features that make for a great user experience. But I’m a practical guy, not a widget geek. I usually want to know a little bit more before I jump in with the rest of the gang and if this is even a good idea for a specific customer.
Here’s what I mean. Imagine you have a very large Field Service staff. You need to automate that staff to continue to evolve your business and stay ahead of the curve. You decide you need a mobile application to automate much of your field processes. You then say, ‘…and I’d like to be able to write once and deploy to many devices….’ At this point, much to the chagrin of my sales team, I usually ask why. You should know by now, if you’ve read any of my previous blog posts, that I’m big into business process and insuring we are making wise decisions. So asking a customer why they want to deploy across a wide range of devices leads to a logical discussion about what they are trying to accomplish.
To support a Field Service staff and their associated work processes you typically end up with a fairly complex, detailed and business rule driven application. After all, replacing paper or phone calls where the techs can pretty much write a novel or dictate an epic over the phone, will require your application to have some structure for it to be effective. Structure drives consistency and repeatability and that’s a desirable characteristic for your ultimate solution. Now here’s where things get tricky. If you want a solid, consistent and repeatable process in the field that is governed by business rules and maps directly to your business why would you want to introduce device variability into the mix? Doesn’t that create the possibility for problems? Devices perform differently and have varying capabilities and now you need to design for all of them? Is that in your best interest?
Here’s some things to consider before jumping on the ‘write once, deploy to many’ bandwagon:
- Who will be using this application? Internal users? External Users? A specific work group? Etc.
- What is the goal of the mobility project? To fix a specific business challenge? Conquer world peace and world hunger simultaneously? Boil the ocean? Etc.
- How complex is the application? How much business governance do you require and how effective will that be if you have a wide variety of device choices?
- Do you have the capacity and infrastructure to provide support for multiple form factors within your organization? If not, how do you plan to get there? Different devices require familiarity with not only your application and business processes but device nuances as well. Are you ready, willing and able to staff up for all of these variables?
- Could you take advantage of some key capabilities if you targeted a specific device rather than the whole crowd? Using the device camera as a barcode scanner is a great example. Different devices may not support this as the camera resolution varies from form factor to form factor and would also require specific API support for each device. Do you want to build all of that logic into one massive application?
There is a time and place for ‘write once, deploy to many’ and I don’t want to diminish the need but there’s also something to be said for a well thought out plan. Maybe you want to solve one problem first and then look at more broad-based apps later. I don’t know what your specific needs are but before you drink the cool-aid you probably want to look a bit deeper and ask some key questions of your team and your vendor. Subject matter expertise is often more valuable than feature sets when it comes to mobility. Take full advantage of your vendors experience and make sure they are looking at your challenges and not just pushing their wares.
Tags: Brian Philbin, Enterprise Mobility, Field Automation, Field Service, Mobile Futures Today, Mobility - General
