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 Service 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.
It is a good debate Carol. Should or can IAM fulfil CIO’s dream of having a one stop shop tool that does it all. Look at SCCM and the titanic reputation that it has. Look at ServiceNow. These products have a reputation of inflexibility or difficult to customize, well you can’t have it all, if you are a jack of all trades then you cannot give the kind of fine antique furniture that the trademan specialized in furniture can do.
I have had to customize MIM to do Server management, creating OUs and other tasks which it was not designed for and it broke easily. Keep IDM products to what it was designed for else its really a waste of time.
But still we should be able to build an identity profile for the user such that one is able to report on what the user has access to or what are the resources associated with the user