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

A couple of us spent some time recently at BEA World in Barcelona.

There was an issue raised in the keynote speech and echoed in later sessions that I wanted to pick up specifically, as it is another example of a vendor spinning an issue to suit its messaging in a way that can easily mislead if taken at face value.

The spin

BEA has been repositioning itself in recent times from a deliverer of "big iron" infrastructure for building and running business-critical Java applications, to the custodian of infrastructure-enabled business agility and flexibility. Moves into portal technology, social computing and business process management through a combination of acquisitions and in house R&D have all been part of this, and the introduction of the word “liquid” into a lot of its branding has reinforced the positioning.

At this level, BEA is right on the money. Our research has indicated repeatedly that businesses often feel constrained by IT’s inability to respond quickly enough to changing demands – so no arguments there. However, BEA is taking this one step further and questioning the value of packaged applications to support this "new world" of adaptable, service-oriented and people/process-centric IT. The words are carefully crafted with phrases such as “the days of being able to innovate through packaged applications are over”, but there is a clear objective to sideline the relevance of packaged applications as we look to the future.

It’s another example of the line we hear from other vendors and, indeed, some analysts, which argues that service-oriented architecture (SOA) and increasing expectations around the need for IT flexibility spells the death of the application software package. Great though this is for generating headlines or (in the case of BEA) promoting the build side of the traditional build-versus-buy argument, there are a few other things we should probably consider before throwing out our ERP systems and other packages.

The reality

Let’s start with some very obvious stuff. If you examine the way any business works, you will find that the majority of its business processes are non-differentiating. What we mean by this is that while you need to be efficient and effective in these areas to manage costs and risks, you are unlikely to compete any more effectively in the market by inventing new ways of doing them.

Examples include the vast majority of the accounting and administration that takes place in the average business, and for most to whom they are relevant, things like inventory management, manufacturing planning and execution, human resource management, logistics, and so on are non-differentiating too.

Sure, there are exceptions such Dell that gains significant competitive advantage from the way it manages its supply chain, manufacturing and logistics activities, but if we look across industries as a whole, most business processes we see are of the non-differentiating kind, for which it makes sense to simply adopt industry best practice rather than reinventing the wheel for the sake of it.

So let’s be blunt – if you are not using packaged software for non-differentiating business processes then you are mad. Even if you could build a better general ledger or accounts receivable system than SAP or Oracle, you would not actually have gained anything through doing so in business terms. Of course, the chances are that whatever you came up with would not actually be as good as a package solution that has been tuned over the years in line with industry best practice and the requirements of thousands of customers, so the reality is that you would probably be worse off.

Having said this, BEA and others make the argument that traditional packaged applications are relatively closed and monolithic in nature, which is a problem when integrating them into the overall landscape, and when you need to change the processes they support. Even non-differentiating processes need to be modified from time to time for efficiency purposes or to accommodate changes in business structure, merger and acquisition activity, new regulatory requirements, and so on. The argument continues that all of those investments made in the 1990s to put ERP and other packages into place has inadvertently locked business processes in a way that is constraining by modern standards.

Let's put aside the configurability of most packages for a minute, and accept this argument for the purposes of discussion. The question then becomes, if you have an old monolithic package that is holding you back, what should you do about it?

It is at this point that the SOA extremists pipe up with the purist line about packages becoming irrelevant in the future as organisations compose their solutions to meet the exact needs of the business by selecting and plugging together the optimum mix of best of breed software components and services.

The problem is, that’s a bit like saying that because the majority of components that make up a PC are now standard and can be plugged together easily, there is no longer a need for pre-built machines. It is basically nonsense. Whether you are a business looking to buy or rent software functionality, a consumer looking for a PC, or someone in the market for a new car, you are likely to want a product that has been assembled, integration tested, and delivered as a working unit, with assurances that it can be maintained and supported as such.

The move to assembly from standards-based components and the surfacing of standards-based interfaces has benefits in all contexts, however, and in acknowledgement of this, pretty much all mainstream application package vendors are moving in the direction of SOA. Will they get there overnight? Certainly not, but both SAP and Oracle, for example, are investing huge sums on re-architecting their solutions, which is something the purists often fail to acknowledge or dismiss as just marketing.

The work is real, though, and the aim is to allow standards based ‘services’ to be exposed for easier integration and for selective substitution where it makes sense. Just like you buy an off-the-shelf PC and perhaps upgrade the graphics card, SOA will allow you take an ERP package, for example, and ‘upgrade’, say, one of the advanced planning components with a third-party alternative.

So, what we need are flexible packages rather than an abandonment of the package concept altogether.

Conclusion

The story we heard from BEA this week is a very strong one, though all of the pieces are not in place yet. When listening to the pitch around the need for more IT infrastructure flexibility that can support the ever increasing rapidity of business change, however, it is important to remember that there is still a lot of relatively routine and boring stuff that will remain best dealt with through prescriptive packaged solutions that encapsulate industry best practice.

Furthermore, off-the-shelf packages or services (if software as a service catches on) are increasingly going to be based on flexible architectures anyway, and the trend away from customisation to ‘soft configuration’ so packages may be tailored to specific needs without code-cutting is already well underway. The ERP and CRM packages of 2007, for example, are inherently more malleable than those of mid-1990s.

In this respect, I would probably on balance disagree with BEA that "software package-enabled business innovation" is dead, though I would agree that IT departments should probably be shifting their attention to using the latest infrastructure, tools, techniques and ideas of the kind BEA is promoting to support the differentiating elements of the business in as flexible and high impact a way as possible. And in some situations, it may not be sensible to even model processes at all, let alone lock them down in software.

The world and technology landscape is definitely changing, but let’s not assume that embracing new ideas always means abandoning the old – or that the traditional stuff is standing still.