This is the first of what I suspect will be many posts for which the impetus is a question from a specific colleague, in this case Dennis Howlett. So as to give credit, or at least curiosity, where it’s due, this one’s for you.
Having seen me refer to (Dennis might say pimping) my latest post on Twitter, “Multi-tenancy: Tables Stakes For HRM In 2011,” and no doubt after reading every post and article I’ve written on the subject (all of which are posted on this blog site), he sent me a perfectly reasonable and very Dennis-like direct tweet: “Why do you keep banging on about MT? It doesn’t make sense unless there is something humungous I am missing.”
Well, if you’ve read any of Dennis’ work on ZDNet, AccMan or followed him on Twitter , you’d know that he’s a pretty smart guy with strong opinions. So, if after reading my complete works on the subject of multi-tenancy, I had somehow not made the business case to Dennis, shame on me. I immediately responded to his inquiry and, given his feedback, my response was useful. But the more I thought about it, I more I felt that, if my previous writings hadn’t made the business case for multi-tenancy to Dennis’ satisfaction, I had better take my latest response to his question and turn it into a post — and so I have.
This is what she wrote:
“There’s something humongous that you’re missing, at least as regards the HRM domain. First, there’s a ton of dynamic business rules/content/etc., including regulatory stuff as well as common/good practice stuff (e.g. competency models) that modern software abstracts to meta data and which needs to be shared across customers (so one instance of this meta data shared across tenants and inherited by each, with the appropriate geographies for regulatory stuff). The advantages in cost, reduction of errors, speed of updates, etc. from being able to do this type of inheritance is substantial and, hopefully, factors into what vendors charge or could charge their customers. Second, there are good opportunities for aggregating useful data across customers (i.e. across tenants), ranging from the type of crowdsourcing that helps vendors see what features are being used, where there are challenges using them, etc., all of which should help vendors invest their resources more wisely and fix issues before they are huge, to benchmarking (e.g. ADP’s labor market data) to creating pools of contractors or applicants shared across tenants (obviously with the permission of all involved parties). While both inheritance and aggregation across customers can be done in single tenant virtualized environments with a variety of add-ons, all those add-ons introduce complexity, cost, and points of failure. These are by no means the only reasons I feel so strongly about multi-tenancy, but it’s been a long day of meetings and travel — really three long days — and, to use your expression (which I love), I’m knackered. Happy to do a call on all of this if we can schedule for next week.”
There are so many reasons for multi-tenancy in a SaaS world that we should now be asking the question: why would you want to subscribe software from an HRM software vendor or run on a BPO platform that isn’t multi-tenant? There are a few reasonable answers to this question, but they don’t apply to the vast majority of us. But if you too have questioned my perspective on this, I hope that the above (plus the other materials on this blog site) has made the case.
(Cross-posted @ In Full Bloom)