FIM is all about data. It’s identity data, sure – but it’s still just data. And it needs to come from somewhere.
Typically we will have multiple sources of data coming into FIM, but as with everything, there are good and bad ways to manage this.
Good vs Bad data sources
Not all data sources are created equal. Ideally we want to get as close as possible to data that is maintained by the people who are most interested in its correctness. So for example:
- Employee information in the HR database,
- Cost Codes in the Purchasing system,
- Location details in the Asset Management system.
Data is entered haphazardly when there is no real penalty from it being wrong. Perhaps telephone numbers are put in AD as a convenience to users but if they’re wrong the phones don’t break, and they only get changed when someone complains. So here AD is a bad source for telephone number.
An object source is allowed to project a new object into the FIM Metaverse. It says “this object can exist as a unique identity in the IdM metadirectory”.
We should have only one object source per object category.
Note I’m not saying object type. It could be perfectly valid for person objects to be projected from HR and the Student Roster and the FIM Portal, being respectively Employees, Students and Contractors.
You get into trouble when the same identity can be projected from multiple sources. I have seen environments where people only show up in HR after they start work, so both AD and HR are declared as projection sources. This is a ludicrous design as you can’t guarantee reliable join criteria, and all you’ve done is made yourself a duplicates generator.
Again we should aim for one attribute source per attribute, per object category.
Say we have multiple email environments for different businesses within a conglomerate. Naturally each should be able to contribute email address – but only for people from that business.
While it’s possible to write all sorts of complex precedence rules it is usually a bad idea. You’re weakening your system to accommodate poor data practices and in the end, no one will thank you for it.
Clearly communicate the various data sources
People are going to have to get used to updating values “at the source”. If a user’s name is misspelt in the GAL there’s no point changing it in AD when FIM is updating the name from HR. It needs to be fixed in HR. This idea will take a while to filter through, but the good thing is, once FIM has changed a value back a few times, people usually get the idea.
Got something to add? Disagree? Comments are open!