I returned from Gartner IAM Wednesday night, having survived the swamps of Orlando and another industry event with only minor scars to nurse.  The event was held at the Gaylord Palms, which was effectively a massive bio dome; I only stepped outside of the compound twice during my stay.  Now that I'm back, it's time to reflect on a couple of things I learned at the Gartner event.

First, I learned that there are still a great deal of organizations out there just starting their identity journeys.  I'm still not sure what was different about Gartner versus some of the other industry events this year, but I spoke with a lot of people who are just now starting to look at provisioning, role management, single sign-on, and even directory implementations.  This is especially true in the financial services industry where M&A activity has increased due to the current economic environment.

The other thing I learned is that people are still trying to understand how roles can be used in their organizations, and where roles may or may not fit into their current identity projects.  Earl Perkins had a session at the event on roles and entitlements management where he made the distinction between IT roles and business roles.  I think this is an important distinction, and helps to explain where we're going with roles and how they can simplify both the provisioning and auditing processes.  The use case I find myself explaining most often is how roles can greatly simplify the process of onboarding a new employee.  Part of approving a new employee's access often involves a business unit manager who doesn't speak "IT."  In other words, this business unit manager isn't going to know or care what AD groups his employees belong to, or whether they need access to the mainframe; however, he is going to know the appropriate job title and function for his employees.  By using business roles to determine and assign access, it's no longer necessary for the business unit manager to understand access described in terms of raw IT entitlements, such is typically the case with what Earl and we call IT roles.

The distinction between business and IT roles again becomes important in the context of an auditing use case, specifically when doing an attestation or recertification.  Again, let's go back to the business unit manager that doesn't speak "IT."  Is it easier for this manager to understand access described in terms of raw IT entitlements (IT roles), or in terms of job title or job function (business roles)?  The obvious answer is the latter. 

The reason I like Earl's distinction between IT and business roles is because Sun Identity Manager also makes this distinction in its approach to role based provisioning.  We've had IT roles for some time, and we added support for business roles in our last release (8.0 which was released in June).  You can download 8.0 here

Comments:

I would bet that the third lesson learned was to "check" folks at the door before inviting them into a party!

Nice post!

Posted by Nicholas Crown on December 01, 2008 at 12:28 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

This blog copyright 2009 by Craig McDonald