Someone just asked me to review what the 3.0 library has related to competencies, so I thought I'd write a post as I'm sure others are interested. I also will offer a related opinion or two based on some discussions at last week's HR-XML Partnering and Integration Summit.

There is quite a lot that is new with respect to competencies in version 3.0. Here is a presentation I delivered back in May that covers this topic. I believe a few field names and other small details have changed in the interim, but that the deck basically covers the motivations for the changes.

Some of the competency-related material within the 3.0 library that you may want to review is briefly reviewed below:

• EPMResult. This is a result sent from an employee performance management system to a relying system (e.g., an LMS or other talent management system). A version of this came out with the 2_5 library. However, this is essentially new since implementations of EPMResult are only just beginning. The EPM result noun has a competency section that allows you to communicate information about groups of competencies, individual competencies, and individual behavioral indicators associated with a competency.


• PositionCompetencyModel. This is a format for the exchange of information about competencies associated with a given position. The PositionCompetency noun allows you to group, weight, and annotate competencies associated with a given position. PositionCompetencyModel can be used to provision an EPM or other system with competencies information. For example, messages (we call them Business Object Documents - BODs), based on PositionCompetencyModel could be used to set up an EPM system with a base competency model that a given position incumbent would be appraised against. Some integrations with assessment providers or LMS systems might present similar requirements.


• CompetencyDefinitions. This is just a simple structure to enable systems to "sync" definitions. The CompetencyDefinitions noun is based on the "reusable competency definition" concept advanced by groups such as the IMS Global Learning Consortium and the IEEE Learning Standards Technology Committee -- but it is built with HR-XML and OAGIS components.


• PositionCompetency and PersonCompetency. We've basically scrapped the prior "CPO" we called "Competency" (If you don't know what a CPO is, don't worry. We don't have them in the 3.0 library). The prior version of Competency basically has been broken apart and rationalized into what is a collection of component types. However, broadly speaking, the common uses of Competency within the HR-XML 2.* releases have been replaced in the equivalent parts of the 3.0 library with either PositionCompetency or PersonCompetency depending on the context.

Miracles and Fear

Now for the opinion part of the post. Competencies are hard. I'm glad it is not my job (and the HR world rejoices as well) to come up with competency models that can be validated in terms of business outcomes. Because there is much variation in thought about what competencies are (or even what to call them), a source of integration issues is simply that relying systems often have very different data models with respect to competencies than the source systems. Furthermore, simple things such as provisioning a system with competency content can be made more complicated by requirements around rights management for proprietary competency content.

My belabored point is that an XML standard by itself isn't likely to solve the above-referenced problems any more than it might make water flow uphill, bring world peace, etc. That said, I am very confident that the competency specifications within the version 3.0 library will be very useful and more than up-to-task of handling the piece of the competency integration puzzle for which they were designed -- to provide a well-modeled, neutral specification for the communication of competency data. So my message is intended for two camps out there: those who are looking for a competency data exchange standard to perform miracles; and those who fear a competency data standard will diminish the value of their competency-related content or services. You both are wrong.

My hope is that we can bypass both those awaiting miracles as well as those wrongly fearing data exchange standards, simply by giving developers ready-to-go packages that get the job done. With respect to SOAP-based web services, we have a start towards this goal in the "packages" published earlier this month. For example, here's one (.zip) related to sync-ing competency definitions. As I mentioned in a blog post earlier this year, I believe there also are some interesting possibilities with respect to competency content and RESTful web services. The "packages" as they exist today aren't anything like complete web service definitions as much as they are "starter kits." By the same token, I don't think we will be designing anyone's RESTful API for competency content, but we might include examples or other artifacts within the packages that would be of help if someone wanted to integrate competency content using a RESTful approach.