Category Archives: identity

The Invention of Tradition

Posted on by

The Allen Brothers (Raeburn)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.

Data: A dirty secret

Posted on by

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.

Enterprise identity strategy: 3. Enhance

Posted on by

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.)

Enterprise identity strategy: 2. Provision key systems

Posted on by

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.