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.

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.