Modest Rant — Applications Integration By Any Other Name… Is Something Else

Painting The Roses Red

Given the active discussion (debate?) over on LinkedIn about my proposed definition of true SaaS (now renamed “Blooming SaaS,” this post was intended to be more of an insistence on precise definitions than a disparagement of other business/deployment/architectural options in enterprise HRM software), I thought I’d rattle a few more cages.  In the interests of encouraging a lively discourse, here I’m tackling the concept of applications integration.  If you think that there’s grade inflation in our schools and in workforce performance measurement, that’s nothing compared to what’s happened to the humble term integration as applied to HRM applications software.

Once upon a time, in a kingdom far away, we had two terms for the way in which applications might be connected.  We called them interfaced, when disparate applications were connected, and integrated, when applications were built from the ground up to be inherently connected.  Everyone understood the differences, and there was peace in the land of (then) data processing.

Interfaced meant that we would pass a file (which could well have been on a reel of tape carried quite literally from one system to another, at least in the very early days of my career, or a transmitted electronic file or an agreed and shared Web service in more recent years) containing data written by one system that was intended to be read by another.  The format of that interface file was either imposed by the more powerful (politically or economically) of the two systems’ owners (e.g. health care plan providers, to this day, have considerable leverage when they insist that incoming employer files be formatted to their receiving specs) or negotiated agreed mutually (as was the case when two independent systems, even those owned by the same vendor, needed to move data between them).  And even as the technology for interfaces has advanced considerably (although delimited electronic file transmissions are still in wide use), what’s important to note here is that an interface does not impact directly the sending or receiving system.  The sending system knows how to create the interface and the receiving system knows how to use it, but they are otherwise just as independent as is AMEX from Amazon when I charge purchases on the latter to my credit card with the former.  In spite of their near real-time and highly automated exchange of agreed protocol messages, their connections still fit my definition of an interface.

In that same far away kingdom, once upon a time, integrated meant that although an application may have consisted of many automated processes/reports/edits/user views/whatever, they had all been developed against the same data design and architecture with the same programming standards applied across all the related code and, most importantly, with the same underlying assumptions about the subject matter domain applied across the entire application or set of applications as defined by the underlying data definitions.  Even as data designs evolved to database schemas and on to object models incarnated as objects, even as architectures evolved to take advantage of cooperative computing and layered designs and to address the needs of connected/social/mobile/self-service/global computing, and even as I lost complete track of how today’s enterprise applications are really constructed (along with many of you), I (some would say foolishly) continued to used the term integrated to refer to applications that were developed against the same object model and architecture with the same definitional development standards applied across all the related functionality and, most importantly, with the same underlying assumptions about the subject matter domain applied across the entire application or set of applications as defined by the underlying object definitions.

And then, when I wasn’t looking, the evil witch stole those very clear and quite different definitions of interfaced and integrated and replaced them with an absolute muddle so that HRM software vendors doing interfaced (but with some truly creative approaches to (1) ensuring that user experiences were consistent across disparate applications, (2) doing reporting/analytics/etc. against a consolidated data store, and (3) minimizing the differences across their applications in terms of domain assumptions) applications could describe their offerings as integrated.   Clearly those vendors appropriating integrated to mean interfaced (but very cleverly so) felt that the term integrated communicated more goodness than interfaced or they wouldn’t have appropriated it.  But in doing so, they forced the vendors with truly integrated application suites, what we’ll now dub “Blooming integration,” to search for a new term that means what the old integrated meant before there was grade inflation.

So out came unified, organic and G-d only knows what else to distinguish between those applications that were in fact integrated by my definition and those that were interfaced, again by my definition, no matter how sexy or attractively that interfacing is done.  Well, bah humbug on that.  None of these terms have the gravitas of integrated, and the vendor marketeers that stole integrated for their own nefarious purposes know that.  So just as I did with “Blooming SaaS,” I’m going to offer the stamp of “Blooming Integrated” to those vendors who really qualify — and call the rest “Blooming Interfaced,” again no matter how effectively it’s done.

But why should customers and users of HR technology care about any of this or is this really just an “inside baseball” discussion among dilettantes with nothing better to do?  These distinctions should matter a ton to customers and users because every dollar that must be spent on maintaining those non-Blooming integrations is a dollar that’s not going to be spent on product enhancements, customer support, thought leadership, and so much more.  And the greater the inherent interconnectedness of the underlying processes and objects of those non-Blooming integrated applications, the more money must be spent — now and forever — on keeping those non-Blooming integrated applications tied together as much as possible.

I’ll leave it for another post to dig into which HRM applications most need to be “Blooming Integrated” versus those which very conveniently can be left to connect via great, highly leveraged interfaces.  But there’s a good taste of where my thoughts are going in the recent #Predict14 videocast sponsored by Workday, beginning at minute 3.30, with more discussion here.  Hopefully, this gives you a little something to chew on mentally when you’ve chewed yourselves beyond full with Christmas dinner.  And may I close with my heart-felt prayer for a little more peace on earth in 2014.