Building SaaS

SaaS Architecture Can Make All the Difference for Buyers - Over the Long-Term

The topic of SaaS architecture is gaining increasing attention, and that is a very good thing for buyers. Enterprise buyers need to be aware the underlying architecture can have a huge impact on their long-term SaaS ownership experience, even when the screens from two SaaS vendors show the same functionality.

In business terms, the underlying SaaS architecture helps determine the long-term solution value in many ways by asking questions such as:

• Data Flexibility – Can client-defined fields be added? Can they be put anywhere on the screens? Are they reportable? Can they be acted on by business logic such as process workflows?
• Process flexibility – Can processes and screens be fully configured to adapt to the enterprise’s vernacular and workflows?
• Reporting – Are all data elements reportable? Is reporting real-time? Is reporting available 24×7? How fast is typical access to reporting?
• Ease of integration – How many off-the-shelf integrations are there? More importantly in an enterprise context, how quickly can the software be integrated with the on-premise ERP/HRIS backbones with enterprise-specific configurations?
• Performance and Scalability – How fast are the typical screens? As the SaaS solution’s data and user volumes grow, how will it perform and scale?
• Longevity – How long will the current architecture last without requiring rewrites or re-architecture – 5 years and 10x data/user volumes? 10 years and 100x the volumes? How efficiently can the provider adopt new UI technologies for mobile and future unknown access methods?
• R&D Efficiency – How much R&D effort does the SaaS provider put into functionality vs. architecture layers?

The last point is one of the long-term benefits of true SaaS over on-premises software – almost all R&D for a SaaS provider should be targeted at new functionality on the SaaS provider’s single optimized technology stack, rather than (for on-premises software) having to port across many underlying technologies, having to support and maintain the software on all permutations, and maintaining dozens of old versions of installed software on a mixture of technology stacks. The more R&D a SaaS provider puts into a proprietary database or programming tools – or if they eventually have to rewrite a component of their solution – the less they have for future free functionality.

With on-premises software, you get exactly the features in the current release that you install. With true SaaS software, you also get all the future features that the SaaS provider creates (with free automatic upgrades), so the SaaS provider’s going-forward product roadmap, R&D investment level and efficiency, and the underlying architecture should be key considerations in the decision process when selecting a SaaS solution.

(Also cross-posted on IQNavigator.com's blog)

Is SaaS the next IT "Big Thing"?

As a thought-starter to the MIT/CIO Magazine Symposium on May 20th, CIO Magazine's Publisher Emeritus Gary Beach recorded a short video introduction where he posits that "IT beats to a 15-year drum".

Starting in 1950 with the mainframe computer, he says, every 15 years a platform transformation comes along that disrupts IT: the minicomputer in 1965, the PC in 1980, and the browser in 1995. That makes 2010 the witching hour for the next disruptive IT platform transformation - what is the next IT Big Thing?

While IT trends like mobility/wireless, cloud computing and virtulization will all cause big changes for corporate IT, I'm putting forth the case that SaaS is the next IT "Big Thing". Rather than just accomplishing incremental change or doing the same things better, SaaS is fundamentally disruptive to both IT's role in the enterprise and the end-user experience with IT:

• IT's Role: IT's role will evolve away from building data centers, selecting & buying servers, purchasing infrastructure software (eg Oracle, WebSphere), developing custom applications, and learning how to install/configure/manage/monitor/optimize all of this, towards SaaS vendor diligence/management, service coordination/integration, and data control/management.
• User's Experience with IT: The typical corporate user's experience with IT will evolve away from the effects of IT's lock-down mentality (no upgrades or changes, must standardize everything) and often glacially slow responsiveness, towards IT quickly delivering new services, granting end-user control and configurability, ongoing change management, and continually increasing/improving service capability with SaaS's ongoing pain-free & cost-free upgrades.

Like Gary's other game-changing platform transformations, IT is resisting the SaaS trend due to perceived less control, influence, and mission-criticality. Nevertheless, the fundamental economic advantages and end-user advantages of SaaS will cause it to take over more and more of corporate software services over the next decade.

In my view, that makes SaaS the next IT "Big Thing".

Why On-Premise Software Vendors Can't Innovate

Vinnie Mirchandani started a firestorm with his observation that "in existing Oracle internally-developed and acquired products in the last 5 years, Oracle’s enhancements have been anemic."

How should we measure innovation for enterprise software? I think it should be measured by customer business impact - not press releases or software demonstrations or even what's "available for download" from the vendor's website, but what is actually used by customers and how much it improves their business results. After all, enterprise software is all about streamlining business processes and enabling enterprises to do things they couldn't do before.

And this is where on-premise software (not just Oracle) falls woefully short. It doesn't have anything to do with talent or effort, there are thousands of hard-working, smart developers at Oracle and other on-premise software companies.

No, the reasons for lack of innovation are endemic to the on-premise business model and the on-premise customer ownership experience. (Bob Warfield starts the list on his blog). The bottom line is that on-premise vendors can develop all the code they want, but because of the high hurdles to upgrading to actually use the new software, most customers can't or won't upgrade for many years, so any "innovations" remain on the distribution DVD and have zero impact.

Why can't on-premise software vendors innovate? Because:

• Development talent is wasted maintaining old versions: since customers don't upgrade, the vendor must support old - even ancient - versions of their software. And upgrades must work with many old versions... again multiplying the effort to write upgrade and migration scripts.
  
• Development talent also wasted porting to multiple platforms: porting the application code to multiple databases, operating systems, and application servers requires a significant amount of development work and time, not to mention significant testing and documentation efforts, and also further multiplies the technical support efforts.
  
• Multi-platform support constrains innovation to the least common denominator of the various platforms: it's hard to be innovative when you're focused on making every new feature work across multiple versions of four different databases.
  
• Long release cycle times reduce ability to innovate: All the porting, multi-path upgrades, and testing efforts mean that releases are very slow in coming - maybe a release a year at most. By contrast, even SaaS applications that have been around for a decade can release new functionality every 3-4 months because all these wasted efforts are eliminated.
  
• On-premise vendors lack intimacy with how customers use the software: On-premise vendors have no idea what the customer's business processes, configurations, setup or data looks like. In addition, they are shielded from customers by the system integrators who perform the lengthy implementation projects. Innovation involves applying technology to solve customer needs, but since on-premise vendors are somewhat blind to how their software is used in practice, their ability to innovate is severely hampered.
  
• Customers don't upgrade: Even when some modicum of innovation is achieved, customers must upgrade for the innovations to have impact, and upgrades are infrequent because they are so costly to customers. For example, even after two years of availability of Oracle E-Business Suite Release 12, less than 5% of customers have upgraded to it.

This is the core issue with on-premise software's lack of innovation - existing customeres, who have committed to the vendor's software, get trapped for years and years on their go-live version with static capabilities, ever-declining support, and no-value maintenance fees, until they decide to disrupt their business and undergo a costly upgrade project.

Of course, SaaS doesn't have any of these issues - that's why it's a better way to build software and deliver innovation to customers. Most enterprise customers don't yet understand the benefit they receive from ongoing innovations delivered by SaaS, without upgrade headaches or costs. But this is changing as enterprise customers experience SaaS's ongoing innovations first-hand.

SaaS and the Innovator's Dilemma

Looking back on SaaS in 2008, the most interesting thing wasn't the inexorable increase in SaaS's market share, but the vocal backlash against SaaS from the large legacy on-premise software providers:

• First, Larry Ellison reiterated that Oracle won't be aggressively pursuing SaaS because it's not profitable enough.
• Then, SAP followed up on the delayed rollout of its SaaS offering, BusinessByDesign, with comments about needing to optimize it and automate the sales/delivery process so it could be profitable.
• Finally, Lawson CEO Harry Debes trumped everyone with the ridiculous pronouncement that the SaaS market will 'collapse' within two years after Salesforce.com misses its growth targets.

I wondered, if SaaS is such a big part of the future, why are the big players hesitating to jump into SaaS due to profitability concerns, and even dispraging it?

So I pulled down my copy of "The Innovator's Dilemma" by Clayton Christensen, and all was explained within a few pages:

"...despite established firms' technological prowess in leading sustaining innovations... the firms that led the industry in every instance of developing and adopting disruptive technologies were [new] entrants to the industry, not its incumbent leaders."

Very interesting.  Why don't the incumbent dominant vendors invest in disruptive technologies?

"First, disruptive products are simpler and cheaper, they generally promise lower margins, not greater profits. Second, disruptive technologies typically are first commercialized in emerging or insignificant markets. And third, leading firms' most profitable customers generally don't want, and indeed initially can't use, products based on disruptive technologies. By and large, a disruptive technology is initially embraced by the least profitable customers in a market."

So is SaaS a disruptive technology? Absolutely - SaaS meets all of these definitions:

"...disruptive innovations are technologically straightforward. They generally package known technologies in a unique architecture and enable the use of these products in applications... [that] previously had not been technologically or economically feasible."

"Products based on disruptive technologies are typically cheaper, simpler, smaller, and frequently more convenient to use."

"Disruptive technologies bring to a market a very different value proposition than had been available previously."

SaaS repackages software functionality onto a lower-cost multi-tenant infrastructure and a new delivery mechanism (via web browser over the Internet) that greatly improves the value proposition for the customer - faster time-to-value, lower infrastructure cost, and ongoing operating costs rather than huge up-front licenses.

For the SaaS vendor however, the economics are far less attractive than shipping CDs for millions of dollars - SaaS margins are lower than on-premise offerings, due to SaaS's up-front infrastructure investment and deferred subscription payments.

So the major ERP providers are looking at decreased profitability from SaaS offerings, and they are prevented by investor expectations from moving strongly into SaaS. For example, even though SAP has V2.0 of Business ByDesign ready, their CEO said that if they were to start pushing it, "we would be hurting our margin, and hurting our stock."

In addition, "The Innovator's Dilemma" states that incumbent vendors' org structures and skillsets (i.e., what they focus on and do well) are internal impediments to adopting a disruptive technology.

Finally, the ERP providers' most profitable customers don't want SaaS, which "The Innovator's Dilemma" says leads to long-term disaster:

"...the leading firms are held captive by their customers, enabling attacking entrant firms to topple the incumbent industry leaders each time a disruptive technology emerges."

So since he can't offer the SaaS disruptive technology, Lawson's Harry Debes instead puts down SaaS to try to delay SaaS adoption and his firm's inevitable decline. Harry has seen a lot of changes in the software industry over the years, but in comparing SaaS to service bureaus and ASPs he is ignoring two decades of Moore's law that have fundamentally restructured the economics of operating software for customers (i.e., personnel time is now much more important than hardware costs), which makes SaaS's time-efficient value proposition very compelling to customers. Plus, SaaS is lower-cost to deliver than the ASP offerings during the bubble, since SaaS is built for time-efficient configurability and cost-efficient multi-tenant delivery.

SaaS has a better value proposition and better economics for customers, leading to ever-increasing customer demand but lower margins for SaaS providers - the formula for a disruptive technology that topples the market leaders. So my view is that Lawson is much more likely to collapse than the SaaS industry, signalled by the brewing ERP backlash.

Does SaaS Matter?

I re-read Nick Carr's "Does IT Matter?" last week, and it seemed to me even more relevant than when it was published four years ago. In particular, it spurred thoughts about SaaS's long-term value and viability in a commodity-IT world.

The major premise of the book seems very SaaS-friendly: Nick's thesis is that IT innovations are increasingly easy for enterprises to replicate, so that competitive advantage from IT is fleeting and not worth the price to create IT innovations internally, or even to pay an early-adopter price premium. As a result, vendors are becoming the major source of IT innovations, making innovations available to all enterprises, and IT prices quickly gravitate to the most cost-effective way to deliver the IT capabilities.

With a shared infrastructure and innovations quickly leveraged across its entire customer base through automatic upgrdes, SaaS is both a major driver and a major beneficiary of Nick's thesis. By eliminating a customer's up-front license costs, infrastructure outlays and benefit-delaying implementation projects, SaaS greatly reduces the adoption cost of IT innovations and capabilities for enterprises.

In addition, while SaaS doesn't eliminate switching costs, if a SaaS solution isn't meeting the enterprise's needs it can be turned off and replaced for far less than an aging on-premise solution.

In short, SaaS makes IT innovations easier, faster and lower-cost to adopt. This pushes IT innovations more quickly throughout the economy, greatly increasing the innovation's overall economic impact, though potentially reducing any unique technololgy advantage for any particular enterprise customer. As a SaaS provider, this works for me - our technology has a bigger impact economy-wide, much more cost-effectively and more quickly than if we sold on-premise software.

With that said, SaaS does matter to individual enterprises in one major way: Enterprises that aggressively adopt SaaS will achieve more benefits (from free ongoing upgrades) at a far lower cost of ownership than enterprises that dogmatically stick to on-premise software. SaaS adopters will pay less, have more flexible expense structures, and avoid throwing capital down the rat-hole of bespoke infrastructures.

All enterprises have to do is select true SaaS providers, avoiding SaaS pretenders that will leave them behind on old versions or with lesser capabilities over time than true SaaS providers. That's the subject of my next post.

More Saas Simplicity: Additional Things That SaaS Customers Don't Have to Worry About

Enterprise software buyers learned over and over again that buying on-premise software is just the first step on a long and winding road to actually improving business results via the software. While the on-premise software vendor can recognize revenue for the entire up-front license fee, declare victory to Wall Street and send its salespeople to Hawaii, the customer is just starting the multi-month/year effort of paying the implementation consultants, assembling and configuring the technology stack, and learning how to operate the on-premise software and its supporting technologies.

With SaaS, of course, the reverse is true - the SaaS vendor is responsible for making the software work to the customer's liking and the software's adoption and business results, while the customer is freed of all the worries of on-premise software ownership. In a previous post, I outlined some things that SaaS customers no longer need to worry about, including:

• Upgrading the software and technology stack
• Becoming orphaned on an old software version
• Solving infrastructure software incompatibilities
• Operating the infrastructure and software
• Maintaining multiple non-production environments
• Diagnosing technical issues
• Building technical expertise for the software
• Enduring cost surprises

Since then I've collected even more unhappy elements of the on-premise ownership experience from various analyst reports and articles and blogs, and as a summary, here are some additional things that SaaS customers no longer need to worry about:

• Shelfware, with Maintenance Fees for Unused Software: Companies end up with shelfware when 1) they pre-buy more licenses than they need in return for a higher up-front discount, or 2) the software doesn't go live as broadly as anticipated. Customers typically still pay for maintenance each year on these licenses, even though the licenses aren't being used.

  This is a big painpoint for CIOs, as they have to send cash each year to vendors for software that is not even being used. On-premise license contracts are engineered to make sure that maintenance costs "ratchet up" with additional licenses, even if some licenses on other modules aren't in use. At one point, Gartner estimated that almost half of CRM licenses were not implemented - is it any wonder that Salesforce.com was the first breakout SaaS company?

  Even worse, although you've committed to the vendor and bought more up-front than you needed, it turns out that the vendor will ignore you if you have significant shelfware (subscription required). If there is no up-sell opportunity then you can't get the attention of the salespeople for information, access or support assistance. Counter-intuitively, the vendor will be much more attentive if they sell less up-front and have the opportunity to sell you more.

  With SaaS, of course, the vendor and customer are much more aligned - the customer only pays for the capacity that is being used, and since more users mean more revenue for the SaaS vendor, SaaS vendors are motivated to provide great service and ensure you are getting the benefits that you need from their software in order to drive expanded usage.

• Platform Changes When Upgrading: It's expensive and disruptive to upgrade on-premise software, so upgrades are done very infrequently. And upgrading doesn't just mean a new version of the on-premise software, it often means upgrading the entire technology stack - the database, the servers, the operating system, the system integrations, etc. So everything the customer has learned about operating, performance-tuning, and maintaining the on-premise software now has to be re-learned... another hidden cost of on-premise software.

• Aging Software: Many on-premise software customers decide not to upgrade because the upgrade project cost is too high or the innovation too low from their on-premise providers (see also "The Oracle Syndrome"), because the on-premise vendors are swamped by supporting a bazillion software versions and infrastructure components. These customers now have to worry about further issues with "aging software", or being charged more for support, or even being abandoned with no support and old formats you can't read any more. SaaS, on the other hand, delivers ever-green software, with innovations and improvements delivered continuously to all customers.

• Licensing Shenanigans: Buying on-premise software involves many frustrations when trying to figure out how many processor licenses to buy, how to license for development and test and failover and disaster recovery environments, how to coordinate with different licensing semantics for the database/application server/operating system, what flavor of maintenance and support to get for every component, etc. In addition, on-premise licenses don't tend to be transferable or flexible if the customer wants to use the licenses in a sister company or overseas, etc. While SaaS doesn't solve all of these problems (and some SaaS providers seem to want to keep complex licensing), the basic SaaS pricing unit (a user or a usage transaction) includes everything, no shenanigans or Excel spreadsheets required.

• Multiple Instances and Versions: In many companies, ERPs and other on-premise software couldn't immediately handle the flexibility and configurability and scalability needed to support the entire organization, so the implementation consultants installed multiple "instances" of the software, multiplying the costs to operate the software. For example, some of our customers have dozens, even hundreds, of instances of their financial software.

  Not only do multiple instances and versions multiply the costs of on-premise software (see below), it greatly complicates getting consolidated enterprise-wide information. Expensive data warehouses are constructed to overcome this issue, which adds further costs and delays to getting consolidated data from on-premise software. These days, of course, the implementation consultants are selling huge "instance consolidation" projects - yet another additional cost of ownership for on-premise solutions.

• Internal Support Staff Costs: I read a fascinating study on ERP staffing ratios by Computer Economics, which underscored just how much big companies are paying in personnel costs to support on-premise software operations, upgrades, customizations, and testing. For each ERP user who used any module, the top-quartile performance had one support person for every 50 users, which represents close to $200 monthly support costs per user. Notably, while ERP systems have much more broad-ranging functionality than most process-focused SaaS solutions, support costs actually did not change based on scope of functionality implemented, as different users typically used different ERP modules - so the HR module had about the same support costs as the sales module, financial module, etc., and these support costs were linear by module. With SaaS solutions, almost all of these customer-incurred support costs go away.

  In addition, the study found that on-premise support costs increased dramatically based on the amount of customization, the number of instances installed, and the number of versions installed. True SaaS solutions don't have any of these cost-multiplying elements, which further leverages the vendor's support efforts and reduces the total cost of ownership for the customer.

• Performance Tuning: Keeping the system humming is a key part of operations, especially as usage and data volumes grow, and as new capabilities and use-cases are utilized. Every application architecture performs differently and requires different and often abstruse skillsets to tune. For example, why should customers have to become experts in a Java virtual machine's thread management or garbage-collection schemes in order to scale some purchased software?

  SaaS providers offload performance tuning and system scaling efforts from customers, including stress-testing, capacity planning, system refactoring, and proactively tuning every element in the infrastructure. In addition, SaaS providers can tune much more efficiently and effectively than any one customer, because the provider's efforts and knowledge are leveraged across many clients. Since performance is a key part of the user experience, SaaS providers are highly motivated and focused on keeping performance high so usage growth and customer retention are high.

• Waiting for Quality: The fact of life for on-premise software is that the vendor doesn't really know how customers are actually using the software, so they have to wait until the first version is installed by customers use before they start getting accurate feedback on software issues. So a new functional release can have an unacceptable number of bugs, which has led to the conventional wisdom in many IT shops is to wait for the service pack or dot-release before upgrading to a new on-premise software version. The separation between on-premise software providers and their customers' installations means that the providers simply do not have the information needed to test the software effectively.

  By contrast, SaaS providers know every customer's data, configuration, and usage patterns, and as a result they know exactly what tests to run to ensure software quality. Since SaaS providers get immediately feedback on any quality issues and their future revenues depend on today's user satisfaction with the software, SaaS providers are again highly motivated to ensure that every new release is of high quality. Customers, in turn, also gain the benefits of new features and innovations right away, rather than having to wait for the bug-fixing service pack before upgrading.

The common factor is that a SaaS vendor's motivations are much better aligned with the customer, since the SaaS vendor's revenue is tied to the customer's satisfaction, retention, and software usage.

By contrast, on-premise licensed software vendors are motivated to "take the money and run", and actually prefer that the customer never installs or uses the software - the vendor already has the license fees, and now would rather not get any costly support calls. While the customer wants to gain value from their purchase, their on-premise vendor is secretly hoping they don't - one more thing that on-premise customers have to worry about.