Building SaaS Programs Meeting the Enterprise’s Cloud Strategy
These SaaS requirements vary by industry, by application type, and by geography. The savvy SaaS vendor will proactively addresses the requirements that will remove many of the barriers that are hindering the adoption of SaaS in the Enterprise.
This article describes the components of SaaS standards for operational requirements. The area of SaaS standard requirements encompass those that are Enterprise specific requirements (such as system availability). Other requirements are from industry standards such as audit standards such as SSAE 16 (successor to SaaS 70). Governmental compliance requirements which are specific to a national or union of nations such as HIPPA or FINRA, or privacy addressed in the EU Data Protection Directive constitute the third major sphere of SaaS requirements.
These articles on each of the major area of SaaS requirements which are becoming standard in the Enterprise can be subscribed to at the Cloud Strategies blog here.
The State of SaaS in the Enterprise
A November 2012 Capgemini report surveyed enterprises with more than 10,000 employees on their current Cloud implementations and their future plans. North American Cloud adoption is further along, but the Worldwide Cloud adoption is accelerating:
The trend in the Enterprise is towards greater use of the Cloud, but primarily for new applications. Fortunately for SaaS providers, there are many new applications driven by initiatives such as mobile, social and regulatory compliance that result in the requirements for new applications likely to be implemented in the Cloud.
The top three barriers cited in the Capgemini report that are hindering the move to the Cloud by Enterprises are Security Concerns, Data Governance & Compliance, and Lack of Integration between applications.
The broader set of requirements for SaaS vendors to meet the enterprise’s SaaS strategy requirements are outlined here and are described in more detail in the this series of posts.
Why Enterprises have been slower to adopt the Cloud
SMBs have had less resistance in adopting Cloud technology than Enterprises since their businesses are less complex, their risk tolerance is greater, and they have fewer controls in introducing new technology. SaaS is enticing to SMBs since they are able to run complex programs without sophisticated IT staff. SMBs are also much more likely to implement SaaS offerings without the constraints of a formal Cloud strategy.
Enterprises are more demanding of their expectations of how SaaS products fit into their overall Cloud strategy. They seek to minimize “Shadow IT” projects where SaaS products are purchased by individuals or departments without adherence to the organization’s Cloud strategy. These Shadow IT projects can complicate the organization security or compliance requirements. When SaaS offerings were brought into the Enterprise without consideration of corporate governance and interoperability issues, it was difficult to make everything “play together”.
IT’s role is changing to allow other departments in the Enterprise to bring in new projects quickly while adhering to their Cloud strategy. SaaS vendors can facilitate their introduction into the organization by adopting Cloud requirements that meet the Enterprise’s standards.
SaaS providers can make their offerings more readily adopted by the Enterprise if they address the key areas of corporate concerns that should be specified in the enterprise’s Cloud strategy.
The developing standard requirements vary by industry and application – financial and medical applications will typically have more rigorous standards than productivity applications. Meeting these developing Cloud standards requires major efforts in the SaaS company’s software development, DevOps and services organizations. Operational transparency in areas such as performance, availability, and security breaches are required.
The specific standard requirements will depend on the 1) criticality of the application, 2) the security, privacy and compliance requirements, 3) the countries where the SaaS product be used, and 4) the unique requirements of the specific Enterprise. SaaS vendors that meet the requirements in these key areas well will have a much better chance of winning the Enterprise deals.
Essential Standard Requirements Areas for SaaS
SaaS Product Requirements
The seven key areas of SaaS standard requirements are:
- Security
- Privacy
- Data Governance
- Availability
- Performance
- Interoperability
- Compliance
These areas should be included in the Enterprise’s Cloud strategy. For example, Data Encryption standards are a factor in a number of the SaaS best practices categories: Security, Privacy, Data Governance, and Compliance.
These requirements will also be contained within the Enterprise RFP (Request for Proposal) for large projects and should also be addressed within the vendor’s Service Level Agreements (SLAs). Vendors may not contractually commit to every aspect of standard requirements, but will state their current practices within their terms and conditions with the right to make changes as conditions warrant.
These standard requirements will impact the SaaS vendor’s organization particularly in areas of software development and SaaS Operations (DevOps).
Each of these key SaaS requirements are summarized below and expanded in an individual blog for each area of SaaS standard requirements. Click here to subscribe to this series of blog posts.
SaaS Security
SaaS Security has been the number one concern of Enterprises adopting SaaS. SaaS companies must assume much of the responsibilities for their SaaS platform – which as traditionally lay with the Enterprise’s IT. The new SaaS vendor responsibilities include hardening the software against security threats, ensuring that the SaaS software works within the security infrastructure of the enterprise, and operationally defending against internal and external threats.
Major SaaS security areas encompass:
- User authentication and access control
- Protection against unauthorized access
- Code hardening and auditing
- Malware detection and remediation
- External threat such as Distributed Denial of Service (DDoS) defense and Remediation
- Rights to audit the SaaS vendor’s operations and access log information
- Physical and personal security
- Protection of access by other tenants collocated in the same system
SaaS Privacy
Privacy is rapidly becoming a key issue for SaaS driven by concerns of individuals and regulatory activity that dictates legal requirements for privacy. Security and Privacy considerations are closely related – while SaaS Privacy depends on SaaS Security, how the secured SaaS data is created, used, and destroyed is dictated by Privacy considerations. The implementation of these privacy policies is part of the SaaS providers Data Governance program.
While many privacy compliance regulations are directed towards social media, SaaS products sold to the Enterprise must ensure that the Enterprise’s customer privacy is protected in accordance with company policy and government regulations.
Privacy standards vary dramatically in different regions of the world, but the SaaS product must meet the privacy standards of every region in which it is deployed. The European Union is particularly taking an aggressive position on new, onerous (to the SaaS company) privacy regulations, while many U.S. companies are working to restrict the extent of these new privacy regulations. Additionally, it is important for SaaS companies to take full advantage of EU Safe Harbor provisions to minimize the company’s liability related to EU Privacy laws.
Data Governance
Data Governance issues are the second most cited concern of Enterprises moving to the Cloud. Data Governance was not a primary concern of on-premise software vendors. On-premise vendors needed to be sure that they had appropriate access control mechanisms to allow the customer to control access to their data, ensure their APIs had appropriate controls, and encrypted data where necessary, but the management of the data was the responsibility of the customer or their IT organization. Under the Cloud models, the SaaS vendor, often in partnership with their IaaS or PaaS suppliers have total responsibility for safeguarding the data.
Data Governance processes are the basis for ensuring that the security, privacy, and compliance requirements can be met. The quality of the data is of prime concern particularly as more data from social sources and big data repositories are incorporated into the SaaS solution. SaaS products need to be integrated with other tools or provide methods for improving data accuracy from the data sources used by the SaaS products. Often there are regulatory requirements for ensuring the accuracy of the data maintained on consumers together with prescribed processes for correcting errors in the data. Data governance requirements will vary greatly depending on the industry served and the country in which the product will be accessed.
A new area of Data Governance concern for SaaS is the ownership of the data including the intermediate data results. Many Enterprises insist not only that they have rights to all the data produced by the SaaS products they use, but also to the intermediate results which may have value for data mining and analytics.
Compliance
Compliance requirements have grown dramatically in all industries over the last decade. Compliance issues for the Internet/SaaS have grown even faster in the last five years as governments around the world have increased their desire to control activities on the internet, and protect the privacy and security of their citizens. Compliance, like security has a higher impact on the SaaS software (and internet) vendor than the on-premise software vendors since they have operational responsibility for the system and its data. On-premise software compliance was the primary responsibility of the Enterprise’s IT organization and secondarily the responsibility of software vendor. That situation is reversed for internet and SaaS vendors.
Compliance for SaaS vendors falls into three major dimensions:
1) Industry specific compliance requirements such as HIPPA, FINRA, SOX, and various DoD requirements (U.S.) – these industry standards are unique to each geopolitical area.
2) Geopolitical compliance requirements such as the EU Data Protection Directive (Directive 95/46/EC), Korea/Taiwan Personal Information Protection Act (PIPA), and India Information Technology Act (ITA) to name just a few.
3) Enterprise specific requirements to meet the corporation’s internal IT standards such as Single Sign-On (SSO) and Authentication standards.
Compliance issues are related to Security and Privacy requirements, but have very specific governmental requirements, a broader scope, and potentially higher damages.
Availability
SaaS system availability has been a prime barrier to the adoption of SaaS even though most enterprises have lower availability of their internal IT systems than of SaaS providers. Many large SaaS providers such as NetSuite have modest uptime guarantees. NetSuite guarantees only 99.5% uptime per quarter excluding scheduled maintenance – that allows 10.8 hours of unscheduled downtime per quarter. Actual uptime by major SaaS vendors is much greater, typically achieving 99.99% uptime. Salesforce has been a pioneer in having transparency of their uptime statistics which are published in real-time at https://trust.salesforce.com/.
SaaS vendors’ availability commitments can (generally) be no better than the platforms on which they are built. AWS availability commitment for EC2 is 99.95% http://aws.amazon.com/ec2-sla/ while Microsoft Azure is availability commitment is 99.9%. SaaS vendors have multiple components each with their own availability characteristics. Since the lack of availability of any one of these components may cause the SaaS application to fail, it is necessary for the SaaS vendor to design their system to use multiple redundant systems or availability zones to ensure a higher degree of availability.
Enterprise SaaS customers with critical requirements for availability will ensure they have access to their data in the event of a failure of the SaaS vendor. In particular, they will want to have the ability for the SaaS vendor or an independent third party such as Iron Mountain to have a disaster recovery (DR) plan in place to have access to their SaaS systems in the event of a catastrophic failure including the bankruptcy of the company.
Performance
Performance has been a concern of Enterprises in deploying SaaS or any web based application over the internet. Performance of web applications must be attacked on multiple fronts. The application themselves must be written to take advantage of HTML5 techniques such as data prefetch and other performance optimizations.
Content Delivery Networks (CDNs) can be used to cache content physically closer to the end user to speed up load times. Various network optimization techniques can be used to stream data much more efficiently which is particularly important for applications that stream large data sources such as medical imaging applications. SaaS applications need to be written to effectively scale to add (and reduce) virtual machines to add capacity to meet the variation of computing demands to deliver acceptable performance. Multi-tenant architectures need to be built to minimize the impacts of tenants on each other, particularly when there can be large variations in data access times when other tenants on the same physical machine place high demands on I/O resources which are shared between the Virtual Machines.
Interoperability
Lack of Integration is the third most cited barrier for Enterprises moving to the Cloud. Interoperability between SaaS systems, other Cloud applications, and legacy applications is a major concern of the Enterprise.
Interoperability between on-premise software systems has been an issue for decades. With all of the data on-premise, and with the ability of Enterprises to directly access the data through the database provides a useable if inelegant (and often risky) ability to link disparate systems together. On-premise applications have, in some cases, embraced Service Oriented Architectures (SOA) to provide well defined programmatic interfaces to the objects within legacy systems.
With SaaS, there is no ability to access the data directly – all access is controlled by the SaaS application. Access to the data may be provided through SOA, or a lighter weight and increasingly more common RESTful API. Still, even with published APIs, there is a great deal of complexity in integrating multiple SaaS and legacy on-premise systems.
A number of vendors such as Boomi and MuleSoft provide an Enterprise Service Bus (ESB) to facilitate the transform and transport the data between disparate systems.
Large SaaS vendors such as Salesforce provide an ecosystem of other SaaS vendors that pre-integrated with Salesforce and each other within their Salesforce AppExchange ecosystem.
There is still a great deal of room for improvement to provide broader interoperability between SaaS programs as well as the legacy systems.
Conclusion
Building World-Class SaaS products for the Enterprise is a complex endeavor. SaaS is just now penetrating the Enterprise, primarily for new applications. In time, more legacy applications will be replaced by SaaS, and this transition will be accelerated as Enterprise SaaS products mature and meet the fundamental requirements of the enterprise.
This series describes the key operational SaaS requirements, and how they are reflected in developing SaaS standards and SLAs.
To subscribe to the SaaS Standards series, please sign-up for the free subscription from Cloud Strategies here. For more insights from CloudStrategies.biz, follow us on Twitter. Follow @DaveKey0
