Human-centric Applications

Since our previous post on our DataYogi ecosystem we have had an amazing range of discussions around the middle box in our diagram marked ‘Human-centric applications’. So much so that this box has been promoted to number one in our ecosystem view, and our short term priority; updated diagram below.

So what is it about human-centric applications that is now making sense to people; most specifically entrepreneurs and developers? Let’s remind what precisely we mean by such things. Human-centric applications – these are a new category of software applications which, by design, recognise the individual as the point of integration and data control.

The other update to the diagram to add emphasis is ‘the orange dot’. This is the point of integration and strategic control point for ‘my data’ and is very much an enabler for individuals; you can think of it as a bit like a router for personal data. Through that control point, data comes in and out, is updated and onward shared where relevant; and ultimately archived or deleted – always with the individual in control of what happens or does not happen. In our DataYogi implementation that comes with decentralised identifiers, and sophisticated software agents on both individual and connection side in order to manage the underlying complexity, cryptographic keys and many point to point data pipes.

The uptick in activity around developing human-centric applications seems to originate from the inherent flexibility of what can be built in this mode, and also the nature of the ‘blank sheet of paper’ opportunity. It also helps that the decentralised identifier specification has now been formally ratified as an Internet specification; this gives people the confidence that what they build upon has some gravitas and an open market around it.

We first noted that inherent flexibility point when building a prototype application of our own around ‘Me plus Hotels’. Once one understands that the main requirement of this design is the separation of core personal data from application function, and then how to build for that in practice, the rest of the application build becomes very straightforward. Or at least is only as complex as the functions being supported. The home screen of the prototype application shown below helps people understand that critical separation. In the multiple app developer conversations that we now have ongoing, the requirement becomes clear; initially causing concern, and then becoming a very positive aspect. ‘So, I don’t have to worry about managing the personal data, but can still use it to drive functionality and personalise the user experience?’. That’s correct, provided the functionality is all transparent to the individual, and they fully permission it, then that is all good. There is then one further requirement of that human-centricity for the application developer; to ensure that key data that is created within the app is available to be pushed back into the individual’s data store should they wish it to be.

That takes us to the inherent flexibility of this form of application development. Our conversations to date have usually gone along the lines of ‘so, anything else we need to know; or constraints?’; to which the answer is ‘no’. We have starter apps in both Azure and Amazon Web Services environments; but beyond that it is a blank sheet of paper, and a genuine ‘blue sky’ opportunity.

So what kind of thing might be built then? Whilst we can imagine any number of requirements, the conversations we are having so far are around:

• Me and wine
• My car(s)
• Get me a copy of my bank transactions
• My Shopping List
• Event attendance
• Loyalty, rewards and reviews (as seen from the customer perspective)

Each of those is a fascinating opportunity; the underlying dynamics even more so. Consider three keys points that emerge in this model:

1. That the individual only needs to hook up/ connect apps and utilities to their data store in order to begin automatically populating their data vault with the data the apps generate
2. One sweet spot in which human-centric apps most obviously make sense and deliver greater benefit than other approaches emerges in areas where the individual is already managing multiple supplier relationships around the same requirement, product or service. This may be multiple suppliers at the same time (e.g. my car or my house). Or multiple suppliers over time – for example home energy, insurances, mortgages where the individual may be switching different suppliers in and out over time around the same requirement. The human-centric model is the only option for managing/ retaining data over that period; e.g. how has my home gas and electricity use changed over a decade (when i’ve had 4 separate suppliers over that time)
3. One underlying promise of this model is ‘personalisation without data sharing’. The ability to access all of the upsides to personalised content, products and services without the massive downsides of privacy invasion and surveillance is a huge deal with many implications

One area of caution though as well. It is clear that these early applications, whilst exciting, will only be forerunners of what will come down the track when all of this new demand-side data becomes available for use in empowering, privacy preserving ways. It will take the first few apps to point the way to some further horizontal (cross sector) capabilities that will be better built and surfaced by specialist providers rather than built by each individual app developer. Payments is one such example, advertising another (albeit we may need a new name for that when that content is being pulled by individuals as discovery and decision support rather than pushed by the supply side in order to sell things).

Exciting times ahead….