Clayton Donley's Blog

When is a network NOT your network? If you're an typical person working for a typical company, it's when you're talking about SOCIAL NETWORKS.

However, this isn't always as bad as it sounds.

I've spent time over the past several months trying out various social networks to understand how people at a typical enterprise might use them -- other than to get a job outside that enterprise!

My interest was originally to understand how we could do a better job supporting more dynamic networks of employees, partners, and suppliers in meaningful online situations.

After all, many of these users are all represented in your enterprise's existing networks in directories, databases, and applications. If I look for a document in my content management system, doesn't it make sense that a result might come back first as much because of who wrote that document and their relationship to me (reporting, project groups, departments, tags, etc...) as much as because of the proximity of my search terms?

That said, this posting is less about enterprise social networking than it is about the existing social networks that everyone knows about and how they fit for an enterprise user:

LinkedIn

By far the most corporate. Most of the people in my address book have an account here. They generally don't do much with these accounts other than "link", but they're there.

I could see a lot of situations where using technology such as virtual directory to link enterprise directory users with their connections on a service like this might be useful...except that the actual relationships here are ill-defined. I might have added some people that I work with all the time and other people that I haven't talked to in ten years. I may have also added people that I talked to once at last week's conference that I'll never talk to again.

As those of us in the identity and directory spaces have known for a while, figuring out how identities really fit together with all the various other identities (e.g. taking ad-hoc groups of users with the same privileges and lumping them into a role) is a lot harder to do than it sounds.

If there was more context around these relationships, linking to it would be the easy way to give your sales people a roadmap to reaching the person they want at a particular account through someone they already know. Or lets you know which partner might be the best to go into an opportunity with based on their existing successful relationships with a customer.

Clearly there's a lot more here, but given that I'm not actually linked via LinkedIn to most of the people I'm REALLY related to (colleagues, managers, staff, etc...), the network being shown is far from complete.

Facebook

Less corporate, but not Myspace (which I won't bother to mention at this point). Probably 10% of the people in my address book could be found on this service.

If I wasn't linked to anyone I deal with on a regular basis on LinkedIn, this is even more the case with Facebook. One again, while I have a network, it's missing major people.

Even more troubling to adoption in corporate environments, though, is the application platform. There is one, but most of what has been built on it isn't very meaningful and it's hard to find the stuff that might be good or become good with enough support.

Since some of the emphasis here is on content sharing (photos, blogs, comments, etc...), many enterprise users are going to be cautious about inviting their colleagues, managers, or subordinates to their network out of concern that sharing their photos from Tahoe might not be interesting to that class of people in their network.

As a source of data and enterprise network information, I have a hard time seeing where a typical enterprise might want to hook up, even with well documented APIs.

Once again, the key problem here is that the "network" lacks important context and even if manual context is created, it can get old fast. After all, nobody's paycheck is linked to their Facebook profile being up-to-date.

Twitter

Twitter is by far my favorite service. It's had a lot of downtime (hint: move your database to Oracle...:-) ) and of my entire address book only contained one person out of 150+.

Certainly at a hit rate of 1/150, it's a network...but a very, very small subset of my real network.

What's different here is that Twitter is less about recreating your own existing real-world networks on the Internet than it is about getting you to communicate with NEW people about NEW things.

It's funny that I wrote the above, as I signed up for Twitter 6 months ago, only to regard it as the medium for "I'm in a boring meeting" announcements, or any other statement that was too boring to write in email, blogs, instant messages, or so forth... It wasn't until 4 months later that I touched it again.

What changed things was this great article about Twitter by Robert Scoble. Basically, the trick to Twitter is in who you are following, not so much in who is following you (not many will at first). Once you're following good people, you're learning new things and contributing to conversations. If you're interesting enough, people will follow you back (and you'll feel good about that...).

So what does Twitter have to do with the Enterprise?

In actuality, the connections made here are even less likely to be meaningful than with either Facebook or LinkedIn. However, it's more likely that someone that uses the service will actually be producing some level of content and because this content is 140 characters or less, it's likely to be less "controlled" than a typical blog posting.

So as an enterprise, I may not interested in the identity connections, but I do want to see what people are saying.

I use a service called Tweetscan that actually gives me every public message sent with the word ORACLE in it. These messages are short and easy to scan.

Every once in a while I come across a gem like:

Sun Identity Manager does not scale...i've come to the conclusion. I wonder if Oracle Identity Manager does...maybe CA? 02:46 PM April 25, 2008 from web

Do you think I followed up with this happy Sun integrator?

Absolutely!

But I just as often follow up on messages that are less specific to my particular responsibilities. After all, the idea here is not to simply spam your commercial messages -- it's to be a participant in a NEW network of people.

Other Networks and Conclusions

There are many, many other networks. I've joined many of them to get a better idea of what's good and bad about them. Some, like Brightkite show a lot of promise through integration of location-aware features. Others, such as DIGG serve as an interesting model for what enterprise portals could do a better job of: showcasing content that others like me think is interesting.

But generally speaking, if I'm looking at identifying the people closest to me in my enterprise setting, the real world is not likely to be reflected in my online social networks. Some networks get closer than others. With some networks, this doesn't even seem to be the purpose.

There are people for whom this is an exception. Certainly online networks are likely to be more accurate for younger people than older people. They are also likely to be more accurate for people in external facing roles (e.g. standards, marketing, sales), but these people also tend to have larger external networks, so differentiating between strong relationships and casual relationships may be even more difficult due to the lack of strong, up-to-date context.

Certainly here at Oracle and particularly in Identity Management we're paying a lot of attention to what people are doing and the enterprise potential that can be delivered to our customers from existing services, as well as the general models and opportunities that they represent.

Technorati Tags: twitter, facebook, linkedin, enterprise social networking

At about the same time I put together yesterday's blog posting about many of the existing personal social networks, Thomas Kurian, the Oracle SVP responsible for Fusion Middleware (among other things) was giving a presentation at JavaOne related to our own efforts in the area of enterprise social networking.

The key word here is enterprise.

Note in the demonstration that you're seeing orders, people, conversations, and other elements linked together from enterprise systems.

Note that the relationships, tagging, and other functionality didn't require redefining new people and relationships, or re-registering for new services. Relationships in an enterprise are often pre-existing. Customers exist. Employees exist. Partners exist. The relationships are often defined in databases and directories, while deeper context exists and can be brought to the surface through integration with business applications.

As the CNET blog posting above indicates, other companies will say that this has been here all along. What those companies aren't saying or showing is such strong integration with existing enterprise systems. There are no green fields in this demo and that's the reality for most enterprises.

For the identity buffs reading this, note the integration of traditional white pages functionality with presence services, instant messaging, and other elements.

From a directory services standpoint, if your existing applications can query a directory today, using virtual directory automatically extends them to access your presence services, database data, and other non-traditional identity information without needing to adopt new frameworks. This shifts the focus from how do I get the data to how can I use the data. Solving the later question is where the value is achieved.

Really fantastic stuff.

Technorati Tags:
enterprise social networking, virtual directory, JavaOne

Dave Kearns says LDAP is the COBOL of Identity.

Jeff Bohren says it's actually the SNMP of Identity.

So now that we're talking about LDAP's role in the universe...

There's no pressing need to get rid of LDAP in existing applications. None at all. It works. The applications support it and will continue to support it indefinitely.

Even in next-generation application I see LDAP support being integrated -- hardly what I see of COBOL and not as the afterthought that SNMP always seems to be.

What does this say about any future identity services?

They must support LDAP-enabled applications.

Does this mean that they will only support LDAP? No.

Does this mean that we shouldn't move new applications to frameworks like the Identity Governance Framework that make it exponentially easier to build identity-aware applications? No.

It simply means that if you want your existing applications to support your new identity service, it had better support LDAP or most of what you have won't work with it.

That said, movement requires motivation. If LDAP is good enough, we'll be talking about next generation identity services for a dozen years before anything meaningful gets shipped. After all, it was almost a decade ago that Bowstreet and others talked about replacing LDAP with DSML. This went nowhere.

So what great advance would provide this motivation? It won't be security, audit, and compliance. These things can be achieved today with LDAP and strong identity management software. If you can do it today, why rework everything?

What's likely to drive the move from LDAP to identity services is the enablement of new applications that have enormous potential for driving business growth.

An application that can take advantage of the extensive information available around identity in a way that relates that identity to its peers, communication, transactions, and other elements can really contribute to business. Since the full picture of identity and its relationships is much richer than LDAP's information model can describe, we will then need to move beyond the LDAP data model -- not by simply rewriting LDAP in XML, but by redefining what an identity representation for applications should look like.

There are many candidates for next-generation LDAP. Which one will win out? I've got my opinions, but in the end it may not matter.

Why? Because virtual directory technology insulates applications from the underlying changes in technology. This technology will easily adapt to add new listeners and adapters for emerging standards while retaining LDAP for the applications that have been written and will continue to be written to that model.

Technorati Tags: identity management, LDAP, virtual directory

Dave continues in his latest posting...

It does seem that when a bold thought is made as an pithy, somewhat humorous statement that it's seen as some how denigrating the subject. so let me say it once again -

Like COBOL, LDAP is so deeply ingrained in our computing arsenal that it can never be entirely replaced.

Exactly. Glad we're all in violent agreement.

That said, the one thing that will be similar to COBOL is that people will be touching it without knowing it.

Just as today there are countless web services that provide access to data that was once tucked away on proprietary mainframes, tomorrow's identity applications will be touching identity data accessed via LDAP under the covers. And just like in the mainframe situation, these directories will only be playing a part of the role necessary to complete the full transaction.

For the record, my first paid technology job (an unpaid internship, now that I think of it) was updating COBOL code on an HP/3000 mini-computer in the late 80's. I can only hope that my code isn't still running someone's business!

Technorati Tags: directory, LDAP

Kim Cameron of Microsoft makes a pitch for why Metadirectory is still relevant, or at least why data needs to live in multiple places.

One key element of this argument is that when combining transactional data with identity data, you're not likely to do the required data joining across remote systems.

Compare this to what happens if all the information necessary to respond to a query is present locally in a single database. I just do a "join" across the tables, and the SQL engine understands exactly how to optimize the query so the result involves little computing power and "even less time". Indexes are used and distributions of values well understood: many thousands of really smart people have been working on these optimizations in many companies for the last 40 years.

He's right and this is a really important point. The data used in this example absolutely should live in a repository where it can be locally joined.

How does the data get from point A to point B in this example? Which of these points is the starting point? Does this data actually originate first in point C? Do these repositories have the same representation for the given data elements?

Certain very widely used data is likely to be in multiple systems and has a relatively low rate of change that doesn't cause much of an issue for any of the usual means of getting it there. Such information might include unique identifiers, names, department, job code, email addresses, and the like.

In Kim's example, it would not be unlikely to do a join against an employee number, department, or other information. In the same way, it would be highly unlikely that this join would be done with a password, data from CRM, and other such data.

The real problem today is that synchronization is so loosely-coupled. This is unlike replication, where it's become relatively easy to recover from failure and the mechanism involved in moving data knows exactly how to deal with both ends of the data movement connection.

As applications become better at pushing their changes, rather than depend on provisioning and meta-directory systems to do deltas against their databases, we'll see much of this problem become greatly simplified.

At that point, instead of the value being in how tightly you can make your connections and move changes, the value is in what you can do with those changes. Can you use those changes to trigger workflow? Can you apply business policy against those changes? Can you centrally audit and do reporting against those changes?

This higher order value is exactly what customers look for in provisioning.

The identity bus itself will be a mix of common publish/subscribe style data movement and virtualization that will provide the identity views that minimize the overall level of data movement through the system.

Technorati Tags: LDAP, meta-directory, virtual directory, identity bus

Dave Kearns has followed up on Kim Cameron's posting from Friday.

1. Kim says that sometimes you need to copy data in order to join it with other data
2. Dave says the same thing, except indicates that you wouldn't copy the data but just use "certain virtual directory functionality"

Actually, in #2, that functionality would likely be persistent cache, which if you look under the covers is exactly the same as a meta-directory in that it will copy data locally. In fact, the data may even be stored (again!) in a relational database (SQLServer in the Radiant Logic example he provides).

Let's use laser focus and only look at Kim's example of joining purchase orders with user identity.

Let's face it. Most applications aren't designed to go to one database when you're dealing solely with transactional data and another database when you're dealing with a combination of transactional data and identities.

If we model this through the virtual directory and indicate that every time an application joins purchase orders and identities that it does so (even via SQL instead of LDAP) through the virtual directory, you've now said the following:

1. You're okay with re-modelling all of these data relationships in a virtual directory -- even those representing purchase order information.
2. You're okay with moving a lot of identity AND transactional information into a virtual directory's local database.
3. You're okay with making this environment scalable and available for those applications.

Unfortunately, this doesn't really hold up. There are a lot more issues, but even after just these first three (or even the first one) you begin to realize that while virtual directory makes sense for identity, it may not make sense as the ONLY way to get identity. I think the same thing goes for an identity hub that ONLY thinks in terms of virtualization.

The real solution here is a combination of virtualization with more standardized publish/subscribe for delivery of changes. This gets us away from this ad-hoc change discovery that makes meta-directories miserable, while ensuring that the data gets where it needs to go for transactions within an application.

Technorati Tags: identity bus, LDAP, meta-directory, virtual directory

While I may not agree that doing SQL through your virtual directory to get access to combined views of transactions and identity information is the right way to go (and I think Dave really wasn't trying to say that anyway), but...

I absolutely DO agree with Dave (and Vikas Mahajan) that there's no reason we should be building additional infrastructure around moving identity around vs. moving any other data around.

Let's keep in mind that a bus can move any arbitrary object from A to B or even A to B, C, and D.

The trick is to make sure that all of these points understand the object being passed between those points.

Just as multiple LDAP-enabled applications need to understand the same schema, multiple parties publishing/subscribing to a queue will need to understand the same messages.

This is true even though each application may only need a slice of that identity data. The overall structure of what is being shared. The Identity Governance Framework (IGF) actually gives you a standard way of defining the attributes present in a message you could accept/publish. It even provides a place for defining which attributes might be used as keys by your particular application, which helps in the previous discussion re: joins.

If we agreed to use IGF's CARML representation to define the attributes that would be present/required by an application and agree on what representation will be used to encapsulate those attributes, all you need is a standard message bus.

Of course, the question then becomes, who will take the messages off the bus and send updates to legacy applications and who will take updates from legacy applications and push them onto the bus in the first place.

This is where identity services come into play. Like virtual directory, they're simply moving data from one context to another so that everyone else doesn't need to adapt to the legacy environment and legacy environments don't have to adapt to each other.

Maybe I could ask my friend and colleague, Phil Hunt, to spare some time to post a quick example of how this looks in real life.

Technorati Tags: identity bus, identity management, LDAP, virtual directory

So there's been a lot of press in the last few days about Facebook shutting off access from the recently announced Google Connect social platform. For those of you that pay attention to identity management, but haven't paid attention to this particular situation, note the following couple of quotes: Robert Scoble comments:

Facebook is being consistent here. Dave Morin told me a few months ago all about Facebook's concerns. Such as, what happens if you change your email address, will it change everywhere that your email address got copied to?

Michael Arrington of TechCrunch responds:

So when Robert Scoble wrote this evening that Google is in the wrong, I disagree. I think Facebook's intentions aren't to let users get data out of the network until Facebook is absolutely forced to do so, and then only on Facebook's terms (see Facebook Connect). The fact is, this isn't Facebook's data. It's my data. And if I give Google permission to do stuff with it, I'm damned well within my rights to do so. By blocking Google, Facebook has blocked ME. And that, frankly, kind of frustrates me.

Michael is clearly in the user centric identity camp with his comments.

Robert's comments (or rather his agreement with Dave Morin's comments) are very similar to the type of concern your typical IT manager has about moving data between applications...only on a much larger scale.

In an ideal world, your identity is your own and you have granular control over who gets what and where it moves.

In reality, if the average user was presented this question as often as identity was requested, it would be a bit like these "desktop firewalls" that continuously ask you to "accept outbound connection to IP 10.10.10.20". Meaning that you'll grow numb to the requests at some point and simply grow accustomed to clicking "Accept" for every request for that data, knowing that clicking "Deny" means that the program (or service) won't work.

This is actually one of the issues that must be overcome by the user-centric identity crowd. It's one thing to provide a layer of security and control, but another thing to make that meaningful in real life.

On the other hand, assuming a data owner (in this case Facebook) wants to actually share their information with a partner (in this case, Google), Robert's mentioned concern about keeping synchronized copies of the data is valid. What's the solution to this part of the problem (assuming that the real problem here isn't Facebook being concerned about Google cannibalizing their business by building a better widget with their users)?

Seems like a case for some combination of virtualization and federation. What do you think?

UPDATE: Note a slight update on Scoble's blog that clarifies a few key details. Removes some of the synchronization/staleness issue, but interesting never-the-less.

UPDATE2: Google employee Kevin Marks says I'm wrong in comments here. Here's his correction to this post: "Robert, you're wrong about Friend Connect data getting stale. It's fetched directly from your linked Friend Data sources, including other Social Networks, with short-term caching on Friend Connect servers. There is a live two-way connection - Friend Connect posts back events to the Social Networks' activity streams when the user choses to do so."

Technorati Tags: facebook, identity management, privacy, identity

• Data Portability: It's The New Walled Garden
  To some degree this is the classic identity politics situation that we talk about all the time with identity virtualization. Basically if I give you a copy of identity data, I lose control of it. Will be interesting to see how this plays out at Internet s
  (tags: identity privacy)
• What Data Portability Means for Business - Covering All That's Social On the Web
  Another good article that puts the Facebook-Google situation in perspective. Users give up privacy nearly every time they click "Accept" on a registration form. There's no reason to think that they will stop doing so anytime soon. Even with InfoCard and o
  (tags: identity privacy)
• IdentityBlog - Digital Identity, Privacy, and the Internet's Missing Identity Layer
  Kim Cameron of Microsoft summarizes the most recent set of discussions we've all been having related to his initial scenario involving a combination of identity and purchase order data being used by the same application.
  (tags: identity)
• The Virtual Quill
  Dave Kearns follows up on the responses from Kim and I. Seems to be in agreement, though points out that we've got to make sure we consider the needs of today's (and yesterday's) applications as much as the next generation. Couldn't agree more.
  (tags: identity)

• Network Security Blog » Data isn't "private" if you put it on a social networking site
  Martin McKeay makes a similar point to mine from earlier. If you register for a service and "ACCEPT" that you're going to share the information in that service, you've given up a degree of privacy to be part of it. This is doubly-true with the case for In
  (tags: identity privacy security)
• Birthing pains in the colonization of the social Web

• Some Thoughts on Facebook Connect, Google Friend Connect and MySpace Data Availability
  (tags: identity socialnetworking)
• blog.pmarca.com: Friend Connect, Open Social, Ning, and the web
  (tags: socialnetworking)
• The Tao of XDI: Did Info Card help?
  Apparently Kim Cameron's integration with InfoCards is keeping poor Andy Dale from authenticating and thus providing his feedback on the latest distributed identity access discussion... I think the answer to his rhetorical question was no, but maybe he en
  (tags: identity infocards)
• Shops secretly track customers via mobile phone - Times Online
  Interesting article. Seems similar to the way that sites track visitors through cookies -- at leas when you ignore the underlying tracking tech.
  (tags: privacy)
• Your Identity in a USB
  Couldn't help but chuckle after coming across this, given Kim Cameron's recent (and excellent) post about the anti-excellence of fingerprints...
  (tags: identity)
• LifeLock CEO Had His Own Identity Stolen Numerous Times, Suit Alleges
  Tip of the day: Don't publish your private information in magazines. Then again, doesn't take a printing press to get your ID stolen.
  (tags: identity privacy)

So I noticed an odd headline in a news feed from the Chicago Tribune this morning: Neighbors seeing red over man's firetruck The gist is that a man purchased a fire truck on e-bay, built a garage near his suburban home for it, and engineered a solution to bring water from his pool to the rescue in the event of a fire. Note that there are 4 fire stations in the vicinity and a fire hydrant 1,000 feet away from the house. His take:

"When you don't have hydrants, you need water," said Mitchell, 59, who does not claim to be a firefighter. "The peace of mind of having the water made my day."

Quote from the Fire Chief about using this water:

"That's really an option way down on the list," Gallas said. "It's available and if we ever needed it we could use it."

What does this have to do with technology, and in particular, identity?

The number one thing that I've seen delay projects related to identity and directories -- as a customer, consultant, and software provider -- has been the tendency to over-engineer these solutions.

In the case above, the odds of a fire are relatively low. The odds that the personal fire truck will be needed is even lower. The odds that the water in the pool will be needed is lower still. By the time you're done looking at the real risk of this happening, you'll have realized that if you thought this risk was real you probably should have just bought some extra insurance, stopped smoking, and stopped cooking with grease (the later two being two of the most common reasons for residential fires).

Similarly, identity management projects need to be designed around realistic goals. These goals should include the right amount of availability and disaster recovery to deal with real business impact in the same way that business deals with other risks.

My favorite case of this tends to be around customers that present requirements for very sophisticated caching in order to circumvent real or perceived catastrophic disasters (complete loss of network connectivity to data sources, those data sources crashing, etc...).

What this tends to forget is that these underlying data sources are often used by many things. For example, if Active Directory goes down, can my users get to their workstations to login? If not, will they mind the fact that their web application can't login either? Similarly, if the database attached to my ERP system goes down and I can't pull their ERP roles, won't the impact of ERP being down be the element that I should be fixing, given that it will impact my company's overall ability to conduct business?

These are just a few examples. There are many more. Other personal favorites would include project delays and complications caused by over-active schema design and planning processes, connectivity to obscure systems that aren't actually core to the business, solving unrealistic and arbitrary latency "issues", etc...

I've mentioned the caching thing several times. Another popular one there is the idea that identities need to be cached for performance. Let's think about this:

1. Your underlying directory will support thousands of requests per second
2. Any good database supports that same neighborhood of selects per second
3. Most databases, directories, and web services have ways of being made highly available if they contain important data
4. Actions such as termination require rapid removal of privileges
5. There is no standard way of detecting changes (for #4) from arbitrary databases and web services that wouldn't require additional complexity.
6. You're probably using #1 and #2 for other, business critical things

Looking at the above, caching is about like buying a personal fire truck. You're adding a lot of complexity for a problem that may not even exist.

Technorati Tags: directory, identity management, LDAP, virtual directory, irrationality