This is the second in a series of posts examining where HR interoperability standards have been and where they are headed. In the first post, I explained that it is as important for a standards organization to have a maturity plan as it is for any company with a maturing commercial product. In this post, I cover some of the "looking back" part, by giving some background on the origins of HR standards and their development through the years. If you are not a history buff, you can jump straight to the point.
Prior Work: 1999
My background (my first career?) was in new product development for information publishers, including BNA and Thomson. I focused on the HR market and gained experience with XML's precursor, something called SGML. With the publication of the XML 1.0 specification in Feb. 1998, I began to put together a few drafts of a markup language for HR. By the spring and summer of 1999, I had begun working with a loosely organized online community on a markup language for job postings and resumes. An archive (.zip) of this prior work is still available still available from the Cover Pages. Some of this prior work also was mentioned in Futurize Your Enterprise, a web strategy book published that year. If you bother cracking the archive to look at the DTD, you'll see that even before the Consortium was started, this work was offered as freely distributable and provided for anyone to use for any purpose.
In July 1999, I began collaborating with Internet start-up Icarian, Inc. to advance this nascent markup language initiative into a broader standards development effort. I visited SHRM that month to explore a role for it in launching the initiative. The following month, www.hr-xml.org went online and the draft specifications were first published as hr-xml.org works. They were also published in the schema repository OASIS maintained at the time. Microsoft did us a great favor by including .xdr versions of the specifications within the BizTalk library they launched Sept. 14, 1999. It was a big break for our very provisional standards initiative to get a press release included within a Microsoft press kit. During the first year of the BizTalk repository, the Resume schema we contributed ranked number 1 in downloads among the approximated 400 schemas.
Conversations within the loosely organized online community continued and attracted additional participants. David Manaster's ere.net briefly hosted a mailing list for us. Industry analyst and consultant Naomi Bloom joined the conversation and helped expand the focus of the initiative from merely exchange standards for job postings and resumes to standards for HR data in general.
The groundwork described above culminated in a first organizational meeting on Oct. 12, 1999. While the meeting attracted more than 50 representatives from more than 30 companies, we unfortunately couldn't manage to get a representative from SHRM to walk across Duke Street to attend the event. We did, however, manage to get the participation of SAP, IBM, and dozens of HR dot coms. By Nov., a provisional board of directors was appointed. By year-end, the HR-XML Consortium, Inc., was officially established as a California corporation.
HR-XML Achievements: The 2.* Series
Many standards development organizations (SDOs) representing other industries and enterprise functions built their XML specifications upon pre-existing electronic data interchange (EDI) standards. In contrast, HR-XML's efforts represented a first-generation of standards for the industry. A cliche that some of my EDI colleagues use to describe their first generation XML initiatives is that they were "paving cow paths" -- in other words, taking their EDI data models and porting them to XML, with various degrees of remodeling along the way. If "paving cow paths" is descriptive of how other verticals advanced their first XML standards, the analogy for HR-XML would be more like "hacking through uncharted forest" since this was the industry's very first data standards initiative.
Progress was remarkable in that the Consortium brought together specialists within nearly a dozen HR sub-domains (for example, recruiting, staffing requisition, payroll, benefits, background checks, stock plans, etc.) to publish specifications that have proved useful within many sectors across North America, Europe, and Asia.
The very first generation of HR-XML was based on Document Type Definition (DTD) syntax and had a relatively brief lifespan. This generation of specifications (so called "HR-XML 1.*" specifications) was largely superseded by the 2.* series of releases that was created using XML schema definition language (XSD). The first in the 2.* series was published in April 2002. While much has been added to the library over six releases, the current, approved HR-XML release (version 2.5), uses the same basic architecture and design approach that was establish with the approval of the version 2.0 release in 2002.
The HR-XML 2.* Generation of Standards
Within the HR-XML 2.* series of releases, the approach used to specify messages was left up to individual working groups. For those "top-downers," if you think about where we were in terms of the standards (as I say, clearing a path through the forest), what other choice was there? While in the next few paragraphs I describe some of the design consequences, I'm not implying that things necessarily could have been much different. HR is a crazy domain. One might say it is really an aggregate of a bunch of different specialties. It is not likely we could have covered as much ground in producing useful specs in reasonable time frames had the work been channeled through a more centralized development structure.
We produced useful specs relatively quickly. However, there were consequences. Different working groups made different design decisions. Some working groups defined schemas that provided a data model for entities being managed, but did not explicitly define any messages. Other working groups had genuine message definitions as part of their specifications, but each largely took a different design approach from one another. While designs differed, the tendency among those that defined messages was to tailor them to a very specific "activity" (e.g., RemoveStockGrant, AssessmentCancelRequest). This isn't an unusual approach, but it does put the burden on all our workgroups to predefine in detail all the operations trading partners may want to perform on the entities they are managing.
One of the key features intended to bring order to the separate workgroup initiatives were so-called "cross-process objects" or "CPOs". As the name implies, these were definitions of aggregate-level elements (for example, PersonName, PostalAddress, etc.) that were shared across working groups. While the modeling behind these individual elements often was very good, the sharing of these key objects across working group specifications was something quite short of a unified HR-XML data model. Each working group had its own data model, but for the collection of shared "CPOs".
The rapid growth the HR-XML library across many specialized sub-domains (and corresponding adoption in the marketplace) is something that certainly should be claimed as success. However, it shouldn't surprise anyone that such growth had a patch-work quality.
Some of the patch-quality of the HR-XML library was most evident in the way HR-XML strung together and nested modular "includes" of HR-XML schemas and imported namespaces. It is said a picture tells a thousand words, but software developer Kirill Grouchnikov didn't refrain from using choice words when he published a visualization of dependencies within the HR-XML SIDES HumanResource schema and called it an "ungodly creature."
While the picture above is pretty bad, most implementations of the 2.* standards were made less complicated through the use of "standalone" schemas that combine the many separate "include" files shown in Kirill's picture. Nevertheless, it should be fairly clear that the lack consistent, well-understood data model and message architecture was increasingly a problem for implementers. Consider that the design choices underlying the 2.* HR-XML schemas pre-date the existence of most of the common tools programmers and integrators use today. Thus, it is not surprising that developers commonly face tool incompatibilities when using the 2.* generation of HR-XML schemas. There also is the issue of implementers wanting to apply specifications spanning multiple HR sub-domains. Some of our SIDES implementers faced particular challenges here. While temporary staffing has requirements that are distinct from recruitment, realistically the two domains should share 50 to 75 percent of the same underlying data model (as you'll see, the 3.0 release makes dramatic improvements in this regard). However, my rough estimate is that the SIDES and SEP (Staffing Exchange Protocol) specifications within the 2.* releases likely share something on the order of 30-40 percent of common components. Reuse should never be a goal unto itself, but sensible reuse lowers learning curves and implementation cycles.
What is My Point?
Yes buried down here in my last paragraph of this long post, is my point. My point isn't to rag on the 2.* library. This still represents a remarkable achievement for the HR services industry. Seriously, I think you'd be hard pressed to find any other standards organization that within a similar time frame brought together as many diverse domain experts to build as broad a library and to gain as much adoption. The key point I want to make is that 1999 was long ago. For that matter, so was 2002, the year HR-XML began the 2.* series of releases. Wouldn't it be a shame if this valuable work remained locked in the framework set for it back in 2002? The design defects discussed above have largely been remedied in version 3.0, which is about to make its debut, but there still is more to do to ensure continued forward progress.
See Part 3, Part 4, and Part 5.
