The Identity Philosophers Song

With all due apologies to Monty Python and specifically Eric Idle here’s the identity industry’s version of the Philosophers Song. Many thanks to everyone who helped this effort and huge thanks to Eve Maler for all her work on this. What follows is meant with much love and respect to everyone in the industry (mentioned or not). And with that… maestro please: Jeremy Grant was a real pissant Who was very rarely stable iglazer, iglazer was a boozy beggar who could think you under the table Blakley whom could out-consume Madsen, Bradley, and Dingle Pat Patterson was a beery swine Who was just as schloshed as Cahill There’s nothing Wilton couldn’t teach ya’ Bout the raising of the wrist. Cameron himself was permanently pissed… George Fletcher, still, of his own free will, On half a pint of shandy was particularly ill. Nishant K could stick it away; Half a crate of whiskey every day. Patrick Harding, Patrick Harding was a bugger for white lightning Nash was fond of his dram, Really Dick Hardt was a drunken fart “I drink, therefore I am” Yes, Cameron himself is particularly missed; A lovely little thinker but a bugger when he’s pissed! And if none of that made sense to you, here’s the original which also might not make much sense either.

My 9 Step Process for Building a Presentation

“How do you build a presentation?” I’ve had the question asked of me a few times recently. And I’ve had enough flights recently to spend some time thinking about the answer. As I mentioned, before I could actually answer the question I had to write this other post about clarity and empathy. Go read that and then come back. With that as context, here is my stripped down process – my 9 essential steps to building a presentation.

No Person is an Island: How Relationships Make Things Better

(The basic text to my talk at Defragcon 2014. The slides I used are at the end of this post and if they don’t show up you can get them here.)

What have we done to manage people, their “things,” and how they interact with organizations?

The sad truth that we tried to treat the outside world of our customers and partners, like the inside world of employees. And we’ve done poorly at both. I mean, think about, “Treat your customers like you treat your employees” is rarely a winning strategy. If it was, just imagine the Successories you’d have to buy for your customers… on second thought, don’t do that. We started by storing people as rows in a database. Rows and rows of people. But treating people like just a row in a database is, essentially, sociopathic behavior. It ignores the reality that you, your organization, and the other person, group, or organization are connected. We made every row, every person an island – disconnected from ourselves. What else did we try? In the world of identity and access management we started storing people as nodes in an LDAP tree. We created an artificial hierarchy and stuff people, our customers, into it. Hierarchies and our love for them is the strange lovechild of Confucius and the military industrial complex. Putting people into these false hierarchies doesn’t help us delight our customers. And it doesn’t really help make management tasks any easier. We made every node, every person, an island – disconnected from ourselves. We tried other things realizing that those two left something to be desired. We tried roles. You have this role and we can treat you as such. You have that role and we should treat you like this. But how many people actually do what their job title says? How many people actually meaningful job titles? And whose customers come with job titles? So, needless to say, roles didn’t work as planned in most cases. We knew this wasn’t going to work. We’ve known since 1623. John Donne told us as much. And his words then are more relevant now than he could have possibly imagined then. Apologies to every English teacher I have ever had as I rework Donne’s words:

The Only Two Skills That Matter: Clarity of Communications and Empathy

I meant to write a post describing how I build presentations, but I realized that I can’t do that without writing this one first. I had the honor of working with Drue Reeves when I was at Burton and Gartner. Drue was my chief of research and as an agenda manager we worked closely in shaping what and how our teams would research. More importantly we got to define the kind of analysts we hired. We talked about all the kinds of skills an analyst should have. We’d list out all sorts of technical certifications, evidence of experience, and the like. But in the end, that list always reduced down to two things. If you have them, you can be successful in all your endeavors. The two most important skills someone needs to be successful in what they do are:

Finding your identity (content) at Dreamforce

Dreamforce is simply a force of nature (excuse the pun.) There are more sessions (1,400+) then you could possibly attend even if you clone yourself a few times over. And that’s not even including some amazing keynotes. Needless to say there’s a ton to occupy your time when you come join us.

The Salesforce Identity team has been putting together some awesome sessions. Interested in topics such as single sign-on for mobile applications, stronger authentication, or getting more out of Active Directory? You need to check out our sessions!

Do we have a round wheel yet? Part 2 of my musings on identity standards

Yesterday I talked about the state of identity standards with regards to authentication and authorization. Today I’ll cover attributes, user provisioning, and where we ought to go as an industry.

Attributes

The wheel of attributes is roundish. There are two parts to the attribute story: access and representation. We can access attributes… sorta. There’s no clear winner that is optimized for the modern web. We’ve got graph APIs, ADAP, and UserInfo Endpoints – not to mention proprietary APIs as well. Notice I added the constraint of “optimized for the modern web.” If remove that constraint, then we could say that access to attributes is a fully solved problem: LDAP. But we are going to need a protocol that enables workers in the modern web to access attributes… and LDAP ain’t it. As for a standardized representation, we have one. Name-value pairs. In fact, name-value pairs might be the new comma. And although NVP are ubiquitous, we don’t have a standard schema. What is the inetOrgPerson of a new generation? There is no inetOrgPerson for millennial developers to use. But does that even matter? We could take SCIM’s schema and decree it to be the standard. But we all know, that each of us would extend the hell out of it. Yes we started with a standard schema, but every service provider’s schema is nearly unique.

Do we have a round wheel yet? Musings on identity standards (Part 1)

Don’t want to read all of this? Check out the video:

Why do human continually seem to reinvent what they already have? Why is it that we take a reasonably functional thing and attempt to rebuild it and in doing so render that reasonably functional thing non-functional for a while? This is a pattern that is familiar. You have a working thing. You attempt to “fix” it and in doing so break it. You then properly fix it and get a slightly more functional thing in the end. Why is it that we reinvent the wheel? Because eventually, we get a round one. Anyone who has worked on technical standards, especially identity standards, recognizes this pattern. We build reasonably workable standards only to rebuild and recast them a few years later. We do this not because we develop some horrid allergy to angle brackets - an allergy that can only be calmed by mustache braces. This is not why we reinvent the wheel, why we revisit and rebuild our standards. Furthermore, revisiting and rebuilding standards isn’t simply a “make-work” affair for identity geeks. Nor is it an excuse to rack up frequent flyer miles.