Modest Rant — Blooming SaaS Or Not

[After a really terrific discussion of this post’s original version, along with a zillion surrounding/closely related topics, over on LinkedIn, I’ve updated the terminology in this post as of 12-3-2013 to replace “true SaaS” with “Blooming SaaS.”  This change is not intended to be facetious but rather to ensure that using value-laden adjectives, like true or pure or real SaaS, doesn’t obscure my efforts to develop or the importance of having agreed definitions for critical concepts in HR technology.  In the future, when you hear/read me using the term “Blooming SaaS,” you’ll know exactly what I mean.]

I’ve been accused, primarily by those who would prefer a less than fully educated consumer, of obsessing over HRM enterprise software object models and architecture.  On the other hand, I would say that I’ve been paying close attention to what really matters, to the foundations upon which durably profitable and customer-serving software is based — and with good reason.

Software’s core object models and architectural foundations are rarely changed except when there’s a generational shift in our industry.  Getting them right determines whether or not a vendor will be able to deliver needed functionality at the right combination of cost, quality and time-to-market, not just once, but over and over again for the life of that architecture.

This is very much like the basic layout, structure and foundations of our home.  Even as many ongoing enhancements and extensions are quite feasible and expected over the course of a lifetime’s use, tearing up the foundations (in our case a cement slab on which our home is built because the water table in south Florida is very close to the surface) because we never plumbed for a fourth bathroom or didn’t anticipate wanting a much bigger central living area just isn’t feasible without essentially starting over.  When your family makeup/lifestyle/circumstances etc. have changed so much that you begin to contemplate ripping up that foundation in order to overhaul your home, it’s absolutely time to look for another house (in SaaS terms, to look for a vendor with no legacy baggage) or to knock this one down and start over (in SaaS terms, to stick with a legacy vendor but bet on their own efforts to start over in a new product line).

Given this context, it won’t surprise you that I’m very precise in my definition of SaaS and frequently call out the incorrect use of this term to mean nearly anything that’s subscribed and hosted by the vendor.  And we won’t even get started on what loose lips are doing to the meaning of “cloud.”  Having been an English major (after realizing that I’d never become a great nuclear physicist in spite of my best efforts), I can’t help myself from going nuts when words are used to mean whatever the marketing teams decides they have to mean.  So I’ve selected, as my background music for this post:  We’re Painting The Roses Red!

SaaS isn’t just anything that vendors without it want it to mean.  When we were going from mainframe apps to client server, as soon as client server became the momentum player (so as soon as PeopleSoft began gaining traction in the market) around 1990, every vendor of outdated mainframe software put a screen-scraping GUI face on their old crap and called it client server.  How I wish I had had Twitter and a blog then to denounce the scoundrels.  The good news is that they have all passed into oblivion even though a few poor customers are still running an ancient implementation of Cyborg, Genesys, Tesseract, Integral, MSA etc.  The bad news is that the latest batch of legacy vendors/application will have a much longer denouement because the much larger size of their installed base maintenance revenue will keep some of them going for longer than I’m likely to survive.

In my view, any vendor which offers so-called choice — licensed/on-premise, subscribed/on-premise, licensed/single tenant hosted, subscribed/single tenant hosted, and every variation of non-cloud cloud — is not a “Blooming SaaS” vendor.  They may offer good products, they may provide an option that’s absolutely correct for a specific customer, and they be your favorite vendor with which to do business.  But they are not a Blooming Saas vendor, and it matters for reasons cited here and here .  No shame in selling/buying/using something other than Blooming SaaS if that’s the right answer for you, whether vendor or end-user, but there is great shame in not knowing or naming the difference —  or worse, knowing the difference, and trying to fool the public about it.

For the record, here’s my definition of Blooming SaaS as it relates to HRM enterprise software:

1. Software is subscribed to customers, usually on a multi-year basis, ranging from 3-5 years, but some do monthly, annual, more frequently adjusted subscriptions.  Smaller, less critical and more easily replaced applications may be available very appropriately on a truly pay-as-you-go basis without a more substantial contract and even on a freemium basis with charges only for add-on capabilities or services.  These subscriptions are usually on a usage basis, e.g. number of serviced employees or workers, and there may also be, especially for broader and more complex applications, some up-front payment for implementation support and, perhaps, a subscription prepayment for a portion of the term.  Of interest to me is the preference of larger/more complex organizations, especially when they’re rebuilding their HRMS/TM foundations, for longer term subscriptions that “lock in” as much as possible their expected subscription rates even as their actual payments may increase or decrease along with the contractual units of usage.
2. Software is hosted by the vendor.  The vendor owns the entire responsibility for operating the code base and providing customer/tenant access to it.  The software may be hosted at one or more 3rd party, industrial data centers or even in a truly elastic commercial cloud, although getting the right SLAs for security, backup and recovery, not to mention privacy protection in a true commercial cloud may still be a work in process for HRM enterprise software.  Of course buyers should consider every possible test of operational capability before subscribing Blooming SaaS, but many (most?) buyers find that reputable Blooming SaaS vendors maintain much higher SLAs (service level agreements) than do their in-house IT organizations.
3. Blooming SaaS software is designed and built from the ground up to be not only multi-tenant but also to be operated in this fashion.  And all customers, even when there are multiple instances for different geographies/target markets/load balancing/etc., use the same code base.  Vendors own the entire responsibility for delivering frequent, non-disruptive and entirely automated upgrades to that code base, and for doing so either at precisely the same time or over a short (weeks not months) period of feathered upgrades.
4. With major upgrades coming multiple times per year and very frequent upgrades coming as needed to support regulatory developments, keep up with mobile device changes, and fix any bugs, Blooming SaaS vendors must invest substantially in the infrastructure for managing these upgrades across their entire business.  Keeping customers informed, agile handling of the entire lifecycle of their products, supporting cross customer collaboration, and so much more go into running a SaaS business successfully.  Yes, it’s about the software, but it’s about so much more than the software.
5. There are no customizations allowed in Blooming SaaS, but there are extensive configuration, including extension, capabilities delivered by the vendor, with each customer/tenant’s configurations protected automatically during the vendor-delivered and entirely automated upgrades.  From tuning the customer experience (UX) to each customer’s corporate look and feel, to adding customer-unique objects/relationships/methods/attributes/valid values as well as processes and workflows, and on to all of the inquiry/reporting/analysis/visualization functionality that’s specific to a customer, good SaaS supports all of this through vendor-delivered tools whose intended user is a business analyst (a real one) rather than a programmer.
6. To make this level of configuration possible, to enable the vendor to deliver tons of new functionality multiple times per year over many years without breaking the software’s foundations or running up cost/time-to-market/error rates, modern software (SaaS or otherwise) is developed mostly without writing a lot of code.  In modern software, must of the functionality is abstracted to metadata (effective-dated metadata of course), and many types of configuration is achieved by making changes to that metadata in those areas to which customers are given access.  Other functionality is delivered by means of tools driven by that metadata, e.g. a inquiry tool whose knowledge of the underlying object model is expressed as metadata to that tool.  In Blooming SaaS, all cross-tenant (i.e. cross-customer) metadata (typically business rules, process flows, UX specifications, and similar) and reference data (typically the valid values for complex object attributes like tax rates or country codes)  is managed by the vendor with a single physical instance shared across customer/tenants.

I’ve got a lot more to say about the object model and architectural foundations of not just Blooming SaaS but really good Blooming SaaS and about the design of a Blooming SaaS business, but I think I’ll stop here for the moment.  This is a tremendously important discussion which raises another aspect of what I call SaaS InFullBloom (for lack of a better term that provides the precise definition I want to present with more thoughts here).  If there’s one thought I’d like you to take away from this post, it’s that what you can’t see easily in the software and vendor you’re considering is what’s most important to evaluate.  So, while waiting for my next installment on this, here’s a little homework.