* Another look at the issue of re-using identifiers and re-using employee ID numbers
Sometimes a clarification succeeds only in further muddying the waters. That’s what I did last week, not for the first time either. Probably won’t be the last, though. It’s concerning that issue of re-using identifiers and re-using employee ID numbers. At the risk of further muddying things, let’s take a final look (for now) at the issues.
I think we can all agree that re-using an identifier so that it could possibly point to two different entities is a bad idea. This is the issue that riled the OpenID community, and continues to smolder beneath the surface, bubbling over from time to time.
The issue we were discussing, though, was the use of the same identifier for an employee who leaves an organization and then returns. The alternative is to issue a second (or subsequent) identifier each time the employee is re-hired. This could mean a single entity with multiple identifiers.
Those are two different issues.
It’s the employee with multiple identifiers that I was trying to address, and the OpenID problem (of a single identifier for multiple entities) was really a red herring dragged across our path to discovering a solution.
As a number of you pointed out – and as I overlooked – even in the enterprise an entity will have multiple identifiers depending on the number of namespaces (HR, Finance, IT, applications, etc.) they are involved in. You can choose one as the enterprise-wide identifier, but be sure to think it through so it is unique.
Since there are legitimate reasons why some namespaces must tie together all instances of an entity (whether those instances have different identifiers or different time frames) there should be an identifier which uniquely identifies each entity over time. For example, even after someone has terminated their employment it is often necessary to keep their identifier tied to various documents as originator, contributor, editor, modifier, etc. for regulatory or compliance reasons. On the other hand, there may be legitimate reasons to be able to isolate the particular employment cycle of the entity who has more than one such cycle.
The answer, of course, is remarkably simple. So simple that I completely overlooked it when talking about using the employee ID number to indicate hire date. The answer? Don’t do it! Don’t use an identifier designed for one purpose to fill another unless you can be absolutely sure that no anomalies will arise – and build in error trapping in anticipation of the day that the anomaly occurs.
In the case that led to this long discussion, a better solution would be to create a new, calculated field in the virtual or meta datastore that the application was using. This would concatenate the employee ID and the most recent start date. Then, based on start date you could easily extract the employee IDs of those hired within the past two years. A little further calculation could eliminate the re-hires and only look at those employees hired for the first time in the past two years.
Now I know there’ll be further discussion about this, but let’s have it on the Network World forums, because a lot happened this week at the Catalyst Conference and that will take up the next few newsletters.
