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

Join us for a Webinar on July 15, 12:00 noon EDT
Space is limited. Reserve your Webinar seat now at:
http://www.hrinterop.org/webinar/

The term "Enterprise Service Bus" continues to create confusion. This is in part because the term is used in a few different ways. "ESB" sometimes is used in describing an architectural approach towards enterprise integration relying on intermediary software to perform message brokering, routing, transformation and similar functions. At the same time, "ESB" also is applied to the broad and evolving category of middleware used in implementing ESB architectures. Adding to the confusion, the ESB category of middleware is so diverse that it defies "apples-to-apples" comparisons of ESB capabilities and features.

The purpose of this webinar is to demystify ESBs for HR IT stakeholders. Within large and medium-sized enterprises, it is common for HR systems to connect into the "enterprise service bus." However, HR IT typically is a relying party and doesn't always exercise control or influence over how ESB infrastructure is applied to HR integration scenarios. In many cases, there is no shortage of middleware or ESB infrastructure within the enterprise, but simply a lack of adequate attention given to the application of such technology to complex and rapidly evolving HR integration scenarios. While some HR integrations are quite pedestrian and well known (HR systems ultimately tie into any enterprise application needing to know who is a current employee), HR increasingly is a step ahead of other enterprise functions with regard to complex integration challenges such as interactions with enterprise portals and SaaS and "cloud-based" resources.

Many thanks to Len Silverston and Paul Agnew for their participation in yesterday's seminar, Universal Patterns: How They Can Help You Develop Your HR Data Model. A screencast of the webinar is in production, but in the mean time, you can browse and download the slides that were presented using the embed below.

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.

My copy of Todd Biske's new book, SOA Governance, arrived today. It is mainly well done. Before you order you should know that this is much more in the genre of a management book than a technical reference. Much of the book uses a narrative about a SOA implementation at a fictional company, Advasco, as a device to explore SOA implementation and governance issues. The book isn't likely to solve all your SOA challenges, but it is useful and an easy read. Among the material that is particularly valuable are the role/position descriptions for a SOA team in chapter 8.

While I'm generally positive about the book, I do have a few issues it. As you might expect, there is a division in the book between "design-time" SOA governance and "run-time" governance. While Biske talks a bit about "design-time checkpoints," he only really talks about testing and measurement as a post-launch, run-time task. For example, Biske writes "the final process associated with SOA governance is that of measurement and improvement". I think something that is missing is a specific mention or any emphasis of the role of iteration and testing during design time. For example, if you read through the section on developing a "canonical model," it sounds more like a classic "waterfall" approach that is highly dependent on accomplishing the correct upfront research and the right agreement among stakeholders ("Consult all potential service consumers," etc.). My own advice would be for SOA implementers to expect model development (perhaps the most important "design time" activity) to be highly iterative and to be test-driven as much as possible.