When building a data-oriented system, which likely comprises a back end and several delivery vehicles (mobile apps, websites, desktop applications, connected objects, etc.), you need to design a clear and efficient strategy on how the data used and produced by these systems is organized, shared and distributed across the back end and the various front ends.
In the early days of mobile computing, the answer used to be based on partial replication of a relational database between mobile and back end, with several RDBMS vendors providing options to facilitate this replication. But things are not so simple anymore.
Here are four elements you should take into account when designing your data distribution strategy.
Java
Review: The big 4 Java IDEs compared
How Eclipse, NetBeans, JDeveloper, and IntelliJ IDEA stack up in capabilities and ease of use
READ NOW
Leverage the computing power of the back end
Your client devices have limited processing capabilities. You want to leverage your back-end infrastructure to do the heavy lifting. Not only is it easy to deploy powerful data processing capabilities such as Hadoop clusters in the cloud (or on premises), but your back end has inherently access to more data: historical data and comparable data from other users, from which to form insight. To realize the promise of big data, you need data to be stored, processed, and analyzed on the back end.
Keep private data where it belongs
Some personal data is better off to be kept on the device, and you want to send it to your back end only if doing so enables business processes that create additional value. Conversely, when you send data from the back end, you want to ensure it respects safeguards. Dating app Tinder got some bad press because its back end was sending to the device location data that was too detailed, and it was actually a simple matter to “hack” the process and get more visibility over this detailed data than what was intended. If data is not meant to be visible, don’t send it without obfuscating/anonymizing it.
Account for different clients and consumers
Because of form factor or screen size, an app running on a tablet, on a phone or on a watch is not going to render the same data, and you probably should consider if it’s worth sending the same data set to all devices and let them sort it out, or if it’s better to customize data flows for each consuming device. Beyond form factors, you also want to acknowledge that not all users have the same profile, the same need for data, and the same level of permission. Leaving this filtering to the client is probably less efficient than processing these different needs on the back end.
Some consumers may also be machines instead of humans: connected objects of all kinds. These objects consume data differently. If the front end interfaces have been properly designed, this distinction should not impact your data distribution strategy — but it may.
Recognize that not every client is always connected at full speed (or at all)
The network connectivity issue is a complex challenge for such distributed systems. Slow mobile networks and no-signal zones should not prevent apps from working (this is clearly not always true, as some apps just cannot work offline).
For apps that can work offline, a certain portion of the data is required to be stored locally, either as a temporary buffer or as a way to “take away” the data that’s needed. Certainly, technology exists that make this easy — but deciding which data to cache locally requires a properly designed strategy.
And for apps that cannot work without connectivity, the challenge becomes to “graciously” handle the failover mode, and whether a degraded behavior can be implemented when the connectivity exists but is too slow.
Also Read: Is Search Engine Optimization (SEO) a Good Career Choice?
