Sharing Distributed Data in the Digital World

People spend their lives in a digital world. They expect ever better services brought to them when and where they want them. As a result, most successful startup companies find their competitive niche as essentially data companies that use the data they collect to develop and refine products and services that make their customers’ goals easier and more convenient to meet. Incumbent companies also understand this and are on the journey to figure out how to leverage the wealth of data assets that they already own. From a customer’s perspective, this utilisation is often a massive boon and — whether explicitly or implicitly — they are typically willing to trade their data for free for those improved products and services.

What characterises this digital world? It is essentially one of multilateralism with we, the customer, sitting at the centre of a network of services where, in theory, our data can be updated and shared in real time. Given this perceived connectivity, we are likely to demand more and more connected services. For example, As companies get better at solving specific tasks (like delivering taxi transport by car), we might then develop the expectation of “on demand” transport services and want an ecosystem of companies to present a singular bilateral experience, like cross-continental travel, which involves multiple steps and coordination between different standalone services (taxi, plane, hire car, etc).

Although we are capable of coordinating multiple services by managing our data ourselves, we prefer to have someone else provide that coordination: multilateralism through a bilateral channel if you will. This is what we find valuable. For example, chat systems allow you to combine conversations with many of your friends, wherever they are, synchronously into a single conversation — essentially turning what would be a multilateral chat of who said what and when, into a bilateral relationship between you and your phone piped through the organising capabilities of the chat service.

Right now, this model only works seamlessly in either (1) a monolithic architecture (e.g. Google) where one entity controls all the data and all the services necessary to provide the relevant services or (2) in a non-profit or consortium model (e.g. Wikipedia) where a third party entity controls all of the data on behalf of the members that agree to the third party controlling the data. This mimics exactly the physical world of conglomerates and consortiums without taking advantage of any opportunities that digitalisation might offer. There is no easy way for a user/customer to easily leverage their data across multiple services, and there is no easy way to keep shared data private and contained.

We believe that Ohalo can offer an alternative way to share data that respects privacy, regulation and the competitive needs of different firms. Ohalo does essentially three things: multi-institution data permission orchestration, data translation, and data request routing. We believe that Ohalo can provide a solution to the generalised technical problem of ecosystem data management and as a result, can offer a scalable route to solving the organisational problems that currently arise when we want to share data.