Earl Perkins

A member of the Gartner Blog Network

Earl Perkins
Research VP
3 years at Gartner
32 years IT industry

Earl Perkins is a research vice president in the Security and Privacy team at Gartner. His focus areas include identity and access management (IAM), including user provisioning, role life cycle management… Read Full Bio

Coverage Areas:

Hiding “the Big Nasty” in IAM

by Earl Perkins  |  July 22, 2011  |  2 Comments

On the list of major annoyances for me are the trite media “sound bites” that you often here on television or online, mostly by politicians, where they attempt to get their idea across in 5 seconds or less with a memorable turn of words. These phrases are decidedly unable to articulate the nature of the problem or the solution, but they sound great and make the speaker appear (emphasis on appear) intelligent. They do very little to advance the debate on issues, and in fact they often obscure complex issues that resist trite and easy answers. In other words, they hide ‘the big nasty’.

In case you haven’t noticed, I’ve just stooped to the very level that annoys me: I’ve created my own flippant phrase for a complex issue. In identity and access management, there are some complex technologies, processes, and skills that are used to fulfill IAM’s mission. The complexity is often in three major areas: the user experience, the workflow experience, and the connectivity experience. Any, some, or all of these could be considered big nasties, because they require much effort to plan, build, and operate for the enterprise. However, rather than considering the act of hiding these nasties as a bad thing, I submit that hiding the big nasty in IAM can actually be a good thing, not an annoyance. In fact, it is the one of the most critical steps that IAM vendors and service providers can take today to confirm that the discipline is maturing.

Hiding the big nasty in IAM has two dimensions. The first aim is to educate. For many years, we’ve attempted to define IAM for the enterprise in technology terms– we are always using geeky words to try and describe to executive management and others about what it is and why they need it, but the myriad blank stares and/or dozing in meetings when this occurs should be a clue that it isn’t working. We aren’t hiding the big nasty. Instead, we should be stepping back, looking at the big picture, and striking the balance between being accurate enough with our descriptions and good enough with our turn of phrase to bring the main concepts into focus for them. That ability is actually a job skill that should be required in IAM and security teams today. As much as the idea annoys me, we need a phrase-maker that gets complex, nasty concepts across quickly and effectively to the right audiences.

The second dimension in hiding the big nasty comes in the IAM solutions themselves, where the user experience itself is simplified to the point where skill set demands are reduced at ALL levels: the level that creates the user interfaces for business users, the level that develops workflow for automating process, and the level that designs and integrates IAM components across the IT software and service architecture. We need to hide the big nasty from all of them, so they can get their jobs done before most of us die of old age. That’s a job for IAM vendors and service providers. Consider harnessing all of that skill you have in marketing cures for IAM nirvana and spin them instead into product development and delivery.

Ok, maybe I’m getting a little carried away there (and am annoying in the process). But hiding the big nasty could go a long way toward building the credibility that IAM so desperately needs in a cynical buying world. The less nasty you see, the more successful you’ll be.

Oh no, a trite phrase arises, in rhyme no less. How annoying is that?

2 Comments »

Category: IAM     Tags:

2 responses so far ↓

  • 1 Paul Corriveau   July 27, 2011 at 11:00 am

    A good observation. I’m reminded that Amory Lovins of the Rocky Mountain Institute (http://www.rmi.org/rmi/) once said that as soon as he started talking dollars saved instead of BTU’s saved to executive management of industrial facilities, he had a wide-awake audience with clear eyes. In his case, there was an easy mapping from BTU’s to dollars. Electricity costs x, it takes y watts to power this light bulb, a watt costs n – do the math.

    IAM is much harder to quantify, and it’s not clear that we have a complete Rosetta stone to map the geek talk to the business. So while phrase-making might be a place to start, I’d much rather have a vocabulary that communicates the business value of IAM to executive management.

    Ok, one trite phrase deserves another:
    Talk this way and they’ll walk this way.

  • 2 Earl Perkins   July 28, 2011 at 8:25 am

    Paul,
    Thank you for your comments, I appreciate them. There are a number of vocabulary lexicons that have been invented over the years for communicating value of IAM, but I think the key issue is that IAM in a vacuum is difficult to justify in the traditional sense. Beyond creating efficiences, IAM business value alone hasn’t been realized by most. Where IAM can and does add business value is when it is combined with other security disciplines that provide context and viability to business decisions– disciplines such as data loss prevention and security information and event management, for example.
    When I speak to executives regarding IAM, I primarily use two major words in my lexicon: accountability and transparency. IAM provides business with the means to hold employees and others accountable for the access they have, management accountable for the access they approve, and administrators accountable for the systems they maintain. Transparency to know who really has access to what, who gave it to them, how they use it, etc. all come from the ability to have transparency into the IAM process. Without accountability and transparency, compliance cannot be really be achieved, and mitigating risk is much harder.
    These may also be considered trite phrases. But of such do business cases start.
    Take are.