A successful standards initiative must influence as well as open itself to be influenced. I've mentioned in recent posts how HR-XML 3.0 advances the maturity of HR standards by incorporating design best practices and content developed by other groups (Open Applications Group, Inc. and UN/CEFACT). While OAGi and UN/CEFACT have much to offer, there are gaps. These organizations have focused primarily on material supply chains as well as domains areas such as finance, insurance, transportation, etc. There is no "HR domain" working group, nor are domains such as learning represented within UN/CEFACT.

Liaison With Learning Groups

There has been long-standing liaison between and among HR-XML and learning and education standards groups, such as the IMS Global Learning Consortium, the IEEE Learning Standards Technical Committee, the Postsecondary Electronic Standards Council (PESC), Learning-Education-Training Systems Interoperability (LETSI.org), The MedBiquitous Consortium, and the short-lived Web Services in Learning (WSIL) initiative. Unfortunately, an honest evaluation of the many years of HR/learning standards liaison would reveal few if any concrete results or progress towards convergence. Why? The fundamental reason is that each group, while in theory not opposed to convergence, quite naturally puts the immediate interests of its respective constituency in front of convergence goals. If convergence means breaking backward compatibility, it simply doesn't happen.

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

HR-XML's background check ("screening") specifications are an interesting case study in standards adoption. The screening schemas are the largest and arguably the most complex within HR-XML's 2.* series of releases, but they also are among the most widely adopted. Why? This has a lot to do with market need and timing. You can trace the development of HR-XML’s Background Check specification back to discussions that began in 2001. It was a good bet that such integration would take off. Integration provided employers with time savings, policy compliance control, and convenience. For screening service providers, integration meant new distribution channels for their services. For the applicant tracking systems (ATSs) in the middle, integration capabilities became a competitive differentiator, and later as the market matured, a required capability. In 2001, you could see that demand for integrated screening services would take off (even before the tragic events of 9/11). However, consider that when we began to develop the screening standards, there was not yet a lot of industry experience to inform design decisions.

Over the years, integration patterns within the screening industry have emerged. Within the forthcoming 3.0 library, we've taken into account some of the common usage patterns. The 3.0 library also offers a much more flexible, configurable component library for "what comes next."

If you take a look at the Version 3.0 screening drafts, you can see that we reference three basic implementation patterns:

I concluded my last post, by saying that the vision for HRInterop is to "open up" (community participation), "lock-down" (lock-down IP for confidence and clarity among implementers and contributors), reduce costs, and improve standards quality and utility.

Opening Up

I've related in previous posts, that it is a sign of success that HR-XML now has more non-member implementers than members. As adoption increases, it is logical to expect there will be more total implementation experience outside of HR-XML than inside. In the course of the 3.0 project, it is fair to say that half or more of the feedback we received was from outside stakeholders.

New content, new channels of participation, and a new structure for managing intellectual property are changes that will support engagement of a broader community. HRInterop.org forums are a place where anyone can bring implementation questions and feedback. There is no cost to participate, but this does require registration and agreement with a feedback policy and community guidelines.

The Return of the Customer

With new channels of participation and new content we also believe we will see a return of HR services customers within the dialog shaping standards.

In its early years, HR-XML enjoyed participation from HR IT representatives at organizations such as Northrup Grumman, Shell, BP, and HP. We even attracted significant support from those working on a next generation HR system at U.S. Department of Defense. Unfortunately, we didn't produce specifications directly addressing the problems of this segment. So it isn't surprising that we weren't able to sustain engagement with these stakeholders.

Contact First/Given Name: margaret

Question: I'd like to confirm these enumerated values:
Immediate - does this mean that requester is going to wait online until the results are ready (i.e. I'll wait until you process the credit check and have results to send back immediately)
Delayed - does this mean that I'm submitting my request for a credit check and the supplier just needs to respond with an acknowledgement that the order was recieved. Then the results will be sent back in a separate request/response transaction.

Margaret,

I assume you are talking about ScreeningOrderServiceCode. You probably found this definition: Refers to type of order processing pattern or level of service requested. This is an open HR-XML list. Enumerated values are Delayed and Immediate. Delayed = Acknowledgement of order receipt requested, but no immediate business-level processing expected. Immediate = Immediate business-level processing expected. This is an HR-XML Open List.

"Immediate" does imply a near-real-time response, which might support the return of a result to a user waiting for a result. I guess there are only a few types of screenings where this might be a reasonable expectation. **just an update to emphasize that this primarily is something that has meaning with a particular trading partner arrangement. I probably should just leave it there. I think the definition is actually pretty good -- immediate business-level processing. I think a synchronous, real time response with a result is a likely outcome, but the message exchange is really a separate matter.***

I'd agree that delayed is generally has the meaning you describe.

PositionLocation.

Question: There are a couple of requests here.

1. Need a UserArea
2. PositionLocation should mirror WorkLocation and include a LocationID and LocationName.

This would aling PositionPosting with IndicativeData.

PositionOrganizationDetails

Question: Hello,

The model should mirror that of DeploymentOrganizationDetails in IndicativeData. It allows for multiple identifiers and types of identifiers.

Here's the fourth post in this series. In part 3, I related some of the external influences that shaped the timing and architectural direction of the HR XML 3.0. In this post, I'll cover the 3.0 development process itself at a high level and get us up to present day. I'll finish with a "Part 5" that talks about some of the motivations for the HRInterop initiative and what we are trying to achieve.

Architectural Influence

As I mentioned in a prior post, HR XML has enjoyed a long history of liaison with OAGIS. However, before the 3.0 initiative, the two organizations -- like most standards organizations -- had little concrete progress towards interoperability. I've gone into detail about the issues we encountered as we began the migration from 2.5 to 3.0 in past presentations. The process involved taking the HR XML 2.5 content out of these silos (.png), slicing and dicing all the component types, putting them back together within single data model, and organizing the library according to the OAGIS modularity model. Remember that diagram in Part 2 that showed the "god awful" includes within the 2,5 model? All gone in 3.0!

Comments about RemunerationRange

Question: Hello,

We have a requirement to pass a minimum, maximum and reference amount.

Also in some cases an explicit remuneration amount may need to be specified, not always a range.

I think adding either the generic RemunerationAmount or a new RemunerationReferenceAmount would work.

Comments about PositionPosting

Question: We have a requirement to have PositionTitle in multiple languages. I can accomplish this using multiple PositionFormattedDescription, but I think it would be appropriate for PositionTitle to have a languageCode attribute and to occur multiple times.

Resolution: Make PositionTitle of TextType and make repeatable.