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 processes, 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 the…

IAM Design Principle: Separate form from function

When collecting requirements for an IAM solution we associate actions with various ways of categorising users – in other words, we are mapping “form” to “function”. When designing the IAM Solution, however, we need to provide a layer of separation between the two. The best way to illustrate why is with a real-life example.