RBAC is like Communism: It sounds really great until you try to implement it,
David Griffeth, Vice President of Enterprise Identity Management, Citizens Bank at Catalyst Conference 2009.

In my previous post in this series, I covered the ROI for improvements in provisioning processes and I began to walk through the employment lifecycle to show how provisioning relates to specific employment lifecyle events. In this post, I finish my discussion of the employment lifecycle and talk a bit more about the limitation of role-based access controls.

RBAC and Communism

I didn't attend last week's Catalyst Conference 2009. However, when I saw David Griffeth's quote about role-based access control (RBAC) tweeted from the conference on Friday afternoon, I thought it captured quite nicely one of the points I'm trying to make in this series of posts. Managing access and entitlements by role gets complex quickly. It is not to say that roles aren't useful in managing provisioning, but starting with a table of events relevant to provisioning and de-provisioning is likely a better way to begin your planning. Increasingly, HR service delivery is distributed among multiple SaaS providers. Roles and sub-roles are likely to be tied to particular SaaS offerings. So lifecycle events - such as those covered in this post and the previous post - are a better starting point than roles. Build your table of lifecycle events, look at target systems, then perhaps look at whether and how roles fit into the provisioning and de-provisioning operations.

In my first post, I covered some basic provisioning concepts and emphasized that while provisioning processes ideally are "role-aware," they also need to be sufficiently flexible to handle a variety of intervening events. In this post, I cover some of the ROI for improvements in provisioning processes and walk through just a few events in an employment life cycle to show where provisioning fits into HR processes. I'll follow-up with two more posts. One to look at termination processes and the other to zoom-in on architecture to support provisioning.

The ROI for Improving Provisioning

There are ample business cases for investments that improve provisioning processes.

From the initial feedback I've received, the premise of last week's webinar was spot on. As Larry Fulton pointed out, enterprise service buses (ESBs) are proliferating and increasingly are bundled within broader software offerings. While there is no shortage of middleware or ESB infrastructure within large and medium-sized enterprises, it is clear that not many HR system stakeholders are actively involved in ESB implementations. Not surprisingly, there also appears to be limited awareness among HR system stakeholders of the architectural foundations necessary to use ESBs effectively in rationalizing a portfolio of distributed HR services.

The Business of HR is Distributed

While HR trails behind other enterprise functions in leveraging ESB infrastructure, it leads the enterprise in other areas, such as in using software as a service (SaaS) delivery models. I've joked that HR Services, like Elvis, have left the building. Benefits administration and payroll services have long been outsourced, but recruitment and a full range of talent management services also are increasingly are delivered by external SasS-model providers.

Below is the first in a few posts looking at managing access and entitlements across an employee lifecycle (from hire to termination). This post covers some basic concepts and definition of terms.

The OASIS Provisioning Services Technical Committee describes provisioning as:

...the automation of all the steps required to manage (setup, amend and revoke) user or system access entitlements or data relative to electronically published services.

In the context of HR processes, the term "provisioning" is commonly used in a few different contexts, but it broadly describes a process of communicating to a target system the information that system needs to authenticate users and to determine their access privileges. Perhaps the most critical task within the provisioning process is "de-provisioning," which refers to the removal of access rights and entitlements.

Provisioning is a horizontal enterprise process that has special relevance for HR systems management because access and entitlements for individuals usually are derived from a individual's status as an employee or contractor and from the particular position they hold or role they play.

New hire and termination processes are of special concern in managing provisioning. The new hire process is of concern, since new employees cannot become fully productive until granted system and facility access they require to do their jobs. Termination is of concern because of the security risks posed if terminating employees are not properly de-provisioned from systems. Provisioning and de-provisioning also may be triggered by many other intervening business and life events (for example, new projects, transfer, promotion, sabbatical, etc.).

Earlier this year, I wrote a couple posts about the "problem with people" -- that is the problem of modeling people within HR processes and systems. Broadly speaking, the problem is that a single person associated with an employer or an employer-sponsored program has a certain set of intrinsic characteristics, but also has characteristics that are relevant only in the context of a particular role or relationship with another party.

The diagram below (click for large version) is intended as a high-level, conceptual depiction of some of these different roles.

As complex as the diagram is, it is easy to see how you might go much farther. For example, I've left out roles such as "learner." I also have left out detailed delineation among roles. For example, one that comes to mind, but that I didn't depict in the diagram is distinguishing between the role of Candidate and that of Applicant. This can be a thorny issue since in many cases it might require application of "official constraints" (laws, regulations, etc.). If you've tracked what has gone on among various U.S. regulatory agencies (EEOC, OFCCP) in this regard, you know bright-line determinations are difficult (or should we just say "impossible"?). While this is complex, from a data modeling perspective it is possible to make simple assertions, such as that an Applicant is a type of Candidate that has become associated with an employment opportunity in manner consistent with employer practice, applicable law, etc.

Modeling People Across Roles

I've written in the past about HR-XML 3.0's potential as a common information model. But what if you aren't really so interested in a "component library," as much as you are interested in just few key interfaces with trading partner -- for example, an HR-XML-based interface for accepting assessment or screening orders. Don't worry - we'll make it easy for you to do this by publishing "packages" of assets drawn from the broader library just for these types of integration requirements.

"Packages," as I'm using the term, combine several schemas into a single flattened schema. Packages were prepared in contemplation of common or typical services implementers need to support. Each package contains an example Web Services Description Language (WSDL) file that may be used as a starting point for deploying related services.

From this page, you can browse and download individual DRAFT packages or download the distribution file that includes all of them. Links to related documentation are provided. If you are not yet familiar with OAGIS Business Object Documents (BODs), spending some time reviewing the documentation on OAGIS data management would be wise. Note that a feedback form is available at the bottom of each page of documentation, so don't hesitate to let us know what works, what doesn't, and what is missing.