I was asked again recently about the options for extending enterprise applications out into the field using mobile technology. It seems that more and more people are looking beyond mobile email to how they can use wireless access in relation to applications such as ERP, CRM, and so on.

One of the most commonly considered applications we see being mobilised is field service management, and the lessons learned in this area are relevant to many other applications. If you are interested in a proper treatment of the topic, I suggest you download this community research report.

For those who are interested in a more 101-level ‘which end is up’ introduction, here are a few notes I jotted down for the person who was enquiring about the topic yesterday.

The main options for wireless-extending existing applications are:

Bolt-on packages: Some application vendors provide these themselves and most have third-party options available as well. We can think of this type of solution as essentially a module that just extends the application, typically reusing a lot of the metadata, master data and transaction layer. This is good if your aim is mobilising a single packaged application such as SAP, Oracle, PeopleSoft or whatever. The downside is that it can be a pain if you want data/functionality from multiple back-end systems to be surfaced together on the device.

Value-added services: Commonly referred to as the ‘VAS’ option in mobility circles. The basic idea is essentially the same as the bolt-on approach defined above, except that the solution is hosted (typically, but not necessarily, by the operator). As operators are mostly into repeatable solutions given their business model and mindset, the VAS approach is typically even more prescriptive than the bolt-on one, and is therefore generally targeted at simpler requirements. However, many applications extension requirements are actually quite simple so there is a place for this approach.

Open middleware platforms: This is where you procure a middleware platform that may be used to bridge the gap between back-end applications and mobile devices, with all of the clever stuff required to make this work properly. These platform solutions generally come with a development environment or allow you to use open tools such as Eclipse to design and build solutions. In reality, many of the solutions in this space are delivered with pre-defined templates or libraries for working with the most common back-end applications, but these are just a starting point for your own development efforts rather than a fully supported turnkey solution. The advantage of this approach is clearly that you have freedom to extend pretty much any application or mix of applications – including bespoke/custom/legacy applications, as well as packages.

The big imperative when getting into all this is understanding your requirement – particularly bearing in mind the medium term at least - think a little way beyond the immediate job at hand. I am personally not an advocate of big over-arching mobile strategies that cut across all types of application as the space is so fast moving and your requirements and what technology will be capable of looking forward are both difficult to predict. The concept of five-year mobility strategies is just nonsense as there are just too many variables that you cannot possibly tie down. There is also a strong argument that mobile access should be an element incorporated into other strategies for mobile working, process automation, collaboration, communication, and so on, rather than a strategy in its own right.

Something that’s critical, though, is getting a sensible policy framework in place, which will address things like security/compliance, integration standards, device selection/endorsement, operational management, and support. When doing this, it is important to think about what needs to integrated with the stuff that is already there and what you can legitimately ‘reinvent’ for mobile specifically without creating lots of disjoints and conflicts. You may have invested a lot of time on a security infrastructure, for example, and be reluctant to put a parallel policy management in place for the mobile domain.

The bottom line is that before you make a move in this space, it is worth taking time out to educate yourself, understand the options, understand your own requirements, then make choices on an objective and informed basis that will work for the immediately funded project and likely additional medium-term requirements.

As I said, this really is just a brief orientation, and my categorisations of solutions are just to give a flavour of what’s out there. Experts will tell you that not all VAS solutions are prescriptive and that bolt-on offerings often have development environments too that allow customisation and access to other applications, but people at least seem to appreciate having some basic classification framework in place as a starting point for gathering their thoughts.

As I said, a lot of this explored further based on actual feedback from practitioners in the Field Service Management report (and thanks to Momote for funding the underlying community research study upon which this is based).

By Dale Vile