Today I had a very thought provoking Twitter exchange.  It started when I read the article, “GE just invented the first ‘internet of things’ device you’ll actually want to own.” Rather than tweeting the title of that article, I chose to quote a phrase deep in the article:

“pretty soon just about everything we own will have some degree of self-awareness” http://t.co/ZtySg70wMf #IoT

Quite quickly, I received two responses, which were really from the same person. Paul Roberts, tweeting both from his personal account @paulfroberts and his professional account @securityledger, responded: 

@mgd “everything we own” but nobody we know, unfortunately! 😉

Could it be that as we instrument our lives more completely in order to connect more efficiently with THINGS, we lose touch with PEOPLE we know?

It is ironic that rather than having this discussion face to face with anyone I know, I am sequestered in my home office communicating virtually with folks in cyberspace.  Am I really IN TOUCH more, or progressively OUT OF TOUCH?

Somehow, I believe we can achieve balance in all of this – seeking to capture the good in IoT and virtual connections while not abandoning the real-world relationships we hold dear.

 

 

To me, one of the most compelling parts in Phil Windley’s recent white paper, “Introducing Forever: Personal Cloud Application Architectures,” was the emphasis placed on relationships between personal clouds.  A few statements that intrigued me (emphasis added):

One of the most important features of the Kynetx CloudOS is its built-in support for personal channels. …

Even more so than personal computers, personal clouds are only interesting when they are connected. The connection between two personal clouds—or between a personal cloud and anything else it is connected to is called a personal channel. The network of people and organizations linked via personal channels is called a relationship network. …

Personal channels on an open-standard relationship web can be dramatically more useful to individuals and businesses than ordinary email or Web connections. Forever makes use of personal channels by using them as the conduits over which permissioned access to profile information for the user’s contacts occurs.

I expect that relationships between personal clouds, not the personal clouds themselves, will provide the fuel to ignite and accelerate substantive growth in the use of personal clouds. The “network effect” emerging as an expanding social graph is instantiated in a personal cloud architecture could create a bandwagon of growing adoption.

The question remains … what “killer application” or set of applications built on a personal cloud architecture will trigger such a crescendo?

Searching back through the archives, I realized that I had first used the term “Identity Relationship Diagram” in a blog post on July 21, 2005. I stated then:

In the discipline of database design, Entity Relationship diagrams are used to diagram database schemas. In a database, neither entity nor relationship is complete without the other. It is the definition of relationship between data elements that adds value – hence the pervasive utility of the relational database.

A simple “Identity Relationship Diagram” (my term) helps to illustrate the concept. Identities are shown in boxes; relationships are shown as arrows.

More recently, following Ian Glazer’s proposal that graph databases replace directories and relational databases in Identity systems, I discussed using directed graph diagrams to illustrate identities and relationships:

We can visualize identities as nodes, each with relevant properties, and relationships between identities as edges.  Interestingly, the edges, or relationships, may also have identities and properties of their own.  

After further study and thought, I believe that “Identity Relationship Diagrams” can be very useful in illustrating concepts in the Identity and Access Management domain. The following diagram, prepared using Graphviz graph visualization software, is helpful to illustrate two general areas of discussion.

The top half of the diagram illustrates basic relationships between individuals how those individuals can belong to groups.  This is the basic construct of the Facebook Identity Graph.

The bottom half of the diagram illustrates how people interact with things via services.  These are the basic elements in the Internet of Things.

My thoughts about how to use this diagramming method are still developing.  Stay tuned for more.

PS.  For those interested in trying out the Graphvis software, the Dot graph description language code to create this diagram is:

## Entity Relationship Diagram – prepared by Mark Dixon

digraph test {

rankdir=LR;

graph [ fontname = “Arial”, fontsize = 20, size = “20,10” ];
node [shape=circle,fixedsize=true,width=2.5,color=blue,style=bold, fontname = “Arial”];
edge [color=red, fontname = “Arial”];

i1 [ label=”Person\n Name = Mark\n ID = i1\n hair color = white\n residence = US”];
i2 [ label=”Group\n Name = Dixon Family\n ID = i2\n attribute 1\n attribute 2″];
i3 [ label=”Thing\n Name = My Fridge\n ID = i3\n attribute 1\n attribute 2″];
i4 [ label=”Service\n Name = Fridge Service\n ID = i4\n attribute 1\n attribute 2″];
i5 [ label=”Person\n Name = Holly\n ID = i5\n hair color = brown\n residence = UK”];

i1->i5 [ label = “Parent of\n ID = r1a\n attribute 1\n attribute 2” ];
i5->i1 [ label = “Child of\n ID = r1a\n attribute 1\n attribute 2” ];

i5->i2 [ label = “Belongs to\n ID = r2a\n attribute 1\n attribute 2” ];
i2->i5 [ label = “Contains\n ID = r2b\n attribute 1\n attribute 2” ];

i1->i2 [ label = “Belongs to\n ID = r3a\n attribute 1\n attribute 2” ];
i2->i1 [ label = “Contains\n ID = r3b\n attribute 1\n attribute 2” ];

i1->i3 [ label = “Owns\n ID = r4a\n attribute 1\n attribute 2” ];
i3->i1 [ label = “Serves\n ID = r4a\n attribute 1\n attribute 2” ];

i4->i3 [ label = “Controls and Monitors\n ID = r6a\n attribute 1\n attribute 2” ];
i3->i4 [ label = “Reports Results\n ID = r6a\n attribute 1\n attribute 2” ];

i1->i4 [ label = “Requests Function\n ID = r5a\n Function 1 = set temperature\n Function 2 = request status” ];
i4->i1 [ label = “Reports Results\n ID = r5a\n attribute 1\n attribute 2” ];

 

overlap=false
label=”Identity Relationship Model”

}

In the book “The Emergence of the Relationship Economy,” Jay Deragon proposes that:

The value of the relationship is categorized into four elements of the individual, and may be of one dimension or a combination.:

1. Economic
2. Intellectual
3. Emotional
4. Spiritual

To understand the juxtaposition of Identity and Relationship, I listed some of my current relationships in the following tables:

 

People Relationships

 

The first table lists a few people relationships I have.  The first, my wife, provides value to me (that sounds kind of crass, actually) in all areas.  Her economic value comes not from revenue (she chose dual careers as  Homemaker and Stay-at-home-Mom), but in her thrift, wise use of money and sound economic advice.  In addition, I deeply value her wisdom, friendship and spirituality.

My relationship with Claudia is in quite stark contrast to my very distant relationship with my employer, Larry Ellison.  Sorry, Larry, I see the value of our relationship as primarily economic, although I must admit receiving a bit of intellectual stimulation from reading about your personal exploits.

On the other hand, my relationship with John, a colleague at Oracle, began as an economic relationship as we worked together in the sales organization, but grew into a deep friendship, with intellectual, emotional and spiritual value.

The final example is Neil, the Bishop of our church congregation and close neighbor.  We have developed a  friendship I value highly, based on strong spiritual, emotional and intellectual relationships.

It could be an interesting experience to assess the value we receive from all of the people with whom we interact in some way, but the real purpose of this post is to explore the value of relationships with information systems.   The following table illustrates a few of the systems with which I interact regularly.

 

System Relationships

 

I definitely have an economic relationship with Oracle Payroll.  Twice every month, a nice paycheck drops into my bank account, and I log onto the payroll system to see how much money I pay in taxes and investments.  While I admit to deriving some emotional satisfaction from that process, we’ll let it remain as an economic value.

In contrast, the different email systems I use can provide value across the board, as I communicate with people on a wide range of subjects.

In social networks, LinkedIn is the vehicle I use to primarily keep track of professional colleagues and associates, although I get emotional value out of maintaining and building friendships with people across miles and time.

Facebook, on the other hand, is where I actively seek to strengthen emotional and spiritual ties with friends and family.

Kindle also sweeps the board – my virtual bookshelf contains titles that provide value in all four areas.

This brings me to a couple of examples of my relationship with “things” that deliver value.  I can monitor and control my new home alarm system from an app on my phone.  The system provides economic protection and emotional peace of mind.

Finally, my remote thermometer satisfies an intellectual curiosity about how hot it is outside, here in the Arizona desert.

It is important to note that how a person uses or views a particular system may influence the value he receives.  For example, I know of people who leverage Facebook primarily for economic advantage.  I just choose not to do that.

 

So What?

How does this relate (pun intended) to Identity?  Here are a few thoughts:

1. Exposed Personae: Certainly different facets of my personal identity are exposed as I interact with different people.  Larry Ellison will never see (even if he cared to) parts of my personality that I have reserved for my closest friends.  My closest friends will never know of parts of myself I share only with my wife.
2. Context: The context of relationships differ, depending on time of day, distance apart, frequency of interaction, mutual interests, etc.  Such differing context has a large impact on the value derived from relationships.
3. Connection method:  How does the relationship connect me with the person or system?  With people, is the relationship primarily in person, by phone, via email, via  a social network or all of these?  Is a digital identity required to enable the relationship?
4. Available functionality: For systems with which I interact, what functionality is available?  What can the system deliver that delivers value to me?
5. Authorized access: Of the sum of all functionality in a system, what am I authorized to use, or what functions do I choose to use?

Focus on Value

Yesterday’s post illustrated a few cases of how relationships can exist between identities and resources or identities and people.  I propose that we should focus not which relationships exist, but on what value can be derived from each relationship.  

In interpersonal relationships, hopefully, value flows to both parties.  In the case of employee relationships with enterprise systems, hopefully value accrues both to the employee and employer.  In the case of individuals connecting to online systems or things, hopefully each person receives value from those relationships.

And Identity is at the core of making these relationships happen.

Stay tuned …

 

 

 

In line with my post yesterday about viewing identities and relationships from the vantage points of “enabling” and “protecting,” I created three diagrams to illustrate how relationships between people and resources or other people provide the opportunity for value creation.

The first diagram illustrates the relationships a person may typically have with information resources within an enterprise.  The objective of these relationships is to connect individual people with the applications or systems that may deliver value, both to the individual and to the enterprise.  Typically, these relationships are granted and governed by the enterprise.

 

 

The second diagram illustrates a person’s connection to items within the emerging Internet of Things.  In some ways, this model is similar to the enterprise model, in that connections are made between people and resources.  However, in this model, individuals typically would initiate and govern their own relationships with things that would deliver value to themselves.

 

 

In the third model, people establish relationships not just with functions or services, but with people, effectively connecting identities together via a social relationship platform.

 

 

In line with my comments yesterday, I propose that in each of these cases, relationships must be established to “enable” people to derive value they seek.  Both Identities and relationships must be “protected” to prevent the wrong people from interfering with a person’s desire to derive value from the relationship, whether it be with a function, service or other person.

That’s all tonight.  More on the morrow.

My thoughts for this post were triggered primarily by two items – me beginning to read “Emergence of the Relationship Economy”  and reading Nishant Kauskik’s tweet Monday:

Is Identity The New Perimeter? – http://t.co/gSQwni5d. Check out the article to see my answer. Hint: It might surprise you. #IAM

I was intrigued by the subsequent conversation:

Ian Glazer:  Good read: http://t.co/gVQHy7MI @NishantK says #IAM is the perimeter. I say relationships are the perimeter. Probably ought to blog this

Dave Kearns:  RT @lpeterman: @iglazer @NishantK Relationships designate the borders of the identity perimeter

Nishant: @iglazer If an account being provisioned to a person is a relationship, if attributes are related to a person, then IAM=Relationship M. So..

Nishant:  @iglazer So…, question is what is the difference between Identity Management and Relationship Management? Where is the separation?

Of course, there were also bits of levity:

Paul Madsen: My take? Circumference is the new perimeter.+

Dave Kearns:  RT @NishantK: @iglazer what is the difference between Identity Management and Relationship Management? Oprah’s name doesn’t come up in IdM

First, I agree that from an information security standpoint, the perimeter has drastically shifted. There is no longer a firm physical or logical perimeter around an enterprise that can be hardened sufficiently to minimize risk to the people and systems inside.

To realize that we must focus on the individual rather than the enterprise boundary as a first line of action and defense certainly seems wise to me.

But what is the correct terminology?  is IAM really Relationship Management?  Is Identity the New Perimeter?  Are Relationships at the real border?

Although I am late to the conversation, here are a few of my thoughts on the subject:

A digital Identity represents a single person or thing in some way.  A digital Identity can certainly include attributes or characteristics that uniquely identify such a person or thing.  A digital Identity surely has value and meaning in and of itself.  However, I believe relationships are what give Identities real substance, particularly as we consider the subject in light of current and emerging business models.

Real-world relationships constitutes linkages between individuals, or between individuals and organizations, or between individuals and things. We may describe digital relationships as the attributes, permissions, entitlements and roles that define how digital identities are linked with organizations, people or things in the overall ecosystem in which the identities reside or participate.

So, is it appropriate to talk about “Identity Management” or “Relationship Management?”  I propose that both are included in the common definition of Identity and Access Management.  Surely, IAM includes managing individual digital identities (e.g.- names, attributes, credentials).  However, IAM also includes the management of relationships – assignment of entitlements to an identity is a good example.

However, I think “management” is the term that is out of whack – not identity or relationship.  Management typically implies one way force, control or direction.  This is the case for traditional IAM – the enterprise creates, owns and governs the identities and associated relationships for all of its users.

On the other hand, in the philosophy behind personal identity management implies that each individual should create, owns and governs his or her own Identity free of coercive control from an enterprise.

I don’t think the boundary is as cut and dried as that.  It is helpful to consider what enterprises really want and what individuals really want.  If we look at the issue that way, I think the verbs “enable” and “protect” are more descriptive than “manage.”

As an individual, I want to participate in systems that “enable” me (as defined by my digital identity) to form relationships that deliver value to me.  I also want systems that “protect” both my identity and the relationships I enter against threats from impostors, thieves and vandals.

On the flip side, I think enterprises seek similar value.  They want to “enable” their users (think digital identities) to establish relationships with systems, people and things that will deliver value to the enterprise.  They also want to “protect” the identities and relationships of their users against threats from bad folk.

The CRM/VRM debate is an example of looking at relationships from different viewpoints.  At one extreme is the enterprise wanting to exert onerous control over all its customers to maximize commerce – hence customer managed by enterprises.  At the other extreme is the enlightened consumer wanting to be free from enterprise tyrany – or vendors managed by consumers.

However, the optimal answer probably somewhere on the scale between the extremes.  In both cases, if we concentrate on what both parties really want, we will progress to a more optimum solution.

If we are to progress toward a highly cooperative ecosystem where multiple  relationships deliver superior value as envisioned by “Emergence of the Relationship Economy,” we must build infrastructure to “enable” and “protect” identities and relationships from multiple points of view.