HR-XML Looking Back, Looking Forward, Part 3

How to Change

They say "a change we'll do you good." That "the only thing that is inevitable is change." We know change brings opportunities and challenges and that change is hard. In Part 1 of this series, I wrote about the importance for standards organizations to have a maturity plan in the same fashion that a maturing commercial product would have such a plan. In Part 2, I provided some background on HR-XML's origin and its early years. In this post, I take a look at some of the events that led to the HR-XML 3.0 project.

Tool Troubles

In business and in life in general, someone can tell you exactly what you need to know, when you need to know it, but the information doesn't always get acted upon immediately. I mentioned that in our very early days, Microsoft had helped raise our profile by allowing us to participate in the BizTalk launch. The very gentleman who had been so helpful back in 1999, visited us at our April 2004 New York meeting and gave us a review of our then 2-year-old version 2.* library. Let's just say this was delivered in the blunt manner characteristic of engineers. He covered items such as the complexity of the xsd:includes (see my Part 2 of this series), the use of troublesome schema features (e.g., the way we had used xsd:union within the date types throughout the library) as emphasizing that interoperability required a solid data model - not just XML. He concluded his presentation by saying something to the effect that we could fix these deficiencies or just become another group that travels, eats a lot of "hotel chicken," and shares a few beers together after work group meetings. The presentation did trigger a lot of discussion, but not necessarily any particular next step.

Though in a less dramatic, similar reports of trouble with data types and resolving includes and imports started to filter back in support requests. Some of these issues arguably had to do with the maturity of programming tools at the time. The tools did improve and many of the problems did go away. However, certainly some of the issues were inherent in the 2.* library design.

HR-XML's Success as a Barrier to Change

Can success be a barrier to change? This sounds weird, but it goes back to the first post in the series in which I describe the imperative for a Consortium to have a maturity model for its specifications and how the development of that maturity model won't always align with the immediate interests of standards implementers.

It is important to realize that the quality and design issues connected with the 2.* architecture didn't prevent adoption. HR-XML schemas fulfilled needs and their use took off across many HR service sectors. Consider that in 2004, at the same time at which we were receiving admonitions from our friend at Microsoft, we had implementations taking off across North America and new initiatives based on the 2.* architecture hatching in France, the Netherlands, and Japan.

I think the HR-XML Background Check specifications are an especially interesting case study. In terms of design and their size, they are among the most complex specifications in the HR-XML library. However, the schemas encapsulate an enormous degree of industry knowledge and they were published just at the time integrated screening services were really taking off. So this is another case that shows that great content and great timing can trump elegant design in terms of standards adoption.

So despite emerging issues with the 2.* design, it was pretty clear that the 2004-2005 time period wasn't a time for the HR-XML Consortium to put the brakes on growing adoption by declaring the need for a "do over." While making a dramatic shift away from 2.* wasn't in the interests of implementers and other stakeholders, it isn't understandable why a plan for the architectural advancement and maturity of the library wasn't developed, at least not internally....

Influence from the Outside

Anyone analyzing the HR function over the past couple decades would likely agree that some of the most far-reaching changes resulted from HR being able to internalize business approaches, processes, and technology from the outside. For example, customer relationship management and supply chain management certainly have helped influence HR and recruiting processes. Likewise, the analytics and business intelligence approaches pioneered on the finance and sales and marketing side of the enterprise have crept their way into the business of HR management. Moreover, despite HR's reputation as a technological backwater, new service delivery approaches -- ASP-model software delivery, software as a service, business process outsourcing, etc. - arguably made their mark in HR ahead of other areas of the enterprise.

If you buy the idea that the farthest reaching changes to HR resulted from HR's capacity to internalize technology and approaches from the outside, the origins of HR-XML 3.0's initiative won't surprise you. HR-XML has had a long relationship with the Open Applications Group, Inc. (OAGi). HR-XML first gave a serious look at the "Business Object Document" (BOD) architecture used within the Open Applications Group Integration Specification (OAGIS) at our January 2002 meeting, in St. Pete Beach, FL. The Staffing Industry Data Exchange Standards (SIDES) specification was being developed. SIDES essentially was a procurement specification for staffing suppliers, customers, and intermediaries. At that time, the SIDES group took a pass on using OAGIS BODs, but HR-XML did continue to maintain active liaison with the OAGIS community. For example, HR-XML and OAGIS co-located their meetings in New Orleans the following year. I'll leave out the travelogue, but suffice it to say representatives continued to attend each others meetings.

Despite this long history, work towards architectural convergence with OAGIS did not begin in a concerted manner until after the appointment of a new CTO at ADP, a mutual member of HR-XML and OAGIS. The new CTO and his architectural team had adopted OAGIS as a basis for developing a canonical message model within ADP and urged HR-XML to bring its architecture in line with OAGIS. This proposal was presented at HR-XML's Oct. 2005 meeting, in Nashville, TN. As the calendar months flew by, the idea that a non-backwardly compatible release to fix deficiencies within the 2.* release up to date had taken hold with HR-XML, but the architectural dimensions of that release were not yet certain. A November 2006 dinner during the week of one of OAGi's meetings brought together representatives of mutual members of HR-XML and OAGIS (ADP, Cisco Systems, IBM, Lawson, Oracle, and SAP) to discuss HR-XML/OAGIS alignment. That was followed-by a conference call between OAGIS board members and HR-XML board members later in the month at which a rough consensus was forged to align HR-XML with OAGIS.

Communication of the proposal to the HR-XML membership and to the broader community began late in the year and continued into the next. A first prototype (HR-XML TimeCard) was readied by February. Work was still proceeding on HR-XML 2.5, which was designated as the last of the 2.* series of releases. The 2_5 release was approved and published on April 15, 2007. The plans for the 3.0 architecture were introduced to the HR-XML membership at HR-XML's May meeting in Houston (co-located with IHRIM) and communicated externally in a series of webinars. At the same time, the conversion and re-modeling of the HR-XML library began in earnest.

A Couple More Posts?

The 3.0 release is just about a week away from the start of its candidate release. There's likely a couple more posts in this series to get you completely up-to-date and to take a look at what is next.