Integration between IT systemsÂ is hard, even when they support common standards, so I understand this desire for a service tool that does “everything”. IAM software platforms are typically extensible in various ways such as scripting, custom schema and custom workflows, so it may well be that you can do something a bit out of the ordinary, butÂ should you? Software is developed with certain uses in mind and trying to force it into some other shapeÂ is rarely good for the on-going effectiveness and maintainability of the solution.
Some “un-natural” things I’ve seen people try to do with theirÂ IAM solution:Â handling service tickets, service catalog, access audit in external systems, asset management, general purpose ETL and orchestration, non-IAM aspects of application administration.
These efforts always come from a need to simplify IT – so many products, difficult integration (even between products from the same vendor), scattered and inconsistent logging – it is way too complex and expensive to maintain, soÂ the “one product that does everything” pipe dream lives on. Meanwhile IAM platforms are, and have to be, extensible to meet the never-ending variety of target systems and business processes we encounter. It is tempting to say “sure we can write some code/scripts/workflows/custom user interfaces to do that” … but should we?
I’m a big believer in “playing to each product’s strengths”. If a product is designed to facilitate any type of user request then that is what itÂ should be used for. The IAM platform will have been designed primarily to perform provisioning and access management based on authoratative source data, so let it do what it’s good at.
The real problems here, in my mind, are poor integration leading to disjointed processes and audit trail – but things are improving. Splunk has become so popular because of the way it can ingestÂ logs in all sorts of formats from a multitude of sources and produce dashboards and reports that help join the dots; application vendors are finally gettingÂ on-board with authentication and integration standards; and Enterprise Servce Bus technology can be deployed to smooth the back-end integrations. I’m hopeful that this is the future and I can stick to building IAM solutions based on what the platform product was designed to do.