The other day I was talking to an acquaintance who has been, not particularly enthusiastically, dragged into an identity project from her usual role of security architect. She said they were starting the project the way everyone does: by examining the onboarding process. “Such a bad place to start,” I heard myself blurting out, “……
Category: Best Practice
IAM Maturity and product selection
I have just completed a product selection exercise with a customer who has past experience of a failed solution with one of the Big Vendor products. In doing this I found it useful to refer to the Gartner IAM Maturity Model, because what is the use of fancy (/expensive) features if you don’t actually have…
Sources of Truth – again!
I’ve blogged about sources of truth, and specifically what makes a good one, before (in 2012 and again in 2016) but I’ve recently thought about an important feature of a SoT that I hadn’t included on my list before. So to recap, a good source of truth: is probably one of a number of sources…
Realms of Integration
This is a slightly updated picture from one I posted on twitter the other day. It’s an attempt to express my general view on high level “should be possible” integration conversations that get misunderstood as “clearly simple and straightforward and definitely happening”. In my mind I’m arguing against tightly-coupled integrations between disparate systems that do…
The perils of HR out-sourcing to an IAM solution
Over the years, I’ve been called in a few times when HR and/or payroll functions are being outsourced (or share-serviced, which is much the same thing), and this includes a migration to a new HR platform. Typically I have been brought in far too late in the proceedings when cost-cutting and service-simplification decisions have already…
Portrait of a MIM project
I recently deployed a MIM 2016 solution into Production that took about 10 months to build, test and deploy. I decided to take a look at the percentage of overall time spent on broad work categories in the whole project, and that’s what this post is about. First I had to get the data on…
IAM Design Principle: Good design is simple to explain
Let’s start with a statement that can be made about any design: good design makes sense, it is coherent, it is self-evident and doesn’t need a lot of explanation. While a simple IAM solution would be a fine thing, the reality is that we must deal with complexity in technical connectivity, data, business rules and…
IAM Design Principle: Handle Non-Standard in a Standard Way
The “ideal” IAM solution would have a reliable flow of pre-checked data and a list of sound, proven business rules from which to provision all the accounts and access each person needs to do their job. This is a fantasy. The types of work people do, and the IT landscape they do it in, are…
IAM Design Principle: Plan for data errors
Automation isn’t just about replicating an existing manual processes. Yes we want the same end results, but the process will have to be different because it’s a dumb computer doing it and not a human. Humans are really good at spotting patterns, including ones we’ve never seen before. A human operator will be able to…
IAM Design Principle: Use your IAM platform for IAM work
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…