The next time you’re about to binge a season of your favorite Netflix show, consider the complex interactions taking place behind the scenes to make this possible. From negotiating with production companies and internet providers to orchestrating network traffic and predictive analytics algorithms, what Netflix has achieved is rather astounding. In just a few seconds, your show is streaming seamlessly. And this experience isn’t unique. Every day, 100 million Netflix subscribers have the same (nearly) faultless experience as they stream an average of 140 million hours of content.
As early as the ’90s, businesses and analysts alike have foretold the death of the ERP system. Over 20 years later, however, ERP is still alive and well. Globalization, digitalization, the internet and a whole host of other technologies have made it virtually impossible for businesses to move away from ERP. There’s simply too much critical data housed in the underlying databases for elimination to ever be a viable option.
Users and developers agree on one thing in relation to enterprise resource planning (ERP) software: it’s boring.
For users, ERP means a lot of data entry added to their daily workload. While ERP is becoming more sophisticated with support for mobile devices and cloud functionality now commonplace, most users would prefer to use systems that are quicker and more responsive.
Developers can see this is a pain point and are trying to innovate past it, but that’s not always possible with the kind of monolithic architecture that can be found in contemporary ERP installations. ERP is a challenge to developers because ERP systems communicate with so many other systems on the network and each ERP installation is so massively configurable. Each individual instance of an ERP can feel like a unique piece of software in itself.
Legacy software vendors that traditionally provide on-premise solutions still face a couple of architectural challenges. Those allow them to provide cloud-native applications as well as a solid foundation for offering a natural bedrock on which to construct bots, ultimately allowing them to offer a conversational user experience.
Many vendors of legacy software struggle to accomplish a smooth transition from a monolithic architecture to a cloud-enabled service oriented architecture, as such a transition involves rewriting, which comes at a significant price. However, the previous economic benefit of re-architecting to ensure a more efficient use of compute and storage resources is gone due to increasingly cheaper IaaS and PaaS services.
The other day on my daily commute I was, as usual, reading the latest news on technology and other, to me, interesting areas, I ended up spending most of my commute reflecting on the subject of mobile apps supporting disconnected state instead of reading. Honestly, I was rather annoyed with the situation, as I really enjoy being able to read my news and emails while riding the train.
So what was difference this particularly morning, since I usually read news and emails while on the train? Well, the difference was that normally I’m on an InterCity train that offers free WIFI, however, on this day I got on an earlier train – the sprinter – which doesn’t have free WIFI. Meaning, that I had to rely on “standard” mobile connectivity, which can be sketchy, even in a country like the Netherlands that got exceptional good network coverage.
Being without reliable connectivity I started testing a number of different news reader apps like Zite, FlipBoard, Dr. Dobbs and others – and found that they all requires connectivity to function. None of the newsreaders I tried, offered any solution for reading news without having connectivity. Which is some part peculiar, and I would argue a major flaw. Most of the apps build personalized news based on users preferences, it’s not as they’re searching the net for news. They could easily, on launch, download the news the user are interested in and store it on the device, and whenever there’s connection sync with the server.
If you think about this, then most of these apps and any other app that relies on connectivity is simply a revamped web app, and they doesn’t really offer any noticeable better user experience than a mobile web app would do. So why even bother building these apps as native apps? Apart from be able to distribute them as native apps by means of the app stores. But honestly, these apps don’t provide any additional advantages over traditional web apps.
When building native apps for devices like the iPad it’s crucial that there are additional benefits for the user over building mobile web apps. And one of these additional benefits is the ability to design and create apps that are capable of running without connectivity – disconnected. Remember that the mobile devices got – nearly – all the capabilities of a modern laptop. Storage, file system and database, so there’s a lot of power of API available to facilitate a great user experience, even when the device is disconnected.
When building mobile apps, you should rethink the functionality in terms of being disconnected. Look at the use case you’re trying to solve, and then rethink the use case in the light of being disconnected. Ask yourself, what your users wants to be do if there’s no connection. In the example of reading news, then I would assume that my users would like to be capable of reading news regardless of whether or not there’s connectivity. Compare it with reading a newspaper, and provide similar functionality – since that’s what the newsreader is trying to substitute – the good old newspaper. For the current mainstream apps in the newsreader space, they clearly haven’t succeeded in providing that richer user experience.
And to everyone out there, arguing that there’s such thing as perpetual connectivity, I suggest you go on a road trip, using different means of transportation as that’ll make you understand that perpetual connectivity doesn’t exists.