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.