HR-XML 3.0: New Architecture, New Opportunities

1. HR-XML 3.0: New Architecture, New Opportunities Chuck Allen, HR-XML Consortium, Inc.

2. HR-XML in 2008 • “The recognized authority on, and leading source of, global interoperability standards for human resources management.” • Now in its ninth year, but relatively young compared to peer organizations. • Global – Broad interest in HR-XML in North America, Europe, Asia. • Solid adoption across many sectors, but still much to be achieved. • Beginning far-reaching re-architecture (our last in 2002). Known as “HR-XML 3.0”.

3. HR-XML Scope • HR-XML covers diverse sub-domains. • 40+ nouns; 2500+ components in HR-XML 3.0 • System Provisioning • User Account • Indicative Data • Recruiting • Candidate • Position Posting • Resume • New Hire • Staffing • Staffing Order • Assignment • Resume • New Hire • Assessments • Assessment Order • Assessment Result • Assessment Catalog • Catalog Query • Payroll • Payroll Benefits Contributions • Payroll Instructions • Indicative Data • Benefits • Enrollment • Savings Plan Enrollment • Stock Plans • Audits • Background Check • Screening Order • Screening Report • Credit • Drug Test Result • Time • Time Card • Time Card Configuration • Performance • EPM Result • Objectives Plan • Development Plan

4. 50+ Certified Solutions: HRCertify.org

5. HR-XML SIDES for France

6. HR-XML SIDES for the Netherlands

7. And Now, HR-XML SIDES for Japan

8. Roadmap: Where We’re Headed • HR-XML 4.0: • Completely model-driven, syntax neutral? • HR-XML 3.0: • First major, non-backwardly compatible release since 2002. • HR-XML 1.0; 2.(*) • All the advantages and disadvantages of being by-passed by EDI. • Pioneering, ground breaking work. Captured a rich set of domain expertise.

9. Long Live HR-XML 2.*! • 2.0 model was released in April 2002 (at our Atlanta meeting). The HR-XML library has grown tremendously since. • Current policy to protect our 2.5 adopters: • Continue to support members and certified organizations for 2.5 and earlier 2.* releases. • A company may newly certify against a release up to a year after that release has been superseded. If you have a 2.* certification, you may renew your certification. • No new work on 2.5, but HR-XML may publish a 2_6 for discrete requirements relating to existing specifications (small changes, bug fixes, regulatory changes, etc.). • Those who have made investments in 2.* are urged to contribute “test cases” for 3.0. This is a way for adopters to gain confidence that they will be able to migrate (not that they have to!).

10. Where Does 3.0 Stand • 1st Q 2009 Ballot • Oct. 13 Release of Candidate Specification at the Partnering and Integration Summit. • June. Initial analysis and conversion of library to new modularity model is nearly complete. • 2_5: 4882 Components • With 90 percent the library converted: 2400 Components.

11. HR-XML 3.0 Goals • Bring the large library we’ve developed over 8 years under a uniform architecture. • Support interoperability with the major ERP/HRIS vendors (ADP, Lawson, Oracle, SAP). • Align with approaches advanced by the Open Applications Group and UN/CEFACT. • Deliver component library that others will be able to reuse flexibly. • Prepare for more change.

12. Past Challenges to Forward Progress • Backward compatibility (eliminated in 3.0). • Lack of architectural framework. Too much heavy lifting put on the shoulders of our domain-oriented workgroups. • Dependencies on volunteers. Often difficult for a member to justify resources to advance the broader model if it just needs a slice. • Lack of the right expertise – good architects are a scarce resource. Aligning with OAGIS/UN/CEFACT gives us access to a brain trust that spans many .orgs. • Library design. 2.* had some nice documentation, but is large and brittle.

13. Standards Quality Measures* • Can a subset of the standard be used or can the standard be used as a component of another standard? • Does the standard maximize use of pre-existing high quality standards? • Is the standard well-factored/allow modular implementation? • Does the standard adequately represent the semantics of the information encoded within it? • Are the methods for describing metadata based on high quality standards? * Bob Sutor, IBM, http://www.sutor.com/newsite/blog-open/?p=1799

14. Library Structure

15. HR-XML 2.*

16. What Does This Mean? • HR-XML workgroups will be able to more easily build documents with a tighter correlation of content to use. • Better able to deliver on projects such as “talent management provisioning” begun last year. • HR-XML becomes more valuable as a resource for implementers to use in constructing their vocabularies. Better able to “snap in” HR-XML content directly rather than using HR-XML merely as a source of ideas. • Easier for implementers to re-use HR-XML components within UserArea extensions. • Not all content will be global, some left locally scoped within particular documents (that which has “composition” versus “aggregation” relationship – in other words, the stuff not likely to be reused elsewhere.)

17. – BODs • Messages (Verb-Noun Constructs) HR-XML 3.0 • i.e., modular. Also will have “Standalone” version – Developer • ProcessTimeCard.xsd (HR-XML target namespace) • Optional - ProcessOnlineOrder.xsd (OAGIS target namespace) – - Miss HR-XML 2.*? Look here for equivalent major schemas. Nouns • TimeCard.xsd (HR-XML target namespace) • Optional - OnlineOrder.xsd (OAGIS target namespace) – Resources • Resources from which “Nouns” / BODs are built • Globally available content – Components + Financial • HR-XML is optionally installed with other verticals + • Globally-scoped HR-XMLcontent here HR + • OAGIS 9.2 content here (all or subset?) Common CoreComponents + • OAGIS implementation of UN/CEFACT CCTS

18. Fields Components Codelists <.xsd> <.xsd> <.xsd> EnumeratedValues, “Lists” “ReusableAggregates” “Leaf-Level”Elements, SimpleTypes, Complex Types With SimpleContent 3.0/Resources/Components/HR • HR reusable content will have the similar modularity model as OAGIS common components – Fields, Components, Codelists.

19. Core Components • HR-XML’s won’t access “core-component types” directly – HR-XML fields will be built with “unqualified” and “qualified” data types. • Benefits: • No longer have to wrestle with technical nuances of a large number xsd:datatypes. • Most everything thing we need is there. • May use certain xsd:types.

20. Unqualified Data Types • IdentifierType • IndicatorType • MeasureType • NumericType • PercentType • RateType • QuantityType • TextType • NameType 3.0/Resources/Components/CoreComponents/UnqualifiedDataTypes.xsd • AmountType • BinaryObjectType • GraphicType • PictureType • SoundType • VideoType • CodeType • DateTimeType • DateType • TimeType

21. ModularityModel

22. New model is not without complexities, but promisesimprovementover the priormodel. http://weblogs.java.net/blog/kirillcool/archive/2005/07/visualize_your.html

23. Codelists A character string (letters, figures or symbols) that for brevity and / or language independence may be used to represent or replace a definitive value or text of a Property. • HR-XML 2.* did not have much organization under our lists – i.e., enumerated values. • HR-XML 3.0 gives us the opportunity to apply best practices, the OAGIS architecture, and to simplify/re-evaluate our content.

24. Codelists See: http://docs.hr-xml.org/wiki/doku.php?id=code_lists • External: • Well-known, official, “standard” codelists for the particular value domain. • Proprietary codelists. • HR-XML Closed: • These are lists HR-XML develops and maintains. A closed list implies that the list will be implemented without restriction or extension. • HR-XML Open: • Provides a base or suggested list of values. No schema enforcement. No conformance requirements unless workgroups set business rules.

25. Naming

26. The Queen’s English • CCTS references the Oxford English Dictionary (OED) as the authoritative source for spellings/meanings. • 20+ volumes in print • Available by subscription online at oed.com • Has proven very helpful in solving “choose-a-word” debates.

27. Naming • In 3.0, we are aiming for business-meaningful, but concise “tag” names, paired with a formal “data element names.” • Data Element Name, developed in accordance with ISO 11179 and CCTS principles in our analysis and naming. • This approach moves us closer to our model-driven ideal. Also provides a way to keep tag names brief.

28. CCTS/ISO 11179 Naming HR-XML 3.0 will involve analysis using CCTS and ISO 11179-5 concepts. Under ISO 11179-5 sets out a model for data elements. A data element name (DEN) is composed of (in order): • An Object class term • Property class term • Representation term A DEN uses a period ( “.” ) to separate between terms.

29. CCTS/ISO 11179 Naming • "Object Class" refers to concepts, abstractions, things in the real world that can be identified within clear boundaries and meanings and whose behavior follow the same rules (examples: person, organization, employer ...) • "Property" is a characteristic feature shared by all the instances of an object class (examples: age, income, address ...) • The "representation" describes the data type and its value range (examples: a date can be represented with date or datetime value domains).

30. ISO 11179/CCTS Naming Qualifiers May be attached to object class terms, property terms, and representation terms to narrow or uniquely define a data element. DEN uses a underscore “_” appended to the end of a term to represent a qualifying term. Examples: Person. Hire Date. Date Person. Proposed_ Hire Date. Date (qualifies the property) Organization. Name Employer_ Organization. Name (qualifies the object class)

31. ISO 11179/CCTS Naming • Multi-word object, property, and representation terms also are allowed. Consider: • Organization. Name. Name (Organization object class, name property, name representation type) • Education_ Organization. Name. Name (A profile or narrowed version of the broader Organization object class.) • Education Organization. Name. Name (This is a different object class.)

32. Naming: Property Representation Name Fields by “representation type”. Driven from UnqualifiedDataTypes for example: • IdentifierType – e.g., OrganizationID • CodeType – e.g., JobClassificationCode • IndicatorType (Boolean) – e.g., BillableIndicator • MeasureType (something requiring a unit code) -- e.g., HeightMeasure Aggregates: • When it is necessary to distinguish a component (aggregate) from a field use “Details” – E.g., EducationScoreDetails (not an EducationScore, which may be a field, a collection of data relating to an EducationScore)