I’ve blogged about sources of truth, and specifically what makes a good one, before (in 2012 and again in 2016) but I’ve recently thought about an important feature of a SoT that I hadn’t included on my list before.
So to recap, a good source of truth:
- is probably one of a number of sources you’re using, but preferably the only one for this particular type of data,
- is a place where this type of data is well managed because stuff breaks if it isn’t,
- has appropriate processes to correct the data if it’s wrong,
- enforces data quality through selection mechanisms rather than free text.
Today I’m adding a new one to this list. An essential feature of a source of truth for an IAM solution:
- is a data store I can query at any time for the current state of the data.
This last one is what makes a service ticketing system a generally poor source of data for identity automation. I was having this conversation with someone recently and he had a good analogy – it’s like if the only way you could get your current bank balance was by going back over all your transactions since the last time you checked. Only it’s worse than that because we’d also be dealing with free text, and mistakes in the request that got sorted out with a phone call, and access granted on the side because the user knew how to call directly, so it’s unlikely we could even construct that current state by going through the history.
A ticketing system is fine and essential for all sorts of requestable stuff, but as far as IAM automation is concerned it’s only good if the end result of the ticket is someone updating the data in the static data source we use for our actual SoT.