SaaSy Is As SaaSy Does

SaaSy Is As SaaSy Does

An introduction to SaaS: architecture, business model, and deployment option

By Naomi Bloom

From the perspective of an HR leader or specialist, what matters about technology is how it helps them achieve the human resource management (HRM) outcomes that lead to and support their organization's business outcomes. However, they need to consider at what cost, risk, pain and reliability does technology deliver the needed administrative and strategic HRM capabilities? That's the bottom line; all the rest is tactics.

Today, HR leaders are interested in using technology for purposes that go way beyond traditional administration and compliance and drive to the heart of improving business results. They want to improve the quality of their hire decisions, engage the workforce in productive behaviors, enhance the capabilities of that workforce, manage key employee segments on a regional or even global basis, reduce their overall compensation and benefits budgets while achieving the same or better attraction and retention results, and increase workforce agility. There's no question that HRM software, at least the best of the available software, really can help organizations accomplish all of this and more when properly selected and implemented. But there's little value if any to those HR leaders from software that limits the creativity of their business rules, takes forever to implement, or calcifies once implemented.

Today, Software as a Service (SaaS) has emerged as one attractive model to which HR leaders look for the software they need.  A potentially more cost-effective approach that allows buyers to pay on a monthly basis, it also effectively relieves them of many (but not all) IT and upgrade burdens along the way. Many organizations already employ SaaS in their organizations through the use of popular applicant tracking systems (ATS) as well as a number of other packages, and the technology has matured from its early day to become a truly reliable method of service delivery. But that wasn't always the case.

Not so long ago, the only really practical tactics available to firms of any size to obtain the needed HRM application software were to:

• License a core ERP or standalone HRMS at a considerable capital outlay with a 20-plus percent annual maintenance payment from a relatively small (and rapidly decreasing) number of vendors;
• License (as needed) equally costly add-ons, with their own capital outlays and annual maintenance fees, from so-called, best-of-breed specialist HRM package vendors;
• Implement all of that software themselves; and
• Deploy it in data center facilities of their own or have it hosted for them by yet another 3rd party IT data center operator.

The architecture of these licensed packages was designed to support one enterprise running on one instance of the software with one specific set of databases. The business model was for those package vendors to sustain fairly long and complex pursuits of mega-buck deals in both up-front license fees and in perpetuity annual maintenance fees. These were expensive, time-consuming, and risky undertakings, with which the industry nevertheless had a lot of experience. However, they were not very hard to understand from a business model, architecture, or deployment options perspective.

During the late 1990s, a number of new HRM software vendors, heavily focused on staffing automation and funded entirely by venture money, came to market with the idea that they would host their own software for each customer, who would pay a subscription (pay-as-you-go) rather than a license (large upfront capital outlay with substantial annual maintenance fees) fee. They thought at the time, they could manage very rapid upgrades, thereby allowing them to come to market more quickly and to build out functionality behind the scenes. They also thought that they could make the buy decision a lot easier for their customers, shortening the sales cycle considerably by taking the in-house IT costs out of the evaluation.

This early version of on-demand applications, where the vendor was called an ASP (application software provider), hosted its own software, and charged fees based on a subscription rather than capital outlay basis, did shorten the sales cycle by removing much of the IT footprint and capital outlay angst. However, few to none of these ASP vendors ever became profitable, and therein lies a cautionary tale.

There was a lot of good thinking here about deployment options and business models, but many of these early "on demand" HRM software vendors have long since disappeared. They discovered that their operations and support costs were totally unaffordable because they were essentially running an instance of their software for each and every customer.  Furthermore, many of them came to market without solid underlying object models or architectures, and their rapid release of enhancements was hampered by the burden on their clients of incompatible data and functionality from release to release, not to mention constantly changing user interfaces.  And with no big upfront license payments, these pioneers of ASP/on demand software lost money on every customer.

But there were many important lessons from these experiments in off-premise deployment and pay-as-you-go business models, which true SaaS (software as a service) vendors have learned:

• Without being able to run their software on a one-to-many basis, the costs to the vendor for deploying/upgrading/supporting the software were too high;
• Off-premise doesn't mean out of sight or disconnected. All the same interfaces that keep that on-premise spaghetti portfolio of applications connected must be recreated when an off-premise application needs those same connections;
• Configuration by client is just as important a capability in off-premise models;
• Without full architectural multi-tenancy (as opposed to multi-tenancy provided through the use of blade servers and/or virtualization), no vendor can begin to cope with extensively configured customer instances at a profit-making cost;
• While it's certainly possible to use single-tenant software as the basis of some flavor of SaaS, its costs will always be higher than that of a SaaS vendor with truly multi-tenant software; and
• When you add architectural multi-tenancy capabilities needed for customer-satisfying on-demand software, not only are the total costs of ownership (think IT-related costs) reduced tremendously, but the improvement in total cost of service delivery (think IT-related plus customer servicing costs) is substantial. And it's total cost of service delivery that matters to HR leaders because they must deliver the service to employees, managers, and many others.

SaaS is the response to these lessons. It is an architectural, business model and deployment approach taken by the vendor/owner of an application software package in which the application is owned, delivered, and managed remotely by that software vendors. SaaS applications are NEVER implemented in-house by their customers, but they are designed to provide substantial integration capabilities. I would add that while the server environment might be outsourced by the software's owners, managing those servers and related resources for incredible up-time and response-time is a core competency of a SaaS vendor.

SaaS applications are based on a single set of common code and data definitions, which are consumed in a one-to-many model by all contracted customers at any time. There may be reasons of operational performance to load balance or to configure the software differently for different target markets, i.e. to split the set of all customers across two physical instances of the code and use cloning or other techniques to keep both instances in sync, but there is only one logical instance even in this case. And architectural multi-tenancy is not just about sharing code and a database but much more importantly about sharing those business rules, work flows, and other configurations that should be shared (e.g., U.S. tax tables when the SaaS application is payroll) while having the fullest possible configuration by individual client (e.g., user experience look and feel, client-specific coding structures, and client-specific processes).

Finally, SaaS applications are always subscribed on a pay-per-use or subscription basis. Here, too, I would add that there is usually a subscription period of at least one year with incentives provided for longer subscriptions. The broader, the more complex, and the more implementation work that the software requires, the longer the subscription periods that are needed to ensure profitability for the vendor as well as a return on their implementation investment for the customer.

While any application software package can be hosted or provided on-demand and paid for on a subscription model, only software designed explicitly for the purpose of SaaS has the architectural multi-tenancy that is at the heart of this concept. Signing up with an HRM applications software vendor who cannot achieve the lower costs of software delivery and higher level of client-specific configuration that are possible with full architectural multi-tenancy may mean signing up with a vendor who isn't going to be successful.

Naomi Bloom is managing partner of Bloom & Wallace, an HRM delivery systems consulting firm based in Fort Myers, Florida.