After beginning to learn about the auditing that "comes with" IDM 4.x,
I'm starting to see some disadvantages...

Just looking to bounce some ideas around about design principles...

- It seems to require a set of Linux servers to run (and everything
else we use is on windows)
- It seems to also need postgresql...and we (I) would prefer MSSQL as
we have a DBA team
- it was "kind of" set up at my company, but the server has been lost
to us while it was in testing (before my time on this system) so we
are "starting over" and have NO audit trail for our IDM system

So...since my past programming experience has been with MSSQL, Linq, and
WCF, I'm trying hard to understand why I wouldn't just create a SOAP
driver to with a filter to listen to all property changes i care about
(much like the data collection service driver) and pump them into a WCF
(windows communication foundation) web service which in turn drops them
into a MSSQL back-end. I had also considered other cutting-edge stuff
like RavenDB as a possible back-end. That way, i can fine-tune our
auditing, utilize our internal reporting team (i.e. crystal reports) and
existing MSSQL infrastructure (i.e. DR, backup, and internal skill

On one hand, I think this would be "better" for our environment since
our auditing needs are really simple - i want to produce a list of what
changed for a user (i.e. property name, property value, date of change).
We don't really use lots workflows (and don't plan to). Virtually all
entitlements are granted manually via userApplication by our access
admin team - meaning we don't have approvals flying off to managers and
group owners in IDM - we have another system for that.

Based on your experience - what would i be "missing out on" if i create
my own audit platform as described?

Let me know if you think this idea is totally ridiculous as well!

Thanks for any/all feedback.

choponis's Profile:
View this thread: