A New Approach to Roles & Entitlements in Software Systems

Traditional Roles

Typically roles have to do with access to screens.

There are countless examples of apps that allow the setting up of permissions through groups, and groups with groups having access to screens:

Person -> Group (with permissions) -> screen

S1 EP works this way, and the merging of BB and PB based on entitlements is based on the assumption that there's a gradient from limited to full access that can be defined solely on screen, tab, or field access.

New Way

My concept is to have predefined "experiences" not screens.

In a loan app for example a borrower should have an entirely different experience than a lender rep.

I posture that the "experience" is much more than access selected from a universal superset.

Another way to say this is that not all experiences are subsets of other experiences -- parts maybe but not all.

The traditional view of entitlements might be expressed in graphic form as a series of circles within one large circle. The large circle represents the "complete user experience", i.e. all functionality available in the system. The other circles represent subsets of that experience. Some of the smaller circles overlap, i.e. some of the entitlement sets share privileges with other entitlement sets.

In this model, ALL entitlement sets are subsets of the "complete" experience.

But in the real world, is the experience of a bank executive a superset of the experience of one of the bank's borrowers? No. It's a different experience altogether. There may be some overlap but very little. How about the experience of a customer service rep compared to that of a borrower? Same story. There's probably more in common there than in the case of the executive but still one is not the superset of the other.

So, if we were to graphically represent the set relationship between these unique experiences we could use the previous picture of traditional entitlements but remove the large circle, i.e. there are various experiences, some of which may overlap with another, some of which may not, but none of which are necessarily a subset of any other. There is no "complete" experience, only "different" experiences.

Unfortunately all the role specification standards like XACML are based on the traditional subset concept.

Higher Conceptual Order

This new idea of varied experiences is the manifestation of higher order conceptual thinking in design applied to roles.

The higher order concept is the idea that in spite of programmers' desire to make generic, the ultimate end user experience is highly specific.

Traditional entitlements are all about making things generic. It's easier to implement.

The higher order concept would say that it the end user experience should be specific and tailored.

Nature of Roles

If in the new way one does not merely check boxes to create subsets of the "whole" functionality, then what do you have?

Answer: you deliver separate experiences and screens per user type, or user role.

Administrator's will *not* be allowed to check lists of entitlements to create new roles.

Won't this be too limiting? I don't believe so. A successful implementation of it will be possible through a thorough understanding of the business domain of the application. By thoroughly understanding the nature of a role you will know which app experience they need, at least 80% of it or more.

For example, let's consider the role of credit officer at a bank. "Credit Officer" role has a fundamental nature that does not change. This literally constitutes the definition of "credit officer." For example a job guide that was top of the list on a google search for "credit officer" says, "Credit officers examine, evaluate and process applications for credit or loans and, in a commercial enterprise, control and process accounts. Credit officers may perform the following tasks..." Then it proceeds to list eight tasks abbreviated as follows:

• assess loan requests
• approve or recommend approval of loans and credit applications
• prepare papers setting out details of agreement
• prepare reports of loans and accounts with unpaid amounts
• keep records of arrears and follow up on them
• prepare statements of overdue accounts
• prepare reports on credit ratings
• answer enquiries concerning loan balances or accounts

This is the nature of "credit officer" role. Therefore, in the new way, when a credit officer logs in (known by assigned role) the application will deliver screens, views, flows, and other features tailored specifically to a credit officer as if the credit officer experience were an entirely separate application. The credit officer experience would be dealing with common data on the back end, but the experience would be completely different, even from, let's say, that of lender representative.

All you need to do is assign the role of credit officer to a person and they will get the credit officer experience when they log in.

Organizational Hierarchies

So what if in an organization there exists a hierarchy of credit officers with those towards the bottom of the org chart having a subset of privileges of those towards the top? POSSIBLY it might make sense to allow traditional entitlements but even then ONLY within a major role like "credit officer."

Again, if the designer of the application has a thorough understanding of the core nature he should then be able to provide the right targeted experiences. For example, you might deliver the system with built-in support for the following roles instead of taking the traditional entitlements approach:

• Credit Officer
• Junior Credit Officer
• Credit Officer Assistant

Also, it should be remembered that a great app is designed to handle "right out of the box" what most customers will need most of the time. If they truly have funky needs that fall into the "20" of the 80/20 they can always write their own software units and screens and hopefully call directly into a rich supply of open backend services. For example they could set up their own roles and call their own traditional entitlements engine.

On the other hand the customer base may simply demand traditional entitlements capability. If so, then it would only be provided WITHIN a major role experience.

Multiple Roles

"That's fine Forsyth but what if someone wears more than one hat? For example, what if someone's a bank executive AND a credit officer?" Firstly, this problem is not solved by the traditional method. Secondly, there ARE good solutions with the new way.

In the traditional method the assumption is that there is one hierarchy tree of privileges. Since this is incorrect, and indeed the activities of bank executive would be different from those of credit officer there would actually be know of way of doing this effectiviely using traditional entitlements.

In the new way, you have some options including:

1. ask the user which experience they want after they supply credentials from the login screen
2. provide the same user (party with two separate login id's, one for each role

I would argue that neither one would be too much of a burden given that these cases likely fall into the "20" of the 80/20 rule.

In option 1 the user logs in could either get something that slides into, or pops up asking them to choose, or they could get a static page with two links, buttons, or such.

So if John had been assigned the role of "bank executive" AND "credit officer" then after he supplied his login credentials and hit "enter" a box would slide in saying something like, "Which role today?" Below that would be the role titles maybe with an intuitive image or something. When they click on one or the other they would be taken to chosen experience.

The system would remember the role last used and make it the default the following time.

Option 2 is easy and is probably the way to go.

This implies that in the data model each login is associated to a party role and not just to party.

Conclusion

The new way adds to traditional entitlements a higher order concept of separate, highly tailored experiences by role.

It allows traditional entitlements (based on subsets of "all privileges") but only within a major role.

To support the "new way" you'll need to,

• In the data model associate login with party-role and not just party
• Define the major roles within the app
• Create separate experiences for each role (admittedly borrowing or reusing...)
• Allow configuration of login specific access (traditional entitlements) but only within major roles
  

-Forsyth