I’ve recently started a new project and we’re in the requirements gathering phase, so lots of meetings and discussions, and also (thankfully) enthusiasm for the project.
There’s also been lots of me repeating stuff I always say when trying to explain Good IAM Design, so I’ve decided to start a new series of short blog posts on the subject. There will be some overlap with an earlier series I did on FIM Best Practises, but I’ll be keeping this one product independent.
On IAM projects there is always a lot of talk about “source of truth”, along with a varying interpretations about what this actually means. My response is that “the source of truth is where people care about the data being right”, and then we aim to get as close to that data source as possible. I’ve written on this subject before: FIM Best Practice: Use the best Data Sources
However now I’d like to add an extra clause that “people care about the data when something breaks if it’s wrong”.
In recent years I’ve worked with a few organisations who have taken this whole Source of Truth thing too far, in that they have attempted to declare One Source to Rule Them All. I have seen the HR system made “authoratative” for what sort of user accounts people get, for application assignment, even for email address. Because HR systems are typically not designed for these applications strange and murky processes get built up on the HR side, as a way of sending smoke signals to the IAM solution. It’s complex and prone to human error – and the worst thing is, HR people don’t (and shouldn’t really have to) care. If they perform these mystical IT-directed rites incorrectly nothing breaks for them. The processes they actually do care about (like people getting paid) work just fine.
So I’m extending the scope of this particular IAM Design principal:
The Source of Truth is where people care about the data being right, and bad stuff happens if it’s wrong, and they can fix it!
