Building SaaS

Outsourcing & Offshoring: Part 1

I was flying back from vacation in California this weekend, and the guy next to me noticed the magazines I was reading and asked if I was in IT.  I said yes, not bothering to distinguish between software and IT.  He said, “With all the outsourcing, you must be the last one left!”

That’s the popular perception, and it's unfortunate because the actual IT employment conditions are in some ways better than they have ever been, but non-stop media reports of offshore outsourcing are driving people away from the profession.

First, some tech-worker employment facts:  An April InformationWeek analysis of Bureau of Labor Statistics showed that more IT workers were employed than ever before, even surpassing the bubble employment of 2000-2001, and more of the jobs are higher-end software engineering jobs than programming jobs. More importantly, the unemployment rate among IT workers had dropped to only 2.5%, down from 5.4% in the first quarter of 2004.

The low unemployment rate is leading to a skills shortage in the United States; according to AMR Research , "the difficulty IT management is having locating and acquiring the right skills at the right time [in the U.S.] is intense—and worsening."  This is driving fast-rising pay in key skillsets (7% to 10% increases in the first half of 2006), leading to 74% of tech workers saying they were happy in their jobs in July.

When the lower-skilled jobs are offshored, will the high-skill jobs be next to go?  McKinsey Global Institute doesn't think so - they analyzed all service jobs in high-wage countries and found that "only 11% of service jobs could, in theory, be performed remotely."  As a result, "offshoring is a relatively small phenomenon in the scheme of total employment of any occupation."

McKinsey's analysis also found that the oft-reported infinite supply of cheap IT workers in India and China is a mirage - only between 10% and 25% of college graduates in those two countries are employable by a multi-national corporation; plus the increasing demand for those graduates has led to 23% annual wage inflation in India's tech sector, almost doubling tech salaries between 2002 and 2005.

Mitigating the jobs that are actually transferred, offshoring has several rebound effects that increase employment in the high-wage country:  high-skill local workers are needed to oversee the offshore provider's projects and deliverables; firms that outshore grow faster and hire more local workers for the remaining higher-value tasks; and the offshore providers themselves hire local account managers and project managers to work onsite with clients.

Finally, as Joel on Software put it, there's always work for really good programmers, no matter where they are. And most programmers really like what they do; to quote Joel, "if you love to program computers, count your blessings: you are in a very fortunate minority of people who can make a great living doing work they love."

Meanwhile, the drumbeat of anecdotal stories about jobs going offshore to India and elsewhere is causing a large decline in the number of college freshmen considering Computer Science as a major.  When I was hiring at the Colorado School of Mines earlier this year, the director of placement said that Computer Science graduates were down 50% from several years ago.

Across all undergraduate institutions, incoming freshmen are dramatically less interested in Computer Science. The Computing Research Association reported in a survey of college freshmen last year that the popularity of Computer Science as a major dropped 70% between 2000 and 2005, down to an interest level last seen in the 1970s.  [Interest in Computer Science among first-year women has dropped even more dramatically... not sure what that means, but it's definitely not good.]

So even as our world gets more technical and technically challenging, the focus on computer technology is declining as an educational pursuit and as an career path.  This is a shame; in my view, technology offers a more rewarding and interesting career than most other options out there for the intellectually curious; more on that in my next post.

Customizing SaaS

[Note: This is a comment I wrote on the blog post "TalkBack: 'A Feeding Frenzy for SaaS Detractors'" on ZDNet's Software as Services blog:]

"SaaS Providers do Customize"

The focus on software customization is somewhat mis-placed, since for most business processes, even large businesses derive competitive advantage from how well they operate the process rather than some unique feature in the software.

An SaaS provider also has pretty complete functionality coverage once they've enabled all the process permutations across 50-100 large customers in a variety of industries around the world. All these permutations and features are configurable on/off in the SaaS software, which is why SaaS's first answer to specific features is often "it's configurable".

In addition, mature SaaS business-process software is configurable beyond functionality and process flows - it also has configurable look-and-feel, verbiage (customers can call objects and attributes what they want), data elements, etc. Finally, some SaaS "configuration" is actually quasi-coding, where the customer utilizes a tool set to design workflows or reports or UI elements - akin to Erik's proposal to move "down the stack" and provide components.

But addressing the customization question directly, SaaS providers can customize, especially those focused on selling to large enterprises. In our development cycle, we have "maintenance releases" every 4-6 weeks specifically targeted at customer-specific features and system integrations needed for go-live. This allows us to fully implement large customers in 2-3 months, including process design and configuration, initial data loading, system integrations, and end-user training.

In ongoing relationships with customers, SaaS providers are very motivated by revenue to increase system usage, gain adoption throughout the customer's enterprise, and retain customers over the long-term. As a result, in our case, we have hundreds of examples where a customer requested functionality and we put it into the next functional release cycle.

It also makes sense that our product team would be far better at adding core features than a system integrator or customer IT developer, because we are "close to the process" as Erik advocates, working directly with customers on their process goals and specific functionality requests, and also because we directly support all our customers and users every day.

So, in contrast to Erik's proposal to have the IT group or customer directly customize the software, we can add features far more quickly, efficiently, and cost-effectively on our platform than anyone else. And the best part is that any features we create are fully supported, usually available to all other customers through configurability, maintained indefinitely, and automatically upgraded to each new version.

The other key aspect of SaaS is that all this is done in an fast-feedback iterative manner. Erik mentions finding issues "a few months before go-live" - that would be well before our SaaS implementation project even starts! With customer-intimate ongoing responsiveness to evolving business needs, true SaaS leverages both deep and broad configuration as well as customization as needed to deliver far more value, more quickly and at a far lower total cost than on-premise software.

- John Martin www.BuildingSaaS.com

High-Metabolism Software Development

There's an interesting anecdote in today's New York Times that underscores how Software-as-a-Service, through instant usage feedback and frequent updates, can quickly learn what adds value to real users and drive the software in that direction:

"For Jana B. Eggers, general manager of QuickBase, a division of Intuit, the software giant, looking at her market is as easy as clicking a mouse. QuickBase applications run over the Internet, so when lots of new users sign up for a trial, or existing users flock to a new feature, Ms. Eggers and her colleagues see the patterns instantly."

The article describes how Intuit saw that rather than small companies adopting QuickBase, large companies were using it for different tasks.  Intuit redirected their marketing and product development in that direction, leading QuickBase to be the "fastest-growing business unit in Intuit."

Compare this to on-premise software products, where it can take months or years for enough customers to upgrade and actually use the latest release to be able to discern how well the software works for customers in practice.  The feedback mechanism for on-premise software is also broken, since the vendor often doesn't work directly with customers but relies on implementation consultants to get the software running.

As an example, last year I interviewed a Quality Assurance manager from one of the big ERP software providers, who described a "bug-fest" project they were working hard on because the latest release of the software has so many bugs. Out of curiosity, I asked how much time had passed between the software being released (to thousands of customers) and the company getting enough feedback to discover that there was a bug crisis: "A year," she answered.

A year!  The ERP software version had been fully tested and put on a CD and shipped to all their customers, and it was a year until enough customers were actually implementing the software that feedback finally made it back to the on-premise provider that there were more than the usual bugs.

That is why customers usually wait for the first service pack of any major on-premise software release - no matter how much Quality Assurance the on-premise provider performed, their tests simply don't reflect the customer's configuration, data, or usage patterns.  The software has to get out into the real world to really get tested.

SaaS providers perform enormous amounts of Quality Assurance because if something doesn't work right, it quickly impacts their customers in 12 hours, not 12 months.  Fortunately, SaaS providers already know and can easily test all their customers' configurations, data, and usage patterns - it's all in the SaaS system, and it's all tested before the upgrade is implemented.

This high-metabolism product development - create a feature, get instant feedback, improve and extend the feature within a few weeks - is a new concept for product development overall, not just software.  No other business or consumer product has had the immediate relevant feedback, product agility instant deployment throughout the customer base to leverage this learning cycle.

SaaS providers who get closer to customers and speed up their metabolism will drive their products faster and more effectively in the direction the market values, creating a sustainable advantage over those behind or slower than them.  According to the New York Times article, Intuit has adopted this approach:

"'So often with software, developers expect a certain feature to be popular, but a different feature winds up being what customers want,' Ms. Eggers said. 'A lot of companies try to explain away these surprises. We embrace them.'"

The Business Value of SaaS

Phil Wainewright in his ZDNet "Software as Services" blog has apparently hit a nerve by asserting that IT departments are "afraid" of SaaS, and followed it up with a summary of the resulting 'feeding frenzy' of comments on his blog.

As sometimes happens in an IT-focused conversation, somewhat lost in the comments is what the business wants out of the software.  We at IQNavigator sell primarily to business buyers, and in our experience there are five factors that dominate the business-focused decision process for application software: process improvement, total cost, speed to value, risk, and agility.

Fundamentally, the reason SaaS is a much better way to build and deliver software is that it delivers much better on each of these dimensions, in many cases by an order of magnitude:

• Process Improvement:  Buyers care most about the effect that the whole program has on the newly-automated business process - cost savings, process speed and accuracy and visibility, better process results - which includes far more than the software functionality.  SaaS providers, since they derive revenue from system adoption, usage volume and customer retention, provide everything needed to be successful with the software - configuration services, change management assistance, system integration creation, and best-practices to ensure that the customer gains the benefits from automating the business process.  By contrast, on-premise software vendors typically give you a CD of software to install, the phone numbers of implementation & customization consultants, and a hearty "Good luck!" as the salesperson takes his 10% commission from the software license fees and heads to sales club. 
• Speed to Value:  Aberdeen has done some research into On-Demand (SaaS) Supply Management buying factors, and found that the top factor driving businesses to consider SaaS was speed to value.  Business buyers are held to quarterly objectives of continual improvement, and as a result, waiting 6-12 months for IT to install, assemble, customize, and learn to operate an on-premise software solution is simply untenable when there's a SaaS alternative.  We are sometimes asked by IT if we can install on-premise, and obviously we can - we have automated installs adn upgrades internally for about a dozen different environments (whereas it takes substantial rearchitecting for an on-premise solution to become an automatically-upgraded single-version multi-tenant SaaS solution).  But eventually the business buyer is faced with a choice - either 1) our implementation team logs in today to our hosted test environment to start the implementation process, or 2) let us know when IT has finished making an environment ready with multiple servers, the Oracle database, an application server, a half-dozen ancillary setups (e.g., an inbound email box for notification responses), and Internet browser access for your business partners.  The wait for option 2 is usually 3-6 months (assuming the business buyer can prioritize the project high enough for IT's involvement and mid-six-figure investment), so inevitably the business buyer chooses the hosted approach because it delivers value much faster than on-premise.
• Total Cost:  Making an apples-to-apples comparison between SaaS and on-premise software is difficult, primarily because of on-premise's many hidden an unaccounted-for costs, and because on-premise simply cannot deliver the level of support and value that SaaS inherently does.  I will address a cost comparison in a separate post, suffice it to say for now that for the same volume of usage, the total cost of true SaaS software is about one-tenth the cost of on-premise software.
• RIsk:  Little addressed in most SaaS debates, risk is top-of-mind for business buyers - risk of delay or the software never going live, the program not delivering process improvement, higher costs than budgeted, or unforseen upgrade costs or obsolesence.  Risk of IT project failure is a huge concern for many business buyers, and the large number of multi-year on-premise implementation projects and high degree of on-premise "shelfware" (unused licenses) are both legacies that make business buyers not want to buy any software, SaaS or on-premise.  Any software implementation can be delayed or not reach expectations (though industry observations of SaaS so far show a much higher rate of success), the difference is that if a bad surprise is discovered six months into a program, the SaaS buyer has invested very little and can easily switch providers, whereas the on-premise buyer has already spent millions of dollars for licenses and infrastructure and consultants.
• Agility:  Finally, business needs evolve over time, and SaaS has several advantages in evolving with the customer's process requirements: 1) SaaS is designed to be inherently configurable, with switches to alter functionality for a single customer in real-time, 2) because SaaS operates on one code base and releases new capabilities every few months, new software features and innovations are quickly available to every customer (without the multi-year product cycles or upgrade delays of on-premise software), and 3) in many cases, customizations can be added within a product cycle or two (3-6 months) for customers that require functionality specific to them.  We have dozens of examples in our customer base where the customer's business needs changed and required changes to the software, and we delivered them in a few months - and the vendor's internal developers are the best on the planet at delivering new functionality on their own platform most quickly, efficiently, and cost-effectively.  Also, SaaS vendor-created customizations are part of the code base so are inherently upgraded and supported as part of the base product - another way SaaS delivers more value.

The key factor to keep in mind is that with most business processes, how the process is operated by the business determines the process's value and even competitive advantage, rather than unique features in the software.

We see business buyers understanding this more and more, and it can be demonstrated across just about every business process, such as: Is it a competitive advantage to have a specific payroll system feature or to have a well-designed incentive program that aligns motivation? Is it a competitive advantage to have a better resume search feature or to interview more effectively to identify the best talent for your enterprise?

The business value derived from a software-automated business process depends on the process design and operational execution, and SaaS enables implementing an automated process and operating it well far better, from a business-factor point of view, than on-premise software.

What Multi-tenancy Really Means

Salesforce.com is obviously the poster-child for SaaS, but it seems as if they may be breathing their own exhaust when it comes to espousing the multi-tenant hosted model.

As many observers have pointed out, there are many aspects of SaaS that may seem like religion, but that have very meaningful impacts on the customer's cost of ownership and value derived from the software.

"Multi-tenant" is short-hand for two key architectural components of a true SaaS solution: 1) single software version and 2) shared infrastructure costs. Both of these have game-changing benefits for both the customer and the SaaS vendor:

• Single Software Version: This means that all customers are automatically upgraded to the latest version. All customers not only get the latest innovations and improvements in the software, they also get unparalleled top-to-bottom support and avoid the risk of being orphaned on an old unsupported, unmaintained version. SaaS vendors only need to maintain one (current) version of the software, and every fix/enhancement goes to every customer. Multi-version vendors end up spending 70-90 percent of their development effort simply on maintenance, according to The Economist, as they fragment their maintenance efforts over more and more versions of the software and each fix applies to a small subset of customers.
• Shared Infrastructure: Multi-tenant allows multiple customers to run on the same infrastructure. Most people think of servers as the main infrastructure cost, but even more costly are the cost of database licenses and other infrastructure software, the 20%-per-year maintenance costs for all infrastructure components, and (most importantly) the operations personnel costs: DBAs, system administrators, network administrators, etc. Fifty customers, each buying and building their own infrastructure, would together spend an order or magnitude more cost than a shared-infrastructure SaaS solution. The customer gains from the SaaS vendor passing along a dramatically lower cost of ownership, and the SaaS provider can also provide capabilities that a single customer couldn't ever justify, such a hot-backup mirror sites, world-class scalability and performance, etc.

Think this doesn't really matter? Here's a very real example: A few years ago, a major U.S. technology manufacturer selected one of our competitors, a fake SaaS provider without single-version automatic upgrades or shared infrastructure. After four years, the customer was fed up: they had wanted a new approval feature and the fake-SaaS vendor was busy working on a new version for future customers and couldn't accommodate them. The customer wanted more reports and eventually had to internally build a datamart to create their own reports, the vendor couldn't implement internationally on the old version, and the system response times got continually longer as data volumes increased.

So we invited this customer to talk with some of our long-standing customers, and they heard first-hand what they had missed: in the same time period, our customers were able to take advantage of several completely new subsystems, international capabilities across all the major economies in the world, a whole new reporting and business intelligence system, and response times that decreased on average every year. And all for free - customers didn't pay any extra cost, allocate any internal IT resources for upgrades or pay any hidden costs.

The story has a happy ending - even though our competitor offered to upgrade the customer for free to their latest version, the customer is now our customer. After the whole decision process ended, the customer's Director of Procurement said "It wasn't even close, you blew them away." And we've stolen other customers from this competitor for the same reason.

Now, are we really that much better than this competitor? The short answer is that the SaaS business model is really that much better, both for customers and the software providers.

SaaS Innovation

Because of their business model, on-premise enterprise application software vendors focus their software innovations in two main areas:

1. Adding features that help sales demonstrations of the software.
2. Building software abstraction layers to enable "porting" to multiple platforms (e.g., databases, operating systems, and application servers).

This is because wIth on-premise software, customers choose a software package based on feature set before the sale, and compatibility with the customer's infrastructure. And once they choose the software with the most features, they are locked-in to that software for many years (usually on the same version), no matter how well the software performs in practice.

So legacy enterprise software vendors can safely ignore adding features for current customers, and invest instead to make the product more attractive to the next customer.

By contrast, SaaS software companies increase revenue through increased usage and adoption of their solution. So SaaS vendors focus their energies on increasing customer adoption, satisfaction and expansion, through innovating in areas that increase value and reduce costs for their business customers:

• Speeding up implementation
• Improving the user experience
• Integrating more easily with customer systems
• Increasing functionality in ways that will increase usage
• Providing more insights to the customer into the value and performance of the automated process.

New features are primarily driven from current-customer feedback, via a high-metabolism process that quickly learns and adapts from iterative customer and user feedback. With functional releases every 3 months or so and fast feedback from customers who are automatically upgraded, SaaS products evolve quickly, especially compared to the 12-18 month product cycle for legacy on-premise solutions with multi-year delays before customers upgrade.

Just as important are the "non-functional" innovations that drive cost of ownership and architecture longevity.  The feedback cycle for SaaS solutions, compared to on-premise solutions, is even faster for non-functional aspects of the software.

For example, a friend of mine joined a new company a couple of years ago as a VP in a 5,000-person salesforce that used Siebel CRM.  He received a new laptop from IT, plugged it in, and four days later it was still synchronizing with the Siebel database!

The interesting part is:  Did Siebel know of this performance problem?  Of course not - the company's IT group knew, maybe the consulting group that implemented the software, maybe even the database vendor.  But Siebel probably had no idea, and even if they did know, they were enhancing their software for the next customer.

By comparison, a SaaS vendor knows of performance problems immediately - not only does it affect the user experience and usage (hence revenue to the SaaS vendor), it also impacts the SaaS vendor's internal costs with additional server and infrastructure usage.  For both of these reasons (immediate impact on revenue and cost), the SaaS vendor is very motivated to proactively track down and fix a performance issue.

Other examples of non-functional SaaS innovation include:

• New user-facing technologies like Ajax and Web 2.0 - these can be adopted and deployed throughout the customer base in months rather than years for an on-premise solution.  (Or decades, apparently there are still SAP customers running mainframe versions.)
• Automated deployment and upgrades - SaaS vendors automatically migrate customers to the next version, and as a result have built tools to upgrade efficiently and assuredly.  (Multi-version SaaS vendors like RightNow Technologies must build many-to-many upgrade capabilities, a questionable investment in my view.)
• Configurability of functionality, user interface, and business processes - True SaaS solutions upgrade all functionality and all customers automatically, so tend to create an efficient configuration backbone
• Continual tuning - More on this in upcoming posts.

In the end, any vendor is motivated by revenue, and since SaaS vendors must keep current customers satisfied to protect their recurring revenue and grow usage to increase revenue, they focus investment and innovation focus on continually adding value to existing customers.

Software Support in the New Era

"Software support" is an oxymoron for on-premises enterprise software.  By the time the business customer installs the on-premise software, gets it connected and running with the database/application server/operation system/monitoring system/etc., creates and opeartes parallel development/test/regression environments, customizes the software to fit their business, determines how to operate the software (monitoring, backups, performance tuning, etc.) and figures out how to use it to benefit their business, the customer knows a lot more about the software in a "real-world" context than the software vendor who created it!

Plus, the on-premise software vendor has no idea how the software is configured, what customizations and system integrations have been performed, the data in the system, etc.  This makes it very difficult for the on-premise software vendor to "support" the software they originally shipped on a CD.

Case in point:  Yesterday, we ran into an issue with BEA Weblogic, where it created an invalid WSDL for a web service we were writing.  I called up BEA, and got the age-old first question:  "What version on you on?"  Then "What service pack? Any patches? What operating system?  What OS version? Which database...?"

BEA needed to replicate the issue in their environment (an error in the customer's environment isn't very helpful to an on-premise software vendor), so we had to write a generic test that demonstrated the error, and email it to them.  They promised to try to replicate the issue and get back to us...

I'm not picking on BEA in particular here, just pointing out how difficult it is for an on-premise software vendor to support a hundreds of software versions and dozens of platforms that their software runs on (each platform component with many more versions), in customer environments where the vendor has no idea what's happening.

If/when we get a response, I guarantee it will be one of the following answers:

1. You need to upgrade to our latest version
2. It's not our software, it's the operating system/database/driver/etc.
3. It's due to a customization, or your code
4. Sorry, we can't replicate the issue
5. A fix is scheduled for the next service pack/version

The common element of all these answer is, of course, they don't fix the problem!  So the only path for enterprise software customers is if a bug is found, work around it, because the odds of the vendor providing a fix expediently is about zero.

SaaS is, of course, completely different - the SaaS vendor is responsible for making the entire stack work together, the SaaS vendor knows the configuration/data/usage pattern already, and when a fix is created it is deployed to every customer, automatically.

An SaaS support anecdote:  We're an SaaS vendor with close to a half-million users, and I called a user yesterday who had several long response times, to find out her intention with her use case.  She didn't report an issue, in fact she had found a workaround already, but I noticed it because it showed up in our monitoring of user issues.  It looks like the issue was the result of a fairly rare combination of user roles, so I wrote up a ticket and the fix will be in the next patch.

Can you imagine Oracle or Ariba calling a user to investigate a performance issue that the user hadn't reported?

A mature SaaS solution has monitoring built in that tracks and notifies the vendor of any errors the user receives, reports that fail, long-running response times, etc.  And the SaaS vendor proactively finds and fixes issues because they know that user satisfaction, adoption and usage are the primary drivers of their revenue and profitability.

This is a big beneficial element of the SaaS customer ownership experience, one that most buyers don't realize they will get when they evaluate a SaaS solution.

What is "Building SaaS"?

Software-as-a-Service (SaaS) delivers a much different and better customer ownership experience for businesses than deployed software - no up-front technology costs, fast time-to-value, low cost of ownership, ongoing free upgrades.  There are many commentators that are tracking the many SaaS customer benefits and emerging software providers - investors, consultants, analysts.

This blog will look more from the SaaS vendor point of view - building, operating and supporting a SaaS solution.  The processes, development approaches, and architecture of SaaS are fundamentally different than for deployed software - trying to build SaaS software the same as deployed software will hobble your solution in the market, as some of our competitors have found out.

I run development, product management, QA, and technical operations for IQNavigator, the market-leading Services e-Procurement provider based in Denver, Colorado, USA.  We have been doing multi-tenant single-version SaaS from the start six years ago, and I feel we have a unique perspective on what makes SaaS solutions better, and how to build a successful SaaS software solution.

I hope you agree.