CQ2

Gartner’s ‘magic quadrant’ ranking of vendors shouldn’t matter as much as it does, but it does.  So it’s good news that the new MQ (as, I think, previous ones) for user provisioning puts Novell’s Identity Manager product in the leader’s quadrant.

To me, the question of vendor choices in provisioning pivots crucially around experience.  If I was in the market for an identity solution, the key question I would ask, and probe on, would be the total number of actual like-sized deployments in production today.  Not sales, not roadmap, not ten-person deployments, but real enterprise-class (or whatever size you are) deployments.  In other words, yes, the technology works but who is actually using it?

Burton, Gartner’s specialist identity competitor, wrote a paper recently (I don’t have it at hand; I’m working from notes) about the provisioning market and the number of actual enterprise customers.  They surveyed the vendors and found that there were, in my analysis of their analysis, four tiers:

(1)  Novell and Microsoft each claim thousands of customers.  I would say that there is a definition issue here, because Microsoft, due to their ubiquity on the desktop, is always going to be a major player in this market, but that their offerings are not nearly as robust as the other vendors.  But, you know, I’m biased.

(2)  IBM, Oracle,  Sun, and each claim several hundred.  IBM — Tivoli, really — is a strong competitor.  Oracle is being Oracle, very aggressive, although it’s not clear that their products work nearly as well as their roadmap.  They have significant integration issues to overcome, but they certainly have a seat at the table, especially since it’s hard even for most IT people to distinguish between a relational database and a directory.  I would say that Sun, for whatever reason, has in the past year or two fallen off of its game in this market and is less aggressive than in the past.  Maybe it’s the departure of the Waveset management, maybe it’s a change in focus; I don’t know.

(3)  BMC and CA also claim ’several hundred’ deployments, although my experience doesn’t support that claim.  I’ve run into the second tier a lot in competitive situations, but not so much BMC and CA.  BMC has a compelling story to tell and Remedy is a big door opener for them, but I see them as perhaps a junior cousin.  HP, now out of the game, and Siemens each claim between one hundred and 250 customers. I never run into Siemens, possibly because their primary customer base is in Europe.  You could argue that tiers 2 & 3 ought to be combined, but that’s not the way that I see the market.

(4)  And then the rest — there are twenty vendors in the market according to Burton — each have something between fifty and one hundred customers.  Burton says that the actual number of deployments is probably half that, so a specialist vendor (less charitably, “a little guy with an idea”) probably has thirty or forty real deployments at actual customers.

Well, here’s one way not to do it:

In reply to: How do you secure sensitive data on your computer? by Marc Bennet

I require a password to access my computer, but to top that off, I try not to store any sensetive [sic] data on my computer. Lists of passwords however, I HAVE to store on my computer, and what I do, is I encrypt them. The simplest way to encrypt something is to type it up in word, then take a screenshot of it, and save the PICTURE as an unknown filename, then of course, you put that in a password protected .zip file.

That password protected zip file really isn’t secure, but the sheer inconvenience of this awkward security-through-obscurity method is what makes it so remarkable: a screenshot of a Word document!

Back in May, Facebook announced Facebook Connect, an authentication API that allows you to use your Facebook credentials on other sites.  And not just to log in; you can also take your Facebook information — trusted friends and privacy settings and the like — with you from site to site.  I thought that was fine and all, but I don’t use Facebook much so I didn’t really give it much more thought; it’s just another identity federation effort, plenty more where that came from.

But Dick Hardt recently pointed out that Facebook has a competitive advantage in the business of authentication:

The killer feature though is something that will be hard for other potential platforms to do. Facebook strives to only have real identities. In the participatory web, the enemy has been the lack of accountability. Trolls pollute the conversation,  spammers fill the web with garbage, and promoters try to game the system. Facebook kills off accounts that are not real people.

Even though he’s an advocate for OpenID, which I’ve seen gaining traction in the web world if not in the enterprise, Hardt thinks that this Facebook Connect poses a real challenge; things like OpenID won’t go away, but may be relegated to the early adopter geek fringe.

Via Valleywag, news that IBM has opened up their corporate whitepages to the Internets, a huge step. Valleywag’s telling headline: “IBM employee directory mocks your company’s lameness.” But, perhaps, like IBM’s other progressive HR policies, this one will point the way for others.

The old Thai capital of Ayutthaya was a fantastically cosmopolitan place in the seventeenth century. Among others, there were French, Dutch, Portuguese, Spanish, Japanese, and Persian colonies living around the city. The Japanese residents alone included ronin, traders, and Japanese Christian refugees. (The photo above is of Japanese mercenaries in the service of the Thai king — note the elephants and the rising sun flag.)

As you might imagine, the characters that wound up in seventeenth-century Ayutthaya were not exactly run of the mill personalities. There was then apparently a job title of “adventurer,” along the lines of the Man Who Would be King: see, for example, Filipe de Brito de Nicote, the Portuguese adventurer in the nearby Arakan coast of Burma, or the unappealing Bastian Gonsalves, aka Sebastian Gonzales Tibao or Sebastian Gonslaves Tibeau. The chaotic history of the failed Portuguese colonization of Chittagong and Sandwip Island (modern Bangladesh) and Arakan is still waiting for a movie.

One of these adventurers was the Greek Constantine Phaulkon who became, briefly, an important character in late 17th century Ayutthaya and married Maria Pina de Guimar, a Luso-Japanese (presumably Catholic) mestizo.

Could you get a more obscure ethnic designation than “Luso-Japanese mestizo”? Only in Ayutthaya.

Or Macao; but that’s another story.

I can still remember how I felt when I first read Hugh Trevor-Roper’s essay, “The Invention of Tradition: The Highland Tradition of Scotland,” the mix of dizzy excitement at the utterly complete debunking of an idea that I thought was real and the thrill of a great story with fantastic(al) characters, all in the calm cool prose of a professional historian writing in full stride.

In 25 pages Trevor-Roper explains that what we think of as Scottish — “real Scotland,” the highlands that were never pacified by the British, that of kilts and bagpipes and clan tartans and all the rest — is a retrospective romantic invention. The Scottish hinterlands were actually an Irish colony, but after the union with England, as a sort of protest, the Scots invented the culture of the Highlands and invested it with the aura of antiquity. Tartans? Invented in 1842 by the awesome Allen brothers, who deserve a movie or something. Kilts? Invented in 1730 by an English Quaker from Lancashire, Thomas Rawlinson. Bagpipes ought to be harps. And the whole fraud of Ireland as colony of Scotland rather than the inverse is the product of two unrelated Macphersons, James and Rev. John.

The essay is in an edited volume by Hobsbawm and Ranger likewise entitled The Invention of Tradition. Highly recommended.

Great posting, and better discussion, on naming conventions around the world, with implications for identity systems, and much else besides.  How do you sort a global address book for a company with employees in the US, Spain, Germany, Thailand, and other countries with different ideas about what constitutes a “last name”?

Data quality is a constant issue in identity solutions.  Usually, this is what happens:  we tell the client that they need to clean up their identity data before we start doing any integration work.  They assure us that this will happen.  We have been burned by this in the past, so we write it into the contract language to try and protect ourselves.  Doesn’t matter: the data cleansing project is so unsexy that it never comes to the top of the priority pile and so it doesn’t get done.  The identity integration, the pipework, is complete before the data, the water that’s supposed to flow through the pipes, is clean.  The client sponsor is furious that the identity work isn’t complete, but it’s a data quality issue and so there’s a delay at the end of the project while data cleansing happens.

Almost every organization I’ve ever looked at has bad identity data.  Even if you go through a data cleansing process, over time the quality will decay.  Based on anecdotal evidence, I think it’s around three or four years to get to the point where you have to do another data cleansing exercise.  For an organization with a relatively static employee base, it might be at the longer (four year) end of that range; for a dynamic business with lots of hires/fires, acquisitions/divestitures, and the like, probably less than three years.

For example, we recently did a simple integration of a file directory with an HR database.  We were able to automatically match with confidence 60% of the accounts in the file directory with actual people.  (Actually, it was 56%; 4% were service accounts that don’t map to people.)  The remaining 40% required some level of manual intervention: 12% were possible matches that needed to be reviewed manually.  Another 8% simply didn’t have enough information to make a judgement on.  And fully 20% were unmatched; we have good information on them but they don’t match people in the HR system.  At some point, after a manual review, those accounts will be closed down and we’ll listen for the complaints to figure out who they belong to.

Loyal readers will recall my tour through enterprise identity management deployments (overview here). This approach includes doing an upfront identity strategy (and here) followed by three stages of deployment: establish the core infrastructure, provision key systems, and enhance the infrastructure.

Enhancement includes adding additional systems, including the remaining identity stores and applications, into the existing identity infrastructure. Even if these systems are disconnected from the network, you can still integrate them through some sort of semi-automated provisioning process. Provisioning is, now that I mention it, a major piece of this stage; simplifying employee new hire on-boarding processes, for example, or introducing role-based access controls (RBAC) to automatically provision systems to people based on their roles.

RBAC is a large subject in of itself, so I’m not going to do it justice here; a few notes will have to suffice. One of the challenges of RBAC is to set up the right number of roles; too many or too few and you get no real advantage. At one extreme, you could say that everyone in the company is in the role of “employee” and gets the same basic provisioning package. But that doesn’t really help. At the other extreme, the map begins to resemble the territory and you can easily end up with as many roles as people. (In really extreme situation, you could have more roles than people; I’ve heard stories about that happening, but they’re probably apocryphal.)

There’s two approaches to defining roles; bottom-up and top-down. Bottom-up is more of a tool driven mechanical approach where you mine identity stores to generate patterns. Top-down is a manual process in which you systematically go through BUs or departments to select groupings. I think the best outcomes involve a mix of the two, meeting in the middle somewhere. The tools-driven approach is comprehensive but also tends to generate garbage that needs to be manually culled. And the top-down approach allows some organizational constructs that may not be obvious in the data.

Beyond RBAC, which is sort of the state-of-the-art today, you start to get into specialized identity management issues. These are the 400-level classes, independent studies and directed readings, if you’ll pardon the metaphor, for upper level undergraduates and grad students. Novell, for instance, does a lot of work with hospital chains and we’ve built a custom clinician workstation that uses identity management as its basis but extends it to optionally include CCOW context management, fast log-in/log-out, proximity cards, and so on.

After these deployment stages, though, you get into the actual management of the deployed systems, which is another challenge entirely. I think of this as ‘governance,’ but that’s a loaded fancy word that tends to raise hackles. So we’ll discuss that next.

(By the way, Ritual Coffee Roasters in the Mission rules. This was a macchiato-powered post.)

Connect key systems

Provision important systems, where “important” is a mix of financially and politically significant systems. Typically, this might include the ERP system (if it’s different than the HR system and especially the finance modules), help desk/trouble ticketing, call center, inventory control/supply chain, intranet or key web-based applications, custom developed database applications, and the physical security (i.e., badging). You want to come up with a list that covers 80% of what real people in the organization care about; this is surprisingly easy to do. The list, I mean; deployment is hard.

These don’t all need to be done at once and for all users, but –again — it’s important to think through the business rules that govern the identity infrastructure so that all the pieces are coordinated over time.

For example, the badging system might be a unique source of identity data with information about people (e.g., night cleaning crews) who have access to your buildings but are not otherwise represented in your IT systems. You probably don’t want to give them email accounts or access to your corporate financials, but that information might be very valuable for disaster planning so that you know who is in your offices at any given time and who, exactly, they are. In some instances, such as hospitals, there are so many employees in the ‘extended enterprise’ that aren’t directly on the payroll that the badging system becomes the source of authority for identity data.

Deploy basic provisioning and workflow

As you move beyond basic capabilities, the feature sets of identity management products start to become differentiated. But in the current state of affairs, most of the major vendors have at least some workflow and automated provisioning capabilities. With the infrastructure pieces in place, you can start to take advantage of these capabilities to do things like new hire provisioning and employee self-service.

These will have obvious end-user benefits (”obvious” in the sense of visible, if not quantifiable) but motivating factor is often de-provisioning. That is, the ability to rapidly — instantly — turn off an employee’s access to those key systems such as payroll or badging when they leave the company. It’s what’s politely described as “zero day stop.” It can be brutally effective; by the time the now ex-employee leaves the conference room after their conversation with their manager, they can no longer access their email account or the corporate intranet or, sometimes, the phone extension on their desk. And it scales! Mass layoffs made easy!

Less ghoulishly, you also get tremendous reductions in help desk calls for password resets and routine requests for changes to information. You might not want to grant all of those requests (allowing users to change job_title often leads to entertaining results and I’ve heard of instances where people change their phone number in their record to a colleague’s number, in order to avoid work), but you can add a manual approvals step to the process to minimize those impacts.