Page 1
ITSM Software: Is SaaS the Model for You?
By Kai Holthaus, ITIL v3 Expert and Director for Third Sky, Inc.
Software as a Service (SaaS) has gotten a lot of attention recently. Many
companies and IT organizations are embracing SaaS as a new model to provide
software-based services to their customers. The field of IT Service Management
(ITSM) software is no exception. But is SaaS always the right model for ITSM
tools?
This white paper provides a closer look at the pros and cons of SaaS for ITSM software. I’ll discuss the benefits of SaaS and on-premise software installations, and will provide a simple checklist you can use to make the right decision for your organization.
SaaS Market Trends
The analyst firm IDC estimates that by 2012, about 85% of new software to the market will be delivered as a service. At the same time, some two-thirds of new offerings from established vendors will be sold as SaaS. SaaS revenue numbers will jump up from US$13.1 billion in 2009 to $40.5 billion by 2014. Figure 1 below shows the number of Gartner clients choosing the SaaS model when purchasing an IT service desk software solution. It can also be expected that license revenues for traditional on-premise applications will decline as the revenue numbers for SaaS will go up.
Page 2 Clearly, SaaS seems to hold a lot of benefits in the eyes of customers.
What is Software as a Service?
Software as a Service (SaaS) is a software delivery model, in which the application and the data it operates on is centrally hosted. Typically, the application is accessed by users using a thin client, such as a web browser.
Unlike the traditional application sales model, which typically involves a one-time fee for a license, SaaS is usually sold in a subscription model, such as a monthly or annual fee. This subscription fee is
competitive with the prices for traditional application delivery not only because it is usually lower or equal to the amount of money paid for licenses and support over a period of time, but also because it might allow a customer to use expenses instead of capital expenditures to pay for the software, resulting in tax benefits.
The ITSM software vendors have embraced SaaS to various degrees. Some vendors offer SaaS as the only delivery method, while others can provide both SaaS and on-premise offerings.
Types of Software as a Service Offerings
Essentially, we can find four different types of SaaS offerings in the marketplace. Type 1: Customized Instances
The first type of SaaS offering is running a single, customized instance of an application for each
customer. The main change between this type of SaaS offering and an on-premise installation is the site of the servers on which the application runs: instead of running on customer-owned and operated hardware, this SaaS offering runs on servers provisioned and maintained by the SaaS provider. This means that there is little difference in the code base for such a SaaS offering and an on-premise installation of the software. The same can be said for the data managed by the application. Each
customer has their own, potentially customized, code base, and their own database instance storing the data.
Upgrading this type of SaaS offering is similar to upgrading an on-premise installation as well. If major customizations were done to the code base, upgrading can become difficult.
Type 2: Configured Instances
Page 3 separate, and potentially customized, code bases. On the hardware side, the same amount of resources is needed as in a Type 1 setting. Data is also stored in separate database instances.
Upgrading this type of SaaS offering is potentially cheaper, since the same code base is used across all customers, and therefore upgrades can be designed and implemented for all customers at the same time. This can lead to issues for customers, however, since upgrading the software may happen at a business-critical time. When negotiating contracts for a Type 2 SaaS offering, this needs to be considered.
Type 3: Multi-Tenant Installations
In the Multi-Tenant SaaS offering, all customers access the same, single instance of the application. All configuration of the application occurs through metadata stored in the database. This reduces resource requirements for the SaaS provider, as there is only one instance of the software running, and not as much storage space is required as compared to Type 1 or Type 2 offerings. Scalability may become an issue, as all resources are shared between all tenants of the multi-tenant application. When evaluating Multi-Tenant Installations, customers should ensure that additional resources can be made available by the SaaS provider in a time-efficient manner, when the need arises.
Customers have no control over the isolation of their data from other customers’ data, since a multi-tenant installation uses a single database instance as well. Security measures have to be put in place to ensure that the data remains isolated.
Since the SaaS provider only has to manage a single code base and a single database instance, upgrade cycles are typically faster than in Type 1 or Type 2 offerings. The same concern about the timing of upgrades mentioned in the section about Type 2 offerings also applies here.
Type 4: Identical Instances
The final type of SaaS offerings is the most demanding, architecturally speaking. It consists of customers accessing identical instances of the software, with all configuration occurring via metadata stored in separate databases, so that each customer receives a unique user experience, such as a different look and feel. This type is to be desired, as it can provide almost unlimited scalability, because new instances of the software can easily be provisioned as demand increases.
A quick test for a customer of SaaS to distinguish between Type 3 and Type 4 offerings is to ask the vendor to provision a new instance of the software. Type 4 offerings can provision instances almost immediately, while Type 3 offerings will have some lead time.
Evaluating ITSM Software
Page 4 How easily can the software be interfaced with already existing data sources, such as general
ledgers or asset management systems?
Does the software include process automation? How easily can processes be modeled and executed in the software?
Which ITSM processes can be enabled or supported by the software? Is the software modular per process? For instance, can you start by only implementing (and paying) for the Incident Management module, while not using (and not paying for) the Problem Management module? How scalable is the software? Does the scalability of the software match the company’s growth
targets?
Is the user interface role-based? How easily can different views into the same data set be provided based on a user’s role?
Are all your needs covered by the configuration options provided by the software? If
customization is needed (and a business case exists to support the customization), how easily can the software be customized? How much customization is needed?
Most ITSM software offerings include modules for the following processes. Keep in mind that a specific software may have additional modules, or may be missing modules that are listed below.
Incident Management: The software records incidents, and manages the process of incident resolution.
Problem Management: Manages process and data collection for root cause analysis. Typically includes functionality to manage a Known Error Database (KEDB).
Change Management: Track, authorize and manage change coordination processes. Should be linked or integrated with Configuration Management for best value.
Release and Deployment Management: Manages the implementation of one or more authorized changes.
Service Asset and Configuration Management (SACM): Keeps track of Configuration Models and asset information. Should be tightly linked to Change Management for best value. Can include discovery functionality to enable configuration identification and verification and audit activities.
Service Catalog Management / Service Level Management: Publishes a service catalog and keeps track of Service Level Agreements and Service Level Achievements. Enables reporting and review.
Request Fulfillment: Tracks Service Requests (similar to the handling of Incidents) and manages fulfillment process, including approvals. Often can enable self-help functionality.
Page 5
SaaS versus On-Premise: A Comparison
Table 1 below highlights the pros and cons of SaaS versus On-Premise installations:
Pros Cons
SaaS Can be deployed with limited IT resources
Can be deployed with limited operating capital
Flexible deployment and scalability Usually relies on open data interface
protocols
Typically faster enhancement cycle Inherent collaborative functionality Uses expenses instead of capital
expenditures
No control over data stored in application – need to trust vendor security provisions
Offers limited configuration and customization options
Might be more expensive with high number of users, depending on licensing model
Requires higher network bandwidth, potential latency issues
Integration with applications holding sensitive customer data
Might be locked into vendor upgrade schedule
On-Premise Data is under customer control
Software can be more easily customized Lower network bandwidth
requirements
Might be more easily integrated with other custom applications
May be cheaper over long-term usage Can determine own upgrade schedule
Uses capital expenditures instead of expenses
Needs company resources to manage and maintain implementation
May be harder to deploy in distributed environment
Usually slower to deploy
Table 1: Pros and Cons of SaaS versus On-Premise Installations Financial Implications:
SaaS offerings can usually be paid for with expenses instead of capital expenditures, which may be beneficial from a tax stand point, depending on how many years of depreciation are being used. Additionally, the subscription-based licensing model of SaaS offerings can be
Page 6 Finally, SaaS may provide a better TCO, depending on the exact needs of the customer. A TCO analysis should be performed to compare SaaS versus on-premise installations. The exact details may differ from software to software and customer to customer.
Data Security Concerns:
Since SaaS offerings typically store the data the application operates on “in the cloud”, i.e. away from a customer’s own data center, data security concerns may arise. This includes both data that “belongs” to the application as well as potentially sensitive data that the SaaS offering may need to pull from or push to other applications which may be housed in the customer’s data center. Data security issues need to be considered when making a decision on whether SaaS is the right way to go.
In the ITSM space, these concerns may be substantial, because the customer’s business may fully depend on highly available IT services, and any disruptions to those services could have a significant impact beyond the unavailability of IT services. SaaS vendor security provisions should carefully be evaluated to address data security-related concerns, both within IT and IT’s customers.
Features versus Customization Ability:
Most SaaS offerings usually have the advantage over on-premise applications with regards to the cycle time necessary to implement new features, because customers typically share a non-customized code base (unless a Type 1 SaaS offering is used). The SaaS provider will take care of enhancing the features of the SaaS offering, and will update the software accordingly. In on-premise installations, enhancement projects are usually initiated to install a new version of a particular software. Depending on the exact circumstances of the software installation, upgrading can turn into a costly and lengthy project. However, the ability to customize certain aspects of an application may outweigh these concerns.
SaaS providers who also offer on-premise installations may have a different approach to upgrading their offerings than pure-SaaS providers. As you evaluate the correct approach for your ITSM solution, you should prioritize your requirements for quicker upgrades versus the ability to configure and customize.
Upgrade Process:
The quicker cycle time of making new features available to customers is typically seen as one of the selling points for SaaS offerings. However, situations may arise that would make a customer wish that they not take part in an upgrade of the software at the base of an SaaS offering. When selecting SaaS over on-premise installations, the requirements with regards to upgrades should be carefully evaluated. Additionally, SaaS offerings sometimes force customers into upgrading within a given time frame, while customers of on-premise installations are completely in control of their own upgrade.
Page 7 you evaluate your options, make sure that you evaluate a vendor’s approach to these two different types of upgrades. Some of the pure-SaaS providers have not yet done any upgrades that change the core data model.
Network Bandwidth Requirements:
Since SaaS applications are typically housed in the cloud, Internet connectivity is a must for every user of such an offering. This may present certain issues if Internet connectivity cannot always be guaranteed, but application availability is still required. Also, the Internet-based nature of SaaS offerings may introduce latency issues, which may make an on-premise installation necessary.
In the ITSM world, latency is usually not important. However, network connectivity may be. If an incident on the Wide Area Network (WAN) needs to be managed, connectivity to a SaaS offering may not be guaranteed for all employees who need access to the ITSM tool and its data.
Alternative ways of connecting to a SaaS-based ITSM solution need to be considered, designed and implemented to ensure access even in times of reduced network availability.
Suggested Approach for Evaluating and Selecting an ITSM SaaS Offering
If your initial evaluations have shown that SaaS might meet your ITSM software needs, Third Sky would recommend a “Fit-Try-Buy” approach, as illustrated in Figure 2 below:
Figure 2: Fit-Try-Buy Approach
During the “Fit” stage, the key is to figure out whether an offering is right for your circumstances, it is critical to define the right requirements. Try to avoid long lists of requirements, and instead focus on the
Fit
• Define
requirements
• Get vendor
demos
• Assess ease-of
use and
efficiency
Try
Page 8 most important ones, as indicated by a “MoSCoW” analysis (Must/Should/Could/Won’t). Provide the requirements and identified use cases to vendors of different SaaS and On-Premise options and ask them to demonstrate their offerings, on how they would address your requirements and use cases. Use a structured evaluation model (weighted requirements and a scoring system) to assess the ease of use of each offering and its efficiency.
Most, if not all of the ITSM tool offerings are based on best practices from the most current ITIL® guidance (ITIL® 2011 Edition, the most recent edition of what is known as ITIL® v3). When evaluating tools, ensure you have prioritized the processes which you would like to enable with the ITSM tool, and ensure that the offerings can actually enable these processes. Investigate how much configuration or customization can be done to the processes included in an ITSM tool. Also, investigate how far your organization is willing to adopt a best-practice process out-of-the-box versus the need to fit the tool to your processes.
Once your evaluation process has yielded a “winner”, you can ask the vendor of the selected offering for a demo instance. Invest the time to try and “kick the tires” of that instance, to see if it not only meets your “Must” requirements, but also any “Should” or “Could” requirements. Bring enough users and data into the try-out as feasible to collect enough feedback to make the try-out meaningful. Additionally, during the Try phase, check references for your selected solution, including any marketplace
recommendations or available reports.
If you have determined that one of the solutions you tried is indeed for you, you can move into negotiations with the selected vendor. If the vendor is offering different licensing models, ensure you select the one that is most beneficial to you. The same goes for the right duration of a contract.
Carefully document any commitments on both the vendor’s side and your own commitments, and agree to regular reviews of whether service levels were actually reached. Follow the guidance in ITIL’s Service Level Management and Supplier Management processes, as described in the Service Design core volume.
Summary
Software as a Service (SaaS) is a delivery framework for software that merits careful investigation for its potential advantages over traditional on-premise installations of applications. Customers should not, however, just blindly jump on the SaaS bandwagon, but instead invest the time to evaluate if SaaS is indeed the right model for a particular software application or solution. Each approach has its pros and cons, and not every solution fits the SaaS model.
Page 9
About Third Sky
Third Sky specializes in the assessment, planning, and adoption of ITIL / ITSM solutions that enable IT organizations to deliver higher levels of service while maintaining or reducing Total Cost of Operations (TCO). Third Sky provides a comprehensive set of IT Service Management solutions addressing people, process, and technology initiatives for medium to large enterprises.
Third Sky can assist you in evaluating different ITSM tool vendors, and their different offerings, by designing evaluation criteria and facilitating the evaluation process. Additionally, Third Sky has ITSM technology experts on staff who have experience in successfully implementing different ITSM tools for our customers.
