Software as a Service (SaaS)
By Ed Carroll, Agilis Solutions
Corporate information technology (IT) departments have gone through many changes in the past five years, reeling through corporate downturns and major budget upheavals, sometimes due to failed projects. This upheaval has caused the corporate IT customer (to a software company) to become something different than in previous years. One of the most important changes is the drive to make IT a service within the business model that fuels corporate growth, efficiency and (even) innovation. For example, I know of a large insurance company that is using the Internet to radically change the way it interacts with its constituents, partners and customers as it aggressively goes after new, non-traditional business. In the meantime, the rest of the IT department is experiencing major cutbacks. Corporate IT departments are being held accountable to their own hype in order to show where investments have specifically contributed in a real way to the bottom line. Software as a service (SaaS) offers the CIO some badly needed flexibility while also reducing project complexity; both of which contribute significantly toward project success.
IDC forecasted in 2005 that worldwide spending on SaaS will reach $10.7 billion by 2009. Some examples of successful SaaS products include implementations of leading enterprise resource planning (ERP) packages such as Oracle and SAP, messaging security products from Symantec and integrated customer resource management (CRM) products such as SalesForce.com and Siebel On-Demand. During the coming years, corporate IT is expected to rely more and more on hosted services that deliver deep functionality. Therefore, it behooves any software product company to understand what SaaS is all about. Let’s explore SaaS from the perspective of the customer.
Who is the customer?
There was a time when CIOs built empires and measured their value to the company based on the size of their team and the amount of the capital expenditures they authorized. The recent recession burst that proud bubble. Now the game is to preserve capital and enable services that provide real measurable value to the business.
Cost of ownership. The biggest difference between SaaS and (hosted in-house) enterprise-off-the-shelf software is hidden within the subscription cost model. To install an enterprise software product across a thousand end users requires a significant hardware and maybe network installation project. With a SaaS model, corporate IT can purchase licenses to use the software and be up and running in a minimal amount of time for a minimal entry fee. A large, complex, capital investment project that only shows results many months down the road ties up money, no matter what the expected return-on-investment (ROI) was. SaaS offers equal results, but can be paid for on an expense line. And, with monthly subscription fees, SaaS allows the implementation to go forward with a level of use that corresponds to the level of need at the time of purchase. The lack of the need to purchase hard assets (hardware, cabling, etc.) provides important cash flow opportunities that both the CIO and the CFO prefer.
Of course, the flip side is that the fees never stop, but the capability to cut losses and stop a service if no longer used is a very attractive option. Anyone who has experienced hardware lease negotiations where there was no exit clause, long after the need ended, will appreciate this option.
Service level agreements. There was a time when CIOs collected hardware and built data center shrines as a way to demonstrate their value to the company. Today, corporate IT is focused on providing services that enable business. Therefore software companies that can deliver their software as a service can blend right into their customers’ own priorities and motivations. With SaaS, a client and provider can negotiate the use of the software in the way that works best for the client’s business, whether the client is trying to comply with some governance requirement or simply trying to satisfy some rogue VP (the one who would have bought the software service without asking the CIO).
Security. There was a time when data was talked about as the most valuable asset a company owned. (I once worked for a large corporation in the mid-90s that seriously thought they could prevent any data from leaving the corporate offices.) The SaaS model has the provider holding substantial amounts of corporate data. This is perhaps the single most difficult objection to the SaaS model, making data security a very serious requirement of any SaaS product architecture. A SaaS provider that cannot ensure a client that they can be trusted with the client’s data will not win a lot of customers. Events in the media of Internet hacks breaking into corporate databases or even news about companies losing laptops with sensitive data only add to the need for real, provable security.
Integration. There was a time when most software sales were accompanied by significant professional services to customize and integrate the new software with the existing legacy applications within the client’s data center. Often the services portion of an installation project added more to the cost of a project than the software license itself. During the recession of 2001-2004, CIOs learned that they could live without customization. Now, SaaS has made installation easy, and with a services oriented architecture (see my article on SOA), integration to those legacy applications can be made easy too.
Providing software as a service
Now let’s talk about SaaS from the perspective of the software product provider. Historically, there has always been a bit of disdain between software engineers and IT professionals, both feeling they do their jobs better than the other. A SaaS business model blends these two worlds into a single company. Data center management – hardware, network, security, governance, separation of data, monitoring services, uptime SLAs, backup and restore, etc. – are now a critical part of the product delivery and included in the cost of goods sold.
The cost of infrastructure with a SaaS delivery model shifts from the customer to the software provider, which has serious implications for how a business manages its investments, cash flow and pricing/payment models. Not only must the cost of software development be amortized into the product pricing, but a SaaS model adds all of the expensive capital equipment and hard assets that the customer is trying to avoid into the provider’s side of the cost equation. Complicating the ROI consideration is the elongated and reduced payment schedule. Now, instead of being paid a hefty upfront fee, the pay back on the cost of services is amortized across many customers making small payments for many months.
Selling to the long tail. Chris Anderson coined the phrase “the long tail” in his article “The Long Tail,” (Wired, 10/04). The long tail, as applied to SaaS, compares the price and volume of clients in a traditional enterprise delivery model to a subscription model. The high investment price a client must pay for a traditional enterprise software package (software, hardware, data center, etc.) limits the number of customers willing to make that investment. Offering software for a small subscription fee and allowing it to be accessed across the Internet with no capital commitment requirement for the customer should significantly increase the number of potential customers. However, the upfront investment requirement on the part of the software provider increases significantly – and always ahead of the payback from the client income stream – due to the long amortization period. This means that the prediction of the number and longevity of customers must be accurate or the desired return will never be achieved on the investment made. Furthermore, it is crucial to include in the calculation the cost of operating, maintaining and enhancing the product over its full operational lifecycle.
Operational lifecycle costing is something that software companies often omit (at least early on) from their go-to-market plans, but it is precisely because the infrastructure for a SaaS offering must be funded ahead of the revenue stream that it becomes so crucial to success. For example, after a modest investment to build our Object Request Broker, our margin expanded to 75% over cost very quickly. On the other hand, the ROI for application investments at Egghead.com (an eCommerce operation is a SaaS business model, in case you had not thought about it) took years to recoup, mainly because our margins were always razor thin (<10% is typical for computer retail). Subscription fees or incremental payments of any kind can significantly elongate the payback period, unless the result of a new application or enhancement is that the number of new purchases increases dramatically. This phenomenon places an interesting focus on the priorities of functions and features for future releases. New customer acquisition becomes the name of the game.
An underlying assumption (on the part of both the customer and the provider) is that by consolidating the physical infrastructure at the software provider, rather than distributed across each customer, is that the provider can gain some economies of scale and then amortize those economies back to the client.
Application architecture
Gaining the economy of scale will require a different approach to the application architecture than one would apply toward a stand alone product.
Configurable. Many software product companies gain considerable additional income by selling professional services along with product licenses. In the SaaS model, the idea is to draw in as many new customers as possible, and as quickly as possible. Customization of the product slows down implementation and raises both the cost and the unit price, therefore limiting the potential number of new customers. A solution that enables quick and easy discovery, purchase and use also enables the desired explosive growth of the new customers. However, a one-size-fits-all approach rarely works beyond the first successful product in the market – “They can have any color they want, as long as it is black…” The more sophisticated the buyer, the more likely they will want a solution that is configurable to their needs. A configurable product in a SaaS model means that the customer does all or most of the manual work to make the product look, feel or do what they want. This meta-data is maintained for each customer and applied to the common product code base each time the customer launches a new session. This way, the common code base remains under the (cost) control of the provider. Most software companies understand that having many customers with different (custom) versions of their application typically causes very difficult technical support problems. Since the ideal in a SaaS model is to have many customers, sharing a common code base (rather than many custom code bases) becomes a critical concept for long-term success.
Multi-tenant. Multi-tenant refers to the handling of multiple customers within a single code base, both the UI/business rules, as well as the data. How the UI/business rules and customer data is viewed, stored and manipulated becomes a critical success factor for SaaS.
A. Meta services. Each customer is allowed to establish a set of its own metadata, which describes or sets the parameters for the customer’s desired look and feel (brand), business rules and workflow, security (access controls) and any allowed extensions to the data model. This metadata governs the application each time an end user from the customer account opens a session of the application. When an end user logs onto the application, a session is spawned using that end-user’s customer/account metadata. Each session is a separate instance of the application.
B. Database services: In a similar fashion, each customer’s data is separated from other customer data by a separate database instance. Each customer’s use of the application (configured UI/business rules and data) fluctuates independently in CPU usage, memory size and configuration.
A good architect or a good database developer will say that there are many well-understood ways to provide the type of separation identified above, without having to create a separate instance of either the application code or the database; that physical separation is an expensive way to ensure separation. However, consider what needs to happen in the event of a failure. If all customers are using the same database, then if there is a problem that requires restoring the database from backup versions, all customers must go through the backup. The result could cost customers money or it may cost the provider money (downtime). If, on the other hand, each customer has a separate database instance, then the problem can be localized to only those database instances affected by the problem; both isolating the problem, and simplifying the fix.
Remember, the goal is to ramp up the number of customers as fast as possible. To do so, the architecture and infrastructure both need to be ready ahead of the ramping curve. A separate-instance architecture should mean that the number of instances (number of customers or end users) are only limited by the number of servers in the data center. Of course, there is a lot more to this topic, but, at least theoretically, infinite scalability is the application architecture goal.
C. Security. Unlike an application that physically sits in a customer’s data center, the SaaS model forces severe security requirements upon the application architecture. Customers will want considerable assurances that no other SaaS customer will be able to access their data, accidentally or otherwise. Database level security routines have been able to keep data from different users separate for many years now. However, let’s think about what it means to be responsible for the security of your customer’s data. Like most product developers, I used to take data security in stride as just a part of any good application; that was before I became an executive at Egghead.com, where one of my responsibilities included system security. Egghead.com was a prominent online retailer, and therefore a big target. On any day of the week, we averaged over 10,000 attempts by hackers trying to penetrate our applications, systems or databases. On bad days, the number would jump to figures like 30,000, 50,000 or even 100,000 attempts in a single day. On one day in 2000, we went dark for a couple of hours after receiving over 300,000 attempts. Fighting off would-be data thieves was a constant effort. At stake was our database with financial information of over four million customers. With widely spreading news about cyber break-ins and lost client data, plus the heightened visibility and importance of data due to governance regulations, CIOs are rightly much more concerned about this issue than at any time in the past.
D. Scalability. Remember that the goal is to ramp up the number of clients/users as quickly as possible; therefore scalability is an essential architecture consideration. There are essentially two considerations regarding scalability. The first is to design the application to handle multi-tenants efficiently – as described above. If that has occurred, then further efficient scalability can be realized through the design of the hardware configuration; much like the design of a web server farm.
Each instance of the front end is spawned into one to many inexpensive web servers, and each instance of the database is spawned into one to many database servers, with a load balancer in between. Some key concepts include:
-
Design the application to run stateless, and design the I/O for asynchronous connections (aka, a web app) so that any available server can pick up the next transaction, optimizing the use of servers.
- Design resources for pooled operations (threads, network connections, database connections, etc.) to optimize CPU utilization.
- Design for maximum concurrency and minimum exclusive record field locking to optimize database processing.
E. Operations. Many software providers run into trouble because they have little or no experience running a data center – particularly one for customers. This traditional IT-centric stuff can determine success or failure, because software developers usually do not consider things such as performance metrics, counting transactions, and back-up routines as part of the application. Some functions to have worked through include:
Conclusion
The SaaS business model is becoming more popular with corporate IT, but it is not necessarily the right model for every software product. The inherent infrastructure cost and the up-front and elongated investment requirements must be balanced against a valid projection of the type and number of new sales. The product architecture needs to be fairly robust in terms of how it will handle multi-tenants, scalability and security of the customer’s data. SaaS brings together software product development and IT infrastructure management into a tight-as-equals partnership. Successful products and efficient infrastructure are both critical components of a successful SaaS business model.
About the author
Ed Carroll has been building software products for more than 20 years, with particular expertise in automating economic analyses, decision support and supply-chain management processes. He has provided strategic technology leadership in roles such as the vice president of engineering for Egghead.com, director of technology at Nike and director of software engineering at Boeing. He can be reached at EdCarroll@AgilisSolutions.com.
|
