Building SaaS

Memo to the Skeptical CIO

Skep: Thanks for your participation in the "Skeptical CIO" panel at the SaaSCon conference in San Francisco.

Phil Wainewright captured the key points of this discussion, which I wanted to address here since your and your fellow CIOs' conclusions seem to indicate that SaaS pretenders and the big ERP vendors are dominating the discussion about SaaS in your offices so far.

To directly address the "Skeptical CIO" conclusions:

• "[SaaS is] not any easier to implement and use. Nor should it pretend to be." Well, as a SaaS vendor, when we're asked by a customer to install on-premise, we simply say "Ok, here's the CD and installation instructions, please call us when your IT group has assembled and installed and configured the servers, database, application server, and other infrastructure for our application. Or, here's the SaaS implementation login which we can start using RIGHT NOW." SaaS eliminates all the time and effort (and cost) to cobble together the components for on-premise software installation, which for an enterprise application can take an IT group months - at least, that's what the business buyers tell us. Plus, most SaaS vendors don't get paid until the software is being used, so they've built their SaaS software to enable fast implementation and to minimize training.
  
  Aberdeen Group's surveys have repeatedly shown both that SaaS implementations are faster and that SaaS's dramatically faster time-to-value is the most important benefit to the business buyer (here's one of their studies in our space). So, I'm not sure why you dismiss this SaaS benefit - surely you and your colleagues have endured plenty of multi-year on-premise software implementation projects?



• "Vendors should stop harping on about how, if you don’t like a SaaS solution, you can just unplug it and go elsewhere. That’s ludicrous." This comment is accurate; this claim isn't one that we make. Switching a SaaS application is really a new implementation - much easier and faster with SaaS, but not trivial.



• "The cost model is not necessarily any better. Customers amortize upfront costs anyway." SaaS creates economies of scale by sharing infrastructure across many customers - and it's true that a large IT shop with a pre-existing infrastructure can gain many of the same economies of scale.
  
  The faster and much smaller implementation project is a real cost savings, however, especially for large enterprises. As RightNow Technology's CEO puts it, you'll save the consulting teams that "camps their tents in the parking lot for three years while they get your application to maybe work."
  
  Another cost savings of SaaS is far less obvious. Ask your on-premise software vendor, "How much of your company's time is spent supporting old versions of your software across all your infrastructure ports (databases, operating systems, etc.), and porting and testing each version and maintaining the compatibility matrix?" If they have a significant customer base and are truthful, it'll be a large part of their development and support effort - according to The Economist, "as much as 70-90% of what programmers do in a large enterprise software firm is maintenance: upgrades, minor enhancements and bug fixes". True SaaS solutions reverse this proportion - spending only 10-20% of development effort on maintenance - because only the current version is maintained on a single platform, and every fix is automatically delivered to all customers. So the vast majority of the SaaS vendor's development effort is applied to new innovation and customer value.



• "On-demand vendors shouldn’t bother to portray themselves as partners in achieiving business results. They’re just software vendors selling products." Well, this may be true for some vendors - especially the SaaS pretenders who are telling you that SaaS is just another "deployment option". According to Jeff Kaplan, "The first thing CIOs have to look at is how any SaaS system is truly architected. Some vendors are still selling legacy apps but simply hosting them and offering them at a different pricing model." For a checklist of questions to ask a potential SaaS vendor, see the whitepaper Why Technology Matters.

Again, thanks for your participation - hopefully this gives some perspective from a true SaaS vendor's point of view.  The bottom line is that SaaS delivers a better ownership experience on factors that business buyers care about, driving SaaS adoption for new purchases and putting CIOs in the position of leading its adoption or being left behind. Embracing and driving the key benefits of SaaS - lower up-front cost, faster implementation and greater vendor accountability - will lead to higher/faster ROI with lower risk for both CIOs and the business.

Why We Don't Offshore Product Development (Part 4)

So far I've outlined why we don't offshore product development from a customer's point of view - mainly because onshore development gives much better responsiveness and quicker cycle time. SaaS's collaborative, fast-response product development and maintenance processes don't lend themselves to overnight development.

Now for the "internal" reasons. These aren't as directly visible to customers but have big impacts on the team's productivity and product quality. Because of these reasons, we have found that we can develop higher-quality and higher-value SaaS software in Denver for the same cost as in India.

• The Collaborative and Creative Nature of Software Development: As described the last post, a customer-collaborative process increases the value of software through frequent feedback and course corrections. Just as importantly, the internal software development process benefits from close collaboration among product management, development, quality assurance, and customer-facing personnel.
  
  Collaborative refinement of specification and design will deliver far higher-quality software than rigidly following a spec. KANA Software, in their offshoring efforts, found "that our offshore developers often told us, 'Here's what we built, exactly as you wanted - but it won't work, and here's why.'"
  
  In addition, software development is different than product manufacturing because every software requirement is unique, and requires creative and learning problem-solving to get to the best answer. If you're making thousands of exact copies of a widget to a specification, then offshoring is great - but "software factory" is an oxymoron.
  
  In fact, some researchers have characterized software development as "artful making", as described in this excerpt from IEEE Software Journal: ("Software Making as Art"; Austin, R. and Devin, L., pp. 93-95, January/February 2003):

  "Artful making... has a recognizable structure. It’s iterative and thus involves doing and doing again... It de-emphasizes planning in favor of learning from experience. It delegates control to makers themselves, aspire to enhance individual and idiosyncratic talents, and uses the environmental uncertainty of ongoing change to fuel innovation... The difference between a good and bad system is not how well it meets the requirements you know in advance. Meeting requirements is a necessary but insufficient condition for producing an excellent system. What makes a system great is details that are not specifiable in advance—aspects that must evolve in the making... As long as our processes are structured for conformance to advance specs, we’ll have problems because software development’s essence is creation, not conformance."

  In short, software development is a creative, collaborative process, and offshoring breaks the short-cycle value-increasing collaborations.



• Far Lower Maintenance Effort With SaaS: Offshoring product development to India initially gained momentum with offshoring software maintenance to India. The first impetus was the Y2K effort, where lots of COBOL programs were shipped overseas for scrubbing to ensure that next-century dates were correctly handled, and in the process India built up infrastructure and capabilities maintaining software offshore.
  
  The second impetus was actually driven by the nature of on-premise software - over time, the on-premise software vendor has to maintain more and more old versions of the software on a myriad of platform software combinations (operating system, database, application server, etc.). The longer the software vendor has been around, the more maintenance effort there is, and The Economist has estimated that up to 80% of development effort and cost is absorbed by maintenance.
  
  Once offshoring became a viable option, on-premise software executives started saying "Why am I paying six figures to each of my senior developers just so they can create hundreds of patches each month? We can offshore maintenance and lower our costs by more than half, and if patches are a little lower quality or slower to be delivered, well that doesn't matter because our customers on maintenance are locked in anyway." Plus, developers liked being relieved of this effort because maintenance required them to work on 3-year-old code and repeatedly fix the same bugs across multiple versions, which is a lot of unsatisfying grunt work. So by offshoring maintenance, everyone was happy and maintenance fees became even more of a money-maker for on-premise software vendors.
  
  With SaaS software, maintenance is a much smaller effort because the SaaS vendor only maintains the current version, and whenever an issue arises the SaaS vendor already knows the customer's configuration, click-stream, and data - so issues are easy to diagnose. Working only on the current version also means the context is already there - the developer is fixing a bug in code that they worked on a couple of weeks ago (rather than years ago with on-premise). As a result of these factors, in our instance, maintenance is typically about 10% of the workload. In addition, maintenance is a key feedback mechanism on the quality of the software and UI design and implementation, improving our internal learning and consistency. So offshoring SaaS maintenance is simply a non-starter - it's a small part of the development cost and also has a lot of value to the development team that would be eliminated by offshoring it.



• System Engineering: Finally, development SaaS software involves a lot more than just adding functionality - since all users will be able to use the feature overnight, the software developer has to design and develop for performance, deployability, UI consistency, monitorability, diagnosability, maintainability, flexibility, enhanceability, etc. - a lot of "abilities" that helps operations deploy the software and monitor it, helps the developer diagnose and fix any issues quickly, and helps enhance the functionality for the next version.
  
  With on-premise software, many of these "abilities" are pushed to the implementation consultants or customers' IT shops to figure out. Others are deferred until the release is out and customers upgrade to it years down the road. The on-premise developer's goal is to get new functionality working well enough for sales to demonstrate it, since customers won't actually use the software in production for quite a while. By then, the offshore team is fixing issues.
  
  But SaaS is used immediately in volume by all customers with their varying usage patterns. So SaaS developers do a lot more than design and code functionality, they are actually system engineers - envisioning how users will use a feature in context, how their code will perform in the real world under load and with the other system components, and what likely directions the maintenance and enhancement effort will take.
  
  Many of the system "abilities" are unspecified in typical software requirements, and some are even unspecifiable as they are internal to the development process and not visible to the software users. Consistent with the creative process outlined above, the system engineering to address all these "abilities" requires highly knowledgeable and highly versatile developers who have the customer context and full range of understanding of how the software will be used, in order to make many judgments and tradeoffs among the various "abilities" when building a software feature.
  
  So while offshore development can develop software so that the screens behave correctly, attaining this level of customer-knowledgeable system engineering that incorporates all the abilities - critical for successful SaaS software - is close to impossible.



• Internal Design Consistency: Another implication of the "abilities" in the last point is that the resulting code needs to be internally consistent in order to maximize maintainability, and also to be compatible with all the non-functional components that make up SaaS software - the monitoring subsystem, configuration backbone, integration framework, etc. Using established design patterns which are supported by the underlying framework will result in more consistent and higher-quality software, since the design patterns and framework have been proven out through multiple maintenance iterations.
  
  We found out the hard way that a separated development team can get the functionality working right and pass all the software quality assurance tests, but under the covers use some new approaches that prove much more difficult to maintain and requiring significant rewrites. Fixing this issue with more training and constant oversight just increases the time and cost of offshore development, not to mention also decreasing the satisfaction of the local development team since they're reviewing checkins and writing emails and checklists rather than coding.
  
  With our local development team, design consistency comes from continual hallway discussions, ad-hoc design reviews, and real-time "ask the expert" queries of the subsystem owners. Sure, an offshore team can read the wiki and email their questions, but answering a question right when it arises with high-bandwidth conversation results in far better software, compared to a day-later email response.

In short, building SaaS software requires a fast-response, customer-knowledgeable, collaborative system engineering effort that also satisfies unspecified (but highly valuable) customer and internal requirements. Satisfying these requirements - and iteratively evolving an excellent system through artful making - cannot be done effectively across 12 timezones.

Measuring Developer Productivity

Joel on Software, as usual, has a great post about software development with a lot of truth in it - in this case, about the impossibility (and even inadvisability) of measuring software development productivity.

As Joel points out, measuring software development productivity is a subset of the problem of measuring knowledge worker performance, which is prone to gaming once a quantitative metric is applied. (In a Dilbert strip, when the programmers were awarded $10 for every bug they found and fixed - even if they created the bug - Wally says "I'm going to write me a minivan this afternoon"!).

But gaming aside, the even bigger reason knowledge worker productivity is hard to measure (and manage) is: How do you measure knowledge worker output, or more importantly, value?

It's especially hard to measure the value of a software developer's work, since there are so many variables that confuse activities with software value, as The Parable of Two Programmers deftly demonstrates.

One of the great things about running a Software-as-a-Service development group is that the software's value is a lot more readily apparent than with on-premise software. With SaaS, the feedback cycle is so quick and direct (through immediate usage by all customers) that many of the components of software value are apparent very quickly - the software's robustness, maintainability, usability, and performance.  All the elements that go into software quality are fully visible to the developer and to management within days, giving excellent insight into each developer's productivity (i.e., value per day) and improvement trajectory.

In addition, the entire software development process benefits from fast customer-based feedback. For example, if Product Management prioritizes a feature that customers end up not using, the software developer challenges them with their future prioritizations.  This accountability helps ensure that Product Management is focused on features that will be used and provide the most value to customers. 

Another aspect that I regularly push is to get a feature in front of customers so we can see how they use it and give us guidance on version 1.1 within days or weeks, not years (as used to be the case with on-premise release cycles). A fast-turn SaaS development approach makes it cheap to fail, delivering more course corrections and customer-determined value while greatly decreasing wasted effort on unfruitful features.

So by continually applying the development team's time on the highest-value features for customers who are currently using the software, the product's value progresses as quickly and efficiently as possible for the development investment. By contrast, with on-premise software, the development investment yields little benefit for customers - feature prioritization is typically targeted at making software demonstrations compelling to the next customer, the several-upgrades-per-decade means that the feedback cycle to the software developer and manager is many years rather than weeks, and a huge percentage of development effort is wasted on maintaining old versions of the software on a myriad of platforms.

The most important part is that the SaaS development process leads to higher value to customers, more quickly and continually increasing over time. The additional value from SaaS after go-live gives customers ever-increasing business benefits, which is why the free ongoing ugprades of SaaS make such a difference in the customer ownership experience vs. on-premise software. Only an ERP practitioner could love the idea of living in the straitjacket of one software version for years and years.

Why We Don't Offshore Product Development (Part 3)

Another posting delay - this time from a medical issue that had me working at about 70% the last month, and unfortunately my non-immediate items had to be dropped like this blog, keeping up on my reading, expense reports, etc. But some minor surgey on Friday has allowed me to drop pain pills for the first time in many weeks, so now back to the series "Why We Don't Offshore Product Development".

In prior posts I outlined why offshoring, in our situation, doesn't actually save any money when looking at total costs, and also our unsuccessful experience with our last offshoring partner. Now, to the meat of the issue, which is why building SaaS software is incompatible with offshoring. First, the external reasons:

High Responsiveness: Our customers expect and require fast turnaround on any software issues, because our customers are very large (almost all in the Global 2000), our software automates a financial business process for them, and we integrate with many of our customers' internal systems. As a result, when an issue occurs, our customers are relying on a quick diagnosis and understanding of the issue, and it simply isn't an option to email the overnight offshore team for an answer tomorrow morning.

We also have a close dialogue with the customers' IT group when we're finalizing and testing system integrations. From experience, we've found that waiting overnight for each cycle greatly lengthened the time to finalize these integrations, potentially delaying customer go-lives (and hence our SaaS revenue!).

Customer-Collaborative Product Development: SaaS providers are much closer to their customers than on-premise software providers, since the SaaS business analysts and software developers know how the customers are using the software, with what configuration and data, and for what business benefits. Having that context is invaluable when working on a customer request, and the only way to get it is to work directly and closely with customers over months and years - it can't be replicated through email or requirements documents.

Value and Speed to Market: All this enables a much higher-value SaaS product that is achieved through the glacially-slow on-premise release schedule. Quick turnaround and intimate understanding of the customer's business process together enable a higher-metabolism, more efficient development process that delivers more value to customers, more quickly. Since SaaS generates revenue as customers actually use the product, both speed and value are of the essence.

Next post - the even more interesting "internal" reasons SaaS is incompatible with offshoring.