From the initial feedback I've received, the premise of last week's webinar was spot on. As Larry Fulton pointed out, enterprise service buses (ESBs) are proliferating and increasingly are bundled within broader software offerings. While there is no shortage of middleware or ESB infrastructure within large and medium-sized enterprises, it is clear that not many HR system stakeholders are actively involved in ESB implementations. Not surprisingly, there also appears to be limited awareness among HR system stakeholders of the architectural foundations necessary to use ESBs effectively in rationalizing a portfolio of distributed HR services.

The Business of HR is Distributed

While HR trails behind other enterprise functions in leveraging ESB infrastructure, it leads the enterprise in other areas, such as in using software as a service (SaaS) delivery models. I've joked that HR Services, like Elvis, have left the building. Benefits administration and payroll services have long been outsourced, but recruitment and a full range of talent management services also are increasingly are delivered by external SasS-model providers.

Thanks to those who attended yesterday's webinar, Demystifying ESBs for HR System Stakeholders, and many thanks to the presenter Larry Fulton.

Larry has made available a copy of the slide deck from his blog. Full replay of the session is available in the two video embeds that appear below.

Another resource that you may find valuable is the January 2009 report on ESBs that Larry wrote while at Forrester. Software AG has made the report available from its website (.pdf).

If Larry and/or I can answer any follow-up questions or be of any assistance, please don't hesitate to contact us. I'd be happy to forward your inquiries to Larry.

Part 1

Demystifying ESBs for HR System Stakeholders - PART 1, Larry Fulton, Senior IT Architect.

Part 2

Last week, I attended the IEEE Learning Standards Technology Committee (LSTC) meeting in Alexandria, VA. There are at least a couple topics discussed at the meeting I'd like to cover. I'm starting in reverse order in this post since I'm covering a topic discussed on the last day of the three-day meeting.

On that third day, Chris Guin of BBN joined us to review the "SCORM RTE Web Services Interface." This was developed as part of an "Integrated Prototype Architecture" funded by Joint ADL Co-Lab beginning in 2006. A paper describing this work was submitted in 2008 in response to LETSI's call for papers on requirements for a successor to the current-day SCORM standards. As the paper describes, the web services interface follows "as closely as possible" the SCORM ECMAScript Interface for Content to Runtime Services Communication (IEEE 1484.11.2-2003).

A key difference between the two versions of the same interface is that while the ECMAScript API facilitates communications to an LMS from a Sharable Content Object (SCO) delivered within web client, the SOAP-based Web Services interface allows any application to act as an SCO. Thus, the web services version opens up the opportunity to use SCORM for integrations where content is delivered within a specialized simulation or game application rather than just a browser.

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.