From Appliance to App to API

When I was first employed in the world of “mobile computing” in October 2000, sales were focused on the features of the hardware. The hardware was often referred to as an "appliance." This was likely due to the standards being positively outdated, even back then, e.g., typical device 486 processor DOS OS, not to mention the monochrome screen and outrageous price tag. 

It did, however, have one thing new to most of us; a touch screen. This allowed true portability and meant you could take a signature right there on the device. It also saw the dawn of UI changes to support a touch screen and the way we capture data in the field

The distractions of the future

The next phase of hardware was really the first step to where we are today. When Microsoft released Windows CE and Pocket PC, they had an interesting perspective on what a mobile computer would look like.  Devices such as the Compaq Ipaq appeared sporting the new OS that tried to emulate a miniature laptop. We had miniature versions of Outlook, Excel, and Word, but the thing that put the fear into employers was Solitaire. 

Many employers believed that if they issued devices with access to such a distraction, their staff would sit in cafes playing games all day. This prompted mobile software providers to lock the OS down and restrict them to their software only. This meant no access to the much sought-after mobile email (not that it really mattered as we were still using analogue phone systems that didn’t support mobile data anyway).

More emphasis was placed on mobile software, despite the term “hardware agnostic” being thrown around. The systems were far from agnostic as they were primarily pushed to an MS platform. If you wanted to use something like a Palm Pilot, you were limited in choice. 

Hardware always drove the software sales it resided on 

When Blackberry started being a status symbol in the early 2000s, we all craved the “always connected” mobile email that it showed us was possible. No more plugging laptops into dial-up modems and blocking off the house phone, no more missing the order deadline when commuting.

The next seismic shift really happened when Apple released the iPhone and more so when the App store was born. This changed everything as it meant fledgling developers, who didn’t have huge overheads the traditional players had, suddenly had access to huge audiences.

During this time, the focus shifted to selling software solutions. There was still a big divide between enterprise and consumer-grade “apps,” but the battlefield had changed. Where many providers were quick to dismiss the iPhone as a toy not fit for a workforce, they did have to concede that customers would have expectations on clients picking their own devices. Even long before the notion of a BYOD world. 

The telco providers generally had such a stronghold on enterprise clients that they would push their own agenda based on carriage, meaning the hardware sale was off the table for the mobile solutions provider. What this meant was sales guys had to get inventive. We started seeing subscription-based models as opposed to the older style of perpetual licenses, perception, and proliferation that have consistently pushed that subscription fee down.

The proliferation of apps has also created its own issues

As apps appeared for pretty much everything, it was an easier decision to adopt them or even build them at will. I met with a client in London last year who, at the time, had 12 field applications and was building a 13th to consolidate. From a support, management, and training perspective, this is just a nightmare. Of course, consolidation is excellent, but what happens when a significant new function outside the scope of the consolidated app comes along? We start the process of app proliferation again. 

So this is really where we come to now. Solutions providers who want to service their clients should look to work with them to ditch the ego-driven app mentality and focus more on the service they aim to provide. Integrating with a legacy system via API is of much more value to a client than presenting them with another system to manage. After all, we buy results, not systems; the systems are merely a tool to provide those results.