In today's workforce, virtually everyone has a personal and often company-supplied, internet-connected mobile device.
Smartphones are ubiquitous, tablets abound, and mobile computing platforms such as laptops or 2-in-1 devices are often used. These devices now have quite a bit of computing power, abundant storage, and connectivity to the internet.
However, enterprise mobile applications that serve as native applications or inside a browser often still treat end-users to experiences reminiscent of the early 2000s.
These applications may rely on VPN connections, don't function when no connection to the internet is present, or are slow because they heavily rely on data that isn't present on the device.
Last but not least, enterprises may miss out on opportunities to utilize data stored on devices and inside the organization to provide maximum value to staff using such applications.
So, we need to ask this: If today’s workforce is ultra-mobile and connected, why do enterprise mobile apps still disappoint?
For the purpose of this article, recommendations will be based on a basic, standard architecture pictured below for use with a mobile application that promotes the best user experience and allows enterprises to leverage data.
Mobile app developers have learned important lessons over the years since the first iPhone was released.
Many of the first iPhone applications would not function at all unless the phone connected to the internet. This tended to irritate end users because when the connection to the internet was interrupted (or dropped altogether), the application would hang, leaving the end-user wondering why they could not make a new move in whatever game they were playing. Developers learned quickly when they saw the impact on adoption and continued use of their apps – it is important for maximum adoption and end-user satisfaction to develop the app so that it c continue operating even when no internet connection is present.
Enterprise mobile applications can benefit from this as well. Web applications have long been utilized inside organizations on corporate networks, where connectivity to servers is consistent and taken for granted.
This means obtaining data about customers inside a web application is as easy as making a call to the CRM's Application Programming Interface – make the call, extract the customer record, and serve that information inside a web browser.
Unfortunately, apps developed for the enterprise do not operate under those connections. End users are not located inside the network with a stable connection; they are mobile and go inside parking garages, old buildings with spotty signals, and high-volume network usage areas like sporting events (or downtown DC or Chicago.) Users of these apps often look up information critical to their job function and thus can afford no delays due to these conditions. That means that real-time calls back to back-office systems over the internet are impractical.
In this scenario, one option is to develop the app in a mode that expects the end-user to have no connectivity when using the application. In this scenario, the app has a local copy of the data on the device that is updated with app-specific information (instead of giant copies of databases) that the app retrieves when connectivity is restored by authenticating to and calling a RESTFul web service accessible over the public internet. Update frequency from source data and to source data over this web service should be determined by business conditions – how often data is likely to change and by whom.
Implementing an offline mode in enterprise mobile applications not only benefits the end-user by providing vital information on demand, but it also follows the Service Oriented Architecture paradigm, emphasizing the importance of separating concerns and abstracting implementation details to reduce maintenance burdens. The use of RESTful web services as contracts ensures all interactions between the app and database happen seamlessly, promoting flexibility and easy replacement of different components of the overall system.
In the above diagram, the app does not need to care about what happens behind the RESTful web service. The database behind that web service could be replaced with a call to an ERP or some system other than an operational database. The app only cares about the contract it has with the service.
On the flip side, the database doesn't need to care about the end-user experience. Technology and business conditions change – perhaps it no longer makes sense to serve the end-user experience up through an iOS app – maybe there is a new hot Z-OS operating system on a new device that is being leveraged. That new app can be created and leverage the same contract the iOS app used. During this change, the database never knew or cared about any changes to the user experience.
On the left-hand side of the above diagram, additional databases can be seen. From the app perspective, it is sending and receiving data to the RESTful web service, and that web service is sending and retrieving data from a database. It is extremely common inside today's enterprise for data to live in multiple systems, and it is also common for end-users to need data from multiple systems. In this case, it makes sense to create an operational data store that the web service can exchange data with that is integrated with systems of record.
Perhaps users of the app need customer data and data from the ERP for client visits. In this case, data critical to this job function is retrieved from and sent back to these systems of record through integration channels from the operational database. This promotes ease of reporting (can be done from the operational database) and done right, allows the enterprise to realize the benefits of SOA mentioned above through the integrations between critical systems. The benefits alone of having one system to create actionable intelligence/reports cannot be understated.
However, integrating these systems is tricky. It's tricky because each system has its unique API or other methods of accessing and updating data. Sometimes it's a web-service, sometimes it's importing/exporting flat files, and sometimes it's an ODBC database call. Even among these common scenarios, there are varying degrees of difficulty, which depends on the vendor of said system's willingness to invest in their client's ability to programmatically exchange data from the system. This means that choosing a flexible integration framework that reliably covers a wide range of scenarios is important.
Creating an application that will drive user adoption, enhance their job experience, and provide actionable data back to the organization is worth the investment to get it right the first time. With the right design, clients will be better served, employees will be less frustrated with the provided technology, and decision-makers inside the enterprise can easily get the intelligence they need.
Ready to have a conversation about your application development strategy? Start with Ntiva..