* More reader comments on the Identity Bus topic addressed
Last week’s newsletter about the Identity Bus raised a number of issues in the Network World forums, some of which I addressed last newsletter. But there was another issue raised that deserves its own discussion.
The method I suggested of identifying employees who were hired in the past two years was called into question by a couple of readers. What I said was: “I will assume that the HR system assigns an employee number to each new hire and that these numbers are sequential using a known sequencing technique. … To find all employees hired in the last two years, I simply query the employee database for the one earliest record that is later than two years ago yesterday. I can retrieve this record and note the employee number. That number and all subsequent numbers represent all the employees hired in the past two years.”
A reader, identified as ‘mchiles,’ writes: “In the scenario you propose, I would suggest it breaks down under the condition where an employee separates from the company and is later rehired. If your system re-assigns the original identifier, that identifier can no longer be used as an indicator of when the employee was hired. Rather, it now indicates when the employee was first hired.” While an anonymous poster notes: “If someone works here, then leaves, then returns, they tend to get their original employee number. The number may have been issued more than 2 years ago, but the employee has not worked here for 2 years.”
That certainly would upset my assumption, as noted by reader Stuart Thompson, but he also said, “With respect to re-hire situations in some of the other posts, I think you will find that some auditors will have a field day with the re-use of old employee ID’s. From a compliance perspective this is a real can of worms.” I couldn’t agree more.
The re-use of identifiers (and the issue has been heatedly discussed by the OpenID community, for example) is at best a “can of worms” and frequently a source of security breaches, identity fraud and other criminal activity. It was just a year ago, in fact, that I addressed this issue in the newsletter (“Uniqueness, hotels and OpenID”).
But the re-use of an employee number to identify the same individual after a re-hire presents us with a dilemma. On the one hand, we’d like the same identifier to indicate one and only one entity while also reflecting all activity by that entity. On the other hand, we’d like each “new” hire (and that includes re-hires) to start with a fresh identifier. For example, a re-hire would have training records attached to their old identifier. But if the training has changed then they should be required to re-train, also. Only a new, unique identifier could indicate this automatically. Still, if a regulatory agency wished to see all activity by a particular individual, then there should be a way to link all of that individual’s activities – spanning all hiring periods – efficiently and automatically. So what’s the answer?
The correct answer is to re-design the system. I know, that’s easier said than done. But the problems associated with re-hires appear to be widespread enough so that a “best practice” method of dealing with them should be written. We’ll start on that in the next issue.
