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!
The few simple pictures above give someone who is not an XML guru or data modeler a quick sense of the process. Without going into depth, it is important to realize that this was not any kind of "conversion exercise". OAGIS provided us with a well-developed architecture and great common content (its implementation of the core component types), but bringing the HR-XML library over to the new architecture literally required thousands of small decisions, drafts, and re-drafts. My point is that this wasn't mechanical conversion. The process represented a great deal of learning in terms of how HR requirements could (and sometimes couldn't) be represented within the OAGIS architecture.
The Impact on Implementers
The version 3.0 release really was a first-of-it-kind experience for HR XML (but not for some of our peer standards organizations). In my first post, I noted that HR-XML did step up from a version 1.0 represented in DTD syntax to the 2.* series expressed within XSD, but that wasn't such a big deal since version 1.0 didn't really have much of an implementation base.
Having a broad-base of implementers cuts few different ways in terms of a major re-architecture. There is some percentage of implementers that are somewhat passive. If you look at even the most ardent HR XML adopter, you'll find many on the 2.3 release, perhaps with plans to step up to 2.5 in 6 months to a year. Such implementers are happy if a better-modeled, easier-to-use library is on its way, but they might take even another year to 18 mos. before they begin planning their 3.0 upgrade. There is another group of implementers who actually may be a bit resistive to the change. If the existing spec works for them, a non-backwardly compatible, next-generation specification may simply appear to be a future cost to bear.
There's at least one other category of implementer that has made an impact on the 3.0 release in a way not seen before -- that is the non-member implementer. Think about this. If a standards organization is successful, at some point in time you have more implementers and more implementation experience externally than internally. Since nearly the beginning of the 3.0 project, drafts have been available for review by anyone registering to download HR XML specifications. On the bottom of each page, there is a feedback form. Those outsiders submitting feedback must agree to a feedback policy (what comes in typically are bits-and-pieces and bug-fixes more than contributions, but we need to cover our bases in terms of intellectual property). My point is that I think it is fair to say that during the course of the 3.0 project, there has been as much if not more feedback from non-member implementers, as from members. This could almost have been mathematically predicted based on adoption, yet on the other hand, we weren't as prepared to engage our "outside" community as we might have been.
If You Build it They Will Come
In a couple recent presentations, I've shown this rather ugly diagram illustrating in general terms where adoption has and hasn't occurred within the HR services ecosphere with respect to the HR XML 2.* library. If you take a look at the 2.* library structure, the adoption patterns make a lot of sense. Most adoption has occurred at the periphery. That's not surprising, since it was these B2B collaborations that working groups focused on and that were the basis for the library structure. My ecosphere diagram shows that the least adoption occurred for those parties needing to work across multiple business processes. The 2.5 library simply did not do this well. It really was a set of individual schemas tailored around specific B2B scenarios. It wasn't anything like a canonical message library created from a single data model. The expectation is that the 3.0 library will allow us to play in both places -- In the arena of B2B exchanges where we've traditionally enjoyed strong adoption as well as places closer to and within the enterprise itself.
So the point of the "Field of Dreams" reference in the title is that building 3.0 should attract new implementers in new places. The good news is that this isn't just an idle hope. There is evidence that this is happening. We've worked very closely with one large, multinational pharmaceutical company that had a major, multi-country SAP integration to carry out. They found the 3.0 draft specification and liked what they found. They've been a steady source of feedback. They've implemented some extensions, but they've found the 3.0 library on the whole to be very suitable for their requirements. I've recently learned of a second multinational enterprise -- a consumer electronics/telecom company -- that likes enough of what it has found within the 3.0 draft to have begun a review of how 3.0 might support its HR master data integrations. Think also about OAGIS adopters -- which include the likes of Boeing, Cisco, IBM, Microsoft, Lenovo, Lucent, Ford, etc. We've just made our library more useful to companies with OAGIS capabilities. HR XML has some usage at a few of these companies already. I don't think it is a great leap to expect to see HR XML 3.0 adoption take off among these companies.
If the 3.0 library helps HR standards gain adoption in multinational enterprises and in other places within the HR services ecosphere, what is the broader impact? I've got to think it will open up opportunities and reduce costs and implementation time frames for HR service providers with capabilities to work with the new standards. What about those vendors that don't have such capabilities or who already have a foot in the door with integrations that are proprietary or non-standard? You can imagine why such service providers wouldn't necessarily be champions of the new standards.
One More Post To Come
Thank you if you've read this far into this series of posts. I hope I've managed to set the stage for my final post, in which I'll address what we're trying to achieve hhere. To really nutshell-ize, the vision for HRInterop is to open up (community participation), lock-down (IP for confidence and clarity among implementers and contributors), reduce costs, and improve standards quality. Look for the final post. We need stakeholders who support these same goals.
