I've been doing a lot of blogging lately, and I don't just mean posting a bunch of stories. I've been posting stories and digging and stumbling and all kinds of crazy things. Despite all of this, most of my hits are still on that one HR-XML article I wrote last year.
That brings up a few thoughts. First, if so many people are looking for information on HR-XML so consistently, they must be actively accepting it or rejecting it, and I'd like to know which and why. Second, I'd like to know who is doing what with HR-XML.
So, when you finish reading this post, I'd really appreciate your comments. What have you decided to do with HR-XML? What led you to this decision? What solutions have you already implemented with HR-XML to date?
My company has been evaluating HR-XML for several months, but we haven't yet implemented an HR-XML solution. We produce several components of an HR suite of software and we have integrated with a number of applications including background check vendors, HRMS, and ATS, but not one vendor has had an HR-XML integration solution (even one particular vendor which purports to be nearing an HR-XML integration solution).
We've been waiting for a partner to be HR-XML capable before we develop our own HR-XML integration. The problem is, I think everybody else is doing the same thing. Well, we're in a good position because the more customers we get and the more applications we have, the more we need our own internal applications.
So, we have decided to take the initiative to develop an HR-XML integration with all of our applications. This will give us a common and standard format with which to transfer data not only among our own applications, but with other applications and vendors as well. Future integrations will go through an "HR-XML layer," including custom integrations. By that, I mean rather than developing integrations to read from spreadsheets and CSV files and then to write directly to our databases, they will first be reformatted to HR-XML and will then be consumed by our HR-XML import engines.
Exports will be handled similarly. This gives our developers and our partners' developers a contract on which to map any imported or exported data without having to know anything about our internal data structures. We're hoping that as we integrate with more and more vendors, that they will also adopt HR-XML allowing all companies which provide human resources software and services to work harmoniously and interchangeably together throughout the entire employee life cycle.
another programmer trying to enhance his craft through information sharing and socialization
Showing posts with label HR-XML. Show all posts
Showing posts with label HR-XML. Show all posts
Sunday, March 1, 2009
Saturday, August 9, 2008
HR-XML Integration in Human Resources Software
Most of the programming and architecture work I do is in the human resources space. I write software for paperless onboarding and acculturation, personell change management, background checks and verification services, new employee requisitioning, and the like. As you can imagine, I spend a great deal of time and effort integrating with human resources software systems. I work with applicant tracking systems, payroll systems, human resources management systems, other onboarding systems, background check providers, and a number of other applications and services that all have to be able to talk to each other.
Some of the software, services, and systems I integrate with aren’t too bad. Some of them, however, are obscene. I work with one HRMS and payroll system, for example, that has a database with more than 1300 tables comprising an absurd 34,000 columns. Most of the tables have 8 to 10 character names; 3 of these characters are consumed by a 3 letter prefix which is carried over into the column names in the table. The tables may or may not have an identity field which is buried somewhere in the table structure, but you don’t need to know what the identity column is because it’s not used as a primary key. Instead, the primary key is derived from a time based calculation with a 1 second granularity. Furthermore, there are thousands of columns on most of the tables that start with UDF and end with a two digit number. In case you haven’t seen this abhorrent pattern before, UDF is short for “User Defined Field,” and it’s pretty darned tacky.
If you’re not yet convinced that this is indeed the ultimate in terrible database design, just go dig up E. F. Codd and you’ll most likely find him spinning in his grave. But, I’m not really writing this entry about bad databases; I mostly wanted to describe why it is so hard for multiple vendors to work together in the same environment. Well, to our rescue comes the HR-XML consortium, “ a non-profit organization dedicated to the development and promotion of a standard suite of XML specifications to enable e-business and the automation of human resources-related data exchanges.”
So, what does that really mean? Well, if your imports and your exports follow the HR-XML schema, you know you can always talk between systems. Our suite of human resources software is fully capable of communicating via HR-XML data. For us internally, it means that any piece of our system can be added or removed based on client needs. It also means that we fit in any stage of an HR process between applicant tracking and termination of an employee.
We can easily integrate with HRMS and Payroll systems, background check vendors, and even the Department of Homeland Security eVerify system. The only real problem is that HR-XML is not well accepted. Most other vendors don’t provide HR-XML integration support. In fact, some companies even lie about HR-XML integration to trick potential customers into believing they are getting an easily extensible system. I even know of one company that not only lies about its HR-XML integration, but also sits on the board of the HR-XML consortium. To me, this seems like the ultimate software insult.
So, if you work in HR or in HR software development, what can you do? Well, tell your vendors you are interested in seeing HR-XML support. Interact with the HR-XML consortium. Make your solutions HR-XML compatible. There are numerous ways to get involved and I hope this article whets your HR-XML appetite. I plan on posting a series of HR-XML articles on my blog so keep checking back. In the meantime, I’d love to hear about your integration nightmares. Please post a comment on this post if you have experienced similar issues.
© 2008, D. Patrick Caldwell, Vice President for Research and Development, Emerald Software Group, LLC
[digg=http://digg.com/programming/HR_XML_Integration_in_Human_Resources_Software]
Some of the software, services, and systems I integrate with aren’t too bad. Some of them, however, are obscene. I work with one HRMS and payroll system, for example, that has a database with more than 1300 tables comprising an absurd 34,000 columns. Most of the tables have 8 to 10 character names; 3 of these characters are consumed by a 3 letter prefix which is carried over into the column names in the table. The tables may or may not have an identity field which is buried somewhere in the table structure, but you don’t need to know what the identity column is because it’s not used as a primary key. Instead, the primary key is derived from a time based calculation with a 1 second granularity. Furthermore, there are thousands of columns on most of the tables that start with UDF and end with a two digit number. In case you haven’t seen this abhorrent pattern before, UDF is short for “User Defined Field,” and it’s pretty darned tacky.
If you’re not yet convinced that this is indeed the ultimate in terrible database design, just go dig up E. F. Codd and you’ll most likely find him spinning in his grave. But, I’m not really writing this entry about bad databases; I mostly wanted to describe why it is so hard for multiple vendors to work together in the same environment. Well, to our rescue comes the HR-XML consortium, “ a non-profit organization dedicated to the development and promotion of a standard suite of XML specifications to enable e-business and the automation of human resources-related data exchanges.”
So, what does that really mean? Well, if your imports and your exports follow the HR-XML schema, you know you can always talk between systems. Our suite of human resources software is fully capable of communicating via HR-XML data. For us internally, it means that any piece of our system can be added or removed based on client needs. It also means that we fit in any stage of an HR process between applicant tracking and termination of an employee.
We can easily integrate with HRMS and Payroll systems, background check vendors, and even the Department of Homeland Security eVerify system. The only real problem is that HR-XML is not well accepted. Most other vendors don’t provide HR-XML integration support. In fact, some companies even lie about HR-XML integration to trick potential customers into believing they are getting an easily extensible system. I even know of one company that not only lies about its HR-XML integration, but also sits on the board of the HR-XML consortium. To me, this seems like the ultimate software insult.
So, if you work in HR or in HR software development, what can you do? Well, tell your vendors you are interested in seeing HR-XML support. Interact with the HR-XML consortium. Make your solutions HR-XML compatible. There are numerous ways to get involved and I hope this article whets your HR-XML appetite. I plan on posting a series of HR-XML articles on my blog so keep checking back. In the meantime, I’d love to hear about your integration nightmares. Please post a comment on this post if you have experienced similar issues.
© 2008, D. Patrick Caldwell, Vice President for Research and Development, Emerald Software Group, LLC
[digg=http://digg.com/programming/HR_XML_Integration_in_Human_Resources_Software]
Subscribe to:
Posts (Atom)