The network dependency of an IBM terminal user of the 70s is surprisingly familiar to a mobile phone user in the 2020s. Without a connection to the network and a centralized server infrastructure, the applications are not working.
Having its roots in the thin clients of mainframe multi-user systems, the server-centric approach was challenged by the emergence of powerful personal computers in the 80s, only to become the de facto standard once again with the smartphone revolution.
With the recent advances in privacy laws and regulations, we might see another shift to the client as the place of data processing.
Client Server Architecture
The client-server model introduces two roles: the service user (client) and the service provider (server). The client requests a resource and the server provides that resource.
During the design process of a client-server application, it is decided which parts of the task should be executed on the client, and which on the server. This decision can crucially affect the cost of clients and servers, the robustness and security of the application as a whole, and the flexibility of the design for later modification.
Early smartphones had limited storage capacity and processing power. Hence mobile application development focused heavily on degrading the smartphone to a pure front-end experience while scalable backend systems provided computational power and storage.
Business interests like analyzing usage patterns or digital rights management further pushed the server-centric agenda of mobile application architecture. End-users received device independence and cloud storage in return for giving up data to organizations.
Today companies implement server-centric architecture without a second thought and mobile application development is mostly reduced to work fancy UX design and backend API integrations.
It might be time to re-think this approach since privacy laws emphasize user rights over company interests.
But enough of the theory and let’s look at a mobile application in the default server-centric setup, the privacy law implications and how it could be transformed.
Symptom Checker App 1.0
A symptom checker is the attempt to replace a doctor visit with an algorithm supported self-diagnosis. After providing some base information like the age and answering a couple of questions, the diagnosis is made. I will not go into the reliability of this kind of diagnosis but rather focus on the technical implementation.
The average symptom checker takes user input and sends it to a backend server where the data is processed in clear text and the results are stored. This means that the correlation between medical and personal data is possible for anyone with access (intended or not) to those systems.
The data cluster of a symptom checker is considered sensitive personal data and is located in the highest data protection category. Appropriate technical and organizational measures have to be implemented to satisfy privacy laws like GDPR. This will be challenging for small to medium-sized organizations, especially when utilizing cloud computing.
Shift To The Client
Handheld devices are also rapidly catching up to desktop computers in terms of computing power and memory. While the performance gap will never be completely closed, the additional abilities of smartphones open up the possibility for more flexibility in system design.
So the question is how a different approach could look like and where to make the trade-offs? For an understanding of the future, I suggest looking to the past.
In the 80s the PC revolution set the trend from server-centric to client-centric. The mainframe was forecasted to be replaced by personal computers with locally installed business logic. The only thing a centralized server was required for was the sharing of files and as a backup solution.
Symptom Checker App 2.0
The algorithm behind a symptom checker is reflected in a decision tree since it only contains conditional control statements. It is therefore small in size and could easily be executed on a smartphone.
By creating an application framework for different downloadable decision trees it is possible to run the logic entirely on the client and reduce the server involvement of a symptom checker app to that of a simple file service.
No critical data would be centralized processed or stored. The user will stay in control and can make a conscious decision about donating data to improve the app or share the results with others.
Let’s be honest, most users don’t care or know whether the application they are using runs locally or remotely.
It’s the responsibility of architects and engineers to make good decisions. Privacy laws force us to think about the data criticality and consider alternative approaches to the well-known default of server-centric applications.