Gartner Blog Network

Role and Entitlement Management Again Already– What’s the Difference?

by Earl Perkins  |  December 23, 2009  |  2 Comments

 Season’s Greetings to readers– I hope this ramble finds all of you safe and healthy for the holiday season. Let me start by making an apology– there will be a lot of  phrases in quotes below (“like this”) since one of the main topics of discussion is word usage to describe things, so be warned. I welcome any responses regarding this rambling on what remains a confusing topic for many of Gartner’s clients.

So, let’s get right to it. Entitlement management needs a new name, and role management too for that matter. “Management” is too broad to denote useful differences for customers, since management can mean anything from the administration of entitlements to the enforcement or resolution of them. Think of it as a “plan, build, and run” discussion, as is often the case in IT. The “run” part of a lifecycle is most often associated with management, but there are planning and building aspects to entitlements as well that are often classified as “managing” the entitlement. So is this merely an argument about the use of certain terms, or is there a reason for all of this?

Well, yes. The market itself for managing entitlements has existed for some time now, and understanding that market and what vendors offer in it is vital to knowing where those offerings may fit in IT for the enterprise. Whether we like it or not, vendors have created market definitions of entitlement management, and we need to correlate this with the more academic discussion of entitlements to know what kind of design and process is to be used in the enterprise for “managing” entitlements.

Today many would agree there is a market for role management solutions and a market for entitlement management solutions. Are they the same market? No. Do they address related issues? Yes. Role management solutions as we understand them today could actually be classified as “entitlement engineering and administration solutions”, but it’s too long to put on a product box.

Role management solutions provide a means to understand and design your entitlement situation in the enterprise—what applications have what entitlements, how those entitlements might be assigned to the appropriate people when they wish access to those applications. Role management provides an environment to allow you to “discover” what you have in the form of entitlements and to associate them with some kind of construct (call it a role) so it’s easier to manage the administrative task of assigning them to the right people. There’s still some debate in the industry whether the role is actually the best way to do that assignment and administration, but right now it’s the primary method we use.

 Entitlement management solutions are mainly “entitlement resolution and enforcement” solutions. This is a bit trickier, since some of those solutions have some basic role management capability, or at least basic entitlement administration capability. But the heart of entitlement management is a processor for entitlements, i.e. they receive an entitlement request, process it, make a decision, and either allow access to occur or not. In many instances entitlement management solutions are self-contained software “engines” that receive access requests, process them, and produce a result on behalf of the application, platform, or service.

 In entitlement management solutions, you’ll hear much discussion about access policy, or the structured rules that guide how entitlements are resolved and enforced. Role management solutions are also guided by the business and technical access policies defined to ensure that the roles are structured to reflect that policy and the entitlements are assigned to also reflect policy requirements. This is something both role and entitlement management share. Entitlement management functions today are buried within the applications themselves, i.e. the application does the entitlement request processing itself in its own unique and proprietary way. Entitlement management solutions propose that as much of this as possible be externalized for “management’s” sake. This is an issue for older applications, since it is what it is and you’re not going to go ripping up code just to externalize a function like entitlements processing. This is mainly a developer concern for newer applications and services, regrettably. It is one reason why the market for these solutions is still quite small, with only the brave at heart (and strong of need) tackle the issue.

That’s my view of this world. One is primarily a preparation and administration function set (role management), the other is primarily a processing and results function set. They have different audiences when it comes to the “run” part of the lifecycle, but share many “plan and build” concerns. Maybe it’s time they were given new names, perhaps under the umbrella of “entitlement lifecycle management”. And no, please don’t make another acronym—just spell it out.


Earl Perkins
Research VP
5 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

Thoughts on Role and Entitlement Management Again Already– What’s the Difference?

  1. David Kearns says:

    We should speak about “role-based access”, since this is the major point of having roles. Whether or not that gets to the fine-grained level of entitlements (as opposed to gross-grained levels such as folders and applications) is a different story.

    If we then subsume “entitlement mgmt” under “access mgmt” we can more easily demonstrate the differences.

  2. Earl Perkins says:

    I agree, David. i’m particularly interested in putting entitlement management in the functional access category to differentiate it from the administrative nature of role management– even though they both have entitlements as their core, atomic element.

Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.