Spaghetti Recipes: Implementing an ESB Without Architecture

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.

SaaS offerings offer predictable pricing, continuous integration of new features, and often involve fewer risks and lower maintenance costs (no direct maintenance costs) compared to implementing the same functionality within a traditional ERP environment. However, integrating a collection of distributed SaaS-model services with a core HR system has its own challenges. Indeed, another area where HR likely leads other enterprise functions is in the extent of so-called "spaghetti integration." This phrase is used to describe where an individual system component is hard-wired to the each and every other component with which it needs to share information. Frankly, the primary way a lot of SaaS-model HR services stay synchronized with core HR systems and other HR services components is by employing some fairly primitive and hard-wired flat file exchanges (comma separated values and the like).

Last year, I was a panelist for a webinar that IHRIM sponsored on the topic of service oriented architecture (SOA). I talked about a number of different styles of SOA, including "outside-in SOA." Outside-in SOA was a phrase popularized by SOA analyst and evangelist David Linthicum. The outside-in style is about developing internal service abstractions to rationalize what might be a diverse range of existing, externally provided services. An enterprise may or may not have influence over the exact interface used to move data directly to or from an external provider, but it can rationalize how any other service component interacts with that provider through its own abstraction of the service and through the use of a service intermediary, such as an ESB. Instead of hard wiring diverse components to one another, they connect via the service bus. The service abstractions together with a canonical data model enable diverse components to talk to one another across the service bus in a loosely coupled manner instead of using a hard-wired, spaghetti-style approach.

There have been dramatic changes in HR services delivery during the past decade. One can expect that the eventual upside of the current business cycle (which hopefully isn't too far away) will bring with it still new types of HR service offerings and new delivery options. Getting a start on a light-weight, "outside-in" services architecture will help HR systems stakeholders rationalize their current set of internal and externally provided services as well as be positioned for the next wave of change.

Make Architecture, Not Spaghetti

The important point for HR IT stakeholders to keep in mind is that ESBs aren't magic. An ESB knows nothing of your business needs nor does it automatically create architecture to support those needs. In other words, ESBs provide infrastructure, not architecture. Those who implement ESBs outside a solid architectural foundation may find themselves adding to a pile of spaghetti versus making any real headway in rationalizing their use of distributed services.