By Takeshi Takeuchi, IAITAM Japan, Inc.
ITAK Volume 6 Issue 6
Editor’s Note: A 20 year IT veteran and published author on LAN, ITSM and ITAM, Takeshi Takeuchi joined IAITAM earlier this year to head the Japanese office of IAITAM, offering ITAM certification courses as well as other IAITAM resources to Japanese professionals.
Compared to on-premise enterprise IT, Software as a Service (SaaS) represents a value proposition of speed and agility for implementation and use. However, these benefits may inflate actual benefits unless the complications are understood. For example, the media in the U.S. has referred to SaaS as being “a compliance minefield.” SaaS changes the relationship of the consumer organization from “owned” to “used,” but does not remove the legal obligation to maintain compliance.
Organizations may misunderstand the risks and think that the SaaS model can be adopted without involving the organization’s IT services, including those experienced with the legal aspects of using software and complying with those legal aspects. Compliance risks and cost challenges quickly arise when IT services such as Software Asset Management, Operations Management and Service Management are not part of the transition. Significant concerns include:
- Aligning software usage to the requirements from the end users, management and other internal users of the data
- Developing and overseeing controls for compliance and reporting, including negotiating these elements into the contract
- Determining a true cost of usage so that administrative costs and other costs are included in the evaluation of the SaaS model
Although service models have been around for some time, many provider organizations are new to the SaaS model and to the cloud services market. With rapid growth and seizing on opportunity, provider processes may be ad hoc or missing proper handling in some scenarios. Access to organizational data is the most significant concern and includes issues regarding legal obligations and the risks of poor financial return, security breaches and injury to the organization’s reputation.
Adding to the provider’s lack of experience with cloud offerings (as with any new technology), is the end user’s willingness to act without the internal resources experienced in delivering services. Lacking a full understanding of what services surround fulfilling the end user’s needs leads to unrealistic expectations and increases the risks described above.
Lack of Software Asset Management Planning
Moving to a SaaS provider without the policies and controls can lead to change without a strategic plan. The number of providers may escalate dramatically as individual departments make their own decisions about moving to SaaS, underestimating the cost of this diversity.
The costs to the systems that remain may also be significant. If there is no strategic plan, Software Asset Managers have to consider if there are orphaned applications that will now be missing important data elements and potentially out of synch with the data that is on the provider’s site. Systems that become silo applications lead to rising costs from duplication of effort, as well as costs from attempts to fix these problems with the provider. Rising overall system costs occur rather than the expected savings.
It is clear that Software Asset Management and Service Management are just as important to the SaaS model for software usage as any other licensing methodology.
The Value of Structure
One of the important contributions of internal resources is in the structure that each of areas provides. Just like any other software license type, The Software Asset Manager offers the services of educating and developing policies, processes and procedures. These deliverables will most likely need to be updated to include new requirements inherent to the SaaS license type. The services sector is in general well-prepared to handle change, with Service Level Agreements (SLAs) and Service Level Management (SLM). By not using these services, the end user department is at risk for errors that damage the cost effectiveness and overall success of the move to SaaS.
If coordinated with the internal IT services, the experience professionals will help assess the move to these off-site products, balancing criteria such as cost, convenience and speed that are required by the end user department. SLAs can be updated and SLM continue to coordinate a common understanding between departments.
Securing the transfer of data between the provider and the organization is another concern that will be addressed according to the policies and practices within the organization.
SaaS Contractual Concerns
The language in the SaaS vendor’s service contract and SLA is typically insufficient to cover the interests of the users and the legal responsibility of the organization using the software. Switching to this model may require an end user license agreement for every software component critical to the system. Software Asset Managers and services negotiators need to be involved in the acquisition process when considering any cloud license models.
If the SaaS provider is responsible for security and continuity, the end user department is entrusting the availability and security of the data to the provider. The external company must be chosen very carefully and the SLA needs to include additional information such as the provider’s:
- Financial statements
- Security policies
- Infrastructure, including data center, internet, hardware, software, applications and web system
- Vulnerability studies and diagnostic reports
- Special provisions for sensitive data
- Power supplies and emergency procedures
- Data migration for implementation and over time
- Additional providers involved (such as internet provider) and their contractual obligations to the SaaS provider
- Maintenance procedures and service disruption notifications
- Termination services
When choosing SaaS, customization is a major cost. There are customizations required for moving data into the provider’s environment such as development of code to the provider’s Application Programming Interface (API). Often, the code necessary is specific to this provider and cannot be used with another provider.
In addition to populating an application, most applications are integrated with other internal systems, either receiving data from that system or providing data to another system. In either case, customization for integration is a significant concern when systems are on different sides of a firewall, introducing the need for updated policies and new secure processes at the least. This type of integration may not be possible at all or if it is, the integration may be very expensive.
End users may be used to a custom look to the product, with a specific interface previously provided on the on-premise version of the product. The SaaS version may provide a similar look and feel with a potential increase in cost. Another source of confusion for the end user is changing the release or version when moving to the provider’s SaaS product. End user confidence and comfort may be undermined by this move, requiring unbudgeted training and mentoring.
When choosing a provider, the end user department has to be particularly vigilant to ensure that the provider’s version of the product has all of the components that are installed and used in the on-premise version. The provider’s version may be basic while the end user may no longer be aware of the separate components that gave them the functionality that they needed. If a component is missing, negotiations must take place to consider options and the cost of those options.
When reviewing the differences in the product and deciding on what customizations are necessary and what the provider is willing to do, the end user department must also think about future business needs and include business expansion and change in the negotiations with the provider. Costs that escalate with customization include:
- Transitional services
- Customization fees
- Consulting fees
A final concern for customization is the loss of advantage over competition as customizations may become part of the provider’s offerings and be available to all of their customers.
SaaS Compliance Audits and Reviews
What happens during compliance events? The end user department may presume a higher level of commitment to provide compliance information or to participate in the compliance event than what the provider is actually prepared to offer. Software compliance is a concern for any application moved to the SaaS model. Contractual language that protects the end user organization is important and is not reduced by the move to this licensing model.
Specific systems may have additional issues. Consider the use of a SaaS license model for financial information, with the long list of requirements from commercial laws, tax laws and labor laws as well as the charter of accounts in the specific countries. Compliance events of every type should be considered and discussed during negotiations to protect the organization.
Use Resources Wisely
SaaS is one of many cloud computing models that organizations are beginning to use with expectations of savings, flexibility and speed. At this point in time, transitioning to this model of software application access is risky if the internal IT services are excluded from selection and implementation process. These risks include security issues and the danger of costly mistakes. Without these experienced resources, the end user department is likely to presume that policies, optimizations, security and compliance are still in place and adequate for the application, which may not be the case.
In addition to daily execution, planning for the future is also unlikely to be robust. The end user department’s expectations for business impact analysis (BIA) with ongoing modification of SLAs for future needs and service lifecycle management are unlikely to be available or as complete, leading to increased future costs.