Person-Centric Architecture

An Enterprise Architecture as if people (and life) mattered

While enormous energy and creativity is invested in developing the next great app, few seem to question the architecture through which its functionality is delivered.

The pre-dominant architecture can be characterized as provider(app)-centric and its essence is depicted in the following diagram.

Each application is offered by a Provider Agent (Amazon, Meta, Google, Twitter, etc.) who hosts the application and the data it stores, either in the cloud or in the provider's own data centers (in this example, Meta is the provider agent of the Facebook app). The figure highlights four major components of a Provider/App-Centric architecture:

• Data: Each app holds and manages data about and for each of its users.

• Identity: Each application relies on some sort of identity provider (ID in the diagram). As a user, I must establish my identity with that identity provider in order to access the application. On one hand, this seems a necessary and desirable security feature. If the app is going to store (possibly sensitive) information about all its users, requiring users to authenticate themselves to the application seems prudent. But through the lens of data sovereignty, it is actually rather odd. I need to prove my identity to the app in order to access the information about me that is hostaged by that app. More on this below.

• Human Experience. The look and feel, visual metaphors and overall organization of the user interface is optimized for and by the application. Each provider creates an internally-coherent user experience -- sometimes at great expense and with very rich functionality. In fact, the apps user interface is often viewed as a competitive differentiator. But that coherence is around that application.

• Notifications: Some applications include push notifications that alert users to important or urgent events. But important to whom?

This architecture is so pervasive that many may simply assume it is the only possible architecture there is. But who does this architecture truly serve?

Not surprisingly, the answer is that the architecture serves the application provider.

This becomes clearer when we consider what the picture looks like when extended to multiple apps?

When looked at from the perspective of an individual person, notice how this architecture fragments my experience.

• My data -- data about and for me -- is fragmented across multiple apps. And it is owned by the application provider. I have little control and even less visibility on how or with whom my data is being shared.

• My identity is fragmented across multiple user accounts with duplicate profile information. Logging in to each app is annoying and inconvenient and the plethora of associated passwords offers a large cybersecurity attack surface.

• My interactive experience is fragmented across multiple user interfaces. As noted above, although each provider strives to create an internally-coherent user experience, that coherence is around the application. I'm sitting here in the middle, interacting with all of these apps and having to deal with the differences between each of their user interfaces.

• I am beset by notifications from multiple applications. They alert me when something happens that is deemed important me. Salience is a core faculty developed through evolutionary selection pressures. If detection of a movement in the grass that could signify a nearby tiger does not interrupt my grazing reverie, the cost could be my life and, by extension, my future genetic and memetic lineage. Salience is the basis for attention. However, in this provider-centric architecture, salience is determined by the provider. Is this event really important to me or is it important to their advertisers? They are highjacking a deeply rooted and valuable evolutionary trait for their own purposes.

The diagram illustrates how I am being pushed in various directions from eight different applications. Now multiply this effect by the tens of applications I am likely to use regularly.

Note further that the task of creating an integrated view, of building a sense of personal coherence from all these scattered fragments, is left with me. Adding to the challenge of this task is the fact the app providers may actively be working against this attempt at personal integration. The burgeoning attention-economy -- where I am not the customer, but the product offered for the benefit of the provider's advertiser's -- monetizes my attention. The providers engaging in this business model are investing in ever more sophisticated and powerful technologies to keep me in their silo -- defying my attempts creating a coherent, integrated sense of... me.

Think outside the apps

The MAP flips this around. Instead of asking, what is the most effective way to interact with this application, the MAP asks, what is the full range of capabilities a human agent requires access to and how can we optimize their experience across all of those applications? Starting with the goal of personal coherence, how can we build and deploy applications of and for people?

A person-centric architecture is profoundly different. The apps are expressed through and arrayed around my circles of coherence:

• Instead of the application storing data about me, I store the application's data about me. My financial records, my health data, my skills, experiences and career history, my DNA results, my browsing and search history, my purchase history, my telecommunications history, etc. are all stored in on my devices in my personal I-Space.

• Instead of me proving my identity to the app that hostages my data, apps need to prove their identity to me in order to access my data. This is elaborated in the discussion of MAP Agent Spaces and the MAP Security Model. MAP Service Agreements formalize the information sharing agreements through which properly authenticated apps are authorized to access the data stored on my devices. The MAP Security Model provides authentication, authorization and auditing services -- giving me control over which agents are allowed to access what information and giving me an audit trail that reliably demonstrates who has seen what data.

• The MAP's Dynamic, Adaptive Holon Navigator (DAHN) aims to bring coherence to my interactive experience, by empowering me with significant control over how MAP information and actions are made available to me.

• The MAP Notification Center brings coherence to notifications by giving me control over the sources of notification, the frequency of notification and the medium for notification. MAP adds a layer of indirection between the notification source and notification delivery. Within this layer, user-specified notification policies can be enforced. The MAP Notification Center allows any-to-any mapping between Notification Sources and end-points and Notification Delivery Venues. This is another way of empowering users. In traditional schemes, the choice of delivery venue is made by the sender. For example, if they send you an email, it will show up in your email inbox. By decoupling end-points from delivery venues, MAP allows the user to specify the policies they would like applied to all incoming notifications. Default policies are always provided that implement reasonable behaviors. In this way, new users are not burdened with complexity. They can grow into greater control over their inbound notifications if and when they choose.

How Do You Take the Provider(s) Out of the Driver's Seat

If we think of the set of services that enable this architecture as constituting a platform, it is natural (and important!) to ask, "does this Person-Centric architecture just switch the power from the application provider(s) to the platform provider? Is there a centralized provider in control, representing a centralized gate on innovation?"

Avoiding these centralized control points demands an open-ended and de-centralized architecture. The MAP supports an ecosystem of providers, each free to contribute components to the platform. The MAP invests power in the individual, enabling each person to pull in the components that best work for them. All agent data is owned by that agent.

Is Person-Centric Architecture Even Possible?

This is the central question that has been driving the MAP design. In many ways, the person-centric architecture is a natural evolution of long-standing architectural trends. But it radically flips some key assumptions on their heads and this necessitates some radical changes in approach. Read on to see how the MAP attempts to address the challenges of realizing a person-centric architecture.