Through the looking glass

by Deborah Volk on March 25th, 2009

One of the key benefits of an identity management solution is the ability to collect data from various systems and use this data to establish relationships between owners (the official term is entities - users, groups, organizations) and things they own. Presuming this magic summary would be shown in a user-friendly format such that a person in a reviewer role (IT auditor, someone's manager, Homer Simpson) can get a cohesive view of the user, we're one step closer to truth. The aggregated set of entities and relationships is a foundation for how such a system might be used to meet compliance needs by answering questions of "who has what " and "how did they get it" nature. Some might even use the term business driver but our blog software filters this out based on an unauthorized autobiography context. (Information Cards, here I come!)

So you've got this wonderful set of data that you presumably give to an auditor in a form of a report...but how much of it is real? There can be an alternate world behind that mirror!
I have had some interesting discussions about getting the representation of the user to be 1) meaningful and 2) accurate.

Let's look at the first part of this. In order to be meaningful you have to understand what people want to see. Just as a rear view mirror in a car is very useful to the driver, to the passenger, they cannot accomplish much with what they see staring back at them. This is where solutions such as data virtualization, business intelligence, or even present-day whiz-bang tech such as mashups could add a lot of value on top of an IDM infrastructure. (Watch our site and this blog for updates about Identigral Labs and our experiments with these technologies). If your IDM reports or dashboard is showing you the rear-view image and you really need the side mirror image, you will have an issue getting the full value out of the system. Some might say, well, just dump the data into a reporting tool and report away. Some bolder ones might even claim that these reports are so friendly they can be manipulated on the fly, drilled down, etc. I beg to differ. This is not a reporting problem, it's a knowledge representation problem that needs a different approach, one that's centered on knowledge, context and semantic rules rather than data and tables. How do I express in SQL what mirror do I need to look at to see who's behind my car if I don't even know what I am looking for.

The second part is accuracy. Since the IDM infrastructure is both the compiler of identities as well as (often) the generator of identities, we could potentially end up with a Hawthorne effect, an old Jedi mind trick that's a version of self-fulfilling prophecy. You are going to be looking at a screen, be it a web page or a report, and you're going to be saying to yourself "This data is right, it has to be right" but how do you really know? Unless you went to individual source and target systems and double-checked yourself, there's no way to tell and that's where accuracy comes in. You don't know the accuracy of represented information unless you've compared the measured value (what's in the IDM system) to the true value (what's in the source or target system) and the comparison was done in an unbiased fashion with an acceptable error rate.

Depending on the requirement for accuracy, data quality products such as DataFlux, Informatica, Trillium (resold by Oracle in Data Integration suite) can be brought to bear on this problem but then we're getting into statistical analysis and who likes that in ye olde IT shop? The phrase standard deviation is probably interpreted as something out of a psych ward manual.

Always conduct a sanity check when looking at a report. Trust but verify!


Posted in Identity Management, Data Quality    Tagged with data quality, accuracy, mashup, semantics


0 Comments


Leave a Comment
Search

Subscribe

follow on

2012 (1)
2011 (2)
2010 (2)
2009 (64)
March (11)
April (18)
May (18)
June (4)
July (1)
August (1)
September (5)
October (5)
December (1)