TRANSFORMING THE SOFTWARE INDUSTRYAdopting the Software as a Service Business Model

DEVELOPED BY SOFTWARE & INFORMATION INDUSTRY ASSOCIATION (SIIA)Executive Council on Software as a ServiceISV Transformation Committee

Copyright © 2005. All rights reserved.

Transforming the Software Industry: Adopting the Software as a Service Business Model

by the ISV Transformation Committee, SIIA's Executive Council on SaaS

The committee is chaired by OpSource's Vice President of Marketing, Mitch Cipriano; the SaaS Working Group is led by Nick Blozan, Senior Vice President of Sales & Marketing at OpSource.

© Copyright 2006, Software & information Industry Association

TABLE OF CONTENTS

TABLE OF CONTENTS ....................................................................................................2 ACKNOWLEDGEMENTS .................................................................................................3 EXECUTIVE SUMMARY ..................................................................................................4 INTRODUCTION...............................................................................................................4 PRODUCT MANAGEMENT & MARKETING ................................................................6

BENEFITS ......................................................................................................................7 CHALLENGES ...............................................................................................................9

SALES AND BUSINESS DEVELOPMENT .................................................................12 T

BENEFITS ....................................................................................................................12 CHALLENGES .............................................................................................................13

CUSTOMER SERVICE & SUPPORT ...........................................................................15 BENEFITS ....................................................................................................................15 CHALLENGES .............................................................................................................16

OPERATIONS ..................................................................................................................17 BENEFITS ....................................................................................................................18 CHALLENGES .............................................................................................................19

TECHNICAL & PRODUCT DEVELOPMENT ..............................................................21 BENEFITS ....................................................................................................................21 CHALLENGES .............................................................................................................23

FINANCE...........................................................................................................................24 BENEFITS ....................................................................................................................24 CHALLENGES .............................................................................................................25

LEGAL / CONTRACTUAL ..............................................................................................26 BENEFITS ....................................................................................................................26 CHALLENGES .............................................................................................................26

CORPORATE FINANCE (VALUATION).....................................................................27 BENEFITS ....................................................................................................................27 CHALLENGES .............................................................................................................27

GLOSSARY.......................................................................................................................29

Transforming the Software Industry 2

ACKNOWLEDGEMENTS

This paper is Copyright © 2006 by Keychain Logic, OpSource, The FactPoint Group, Jamcracker, SpringCM, Vista Equity Partners, eMeta, Aladdin Knowledge Systems, and OpenAir, each granting non-exclusive use to the Software & Information Industry Association (SIIA).

Transforming the Software Industry was authored by members of the ISV Transformation Committee, a subset of the SIIA's SaaS Working Group. The committee is chaired by OpSource's Vice President of Marketing, Mitch Cipriano; the SaaS Working Group is led by Nick Blozan, Senior Vice President of Sales & Marketing at OpSource.

The paper's primary author was Keychain Logic's Ken Boasso, with significant draft contributions made by Tim Clark (The FactPoint Group), Brent Arslaner (Jamcracker), and David Dahl (SpringCM). Additional notable draft contributions were made by Stephen Davis (Vista Equity Partners) and Nick Blozan. Constructive revisions were ably offered by Nick Blozan, Tim Clark), Mitch Cipriano (OpSource), and Ken Boasso. The entire paper was built from a robust outline developed by committee members Ken Boasso, Nick Blozan, Mitch Cipriano, David Dahl), Sean Murphy (Jamcracker), Ramnik Gulati (Aladdin Knowledge Systems), and Stephen Davis (Vista Equity Partners).

The SIIA, its SaaS Working Group, and the ISV Transformation Committee are all grateful for these significant contributions, without which Transforming the Software Industry would not be possible.

Transforming the Software Industry 3

EXECUTIVE SUMMARY

This paper, provided by members of the Software & Information Industry Association’s Software-as-a-Service (SaaS) Working Group, is intended for software companies, enterprises, analysts, and other interested parties, who are interested in the development of the SaaS business model and the current acceleration of its acceptance among independent software vendors (ISVs) and their enterprise customers. Designed to address the departmental functions of an average ISV, Transforming the Software Industry: Adopting the Software as a Service Business Model covers a range of areas that should be reviewed and examined by companies interested in SaaS. Each section includes information about how the SaaS model benefits the different organizational areas of a software company and then offers a number of issues and challenges for consideration.

In this document, the following characteristics are used in describing the SaaS delivery model:

• Ubiquitous availability from a common web browser • Applications built upon internet technologies and open standards • Independent software vendors’ (ISVs’) operation of applications with

multi-tenancy • Systems hosted by a commercial provider other than the end user

Furthermore, the traditional software model is assumed to have the following characteristics:

• Software distributed to be installed on the end users’ systems • Applications typically based on a closed architecture • Systems procured, administered and maintained and hosted by the end

user

INTRODUCTION

As the enterprise software industry emerges from a five-year slump of flat sales, declining profits, and a dearth of application development, independent software vendors (ISVs) are confronted with a variety of technological and business model changes that are destined to forever alter the industry’s landscape. This rising tide of transformation includes the broad deployment and acceptance of Open Source, the development of robust Service-Oriented Architectures (SOAs), and the perfection of alternative delivery mechanisms such as Software-as-a-Service (SaaS) that both respond to market demand for more cost-effective application solutions and open new markets for enterprise ISVs. Insofar as it will prompt a complete shift in the enterprise software business paradigm, SaaS is the most radical of these changes, but it will prove to be the most extensive and profitable for those ISVs that can adopt the requisite focus and provide their customers with complete solutions via an integrated services package.

The challenges to adopting or transforming to SaaS are numerous, as discussed in this analysis; however, they are readily solved and far outweighed by the benefits achieved though this business model. As Accenture noted in its fine study, The Future of Enterprise Software: How Software Companies Can Achieve High Performance in an Era of Disruptive Change and Uncertainty (2005), SaaS ISVs “must inject a both a new mindset and a new discipline into their business. The

Transforming the Software Industry 4

mindset is a focus on the full solution, its total impact on the customer experience, and its total cost of ownership; the discipline is a systematic reengineering of the enterprise software value chain.” Traditional ISVs that believe their applications and businesses are appropriately focused on providing complete solutions will find here important insights that reveal the depth and breadth of the SaaS-led changes. New entries to the enterprise software sector will benefit from the discussion of best practices and the roadmap to guide them around potential problems with adopting the SaaS model.

In either case, ISVs will see how SaaS will help them significantly improve both the speed with which new applications, products, and services can be brought to market and the quality and effectiveness of SaaS offerings. SaaS not only requires ISVs to deliver useful and cost-effective solutions, it provides the vendors with immediate insight into how their intellectual property is being used and – sometimes more importantly – how customers are not using certain features and functionality.

While these product design and quality control benefits will prove to be among the most important in the coming battle between enterprise software models, they are not the only advantages offered to SaaS providers. Technically, SaaS is a better platform for the deployment of new technologies, particularly where ISVs take full advantage of SOAs, Open Source, "Agile Development" practices, and Web 2.0 technologies that enhance applications' utility.

More productive marketing and lead generation will contribute greatly to the inherently simpler (and, therefore, shorter) sales cycle of the SaaS model, and the most effective ISVs will establish themselves as trusted advisors within their broader customer base. The development of the ISV’s business and technical expertise beyond the software application and the adoption of an integrated service-provider focus will similarly broaden revenue opportunities as SaaS providers grow to offer more than information or improved business processes to their customers. Increasingly, business customers will require three things from their information technology vendors: Applications, improved business processes, and information (content). Alone, the SaaS model positions ISVs to offer two legs (applications and business process) of this marvelously strong three-legged stool; with some foresight and by leveraging the power of the internet, they can readily expand their product set to include the third, content.

As Accenture points out, “the key [to SaaS providers’ success] is their wholesale re-invention of the business model. The most successful of the emerging SaaS providers will be service providers that happen to be powered by software.” Industry observers that agree point to not only on-demand ISVs like salesforce.com but companies that fall outside the traditional software industry umbrella, like ADP and eBay. While this paradigm shift will be difficult, we do not agree with naysayers who alternately argue that the typical ISV has neither the will nor the ability to effectively manage such wholesale changes to its business model and that industry inertia is both protecting the traditional model and holding it in place.

Instead, we concur with Accenture’s point that maintaining the status quo simply will not be possible. In 2005, we saw broad adoption of SaaS offerings among business users who, as Accenture notes, “now are embracing … SaaS as a genuine alternative to traditional packaged solutions.” This is not surprising, given that most enterprise software users have been unhappy with the traditional perpetual license model for some time. Not only have its economics proven untenable for today’s high-performance enterprises, the problems inherent with its associated product development cycles and customer-specific support challenges have fed a

Transforming the Software Industry 5

growing discontent with vendors who are perceived to offer unacceptable service for their substandard products.

The growing demand for service-based solutions is excellent news for technology investors, who note the higher valuations achieved by successful SaaS ISVs that are due to the more predictable annuity-like recurring revenue streams (the true holy grail of any B2B vendor). Gone are the boom-and-bust cycles of traditional software revenue acquisition and, with them, the massive end-of-quarter discounting (and resulting devaluation) of the ISV’s intellectual property. While the SaaS provider takes on a more important role with regard to its customers’ data security and consistent service delivery, that very increased importance justifies the higher gross profit margins that accompany the expanded solution-focused product offering. Thus, the financial benefits to SaaS alone argue in support of IDC’s industry prediction that 50% of all new software sold in 2009 – a scant three years away – will be SaaS applications.

The most significant challenge for existing enterprise ISVs will be entering the SaaS business because so much of the model is different from the way the industry has traditionally operated. Those ISVs that are serious about their futures will adopt the new delivery model quickly so they can be in a position to control how the transition happens. The others that wait will find themselves reacting to the market and their competitors, and they will have difficulty controlling quality, customers, and vendors when their market for installed applications is collapsing.

Between today and that future, however, market warfare will reign. Describing it as “guerrilla warfare … of the value chains,” Accenture predicts that it will be “governed by disruptive, internet-created dynamics and will involve vendors competing against companies or entities with business models they still may not comprehend.” We agree and offer this paper to the industry as a part of their comprehensive battle plan for the coming revolution.

PRODUCT MANAGEMENT & MARKETING

In an OpEd piece titled "The Coming Service Revolution" (SandHill.com 31 Jan 2005), Kleiner Perkins’ Ray Lane noted that the development of the Software-as-a-Service (SaaS) model is responsive to market demand. Noting that this demand is steadily increasing for the service-oriented delivery of virtually any application, Lane counseled that “customers are in control, [and] they’re demanding … more accountability for results.” Early SaaS adopters understand that giving customers what they want is only the ISV’s first step in establishing strong relationships with them.

The SaaS model not only provides consumers with an instant path to results accountability, it opens a window of opportunity for the ISV’s Product Management & Marketing team. Prior to SaaS, software product managers did not know how their applications were being used; they had to wait for sporadic and incomplete feedback via unreliable customer surveys and market reports.

In a SaaS environment, these same product managers now have constant feedback. They can see, track, and analyze customer usage. When customers are unhappy because the service is not performing as promised, the SaaS product manager knows immediately and immediately knows why.

In short, the application in no longer merely a component of the business process solution; it is the solution.

Transforming the Software Industry 6

In this environment, competition is no longer merely an arms race of more features. Differentiation is based on the value of the SaaS ISV’s entire solution, built not only on its intellectual property but also on the integrated service and solutions it provides.

BENEFITS

While considering the product management and marketing issues discussed below, the SaaS ISV will have the opportunity to review how it packages its entire solution. Will the SaaS release be significantly different from any perpetual license release? Will there be separate code bases for these different delivery models? If so, will the two releases offer different feature sets or functionality? These are powerful questions to consider from both a cost (for R&D / product development) and go-to-market perspectives. They offer the ISV the opportunity to expand its market presence at the same time it either grows or transforms its product line. By adding a SaaS offering, the ISV can expand its potential customer base. Different versions of the same application can help protect existing business lines.

Application Transparency & Usage-Based Feedback

As noted, the greatest product marketing/management benefit to SaaS applications is that they give greater and immediate insight into which features and functions are used by most customers. Customer preferences for features and functionality can be quickly and efficiently surveyed by analyzing actual use, and additional feedback can be easily solicited via log-on messaging, dashboard interfaces, and other on-line devices. Beta testing can be done in similarly efficient ways, with targeted deployment to limited users or by a self-selection process where customers sign up for or download the new application or feature.

Similar usage-based feedback can be used to develop patches and new releases. Incremental customer feedback – as opposed to surveying and waiting – can be used for quicker, more frequent updates, increasing the utility of the application in nearly real-time. This brings the development lifecycle closer to actual customer usage, provides developers with clear and concise usage cases and shortens the process from requirements development to deployment. Similarly, features are then added based on what customers actually need (and will be willing to pay for) versus a generalized perception of the market’s requirements.

Pricing Schemes & Price Testing

Not only do these benefits apply to product development and management, they are also extremely useful in testing new pricing. In the same way the on-line SaaS application lends itself to many different pricing schemes, the ISV can test each of those models by making them available to different customers and then tracking subsequent usage before broad, general roll-out. This is particularly useful in per-transaction, per-seat, and success-based models.

SaaS offerings should be priced as subscriptions, but the bases for these recurring charges can differ from ISV to ISV and application to application. Per-seat rate structures are popular among SaaS companies, as are per-transaction models; which works best will depend upon the application’s intended function and how the customer expects to use it. When offering term contracts under either of these models, the ISV likely will want to design tiered pricing based on a certain minimum commitment with monthly or quarterly true-ups (adjustments) based on actual use.

Transforming the Software Industry 7

Another pricing scheme that is particularly popular with customers and early-stage start-up ISVs is the success-based model. Under such a plan, the application tracks business results and issues monthly or quarterly invoices based on business improvements. Lead generation / tracking applications that double as or integrate with customer relationship management tools provide an excellent example. As the customer uses these applications and improves its sales results and/or shortens its sales cycles, the SaaS ISV can track results through the application and share in its customer’s success.

The available pricing schemes / structures can also help an ISV differentiate between product lines and offer different levels of its services. A more robust, feature-rich application – which might be sold as licensed software into large enterprises with distinct requirements and sufficient internal support – could help retain or grow the ISV’s position in the licensed market, while a more generalized version could be priced as a subscription and marketed to small- to medium-sized businesses (SMBs) and lead the way to SaaS adoption and transformation.

More Focused Product Development

All of these benefits contribute to more focused product development because the SaaS ISV has real-time visibility into what works for its customers and what needs work. Requirements are more readily prioritized because actual usage by multiple customers – or a projected increase in usage based on certain customers’ past behaviors – can dictate development. This decreases the tendency to invest in features that will never be used by most customers.

Increased Market Opportunities & Alternate Channels

Moreover, the model opens up new markets to the SaaS ISV. Due to lower total cost of ownership (TCO), SaaS applications can be readily sold into SMB verticals. Here, software pricing has not been the only variable inhibiting ISV entry and expansion. Smaller companies lack the robust information technology (IT) departments of larger enterprises, so their resources – in terms of both personnel and available hardware and network infrastructure – are severely limited. SaaS applications require only internet connectivity, which is virtually ubiquitous in today’s business environment, so new SMB customers need limited dedicated resources in order to consume the service.

The simplified nature of SaaS deployment also aids SMB market entry where infrastructure cost was too high for traditional delivery. Targeted features can be readily developed with a vertical focus. These benefits make it easier to deliver solutions via alliance partners, allowing ISVs to open alternate channels. SaaS applications’ single code base and component user interface will attract channel partners (in the manner of salesforce.com) or better execute on a verticalized strategy (such as Seibel On Demand).

A vertical strategy allows the SaaS ISV to increase its targeted offerings of value-added services because it can develop best practices based on the industry / vertical and then sell optimization services based on an analysis of customers’ usage and behavior. Even with such customization and verticalization, the SaaS ISV can bring new products, services, and releases to market in a much more cost- and time-efficient manner.

Transforming the Software Industry 8

Partnership Opportunities

Potential partnership opportunities present themselves in the areas of training and support. SaaS ISVs can enlist their partners to support end-user training, engaging in “train-the-trainer” activities. The SaaS ISV also has more training options and can produce webinars that are always available on line, or it can offer similar webinars led by a moderator who takes questions.

More complex applications might require a more interactive environment like webinars lead by trainers or on-site training. The SaaS ISV needs to determine what, if anything, it will charge for these more costly options. Other strategic alliances and channel sales partnerships are discussed more fully in “Sales & Business Development” (section 3).

CHALLENGES

The primary challenges in developing a SaaS offering are developing the full-service business model, code appropriate for the SaaS environment, and on-going operations. Sales compensation, another business model challenge, is discussed in “Sales & Business Development” (section 3).

Business Model Challenges, including Pricing, Placement & Promotion

Identifying the appropriate pricing scheme and determining the right price are key challenges, particularly in the early stages of the SaaS model's development and adoption. SaaS vendors will not have a large number of competitors against which to review pricing schemes; they must avoid setting pricing based solely on competing perpetual license software offering similar applications. The ideal pricing structure will be based on all of the customers' economic alternatives to using the SaaS application; e.g., if the application facilitates integrated back-office processes, one pricing methodology would be to determine the customer's cost of hiring additional personnel to perform the tasks managed by the SaaS application.

Because SaaS providers are offering a complete service, they must promote it as such and target their placement at the business customer who most experiences the problems that the SaaS application solves. While promoting the solution via whitepapers and other analyses is a great tactic, it is largely useless to publish an article on the regulatory challenges in the international shipping industry in a journal dedicated to software development. The key to both product promotion and placement is for the SaaS vendor to establish its credibility as a provider of business solutions by demonstrating its expertise to the appropriate audience.

Before developing the complete set of intellectual property and introducing the application to the market, the SaaS ISV should consider these factors in building the product management plan:

• Architecture • Packaging • Pricing • Service level agreements (SLAs) • Partner-enabled solutions • Support

Transforming the Software Industry 9

Operations-Related Challenges, including Infrastructure Architecture

SaaS ISVs will need to pay close attention to the infrastructure required to deliver their product, including:

• Network, server and application security • Lload balancing • Data backup and disaster recovery • Change control • Customer support and help desk, including escalation procedures (see

“Customer Service & Support” in section 4)

All of these services are significantly different from traditional licensed applications. Some of these topics are discussed more fully in “Operations” (section 5),

SaaS applications must be architected for an environment utilizing shared hardware and network resources. Equipment must be configured to provide virtualization services and to ensure balanced work loads, particularly during peak usage periods. . Multi-core processors are necessary to help ensure uptime and robust processing capability. For security, the equipment and network must be protected with firewalls, the SaaS ISV must provide access to and from virtual private networks, and it must also provide storage area network (SAN) support.

Code-Related Challenges, including Multi-Tenancy, Open Source, Browsers, etc.

SaaS applications must accommodate access via different browsers, but coding requirements go beyond that. ISVs must pay attention to the deployment of single instance vs. multi-instance vs. multi-tenant applications; proprietary middleware and databases vs. open source alternatives; and provisions for application security, user authentication, and generating billing records. More on how code development will differ from that done for perpetual licensed applications is detailed in “Technical and Product Development” (section 6).

One major difference between the SaaS model and that of application service providers (ASPs) is shared tenancy, meaning the application’s ability to support multiple customers with a single software instance. Shared tenancy helps in scaling growth, but it also means customers’ data must be kept separate from one another for security purposes. The most effective shared tenancy configurations delegate the administration processes for setting up companies and individual users, and they contain internal data security within the application’s core database.

In developing their code architecture, today’s SaaS ISVs must consider open source options such as JBOSS, MySQL, and others. These cost-effective alternatives offer ISVs developing new SaaS code the opportunity to break from their past dependence on expensive middleware and databases.

In development of the SaaS application, ISVs must consider the appropriate deployment architecture for scalability and reliability. Three- or four tier deployment works best for scalability, and clustering provides additional application stability, as do failover provisions at the database and other tiers.

Transforming the Software Industry 10

Integration Challenges

Maximizing flexibility in application integration is key in SaaS product development and management. Most companies provide some kind of service oriented architecture (SOA) interface, but most do not architect for pure SOA deployments because of the need to be very security-aware, providing protections from the application program interface (API) through user levels, and the SaaS ISV needs to ensure that access levels are consistent.

When designing and deploying the application, the SaaS ISV should consider how it will integrate with customer and partner processes and infrastructure. Multi-point integration is both scalable and reliable, and SaaS ISVs do well to accommodate data transformation, including mapping. Of course, security and access infrastructure must also be fully integrated.

Product Cannibalization & Multi-Line Challenges

Perpetual license ISVs with existing enterprise customers may worry about revenue “cannibalization” as their existing customers migrate to the SaaS platform. This is of particular concern for larger, public companies that are acutely aware of how their quarterly performance is judged by Wall Street, but it is also an issue for privately held ISVs with established customer bases. IDC is projecting that more than 50% of all enterprise software solutions will be sold via a SaaS platform by the end of the decade. Companies must master and exploit the SaaS delivery model, or ultimately their competitors will take their customers.

SaaS cannibalization is going to happen. The question is whether any particular ISV experiences it from within or from a competitor.

One approach for perpetual license ISVs is to introduce their SaaS solution into a different market, establishing an expanded, balanced product mix. These ISVs must determine whether their architecture lends itself to a fully multi-tenant application. If not, they can conserve some development capital and test the market with a suboptimal version of the SaaS application as they control their transition.

Service Level Agreements

No matter the product mix or pricing scheme, the SaaS ISV must also determine what kind of service level agreement (SLA) it will offer with its on-line application. What guarantee will the ISV make that the application and all customer data will be available? Customers will demand 24-hour a day, 7-day a week access, and the SaaS ISV must determine what level of risk it is willing to accept in providing uptime commitments. If the application, network, or access fails, what will be the remedy provided to the customers? Will the ISV issue credits, and, if so, at what level?

These matters are further complicated when the SaaS ISV partners with other service and application providers. The partners need to determine up front how far they will take integration, both technically and from a business perspective. Which of the partners will “own” the integrated product’s branding? Which will “own” the customer and be responsible for billing and collecting revenue and handling customer service issues? As discussed more fully in the next section (in the context of channel partners and alliances), implementation (i.e., on-boarding)

Transforming the Software Industry 11

must be designed to facilitate such partnerships for these alternate sales channels to be effective.

SALES AND BUSINESS DEVELOPMENT

Nowhere else in the software-as-a-service (SaaS) business will the clear and successful paradigm shift to a service focus be more important than in customer acquisition and revenue generation. Successful SaaS providers are re-honing their entire sales, marketing and business development functions away from the application itself and learning to offer expert services through the delivery of that app. They are moving beyond merely selling software and, instead, are selling business solutions delivered via the SaaS technology platform.

This change first manifests itself in the guerrilla marketing tactics employed to develop brand, markets, and leads, and it is carried through strategic partnerships and direct sales efforts. The SaaS provider establishes itself as an expert in the business problems addressed by its application, and, by helping its customers solve those problems, becomes a trusted advisor, elevating itself from a mere position on the enterprise supply chain.

BENEFITS

As a trusted advisor, the SaaS provider is in a position to influence the operating and buying decisions its enterprise customers make. This enhanced relationship (as opposed to the traditional “license and forget” relationship between perpetual license ISVs and their customers) increases brand awareness because every user becomes part of the SaaS provider’s viral marketing campaign. Moreover, the positioning of the application as a service offering attracts new and different channel partners, particularly if the application provides a solution to the channel partners’ own business problems.

Enhanced Customer Relationships via Guerrilla Marketing Techniques

Because the SaaS provider assumes responsibility for the functioning and maintenance of the app, the relationship between vendor and customer can be focused on how the application improves the users’ business processes and performance. With broad exposure to its customers’ varied uses, the SaaS provider gains industry-wide experience in how problems are solved and can make best-practices recommendations. By publishing white papers and articles, conducting seminars and webinars, and participating in industry forums and panel discussions, SaaS providers can share this expertise and reaffirm their position as service and solutions providers, more than mere technology vendors.

These techniques combine with the "inbound world" of on-line marketing (including the use of search engine optimization, meta-tagging, Google "AdWords" campaigns, and strategically-placed blogs, webinars, and other Web 2.0 features) to provide the SaaS ISV with high-quality actionable sales leads.

When integrated with traditional brand marketing, guerrilla techniques such as drip marketing combined with whitepaper programs promote the added benefit of reducing the need for cold-calling and other proactive lead generation techniques.

Transforming the Software Industry 12

By bringing the customer’s focus on the solution, such guerrilla / service marketing benefits the SaaS ISV because price is less of an issue during the actual sales cycle.

Alternative Channel Development

The solution-focused, trusted advisor role can also broaden the SaaS ISV’s potential channels and strategic partnerships. The traditional relationships with systems integrators, hardware vendors, and other application providers are still available, but with increased value due to the SaaS application’s greater accessibility. The channel approach is broadened because the SaaS application can be readily bundled with other solutions offered by the strategic partners, whether they are hardware, software, network, or other services. Short of bundling or channel sales, the sales process is simplified by better demos. SaaS applications – by definition – do not need to be installed on the customer’s equipment to be demonstrated. The customer needs only a temporary log-on procedure and, possibly, some assistance populating the application with live data that can show the application’s functionality.

Demonstrations can be readily converted to trial sales periods and then to actual sales, further simplifying a sales process made easier by the guerrilla approach to marketing.

Increased Sales Effectiveness

By expanding on the solutions focus, the SaaS ISV’s sales organization usually can avoid selling into its customers’ technical departments, unless the application has specific utility to them.

Similarly, the SaaS ISV’s sales teams generally can avoid the problems of selling elusive “return on investment” benefits to CFOs and other financial executives. It is far easier for the SaaS ISV to sell a service that calls for a recurring subscription payment or, better yet, has a success-based pricing scheme.

The SaaS ISV’s sales teams can focus on their end user customers’ business problems and sell their application’s utility in helping solve them. That means selling to business users: CRM tools can be sold directly to sales vice presidents, PLM tools directly to manufacturing departments.

Shortened Sales Cycle

The simplified sales process should significantly speed up the average sales cycle and, because the application is delivered easily on-line, allow every sales team to support more customers. These translate directly into greater revenue per ISV employee.

CHALLENGES

Probably the most significant hurdle for the SaaS ISV to overcome is the need view itself primarily as a service provider to its customers, rather than as a technology vendor. This paradigm shift requires a change in management’s focus and how the SaaS ISV describes itself. It also necessitates a complete overhaul of its processes and systems

Transforming the Software Industry 13

Thus, ISVs in the SaaS space need to look closely at their sales and marketing systems and processes to effectively implement changes. They need to think always in terms of solutions to their customers’ problems (or, better yet, in terms of solutions to their customers’ customers’ problems). With this very different service view, they can begin rebuilding their sales and marketing strategies, plans, and tactics to ensure SaaS success.

Developing Guerrilla Marketing Strategies

The implementation of this new view begins with the guerrilla marketing tactics used to establish the SaaS ISV’s expertise. The ISV’s marketing department needs quality content for its white papers, seminars / webinars, press releases, newsletters, etc. This content must be useful to customers in the ISV’s target verticals, and it must not be merely disguised advertisements for the SaaS application.

Solution Sales Process

Because the sales contact follows directly from the marketing initiatives, it is critical that the SaaS ISV adopt a solutions-focused sales process. Gone must be the standard “features and benefits” pitch. Instead, the ISV’s sales organization needs to adopt a consultative sales style that reveals customers’ pain and allows the ISV to propose solutions that include use of the SaaS application. Demonstrations focus on how the application solves the customer’s problem. Other application features and benefits, then, come last, as an afterthought.

Selecting Appropriate Channel Partners

Channel partners, too, must be selected and managed to present the SaaS ISV’s solution instead of its application, either separately or as part of the channel partner’s bundled offering. Such partnerships and strategic alliances may present challenges to ISVs not familiar with this kind of relationship. The SaaS ISV’s back-office processes for demonstrations, enrollment, and implementation must be sufficiently robust so they are virtually transparent to both the alliance partner and the end user. Make them simple -- complicated or repetitive procedures will drive the channel partner to offer other solutions or none at all.

Effective Compensation

Direct sales compensation for SaaS ISVs also require different approaches to setting quotas, defining commissionable events, and establishing payment plans. SaaS ISVs must link the timing of compensation payments (for both direct and alternative sales channels) to receipt of revenue to avoid negative cash-flow issues and minimize overpayment for revenue acquisition.

The attraction of familiar, traditional software compensation plans presents a major challenge. If they pay commissions based on an estimated total contract value, SaaS ISVs create the unnecessary complexities of managing charge-backs and can develop cash-flow problems. Annuity payments of sales compensation present a simple alternative but offer other problems. Salespeople find them slow to ramp up to desired earnings. They also may expect infinite on-going payments from existing customers. This pattern of continuing payments may transform a “hunting” sales force dedicated to acquiring new revenue and growing the ISV’s top line to one primarily concerned with “farming” the existing customer base.

Transforming the Software Industry 14

Compensation planning and quota assignment must also anticipate shorter sales cycle. Tthe SaaS model should anticipate more customers per salesperson and more closed sales in a given period. SaaS ISVs must address sales achievement early in the compensation planning process to ensure appropriate goal-setting and staffing. When transforming an existing sales force to a SaaS revenue and compensation plan, education of the upside potential is key to properly motivating continued success.

Compensation of channel partners also must drive sales activity but also be tied to future account maintenance / ownership. If the channel partner will maintain and grow the relationship with the customer, then the SaaS ISV must provide resources and pay for that activity. If, on the other hand, the customer is handed off to the SaaS ISV, a different channel commission structure is needed. While some channel conflict is not altogether bad, unbalanced compensation will expand battles between channel and direct sales, creating sales management problems.

CUSTOMER SERVICE & SUPPORT

After establishing itself as the subject-matter expert in its customers’ particular business problem with the de facto solution addressing that problem, the SaaS ISV must deliver on its promises. That falls to customer services and technical support. As a trusted advisor, the SaaS provider must take its service offering beyond merely understanding how its application works to how its customers use the SaaS offering and what they hope to gain from it. These changes can be challenging at first, but the benefits of implementing them go far beyond simplified, more regular service procedures and processes. When executed properly, expanded customer services and support enhance the SaaS ISV’s reputation, contribute to a powerful viral marketing effort, and provide valuable insight into customers’ businesses that can be used to further expand the SaaS business.

BENEFITS

Operationally, the ISV benefits from this approach to customer services and support in the form of simplified and more IT controlled environments. Since a single incidence of the application is used by multiple customers, fixes easily reach the entire customer base at once. High visibility into usage reveals problems sooner, and the iterative development process inherent to robust SaaS delivery allows a far more rapid response to customers’ issues than in a traditional installed environment.

Consistent Operating Environment

Because the application is offered from the same platform for every customer, the operational IT environment is controlled by the SaaS ISV. This presents a stark contrast to the traditional installed license model, where the ISV’s customer and technical service personnel must learn and understand the customer’s IT infrastructure.

Thus, with the number usage configurations vastly reduced, the SaaS ISV customer services and support personnel can be trained to focus on how the customer is using the application and what business improvement the customer expects.

Transforming the Software Industry 15

Support Costs

This consistent operating environment also lowers the SaaS ISV’ssupport costs because personnel need not be trained in the many possible configurations to run the application, and the ISV need not invest in the equipment and resources to simulate these environments. Moreover, truly expert SaaS ISVs can develop professional services organizations that provide business guidance beyond the application’s functions. Of course, such value-added services provide the SaaS ISV with other potential revenue streams.

Technical Support Costs

Even though technical application issues arising within the SaaS environment are fewer in number, the technical support demands by SaaS applications can generate higher costs than those of the traditional model because of 24 x 7 x 365 availability requirements. Tech support personnel must be available any time a customer might use the application.

Best Practices Based on Actual Usage

The SaaS ISV has extremely high visibility into customers’ use of the application. Based on usage patterns and the SaaS ISV’s experience in implementing other customers, the SaaS ISV can provide best practices advice. Demonstrating success in these areas allows the SaaS ISV to obtain customer references, which establishes the SaaS ISV as a full-service provider focused on solving its customers’ key business problems.

CHALLENGES

The real-time nature of the application’s delivery and subsequent support services can present some difficulties for new SaaS ISVs, but these are readily overcome.

Release and Upgrade Control

SaaS ISVs need to maintain tight control over new releases and upgrades because they affect the entire customer base. Proper change control procedures and roll-back capabilities need to be in place prior to any general release.

Controls should include a clear process for applying patches and upgrades, including operating a sandbox for testing, and a very robust quality assurance process to ensure the mandatory high quality levels.

Advance Notification Requirements

Advance notification to customers (usually administrators as opposed to the entire end-user base) prior to significant patches or upgrades can avoid surprising customers and increasing customer support calls. Pre-release training for new functionality and fixes will provide the ISV with the opportunity for more real-time feedback from users

Transforming the Software Industry 16

User & Partner Training

The requirement for robust initial training falls on the SaaS ISV’s customer services and support teams for both direct sales customers and those acquired through and supported by alternate channels. The most successful SaaS vendors implement multi-channel training and support.

Both in-house staff and channel partners ideally will become true experts in the both end user’s business and in the application so that they can help implement the application and deliver value-added services to the customer.

On-Line Customer, User, and Technical Support

Both channel and direct support services should be augmented by on-line or web-based technical support, and the SaaS ISV needs to make sure it provides tools to make support as robust as possible. For example, technical support personnel need to know how the application functions with different browsers.

Instead of troubleshooting the application, SaaS customer service and support seeks to help the customer unlock the value of the application after implementation.

OPERATIONS

Software-as-a-Service (SaaS) applications require independent software vendors (ISVs) to possess operational expertise and the ability to address network and hardware issues that packaged software vendors never face. These issues arise from the need to deliver the SaaS application reliably on-line, in real time, and to multiple customers.

SaaS requires the ISV to deliver software functionality over a network, in most cases the internet, to customers who believe they are accustomed to high reliability from their own data centers. Although it is unclear that company-operated or -outsourced data centers provide any greater reliability than those used by SaaS ISVs (and it is entirely possible that studies will support some SaaS providers' contention that SaaS applications are more available, overall), the real test for SaaS ISVs will be whether they can maintain high reliability as they scale. As they reach the limits of single data center operations and/or the transmission speeds necessary to maintain truly redundant infrastrutures, it may be necessary to create separate instances that allow a failure to be limited to a small number of customers.

This section addresses the benefits and challenges of the SaaS provider’s operational requirements from three categories:

Infrastructure Hosting♣ & Operations, which involves the physical data center itself, the hardware and infrastructure software, and the network connections necessary to link the data center to SaaS customers;

Application Management, which is the day-to-day fine-tuning that optimizes♣ how a specific SaaS application runs; and

Transforming the Software Industry 17

Service Delivery, which, in addition to actually provides the service to♣ the SaaS customer, requires planning for the entire lifecycle of both the application and the customer.

BENEFITS

Operationally, the benefits to SaaS ISVs are found primarily in expanded opportunities for cost efficiencies as well as the extent to which the SaaS business model lends itself to automation. Since all SaaS customers are being delivered essentially the same application via the same infrastructure, ISVs experience operational gains in the form of greater efficiencies and the ability to more readily scale support with customer and revenue growth. Clearly, these benefits carry through to the ISVs’ bottom line, translating into increased profit opportunities (as discussed in “Finance,” section 8).

Infrastructure Hosting & Operations

Whether the SaaS provider decides to host their software or outsource some or all of the operational activities to a SaaS hosting service, many cost-effective options are available. Both options come with their own sets of benefits.

By investing in the necessary hardware, infrastructure software, and people, the SaaS ISV closely controls the infrastructure for its services. With many hosting competitors, equipment can be acquired at reasonable cost, and open source options can dramatically decrease the cost of infrastructure software. Reliable data center space is ubiquitously available, as is highly dependable internet bandwidth; both will be acquired in the same location, often from the same vendor, and ISVs can provide their customers with added reliability by establishing redundancies with different vendors and in different locations.

Still, some ISVs may decide that self-hosting will increase time-to-market by an unacceptable amount. They can choose to hand off the operations to any of a number of SaaS hosting services. Should they decide to outsource, SaaS providers should understand the complexities involved and determine whether their SaaS hosting vendor meets all of the service level and redundancy requirements necessary.

A growing number of these SaaS vendors are exploring quality certifications such as SAS 70 or ISO for themselves or their hosting service, which some customers may require in addition to security audits of the hosting environment. By acquiring these certifications as part of a hosted SaaS package, ISVs can save the time, trouble, and cost of becoming certified themselves.

For all infrastructure vendors – from hardware and data centers to bandwidth providers and outsourcers – robust service level agreements with teeth are available. SaaS ISVs should obtain assurances from their suppliers that they quality, fully integrated service is always available.

Because the business and operations processes required to deliver the SaaS application will require coordination across multiple departments, many ISVs will develop automated operations systems and clearly define responsibility for implementing operational policies.

Transforming the Software Industry 18

Application Management

When application problems arise, generally a single fix will correct all incidents of the same problem. Moreover, when built properly, the hosting environment and application are far more scalable than the underlying infrastructure in a traditional packaged software environment. SaaS ISVs can enroll more customers more quickly without having to hire additional support personnel or add more infrastructure than their traditional perpetual license counterparts.

Service Delivery

As with application management, one of the main operational benefits in regards to service delivery is the increased efficiency SaaS ISVs achieve through standardization, automation and scale. When billing, help desk, usage data, and auditing functions are all linked, the SaaS ISVs’ management teams have increased visibility into the health of the company and its relationships with key customers. Usage tracking, revenue sources, auditing processes all benefit from increased integration. Key touch points can be developed to provide a broad array of operational data that help the company stay on track and manage its growth.

Moreover, the iterative application improvement and release process described in “Product Management & Marketing” (section 2) allows the ISV to better control and support the versions of software that are on the market. By ensuring that a single patch, fix, or upgrade impacts all customers equally and at the same time, the SaaS model further democratizes the application and improves the quality of the basic service for all.

CHALLENGES

Because most software companies have little experience with the requirements of running a publicly accessible network, including the hardware, connectivity, and other infrastructure necessary to support it, the operational challenges to provisioning SaaS may seem foreign and cumbersome. As with any service-oriented system, the keys are in thorough planning, coordinated execution, and regular monitoring and follow-up. The key is to provide “always on” service, and SaaS ISVs’ operations departments are tasked with that responsibility.

Infrastructure Hosting & Operations

Redundant systems will be required to meet customer-facing SLAs for bandwidth (multiple providers of internet access) and data storage (often both on-site and off-site back-up). SaaS providers also must decide whether they will invest in fully redundant data centers for failover if one goes down or live on the dangerous side by operating from a single data center.

In either event, each vendor must provide its own SLA and be held, contractually, to standards of reliability and redundancy. Each bandwidth provider must provide connectivity reliability guarantees, each data center will require round-the-clock support either on-site or through remote monitoring, and data storage systems must have fail-safe options.

Beyond the physical devices and connectivity, the SaaS provider must support and maintain the stack of infrastructure software (operating system, database, application server, Web server, etc.) that the SaaS application runs on. The

Transforming the Software Industry 19

functions include provisioning adequate resources to run the application, configuring different elements of the stack to work together, and patching each piece of infrastructure software as required. Patches may require reconfiguration.

Operating systems and databases must be administered, and the entire environment must be monitored to comply with third-party software licenses. The SaaS provider or hosting service also must address the many details of testing, deploying and managing cabling, switches, routers, firewalls, load balancers, backbone connectivity, etc.

Whether SaaS ISVs choose to conduct these operations themselves or outsource to hosted SaaS systems providers, the data center itself must be physically secure, and each customer’s data within the data center tightly guarded. Each SaaS customer will require fine-grained access control so that only authorized users within the company can access the SaaS application and related data appropriately. Customers may require support for multiple authentication technologies.

Application Management

In order to ensure optimal function of the SaaS application, the infrastructure will require regular tuning. Tuning includes customized security for servers and other devices, monitoring thresholds for application and devices, and monitoring storage for reliability and performance. An auditing system and processes must track all layers of the application hosting environment, managed service, database and application. Incidents must be monitored through to resolution.

In case of problems, specific roles and procedures must be assigned for dealing with events. These include escalation procedures when specific events triggered by the application (SLA requirements for example) require a response. That may include creating a “run book” to log responses to application-based events.

Once procedures are established, they must be managed to make certain they are followed and altered as necessary.

Service Delivery

On the customer-facing side of service delivery, procedures must be created to bring new companies and employees on board. These will cover user (and company) provisioning and change management as employees are hired, leave or change jobs.

The SaaS provider must establish specific responsibilities for implementing (or “on-boarding”) new customers and users. Whether the on-boarding process will be handled by the SaaS ISV’s operations departments, customer service, professional services, or other group will vary, but the process will cut across functional lines within the SaaS provider’s organization. A matrix approach may be employed that includes people from sales, support, customer service, finance and internal operations. An external professional services provider also may be involved in some implementations.

Access to the SaaS application may require supporting a range of authentication technologies used by different customers: Username and password, single sign-on for users, digital certificates, public key infrastructure (PKI), hardware tokens or biometric devices.

Transforming the Software Industry 20

Most SaaS applications do not run in isolation at a customer’s site, so they will need to be integrated with other enterprise applications, customer or partner portals, or even public Web sites. Security and access control for the SaaS application may be based on an existing relational database, directory server or enterprise application such as SAP or Oracle. Integration may be undertaken by the customer, SaaS provider or a third-party integrator.

In addition, SaaS providers must contemplate how much to customize their application to meet an individual customer’s requirements. The customization issue will impact not only future releases of the SaaS application but other departments within the SaaS company.

Integration also will be required within different departments of the SaaS provider itself. Billing, help desk, usage data and auditing functions must be linked. Software bug reports and trouble tickets must be shared among multiple departments. Tracking and auditing systems must be monitored for reporting and compliance.

For the application itself, procedures must be established for rolling in patches and new releases and winding down old releases as they are phased out. Certain customers may prefer to stay on an older release, so the SaaS provider must evolve policies for that.

TECHNICAL & PRODUCT DEVELOPMENT

With the Software-as-a-Service (SaaS) model’s dramatic changes to the way businesses procure, use, and pay, for software, it is important for business leaders – of any discipline – to fully understand the Technical and Product development aspects of SaaS and the implications they have on businesses.

SaaS applications follow the same general lifecycle as other kinds of software; it simply speeds up the lifecycle.A product development lifecycle starts by gathering customer needs, followed by a development phase and then a beta rollout phase where customers can provide pre-production feedback on a prototype. Finally, the loop is closed with additional customer feedback on the production system that is then fed back into the lifecycle for future application releases. With SaaS, these steps proceeds more quickly and thus cost-effectively.

BENEFITS

The primary technical and product development benefit of SaaS is lower costs. In the SaaS model, product can be brought to market, upgraded, and serviced on a more efficient per-customer basis than in the traditional perpetual license model.

Development Costs

Software development costs can be (but are not always) lower when building SaaS solutions. SaaS development departments must architect solutions and processes to be as flexible as possible. Maximum flexibility can be achieved though service oriented architectures (externally and internally), component-based architectures (internally), object oriented programming languages, and agile development methodologies.

Transforming the Software Industry 21

Distribution Costs

The traditional software model has always been burdened by costly distribution (getting software to customers), installation management and support (of application installs or upgrade patches). SaaS makes these processes much simpler and efficient.

By nature, the SaaS solution is hosted in one logical location controlled by the ISV. Called “shared tenancy,” this location is a single logical production application for multiple users (or “tenants”). In the shared tenancy environment, software and on-line documentation updates occur simultaneously and immediately for all customers.

Similarly, when emergency fixes are necessary, the SaaS distribution model is cheaper than the traditional model, thereby making SaaS solutions inherently more cost-effective and secure.

Finally, because controls 100% of the technology used to deliver the service, reusing technology for new components is trivial. For example: A SaaS provider could readily remove the standard web browser as the user interface and replace it with a system-to-system interface (thereby enabling partner systems to communicate real time) and effect such a change for all designated users at one time.

Product Feedback Costs

Because switching costs can be low for SaaS solutions, products must be developed as clearly and intuitively as possible. However (as discussed in “Product Management & Marketing,” section 2), this increase in cost is more than balanced by a savings in the cost timeliness and accuracy of user feedback that fuel future requirements gathering.

The two most important analytics for measuring implicit user behavior are relative click-through rates and bread crumbs. Additionally, technical product developers can gather low-cost direct user feedback by implementing web-based point-of-interaction surveys.

Asset Click-Through (Indirect Feedback)

Click-through rates measure how often a link (or other actionable asset) is clicked by a user. Over time, technical product developers can see changes in click-through as assets are changed. For example, as soon as an asset drops below the fold (i.e., the bottom of the user’s monitor screen) its click-through rate drops dramatically. Measuring and monitoring click-through rates tell technical product developers if the right assets are receiving the right amount of attention, and this feedback can be provided in near-real time.

Bread Crumbs (Indirect Feedback)

Bread crumbs tell the whole story of a user session by showing exactly what pages and actions were taken in what order; they can be viewed on a session basis or in aggregate. The value of bread crumbs (or “bread crumbing”) is that technical product developers can easily see if users are using the application in the same manner as expected. Specific attention should be paid to drop-off rates.

Transforming the Software Industry 22

Point of Interaction Surveys (Direct Feedback)

Developers and product marketers can easily and inexpensively gather user impressions right at the point of interaction by implementing web-based surveys. These survey results are timely and near-real-time. . Many development tool packages and third-party services exist to gather and report such survey results.

CHALLENGES

When comparing traditional customer-installed software with SaaS products, the single largest technical cost differential lies in the operational functions of setup, service, and maintenance. Since product usability is a new concern for SaaS ISVs, other indirect costs (such as customer service and revenue acquisition and maintenance) will increase; however, this is not usually a technical or product development issue.

Security

Application security is a much higher concern with SaaS than in the traditional software model. The SaaS model that delivers an integrated package of network connectivity, hardware, and application software is necessarily exposed to the internet (and its security risks) for connectivity. As discussed in “Operations,” section 5, the SaaS ISV must also take security precautions to protect its network connectivity and hardware, as well. The entire integrated system can be vulnerable to viruses, worms, database injections, and denial-of-service attacks, and the SaaS ISV must bear the cost of protecting against them.

SaaS providers must clearly articulate their security policies and procedures, and they must have processes to recover from a security compromise. Security not only protects sensitive user data, but also ensures SLA compliance, reliability, and disaster recovery.

Availability, Reliability and Disaster Recovery

Because SaaS solutions locally house all capabilities and customer data and because customers increasingly expect 24 x 7 x 365 availability, the SaaS ISV must develop internal policies and procedures to meet these performance standards.

A highly available system is not possible without high reliability. SaaS vendors must prepare for operational spikes in customer demand, sub-system failures, and security breaches. Applications properly architected with zero single-points-of-failure (ZPF) radically increase overall system reliability. (Technical and product development organizations need to plan for any failure. ZPF analysis consists of analyzing all physical layers – network, hardware, software – and identifying any component, upon failure, that will render any subsystem inoperable.)

Scalability

When deploying an initial SaaS system, customer demand must be clearly estimated and the resulting system implications must be accurately estimated.

Technical and product development organizations are also responsible for growing the applications in time to satisfy increasing capacity demands. This is achieved

Transforming the Software Industry 23

through monitoring the usage of scarce resources as well as staying abreast of pending large increases in users to project future demand. In the SaaS mode, a big sale requires technical and product development groups to prepare for increased demand.

Product Usability

SaaS software carries very low switching costs. When an application’s medium is a web browser, competitive offerings are a simple web-search away. For this reason, technical product developers of SaaS applications should strive for clean, clear, intuitive user interfaces.

Clearly, solutions can be stable and viable with less-than-perfect usability; however, companies that don’t study usability and craft the user interface will see lower customer retention and a higher cost per customer acquisition.

While this may increase the cost of developing and maintaining the best user interface, the internet-based model allows product development to see quickly and clearly the implication on user interface changes.

FINANCE

A SaaS model carries specific requirements for the ISV’s finance, accounting and controller departments. The goal is more consistency in the ISV’s processes with customers, thereby improving the relationship between the two.

BENEFITS

The primary benefits to the ISV’s controller function will be found in the improved automation and standardization of its functions as they relate to the company’s customers. This is similar to “Operations” (section 5) and “Customer Service & Support” (section 4). While the number of accounting transactions for SaaS will increase dramatically, particularly in billing and collections, the costs and complications associated with such increases will be more than offset by the efficiencies gained.

Billing & Collections

While traditional software vendors will be inclined to adopt policies for annual billing done in advance, customers may resist. For customers, annual billing obviates the benefits implied by the SaaS ISV’s service. Instead, regular cycles that bill customers monthly in advance (with monthly or quarterly true-ups (adjustments) as required for per-transaction or performance-based pricing) will provide the ISV with regular and predictable revenue streams.

Automated billing systems are readily available and can be customized to particular needs, and the ISV can establish regular automatic payment processing through its and its customers’ banks. These will minimize collection efforts, which (if they must be employed) can include disconnecting customers that are in arrears from the service and their business data.

Transforming the Software Industry 24

Contract Renewals

Generally support contract renewals in the perpetual license ISV are handled by its finance department. SaaS contract renewal is no longer about application support; instead, it is about continued product relevance, customer support, and overall service utility. The mechanics of renewal can be reassigned from the finance department to customer service or sales since they are focused on continued customer satisfaction. However, review or audits by finance will provide checks and balances.

Contract Standardization

In the SaaS environment, customers understand that they are enrolling in a more standardized offering, and contract terms can be standardized too. Such standardization benefits the ISV’s finance department because it obviates the need to manage the bulk of the company’s contracts on an exception basis. With standardized contract terms, automated billing systems, and the ability to manage customer usage-based payments in an automated environment, the SaaS ISV’s finance organization can readily support the larger, more regular customer base. This point is discussed in more detail in “Legal” (section 8).

CHALLENGES

The greatest challenge to the adapting ISV’s finance organization will be in the change in mindset. Part and parcel of the market drive behind SaaS growth is the enterprise software customers’ desire to change the fundamental nature of their relationship with their technology vendors. SaaS ISV finance organizations will need to successfully adapt to the service-focused metrics necessary to support this new model.

Billing & Collections

ISV financial executives will point out that generating invoices and receiving payments monthly boost the number of paper and accounting transactions dramatically. This is not to be taken lightly.

Finance departments will need to work closely with product management and marketing on mutually acceptable pricing schemes that can be supported by accounting and still meet customer expectations.

A monthly cycle, clearly preferred by customers, will require a clear, efficient, and scalable process – preferably one that maximizes automation – for billing and collection.

True-Ups, Charge-Backs, and Credits

SaaS ISVs that do not or cannot support a monthly recurring billing scheme and instead adopt a quarterly or annual process will find complexity in the mechanisms for performing scheduled true-ups (based on a comparison of billed or estimated usage to actual usage) and the resulting charge-backs and credits. The gains realized by avoiding a monthly billing cycle may well be consumed by the complications of quarterly or annual adjustments and the resulting proofs and audits necessary to reach agreement with customers.

Transforming the Software Industry 25

Service Level Agreement Management

When outages occur, the finance organization’s will calculate the appropriate, customer-specific amounts for service level agreement (SLA) adjustments.

LEGAL / CONTRACTUAL

The SaaS model provides the same fundamental right to software usage as the perpetual license model, but there are contractual differences, particularly with respect to security, reliability, data privacy, and indemnity. These issues need to be addressed in advance to clarify the customers’ and ISVs’ respective rights and responsibilities.

BENEFITS

Improved standardization in contract negotiations will result in more streamlined legal operations within the SaaS ISV. Not only will these improve customer relations, they will contribute significantly to a shortened sales cycle (see “Sales & Business Development,” section 3), allowing the SaaS ISV to acquire more business quickly and expand into new markets.

Standardized Contracts

The SaaS contract should in many cases be more standardized than the traditional ISV’s perpetual licenses and can be focused on addressing business risks. SaaS contracts will typically include concepts of indemnity and limitations of liability. Ideally, SaaS contracts should be balanced, where the customer and ISV provide mutual guarantees against certain behaviors and limit respective liabilities to actual direct losses. That will result in shorter negotiations and fewer contract revisions. Customers may focus on service level agreements relating to system uptime. That responsibility will remain within the SaaS ISV’s product delivery and sales organizations, while legal retains a critical role in monitoring what sales implements.

CHALLENGES

The service-oriented environment will present the SaaS ISV’s legal department with new and different concepts that will need clarification. As with other contract terms, these generally can be standardized across all customer-facing contracts, requiring little or no negotiation.

Another approach that works well in the SaaS’s service-focused model is to take virtually all non-legal terms out of the standard contract –service delivery, acceptable use, access control, etc.– and put them in a user guide. Incorporated into the contract by reference, such guides are common among service companies, and their content can be changed by the ISV from time to time as circumstances dictate. This provides the ISV with maximum operational flexibility while binding customers to the ISV’s preferred business methods.

Transforming the Software Industry 26

Data and Privacy

SaaS vendors will likely have access to customers’ data. SaaS vendors will need to assure their customers of the security and privacy of such data and may need to address legal requirements of different jurisdictions.

Service Level Agreements

Unlike a perpetual license vendor, the SaaS ISV provides its software on a daily basis and is responsible for provisioning the software. SaaS vendors should provide in its standard customer contract or user guide language that describes the availability of the ISV’s service.

Indemnity

Many perpetual license vendors state that liability is limited to the purchase price of the software. SaaS vendors may use this metric, but it is likely to be less acceptable to customers unless the indemnity language is limited and mutual to both sides.

CORPORATE FINANCE (VALUATION)

The benefits of a SaaS model include a substantial amount of predictable, recurring revenue, which can have the affect of increasing the ISV’s market value. However, traditional perpetual license ISVs transforming to the SaaS model will need to strengthen their balance sheets considerably because of the significant cash requirements for the transition.

BENEFITS

Fundamentally, a SaaS business model provides greater stability and visibility into the business and enables management to manage the business with greater certainty, which ultimately will lead to more value creation for shareholders. Fundamental valuation theory provides that the more certain a company’s cash flows, the more valuable they are, all other things being equal.

Currently, some analysts are viewing recurring revenue as another metric to be considered in determining the value of a software business. Rick Sherlund of Goldman Sachs said that “maintenance revenue remains a useful measure of value” and evaluates companies in part based on this metric. While there are always anomalies, Wall Street generally recognizes the value of strong, recurring revenue businesses and attaches a significant premium to them. As a SaaS vendor continues to demonstrate steady predictable revenues, the premium attached to it will increase.

CHALLENGES

Many ISVs and the venture capitalists that fund them viewed the perpetual license model as a way to ensure financing for the ISV’s operations and continued development. With the pay-as-you-go model of SaaS, ISVs likely will need cash on the balance sheet to support these functions. For example, investors will be concerned about negative cash flow from paying commissions before revenue is

Transforming the Software Industry 27

received unless incentive compensation plans are restructured. (For additional discussion of this, see “Sales & Business Development,” section 3.)

Whether or not Wall Street will recognize the benefits of recurring revenue is also difficult to predict. In slow economic periods and downturns, Wall Street has discounted recurring revenue businesses as unexciting and low growth and thus at those times favored high-growth businesses

Transforming the Software Industry 28

GLOSSARY

ASP Application Service Provider (aka Application Hosting)

An ASP deploys, hosts and manages packaged software applications for customers from a centrally managed facility. The software is delivered over networks on either a traditional licensed or subscription basis. An example would be Corio (now IBM), which offers Oracle, SAP, Peoplesoft, Ariba and other types of enterprise applications through an outsourced infrastructure.

Grid Computing

Using the resources of many, disparate computers connected across a network (most typically the Internet) to work on large-scale computation. An example of Grid Computing is the SETI (Search for Extraterrestrial Life Initiative). User’s can participate by downloading a small program which then borrows unused CPU cycles (when the computer is in screen save mode) to work on small bits of a larger set of information processing.

LAMP Stack (acronym) (o/s), (web server), (database) Perl/PHP (language)

Linux Apache MySQL

A low cost development framework of open source applications used by many SaaS companies to develop and deliver on demand software products.

Multi-Instance

Refers to the ability of an application to run multiple, simultaneous instances of an application’s software on one server in a manner which affords scalability for multiple clients. Multiple Application Instances are commonly managed by Application Servers.

Net-Native

Net-Native describes Software-as-a-Service providers that have chosen the Web Browser as the main client interface for accessing their software product.

MSP Managed Service Provider

An MSP provides delivery and management of network based services, applications and equipment. Managed Service Providers typically offer a range of services and software that can include everything from fully outsourced network management, including things like telephony, messaging or call center – or more traditional software applications such as managed firewall or security applications.

Multi-Tenant

Refers to the ability of a single Application to host multiple, simultaneous End-user organizations.

On Demand

Transforming the Software Industry 29

Originated by IBM in 2005, it is currently used to describe a number of ideas such as: On Demand Business, On Demand Operating Environment, On Demand Phase, On Demand Software

The definition has morphed from its origin, which was originally describing grid computing and utility computing to now include all of

these concepts along with Software-as-a-Service, ASP’s, MSP’s and Service Oriented Architectures (SOA). Generally this equates to fully integrated applications, services and technology that communicate via open standards across the Internet to provide business benefits.

On-Premise Software

As opposed to Software-as-a-Service – On-premise software is installed software located at a customer’s place of business or data center.

SAS-70

Statement on Auditing Standards number 70 (SAS 70) is an internationally recognized auditing standard set forth by the AICPA (American Institute of Certified Public Accountants). This auditing standard is particularly focused on service organizations. SAS 70 is the authoritative guidance that allows provider organizations to disclose their control activities and processes to their respective customers and their customers auditors in a uniform reporting format. Performed by a third party auditor, the standard centers on the internal control activities of an organization. The primary focus is on those controls associated with information technology and the associated procedures and processes. Other controls such as hiring and physical access to systems and documentation are also scrutinized.

There are two types of reports generated under this standard:

• Type I – This audit centers on the process and procedures that an organization has put into place. The processes associated with IT functions, access to systems and information, organizational structure, etc., are reviewed. Also Included in the review are policies as they pertain to hiring and organizational decision making. Think of this audit as a snap shot taken at the time of the review, of all process the organization has in place.

• Type II – This audit takes into account all of the those items under review for the Type I, but includes testing. The auditor will take a period of time (usually 6 months) and test the processes that the organization has established (does the organization follow its own process and procedure). All associated records are reviewed and validated for said period.

Single Instance

A restriction of an Application to require a dedicated server infrastructure for each end-user organization. This architecture consumes significant infrastructure and typically does not scale well in a SaaS model.

SLA – n. Service Level Agreement_

A formal written agreement made between two parties: the service provider and the customer. The SLA defines the understanding between the service provider

Transforming the Software Industry 30

and the customer for the standards by which the service will be measured. The content will vary based on the types of services provided, but will generally contain an enumerated set of “promises” which, if broken, allow for some remuneration for the customer. An example would be an “uptime guarantee” for a Software-as-a-Service provider. The provider would guarantee 99% monthly uptime for a customer. Then if the software application was unavailable for less then that in any given month, the customer would receive credit for the monthly fees that they pay to the provider.

SOA (acronym) Service-Oriented Architecture

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

Software-as-a-Service – n. (aka in acronym form as or SaS SaaS)

Software-as-a-Service is software which is accessed via the Internet and specifically developed and designed to run multiple customers through a single instance of the software. It is this multi-tenancy which distinguishes SaaS from ASP services. Examples of Software-as-a-Service include Salesforce.com. ASP’s can offer SaaS solutions.

Web Services

Web-based applications that dynamically interact with other Web applications using open standards that include XML, UDDI and SOAP. Such applications typically run behind the scenes, one program "talking to" another (server to server). LAMP, Microsoft's .NET and Sun's Sun ONE (J2EE) are the major development platforms that natively support these standards.

Utility Computing n. (see also On-Demand Computing)

Is a model where a Managed Service Provider makes a network of computer resources available to customers and charges customers by usage of the resources, rather than the full cost of the network. Customers can pay for access to a large network of computers for Grid Computing needs and, much like paying the electric company, pay for the metered usage, rather than the entire infrastructure.

XML Extensible Markup Language

An open standard for describing data from the W3C. It is used for defining data elements on a Web page and business-to-business documents. XML uses a similar tag structure as HTML; however, whereas HTML defines how elements are displayed, XML defines what those elements contain. By providing a common method for identifying data, XML supports business-to-business transactions and has become "the" format for electronic data interchange and Web services

Transforming the Software Industry 31

Transforming the Software Industry 32