Modeling

Slides for "Universal Patterns: How They Can Help You Develop Your HR Data Model"

Many thanks to Len Silverston and Paul Agnew for their participation in yesterday's seminar, Universal Patterns: How They Can Help You Develop Your HR Data Model. A screencast of the webinar is in production, but in the mean time, you can browse and download the slides that were presented using the embed below.

Jan 22 Webinar: Universal Data Model Patterns, Len Silverston, Paul Agnew


A well-conceived data model is a necessary foundation for any service oriented architecture (SOA). Architects looking for proven data model templates and best practices will find few resources more valuable than the The Data Model Resource Book series. In the recently published third volume (Universal Patterns for Data Modeling), data modeling experts Len Silverston and Paul Agnew, examine the recurring patterns that are essential for architects to understand in building and maintaining enterprise data models.

In this month's Webinar, we are fortunate to have Len and Paul join us to review their latest book and comment on the applicability of "universal patterns" to human resource data models.

The Problem With People III: The Roles People Play

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

Syndicate content