Roles - What 'bout it?

Disclaimer - I have not worked on role-mining project and so most of the views expressed here are based on very limited understanding, a lot of arm chair thinking and some understanding of access management. I may be slightly biased against the role-management because I seem the end goal as Access Management and not role management and so far I have not had the "aha" moment for Role Management.

Coming from fine-grained access management background, I have always considered roles as a means to achieve the end goal of access management. Roles to me are an abstraction that we use to separate the policy modeling phase (roles being used to design policy model) and policy management phase (by managing user to role assignment).
But a lot of people do see the roles themselves as something important that need to be "mined" out of privileges. This could be, to some extent, a result of role-centric security model  pushed by J2EE specification in past (and now through SCA Policy Framework) and the developers being comfortable with such models which tried to build a simple security model built around the idea of Is User In Role. Even though this works for most of the simplistic use-cases, some of the security model are more complex and that may warrants the need for XACML profile for J2EE to express the security policy to be enforced. 

But there is another dimension to this whole discussion. There is a neat idea of  Business Role and IT Role (equivalent to Basic Roles in NIST RBAC?) that seems to be gaining ground. The business roles are typically something that are defined by the Business/Organization (like Vice President, Teller, Trader, Foreman, etc) and IT Roles are defined by the application (like admin, user, auditor, etc). Most of the time it is expected that mapping the business roles to IT Roles would simplify the policy modeling and management. This could be a good justification for finding business roles (probably using top-down approach) and "mining" IT Roles (probably using bottom-up approach), if not already present, and mapping the two. So the problem of managing all the user-role relationships can be reduced to controlling user assignment to Business Roles which is something that is already in place in form of HR systems in many enterprise (Again it is probably already showing why I should not talk about things I do not have experience with and so feel free to correct my understanding)
Even though this approach looks great on paper, I am not sure how effective it is. In the few domains that I have worked, most of the business roles are contextual (for example - trader on a desk, teller at a bank branch). I have always thought that some of domains like manufacturing and retailing were closer to a standard role based entitlement model because of very well defined processes and role. But thinking more about it, even those may have nuances like supervisor of a specific shop. Similarly most of the IT roles are also context based. For example an admin role in a account management application would probably be given on specific accounts.
At the same time there are definitely applications ( for example any vice president can approve expense report ; show the admin menu only to an administrator) that can be fulfilled by generic roles.
Ultimately the use of NIST RBAC in an application boils down to how complex the role context is within the domain. In case the context is simple enough, it can addressed by building it in to roles so that you may have na_sales_mgr, emea_sales_mgr and so on. But most of us already know that such hacks, if not controlled, can become a recipe for role explosion and would ensure that you need a role management product.
The complexity of the context itself can make the role almost a secondary concept. For example let's take a case of a consulting firm working on large project. Such a project may have separate teams of developers, architects, infra guys spread over multiple geographical locations. Now such a scenario may be uncommon in IT consulting but I think some thing similar would be case in a auditing or investment banking where some of the multi-national M&A deals and company auditing take place. In the example earlier let's say the employee John Doe is assigned role DBA for the developer teams in New york and Seattle for the project Big Bang and Backup DBA for the architect teams in Europe (located in London and Paris) for the project Solve World Hunger. In this example the role itself is such a tiny part of the possible complex context structure (Location hierarchy, teams, etc). Now there may not be that many examples out there with such complexity at the context but at the same time such examples help keeping things in perspective.

To summarize I think we need to be clear about what is the problem we are trying to solve before starting on the role management path. If the end goal is access management then NIST RBAC should be looked at just one of the ways of policy modeling. But if the goal is to get the organizational hierarchy in control, then using a role mining tool to get some roles that are meaningless to business may not be right way to proceed and instead appropriate process must be defined and implemented for organizational hierarchy leaving the IT Roles out of scope.