Skip to content

Jan 22 Webinar: Universal Data Model Patterns, Len Silverston

Saturday, December 27, 2008

A well-conceived data model is a necessary foundation for any service oriented architecture (SOA). Architects looking for proven data model templates and best practices will find few resources more valuable than the The Data Model Resource Book series. In the recently published third volume (Universal Patterns for Data Modeling), data modeling experts Len Silverston and Paul Agnew, examine the recurring patterns that are essential for architects to understand in building and maintaining enterprise data models.

In this month’s Webinar, we are fortunate to have Len and Paul join us to review their latest book and comment on the applicability of “universal patterns” to human resource data models.


Order On Amazon


Len Silverston


Paul Agnew

Universal Patterns: How They Can Help You Develop Your HR Data Model

Date: Thursday, January 22, 2009
Time: 12:00 PM - 1:15 PM EST (9:00 AM - 10:15 AM PST)

[ Reserve your Webinar seat today. Space is limited ]

Len Silverston and Paul Agnew have discovered in decades of data modeling that there are “universal patterns” that apply to well over 50 percent of data model constructs and that can be reused for many applications, including human resources. For example, a roles pattern may be used to consistently model employees, contractors, workers, and other roles. A hierarchy pattern may be used to consistently model employee, position and organizational structures. A classification pattern may be used to consistently model demographics of employees as well as other parties.

In this webinar, Silverston and Agnew will define what they mean by “universal patterns” and explain how these patterns can be applied to the development of human resource data models. They will focus on some of the most common re-usable patterns, including roles, hierarchies, and classifications that can aid in the development of consistent, flexible and powerful human resources data models. These can be used to effectively model employee information, position hierarchies, demographics, and much more.

After registering, you will receive a confirmation email with instructions to join the Webinar.

Note that Volume 3 of the The Data Model Resource Book series as well as Volume 1 and Volume 2 are available for purchase on Amazon.com.

About the Presenters

Len Silverston is a best-selling author of The Data Model Resource Book series and a speaker and consultant with over 25 years of experience helping organizations integrate their information and systems. In 2008, he co-authored his latest work, The Data Model Resource Book, Volume 3, Universal Patterns for Data Modeling. Mr. Silverston has written and spoken extensively all over the world on topics such as re-usable data models, data integration, and power and politics in data management. He has published hundreds of holistic, re-usable data models and his book The Data Model Resource Book was rated #12 on the Computer Literacy Best Seller List. His book, The Data Model Resource Book, Volume 2, which provides universal data models for various industries, has been translated into Chinese. He is the winner of the DAMA (Data Administration Management Association) International Professional Achievement Award for 2004 and the DAMA Community Award for 2006. Mr. Silverston’s company, Universal Data Models, provides consulting, training, publications, and software regarding re-usable data models and data management strategies to help integrate information, systems, and people.

Paul Agnew is an author, consultant and speaker with more than 17 years experience in the data modeling and data integration field in many different industries. He is the co-author of the just recently released book, The Data Model Resource Book Volume 3: Universal Patterns in Data Modeling, Paul has worked in many industries as an expert in data architecture and data integration, including investment banking firms on wall street, telecommunications, insurance and engineering. In the last 8 years Paul and Len Silverston have worked together helping many of the top fortune 500 companies around the world build and integrate information systems using Universal Patterns for Data Modeling, and Universal Data Models. He has delivered many training sessions and seminars on Universal Data Models and Universal Patterns.

Filed in Architecture, Data Model, HRInterop.org, SOA, Webinar | Comments (0)

Standards for the Cloud: Constraints Breed Innovation

Wednesday, December 17, 2008

While the pace of business change is never slow, many observers note that the current economic downturn, far from slowing the pace of innovation, is certain to increase the pace of change within many sectors. The growing attention given to “cloud computing” is one example of economic constraints driving such change.

In recent a post, I promised I’d address the relationship between standards and APIs. A broad assertion that I believe holds up fairly well, is that standards are not APIs, but that ideally good standards figure into what makes a good API. As I write this post, I notice that IBM’s Bob Sutor has put up a post on his blog describing issues with the proliferation of APIs that fall short on measures of “compatibility,” “interoperability,” or “interchangeability.” Bob writes:

With cloud computing becoming more and more important, people are correctly asking questions about standards. My sense is that virtually none of the cloud environments are interchangeable and that interoperability among them is sketchy, at best. Unless one provider ends up being overwhelmingly dominant, interoperability will need to be improved.

Many would agree that standards potentially have a very important role to play in leveraging capabilities from the cloud. However, many also would agree that there are significant obstacles to realizing anything like standards-based cloud computing.

The Challenge for Standards Development Organizations

APIs tend to be developed by a single organization, sometimes in collaboration with partners, to achieve a specific goal such as opening sales and partner distribution channels, increasing the visibility of products or services, giving users access to data or visibility into processes, or providing users with higher levels of control, configuration, or collaboration. While it might be ideal from the perspective of a customer or partner relying upon an API that the API be standards-based, standards conformance is at best a secondary consideration from the perspective of the API developer. The API developer’s immediate concern is to deliver a design that will achieve a specific business goal and to finish the API on-time and on-budget.

This is what leaders of standards development organizations (SDOs) and standards evangelists need to keep in mind. Factors such as suitability to the immediate business goal and ease of implementation/use are always going to drive API design before considerations of standards conformance. I’m not writing off standards (not all, not yet), but it is increasingly clear that many if not most standards organizations need to change the way they operate to keep up. One source of the problem is that standards organizations may be the last great bastion for waterfall design methodologies. Analysis and requirements enter at one end of the process and a specification emerges many months or even years later, possibly followed by something like a real-world test of the specification in terms of a reference implementation. Agile, test-driven development in some form or other is rapidly becoming the norm everywhere except within standards organizations.

The other key challenge is one of constituency. I mentioned in an earlier post that there are at least a few sources of market metrics as to the type of APIs, as well as the particular APIs, that are gaining adoption. Available data shows growing use of RESTful APIs and general preference for simplicity. If you were compare the design characteristics of the APIs with strongest market adoption with the design characteristics of standards currently being developed by SDOs and Consortia, you’d find a gap. Standards organizations are behind in the shift to RESTful approaches. But even if you were to compare the SOAP-based APIs with market traction to SOAP/XML-based message standards offered by SDO’s you’d find great differences in complexity. You need look no farther than counting XML name spaces. These proliferate in offerings by standards groups whereas the SOAP-based APIs with adoption in the marketplace usually keep message payloads to a single name space.

There are likely many factors contributing to the gap between what SDOs are delivering and what the market demands. Obviously, most standards organizations answer primarily to internal constituencies with a narrower set of interests than those within the broader marketplace. This has some logic to it. The group most invested in the standard would tend to favor stability versus change. On the other hand, it is hard to see how SDOs with an internal orientation can remain relevant, much less be poised to make an impact on cloud computing APIs.

So what is an SDO to do? Simply stated, the challenge for SDOs is to “get agile” and to “open up.” Constraints will bring change and innovation. Perhaps some SDOs can adapt their methodologies to better ensure their offerings are aligned with market demand. Perhaps there is a role for new types of organizations or initiatives to work along side traditional SDOs. These are questions I’ll continue to explore in posts to this blog.

Filed in Architecture, Cloud Computing, RESTful, SOA, standards | Comments (0)

Cloud Computing Rants, APIs, and HR

Thursday, December 11, 2008

Along with the growing cloud-computing hype is growing push back along the lines that cloud-computing is merely a new way for vendors to pitch the same offerings wrapped up in the latest buzzword. Shally Steckerl, a recruiting strategist and consultant, delivers a blistering post along these lines on ERE.net.

It is easy to sympathize with Shalley and other users of HR services who see new buzzwords advance in vendor marketing campaigns often at a pace more rapid than functional improvements or efficiencies evident in the vendor offerings themselves. However, vendor marketing hype aside, cloud computing is (or should be), more than a re-branding of existing SAAS or ASP offerings.

As I mentioned in my previously post, there isn’t unanimity about what cloud computing is. However, most associate the phrase with an approach in which IT or business capabilities are accessed as services through publicly available (or readily available) Application Programming Interfaces (APIs). While HR abounds with SAAS providers, there aren’t many that arguably fit the cloud model. Most HR service providers today simply don’t have the well-defined APIs. There are companies that likely have a head start such as ADP Employease and Workday (links to API pages). However, contrary to what Shalley says in his rant and vendor hype aside, the cloud model is quite new and is distinct from mere SAAS and ASP offerings.

Another aspect of cloud computing that makes it different is the way data storage, access, and integration is handled. Today, much integration among HR systems is brute force replication and synchronization of data. In some ways, the proliferation of various best-of-breed SAAS offerings has simply increased the extent of data replication across systems.

In a full-blown version of cloud-computing for HR, employee and HR data would stay in place, perhaps even apart from any particular HR service provider. In this idealized version of HR cloud computing, data is integrated or (using the hip, programmable web vernacular) “mashed up” on an on-demand basis. This is a key difference from today’s SAAS offerings. Cloud computing implies data that data is available from cloud-based data stores, which can be read, updated, subscribed to, and maintained by various authorized HR services — enrollment, performance management, learning, compensation, etc. This doesn’t mean that there would be a single HR cloud database for an employer’s entire HR function. There likely would be a single cloud database for HR master data and separate stores for data owned or controlled by ecosphere partners. Examples of the latter might be competency content or candidate profile data.

Suffice it to say that the version of cloud computing introduced in the paragraphs above is not how HR services are provided today. Full-blown cloud-computing for HR is years away if realizable at all. Skepticism is warranted. However, it merits watching. End users should neither lump it in with SAAS and ASP offerings, nor tolerate loose claims from vendors related to providing services from the cloud.

While this is all very geeky tech stuff, I actually think many non-techie HR end-users have a growing appreciation for how cloud computing and the programmable web work. Consider the growing number of recruiters on twitter. Most of these recruiters know nothing about the twitter API other than that twitter has an API. They know it exists and it works because it is well evidenced by a growing number of third-party services and applications that the recruiters themselves use (e.g., ping.fm, TweetDeck, twitterfeed, etc). My point is that rather than just ranting about the latest vendor hype over cloud computing, ask questions. When vendors hype cloud computing ask them show you that APIs exist and where they live. Have them show you the reference implementations that evidence the value and utility of the APIs. Ask them how their vision of cloud computing enhances (opens up) collaboration with ecosphere partners.

Filed in Architecture, SOA | Comments (1)

Interoperability Linky Goodness

Thursday, December 4, 2008

Links to a few things I’m reading:

  • SOA Goverance and Canonical Model Development   More than just consulting with service stakeholders, your information architect needs to actively collect test cases, usually in the form of real-world data instances representing the particular entities being managed. If done right, this test-driven development will avoid the “analysis paralysis” that Biske cautions against while better guarantying that models meet the real-world requirements of stakeholders.

  • Which came first, the SOA or the data model?   The effective adoption of SOA requires a well-designed data model at the physical and logical levels. Many organizations even aim toward the development of a canonical domain model. The intersection between MDM and SOA is surfacing with increasing frequency and I expect this trend to continue for the next couple of years.

  • The emerging case for open business methods | Enterprise Web 2.0 | ZDNet.com   Whether your open business strategy is some internal Enterprise 2.0, crowdsourcing your next product design, or using customer communities to provide customer self-service, the business world of the next decade will look quite different from today and require different values and management styles to match.

  • The key to making health IT reform work | ZDNet Healthcare | ZDNet.com   The host of proprietary interests in medical computing today make most output garbage. A single word, and concept, can change that, but it must be demanded from the nation’s new CTO. Standards. Specifically, non royalty-bearing standards.
Filed in Architecture, Canonical | Comments (0)

APIs as business assets. “A big truck” or a “series of tubes”?

Thursday, December 4, 2008

Everyday there is more written and presented about what makes a good API.

In recent years, much discussion related to APIs has focused on architectural approach (e.g., SOAP-based web services vs. RESTful ones) or even how a specific approach (like REST) is best applied. Beyond all the blog-blather about APIs (this post included among the blather), there also is an increasing number of market metrics as to the type of APIs, as well as the particular APIs, that are gaining the most adoption.

Some of the metrics come from the API publishers themselves. For example, a key data point frequently cited with regard to Amazon web services (offered in both SOAP and RESTful configurations) is that 20 percent of the usage is SOAP, while 80 percent is REST. There also are a few independent sources of information about API usage. SOA analyst and born-again cloud-computing evangelist David Lithicum highlighted in one of his recent podcasts the website Programmableweb.com, which provides a directory of, and community feedback on, more than 1,000 APIs.

What Makes a Good API?

I won’t try to recreate the aforementioned blog blather about what makes a good API, but if you want to be spoon-fed a good, high-level introduction on this topic there really are few better sources than the webcast embedded below (also available here) by Joshua Bloch, a senior software engineer and architect at Google. This is a high-level review of technical design principles. I have a follow-up regarding one of Bloch’s early statements in the webcast about API’s as “business assets,” which I’ll get to below the embed.

API’s as Business Assets

To borrow (and bend) a phrase from renowned Internet expert, Senator Ted Stevens (fmr. R-Alaska), let me say that an API is neither “a big truck,” nor a “series of tubes.” Most businesses develop APIs for reasons such as opening sales and partner distribution channels, increasing the visibility of their products or services, or providing higher levels of control, configuration, or collaboration with users. My only mincing of words in terms of Bloch’s introduction to quality APIs, is with regard to his statement about API’s as “business assets.” In the context in which he makes the statement, it makes sense. I don’t worry about how a tech audience would interpret this remark. It is my experience that the business side of the house — e.g., product managers and business strategists — are more likely to misunderstand APIs as assets than technologists.

The subtle distinction here is that any API has little or no intrinsic business value. The business value associated with an API is derived only from adoption of the API and, of course, how well the API (or any API, for that matter) is suited to the desired business outcome or goal. An elegantly written API can be a company’s crucial link to customers, partners, and business growth or (back to my Ted Stevens reference) a tube to nowhere (or would it be a “big truck”?).

My point here is not to diminish well-architected APIs. Actually, it is quite the opposite. My experience is that the business side of the house sometimes gets too preoccupied with the tangible API and control over it, whereas the focus should be on what business results are desired and how to best position the API to be adopted by all stakeholders. Techies like Bloch obviously realize this, despite me seizing on his description of APIs as “assets”. It worries me less when techies use such a description than individuals to whom “assets” are regarded as things to accumulate, control, and conserve, which is almost the exact opposite of what is necessary for APIs to flourish and deliver business value.

In the next post, I’ll look at the relation between standards and APIs.

Filed in Architecture | Comments (0)

APIs, Cloud Computing, and HR

Thursday, December 4, 2008

The non-profit National Bureau of Economic Research officially announced on Monday what everyone has known for a long time - that the U.S. economy is in a recession. As the economy and stock market spiraled downward over the past year, at least one thing on the rise was “Cloud Computing” as a technology meme. (Of course, the phrase “technology meme” is favored since it sounds so much better than “hype” ;-> ) As is the case with these technology memes, the definition of the particulars is seldom precise. However, the reason for the increased number of conversations around cloud computing is easy to understand — Under current economic conditions, flexible, Internet-accessible technology and services are going to be in many cases much more attractive alternatives to building, buying, or managing infrastructure or business capabilities directly.

As the phrase is broadly used, “cloud computing” encompasses concepts such as “software as a service” (last year’s meme?). However, you also see the concept used in a narrower sense to refer to a style of computing in which IT-related capabilities are accessed as services through publicly available APIs. These services can fulfill basic infrastructure needs such as storage or virtual servers (Amazon’s S3 and EC2 being the best-known examples) or they can provide conceivably any other type of business functionality ranging from something tiny and specific (an address validation service) to something like the Force.com Platform that enables a wide-range of complex business functionality/capability to be built on top of the main Salesforce application.

But of course, none to which I refer is new. The architectural approaches are not new and neither are the services that I mention as examples. What is new is wrapping these up within the cloud computing meme.

Beyond the Hype, A New Focus on APIs

While the cynical might look at this as merely swapping last year’s buzz words for this year’s, many (me included) are buying into the notion that the latest economic earthquake, taken with other trends, will result in an additional and accelerated “tectonic shift” in the way enterprises fulfill a wide-variety of business capabilities, including HR management functions.

The other key trend that also is contributing to this shift is the growing number of vibrant developer communities that offer a seemingly non-stop pipeline of creative applications using social networking APIs. This gets to the issue I really want to examine over the next dozen posts or so. Along with the rise of the cloud computing meme is much renewed interest and thinking about APIs. This is both a technical topic (what makes a good API?) as well as a topic that many HR service providers are trying to figure out in terms of business strategy and growth.

Don’t these sound like fun topics? More to follow on both of these aspects of APIs.

Filed in Architecture, RESTful, SOA | Comments (0)

Common Data Types for Learning and HR

Monday, November 24, 2008

A successful standards initiative must influence as well as open itself to be influenced. I’ve mentioned in recent posts how HR-XML 3.0 advances the maturity of HR standards by incorporating design best practices and content developed by other groups (Open Applications Group, Inc. and UN/CEFACT). While OAGi and UN/CEFACT have much to offer, there are gaps. These organizations have focused primarily on material supply chains as well as domains areas such as finance, insurance, transportation, etc. There is no “HR domain” working group, nor are domains such as learning represented within UN/CEFACT.

Liaison With Learning Groups

There has been long-standing liaison between and among HR-XML and learning and education standards groups, such as the IMS Global Learning Consortium, the IEEE Learning Standards Technical Committee, the Postsecondary Electronic Standards Council (PESC), Learning-Education-Training Systems Interoperability (LETSI.org), The MedBiquitous Consortium, and the short-lived Web Services in Learning (WSIL) initiative. Unfortunately, an honest evaluation of the many years of HR/learning standards liaison would reveal few if any concrete results or progress towards convergence. Why? The fundamental reason is that each group, while in theory not opposed to convergence, quite naturally puts the immediate interests of its respective constituency in front of convergence goals. If convergence means breaking backward compatibility, it simply doesn’t happen.

So if existing liaison relationships don’t work and if big-bang convergence simply doesn’t happen, what is to be done? There is a third path that is beginning to be discussed. Rather than holding out for convergence or continuing non-productive liaison, the third path is for groups to focus on developing a small group of common components. While the HR and learning domains are not currently represented within UN/CEFACT, that organization does provide neutral turf for such a collaboration as well as a methodology to guide it (the core components technical specification).

This “third path” is not yet well defined or formalized. However, a first component I’ve put forward and on-which work has begun is “Score Type” (A numerical record associated with an individual in the measurement of abilities, capacity to learn, in the assessment of personality, or in measurement of other personal characteristics - e.g., credit worthiness). While this a small, single component, it is something that clearly has utility across the HR, learning, and education domains. The proposal I drafted was circulated among all the aforementioned .orgs and submitted to UN/CEFACT’s Core Data Type Catalog working group. The final version will be in the UN/CEFACT CDT Catalog due out by year end.

Hopefully, work along the same lines will continue. Agreement on a small collection of useful components is a lot easier than brokering agreement among different groups on bigger, more complex things (e.g., a framework for competencies). This third approach doesn’t require big-bang convergence nor immediate non-backwardly compatible changes. Each group can draw upon the resulting set of components as their release time lines and their priorities dictate.

Filed in Architecture, HR-XML | Comments (0)

The Roles People Play: Towards a Person Model for HR

Monday, November 24, 2008

Earlier this year, I wrote a couple posts about the “problem with people” — that is the problem of modeling people within HR processes and systems. Broadly speaking, the problem is that a single person associated with an employer or an employer-sponsored program has a certain set of intrinsic characteristics, but also has characteristics that are relevant only within the context of a particular role or relationship with another party.

The diagram below (click for large version) is intended as a high-level, conceptual depiction of some of these different roles.

As complex as the diagram is, it is easy to see how you might go much farther. For example, I’ve left out roles such as “learner.” I also have left out detailed delineation among roles. For example, one that came to mind, but that I didn’t depict in the diagram is distinguishing between the role of Candidate and that of Applicant. This can be a thorny issue since in many cases it might require application of “official constraints” (laws, regulations, etc.). If you’ve tracked what has gone on among various U.S. regulatory agencies (EEOC, OFCCP) in this regard, you know bright-line determinations are difficult (or should we just say “impossible”?). While this is complex, from a data modeling perspective it is possible to make simple assertions, such as that an Applicant is a type of Candidate that has become associated with an employment opportunity in manner consistent with employer practice, applicable law, etc.

Modeling People Across Roles

Why is this important? Consider that in the HR-XML 2.* architecture, each and every role depicted in the diagram above was within the library somewhere. However, each and every role was essentially a “one-off,” modeled only for the purposes of the particular schema in which it appeared. As I’ve discussed in blog posts earlier this year on the HR-XML website and in presentations I’ve given this year, one of the important features of HR-XML 3.0 is its inclusion of a “meta-model” useful for organizing the different bits of people data in a consistent way across different roles. Perhaps after the version 3.0 candidate release is published (real soon now?), I’ll revisit that meta-model in a blog post.

While I won’t review the meta-model today, suffice it to say it represents a vast improvement over the design (or lack of design) within the 2.* architecture and is better than similar content within the libraries of peer standards organizations. One of HR-XML’s founding board members, Gary O’Neal used to emphasize that success would depend on influencing others as well as opening ourselves up to be influenced. As I recounted in the recent series of posts, Looking Forward, Looking Back, HR-XML 3.0 represents the incorporation of best practices and design that originated outside of the Consortium. Knowing where HR-XML 3.0’s person meta-model stands in comparison to similar work by peer standards organizations, I believe a next challenge/opportunity for the HR standards community is to perhaps itself to shift roles to being one of an influencer. The broader community of HR standards stakeholders benefits if data about employees and other HR person roles are represented more consistently in the standards developed by supply chain, insurance, learning, and other domains. HR has long shown it can effectively internalize business approaches, processes, and technology from the outside However, when the topic is people within employment and work roles, who other than the HR standards community should take the lead?

Filed in Architecture, Canonical, HR-XML | Comments (0)

HR Interoperability Links - 2008-11-21

Friday, November 21, 2008

Links to a few HR interoperability-related items:

  • LETSI: HR-XML Consortium Seeks Cross-Domain Interoperability
    “Learning, education, and HR standards communities have very little to show in terms of cross-domain standards interoperability and convergence despite significant investments over a period of more than a decade.” Chuck Allen, Executive Director of the HR-XML Consortium, made this assessment of standards that cross the boundaries of standards-setting bodies in a “White Paper” submitted to the LETSI SCORM 2.0 Workshop held October 15-17, 2008 in Pensacola, Florida.
  • Ahh Shucks, SOA Is A Failure
    A letter from a fictional enterprise architect. Despite all of the things I have NOT done, SOA has failed. My additional failure to recognize and implement best practices that have been proven successful in many other companies worldwide also play into the failure of SOA.
  • Enterprise Mashups - The Icing on your SOA
    Deepak discussed how enterprises have been focusing more on infrastructure and technology and not on the consumers of data. As he coined it, many shops are “developing horizontally and not addressing the needs of the users”.
  • The Problem With People - HRM Today Social Network
    The problem is that a single person associated with an employer or an employer-sponsored program has a certain set of intrinsic characteristics, but also has characteristics that are relevant only within the context of a particular role or relationship with another party.
  • Extracting Details from Resume/CV
    Can any one help me out in extracting the details of a resume. I am using the logic - (1) First convert the resume file (txt,doc,html,pdf. etc) into XML (2) Then Convert the XML into HR-XML, which is now easy to parse.
  • Recruiting Software Goes Berserk — Again!
    Nearly 10 years ago, during the dot-com boom, Doug Merritt, then CEO of high-flying ATS-vendor Icarian, helped fund the nascent HR-XML Consortium with the express hope it would create a descriptively tagged resume template that would eliminate the informed guessing of parsing and extracting information from untagged resumes. A process that is still never more than 90 percent to 95 percent accurate — and it drove him crazy. The effort failed, even after Microsoft and Monster were brought into the negotiation, and obviously efforts continue to this day.
  • Trust Found in Next Gen Resume
    All stakeholders who handle the Next Gen Resume ™ benefit. For example, candidates can better represent themselves and employers can make more well-informed candidate selection decisions. Job boards can now have higher value data in their resume silo for employers to conduct better searches.
Filed in HR-XML, SOA | Comments (0)

IBM Websphere, MS BizTalk, and OAGIS

Friday, November 7, 2008

In some of my recent presentations, I’ve talked about where HR-XML has enjoyed uptake within the broader HR services ecosphere and where it hasn’t. See slides 11 and 12 from the deck embedded below (or if the embed is giving you problems, view here). Simply stated, HR-XML has had some success as a starting point for B2B integrations, such as those between applicant tracking systems and screening service providers. This is good. There is a lot of value in such connections. Where HR-XML hasn’t proved as useful is for those stakeholders that need a data model that works in a consistent way across HR business processes. I’ve mentioned in prior posts, the forthcoming 3.0 library goes a long way towards providing the uniform model that has been lacking.

On slide 12, I cover support by “tool and platform” providers. There are a few success stories here, but these are fairly specialized offerings. For example, in one of our recent Webinars, Pilotfish Technology demonstrated an HR-XML-2_5-Enrollment to ASC-X12-834 transformation offered with their XCS eiConsole platform.

With the version 3.0 release, HR standards are much better positioned for some level of support by enterprise application integration (EAI) vendors. This is mainly because the version 3.0 release fits into an architecture that is bigger than just HR. As I’ve written elsewhere, the version 3.0 library will be the first industry standard to be designed as a plug-in to the Open Applications Group Integration Specification (OAGIS).

The Open Applications Group has been quite single minded in advancing the OAGIS architecture through 4 major revisions. OAGIS is now at a point in maturity where it is starting to get direct support by major EAI vendors. The latest evidence in this regard was Microsoft’s release at the end of September of a BizTalk Server 2006 Developer Guide for OAGIS. The document provides guidance on using BizTalk with OAGIS Business Object Documents (BODs) and goes through a simple purchase order processing scenario using the OAGIS AcknowledgePurchaseOrder, ConfirmBOD and ProcessPurchaseOrder BODs.

Microsoft is just latest to turn its attention to supporting OAGIS. IBM’s Websphere Commerce has for a couple of years offered a set of service interfaces based on OAGIS BODs. You can find very extensive documentation of these interfaces on the Websphere Commerce Website.

There are no guarantees. However, it sure makes sense that aligning HR business language standards with an architecture that is getting increasing attention by major EAI vendors increases the chances for direct support of HR standards as well. My slide 12 was the one dealing with “platform” support. Go back to slide 11. Better support in EAI tools ripples throughout the ecosphere. In 9 years of working with HR-XML, I’ve learned that there are widely varying capabilities out there. I can assure you there are some organizations that simply aren’t likely to adopt standards until they they are supported directly within the tool sets they already know and have deployed.

HR-XML 3.0 Preview: A Next Generation in Standards for HR Services
View SlideShare presentation or Upload your own. (tags: hr xml)
Filed in Architecture, HR-XML, OAGIS | Comments (0)