MatHamlin.com

As I return from my first Burton Catalyst Show in San Diego, many of the ideas, concepts and statements presented still linger in my head.   Before they all leak out, I’ll attempt at formalizing some of them.

 

In this first blog relating to the show, I wanted to talk about the difference between Business Roles and IT Roles and the need for their distinction.  Now before I go any further, I want to direct you to my Blog’s tag line… Simplicity is elemental…. my attempt here is not to go head to head with the acadmeia and drivers of standards, but to try and tackle a complex subject simply… and hopefully the outcome relates to the standards and open debates currently brewing.

 

Business Roles at the core are a representation of a relationship an individual has with an enterprise or organization.  

 

Examples:

• A job function like Product Manager or CFO
• An affiliation like alumni or contributor
• A temporary relationship, internal or external, like project leader or anonymous buyer
• In all case, there is a set of attributes or information that can be modeled and captured for each segmented group.

IT Roles can be described as a container of entitlements, or simply, a set of rights to gain (or deny) access to information or assets.

Examples:

• Access to the accounting system for viewing sales data
• Perimeter access to the Austin Campus

 

Now, the topic of debate at hand.  Is there truly a need for the distinction between Business Roles and IT Roles? 

 

The thought leaders at the conference seemed to be in two camps, one which was more pragmatic about the current application of Roles and believed there is little need for the separation, and one which was more standards based and academic, believing that there is a need for distinction.

 

I side with the later, but for the reason of the former.  Business Role and IT Roles have pragmatic application uses today… whether they are being utilized or not.

 

What struck me odd about the conversations and debates about this subject is that no one chose to span the gap and talk about how Business and IT Roles apply to actual market problems today and in the future.  There is an immediate need for Roles Based Access Control, which does not require Role Types, but by defining types now, there are options for additional uses of each type within and outside the scope of the current IT needs.

 

In my opinion, there is value in Business Roles and modeling a relationship outside the context of IT entitlements.  

 

Examples:

• Segmenting customers by Role 
  • Airlines do this with their rewards programs (member, platinum, executive platinum).  Arguably, this is just an attribute of an individual in context of the company’s relationship to them, but that is limiting.  Modeling an Executive platinum role gives an airline a way to group individual based on their relationship to the company and provide additional services (which can be an IT function such as free WiFi access in the executive lounge or a human interaction such as an extra “You’re super awsome” phone call).   A role also facilitates additional customer relations such as affiliations with partners…. Exec Platinum get free coffee at <insert favorite coffee shop here>. 
• Segmenting employees by Roles other than their Job Function
  • Roles based on enrollment in corporate programs such as Fitness or Philanthropic ventures.  A member of the Fit Club could be given access to the Gym (IT functions), but also the membership could indicate to others in the organization that you optionally have chosen to provide assistance to others looking to get fit.

These examples show the value of Roles outside of IT functions.  So, I agree with camp 2 that there is a need for at least a conceptual distinction.  However, the reason that 99% of the people were even discussing Roles at Burton Catalyst was in the context of IT functions.  Roles today, whether business or IT roles, are being used to describe IT access.  Therefore, I also agree with the pragmatic view of camp 1, in that there is does not need to be an implemented distinction.

 

With all that said, If I were implementing a Role Based Access Control solution, I would model Business Roles and IT Roles.  Here’s why: It’s easier to understand and manage over time.

 

If you own a coffee shop and wanted to give your employees roles how would you begin?  You would likely start with the job functions or titles of the employees.  Maybe you end up with a “Barista” role.  Now, a Barista needs what?  Well they need to be able to “clock in”, they need access to the bean storage, and they need access to the barista training material.  Oh, and maybe we decide that this Role is Activated once training is completed.  Do they need access to the cash register? maybe.  Is there a business need for a Barista to check out a customer?

 

So let’s begin.  

Step 1: Create new “Barista” role.

Step 2: Give the Barista access to the system for clocking in….  How do we do that?  Do we assign access rights directly to the Barista Role or do we create an IT Role that contains the access rights to clock in?  Both would work, but direct assignment limits you from grouping access rights in a logical way across systems.  A “Base Access” IT Role could contain the access rights for perimeter access and the ability to clock in…. everybody needs to be able to enter the kitchen and clock in, right?  So in this scenario you have either:

 

• Barista (Role)
  • Clock in (Entitlement)
  • Perimeter Access (Entitlement)
  • Bean Closet Access (Entitlement)
  • Inventory System Access (Entitlement)
• Barista (Business Role)
  • Base Access (IT Role)
    • Clock in (Entitlement)
    • Perimeter Access (Entitlement)
  • Supplies Controller (IT Role)
    • Bean Closet Access (Entitlement)
    • Inventory System Access (Entitlement)

Ok, ok..  I know what you’re thinking…  Yes, this is a good place for a hierarchy…. so I guess we should step briefly into that.  Taking another look, you could state that Barista is an extension of and Employee and if you are assigned a Barista Role, that should include the Employee Role and all of the Entitlements it provides.  Here’s how that would look.

 

• Barista (Business Role)
  • Employee (Business Role)
    • Base Access (IT Role)
      • Clock in (Entitlement)
      • Perimeter Access (Entitlement)
  • Supplies Controller (IT Role)
    • Bean Closet Access (Entitlement)
    • Inventory System Access (Entitlement)

 

Back to the ease of use… In all the cases above, when you are describing the access to someone, you’d say, “Bobs’ a Barista, which means he can Clock in, Get in the Kitchen, Get in the Bean Closet, and update the inventory system” ….   Now what if instead of 4 entitlements, Bob had 40.  Would you list them all, or would you say…  “Bob’s a Barista, which gives him the ability to manage the supplies” … and just assume that it is understood that he has the “Base Access”.   And from a management standpoint, modeling Business and IT Roles is also easier to manage.  Isn’t is easier to create a new Super Barista role and merely assign the Barista (Business Role) and the IT Role “Vault Access” which provides access to the Super Expensive (yet very disturbing) beans than to assign all the entitlements directly?

 

• Super Barista (Business Role)
  • Barista (Business Role)…
  • Special Supply Controller (IT Role)
    • Vault Access (Entitlement)

 

One additional (and good) argument for Role Types (in this case Business and IT) is that it allows you to implement management controls around the roles themselves… 

 

Examples:

• Only Business Roles can be directly assigned to users
• Only “Administrators” can edit IT Roles
• Business Roles can only contain other Roles, and not direct entitlements
• All Business Roles must be approved by HR

 

At the end of the say, maybe it’s just a semantic difference.  Whatever you call it, a well modeled, typed, hierarchical, inherited model will best serve the enterprise.

Posted under Roles