Difference between Online and Offline Applications
Before we look in to the approaches and architectures for offline mobile applications, let’s take a quick look in to the aspects that make an offline application different. In Online applications the GUI requests the server for data based on user input. Based on this, the server side business logic determines the relevant data set and sends it back to the GUI.
Fig 1. Similarly in an Offline application, the GUI fires the query, however not against a server, but within the same device e.g. Laptop or PDA and expects the same or nearly same result set as it would from the server. This results in the following requirement for offline applications 1. A local data store that has all the relevant data for the user. 2. Business logic on the device equivalent to that on the server so that the user experience with the application does not change These two critical requirements determine the overall architecture required for offline mobile applications.
Requirement 1: A local data store that has all the relevant data for the user
As one could imagine, even with the most powerful and fastest Laptops available today, it’s not realistic to have an entire Enterprise system database like CRM database on a Laptop, let alone on a PDA. This necessitates that the data from the enterprise system must be distributed to every device based on different criteria like user profile, business process, role etc. in such a manner that there is no more data than that is required, no less either. In order to server this requirement, there is a need for a middleware or a data orchestration engine, that can determine the exact dataset for every device based on rules and criteria that can be modeled or defined in the data orchestration engine. As you might expect several thousand devices to be requesting for data from such an engine, the data orchestration engine needs to have efficient and scalable staging area and data distribution algorithms. One could argue that the data required for the device can be cached as and when the user access the server or have predictive algorithms to determine the data on the device. These approaches should not be ignored but must be evaluated carefully based on the business requirement. Some of the pitfalls with such approaches are the completeness of data, ability to change with business process changes. If you users have not accessed the information before, they may not have the possibility to react at short notices, for e.g. if a Sales Rep Dan calls his colleague Rick and requests him to service his customer, Rick may not be able to do so without first accessing the customer information “online” though they may be in the same territory. Similar would be the situation when there is a change in business process, for e.g. if there is a territory realignment, until users access their “new” customer base explicitly to update their cache, they will not be able to service them. However these and many such pitfall can be adequately addressed having a high scalable data orchestration engine with easy to model data distribution rules
Requirement 2: Business logic on the device equivalent to that on the server so that the user experience with the application does not change ...and that the business does not suffer due to errors.
If you are a strong proponent of data caching approach mentioned above, then you would definitely question the need for having offline business logic. Consider the scenario where the Sales rep needs to take an order and issue an invoice to the customer. He would definitely need to have all the pricing conditions and the discount logic that’s appropriate before issuing the invoice. Or consider service scenarios like in defense or mining where end-users are offline for long periods, they need to be informed correctly on the maintenance schedules of the equipment they are servicing. Also remember there are scenarios that don’t need any business logic on the device, typically form based ones that are on-site data entry applications like in inspections which can also be mobilized as offline applications. Once you have determined the need for business logic on the device, you need a way to model the application and change business logic with ease, since it’s not the standard software that gives you competitive advantage; it’s your unique business process that gives you the competitive edge. Standard software is like education you got like several others, but your success depends on how you have applied it. Therefore like the need to have model driven, rules based data distribution that is flexible and easy to change with change in business process, the application development also needs to be model driven and easy to change whether you have business logic on the device or not. Taking these into consideration, the approaches and architectures for offline applications can be summarized as in the table below
As always, you as a BPX are responsible for translating the business needs to the right architecture for offline enablement of business scenario and hope this provides some good inputs for your decision
Before we look in to the approaches and architectures for offline mobile applications, let’s take a quick look in to the aspects that make an offline application different. In Online applications the GUI requests the server for data based on user input. Based on this, the server side business logic determines the relevant data set and sends it back to the GUI.
Fig 1. Similarly in an Offline application, the GUI fires the query, however not against a server, but within the same device e.g. Laptop or PDA and expects the same or nearly same result set as it would from the server. This results in the following requirement for offline applications 1. A local data store that has all the relevant data for the user. 2. Business logic on the device equivalent to that on the server so that the user experience with the application does not change These two critical requirements determine the overall architecture required for offline mobile applications. Requirement 1: A local data store that has all the relevant data for the user
As one could imagine, even with the most powerful and fastest Laptops available today, it’s not realistic to have an entire Enterprise system database like CRM database on a Laptop, let alone on a PDA. This necessitates that the data from the enterprise system must be distributed to every device based on different criteria like user profile, business process, role etc. in such a manner that there is no more data than that is required, no less either. In order to server this requirement, there is a need for a middleware or a data orchestration engine, that can determine the exact dataset for every device based on rules and criteria that can be modeled or defined in the data orchestration engine. As you might expect several thousand devices to be requesting for data from such an engine, the data orchestration engine needs to have efficient and scalable staging area and data distribution algorithms. One could argue that the data required for the device can be cached as and when the user access the server or have predictive algorithms to determine the data on the device. These approaches should not be ignored but must be evaluated carefully based on the business requirement. Some of the pitfalls with such approaches are the completeness of data, ability to change with business process changes. If you users have not accessed the information before, they may not have the possibility to react at short notices, for e.g. if a Sales Rep Dan calls his colleague Rick and requests him to service his customer, Rick may not be able to do so without first accessing the customer information “online” though they may be in the same territory. Similar would be the situation when there is a change in business process, for e.g. if there is a territory realignment, until users access their “new” customer base explicitly to update their cache, they will not be able to service them. However these and many such pitfall can be adequately addressed having a high scalable data orchestration engine with easy to model data distribution rules
Requirement 2: Business logic on the device equivalent to that on the server so that the user experience with the application does not change ...and that the business does not suffer due to errors.
If you are a strong proponent of data caching approach mentioned above, then you would definitely question the need for having offline business logic. Consider the scenario where the Sales rep needs to take an order and issue an invoice to the customer. He would definitely need to have all the pricing conditions and the discount logic that’s appropriate before issuing the invoice. Or consider service scenarios like in defense or mining where end-users are offline for long periods, they need to be informed correctly on the maintenance schedules of the equipment they are servicing. Also remember there are scenarios that don’t need any business logic on the device, typically form based ones that are on-site data entry applications like in inspections which can also be mobilized as offline applications. Once you have determined the need for business logic on the device, you need a way to model the application and change business logic with ease, since it’s not the standard software that gives you competitive advantage; it’s your unique business process that gives you the competitive edge. Standard software is like education you got like several others, but your success depends on how you have applied it. Therefore like the need to have model driven, rules based data distribution that is flexible and easy to change with change in business process, the application development also needs to be model driven and easy to change whether you have business logic on the device or not. Taking these into consideration, the approaches and architectures for offline applications can be summarized as in the table below
| Characteristic | Lean | Intermediate | Rich |
|---|---|---|---|
| Business logic on devices | No | No | Yes |
| Data completeness on devices | No | Yes | Yes |
| Middleware/data orchestration engine | Not required | Required | Required |
| Scenarios | Forms based, data entry scenario where caching mechanisms can satisfy user needs | Scenarios having low or no business logic; or where user error frequency is low | Rich functionality |
