Picking the right SaaS provider has become critical as an increasing number of businesses seek to externalize their IT systems. Due to a few barriers to entry and nature of the cloud industry, it’s not surprising to see a myriad of SaaS providers that offer a large number of services. This makes selecting the right provider difficult, especially when everyone is claiming to be the best. This post discusses some key factors to consider when selecting a SaaS provider, which helps businesses and individuals evaluate them and make a better decision.
Understanding Business Needs
Moving onto the cloud just for the sake of it isn’t the optimal strategy and businesses need to evaluate if they should really make the move. A proper understanding of specific business needs is critical before selecting any SaaS provider, including technical and service requirements, data governance, data security and service management. This includes clarifying minimum and specific business requirements so you can compare them with what the provider is offering.
Selecting or benchmarking a service provider becomes easier once you have clearly identified the minimum and specific business requirements. Although requirements and specifications can differ from one business to another, there are certain important areas that are relevant for evaluating any SaaS provider. These areas have been divided into different sections to make it easier to compare different providers and pick the one that delivers the best value.
Certification, Compliance and Standardization
While certification and compliance might not be so important for small projects and businesses, they can be the deciding factor for enterprises that have to comply with industry standards. Standards and frameworks help short list providers, but they should not be the only deciding factor. Here are some of the main certification bodies and frameworks you should consider when selecting a SaaS provider:
- CSA (Cyber Security Alliance)
- PCI DSS
- Cyber Essentials
- Open Cloud Consortium
- Cloud Standards Customer Council
- TOGAF 9
Technology and Platform
Provider’s technologies and platform should align with enterprise cloud objectives and its current IT environment. Too much re-coding and customization just to align to provider’s standards, cloud architectures and services would mean investing a lot of time and effort to manage your workload.
Providers that offer migration services are easier to work with, but it’s important to understand the kind of services a provider offers such as assistance assessment, planning and technical assistance during migration.
Many top-tier providers offer limited technology and migration support so you might have to consider a third-party support for filling in the gaps. Some providers also recommend support/technology partners, which makes things a bit easier as they should theoretically have a better understanding of how the systems work.
In both scenarios, a business needs to clearly understand the scope of work for each stage and what to expect from the provider. This includes:
- Workload assessment
- Proof of concept
- Application re-factoring
- Workload migration
- Network architecture and connectivity
Service Deployment Roadmap
Understanding how a provider plans to innovate and grow helps determine if it would fit to your long-term goals. This includes provider’s commitment to specific vendors, technologies, features, integration roadmap and interoperability. It’s best to ask a provider to demonstrate deployments similar to what you are planning for to get a better idea of how thing should work out in the future.
Data Governance and Management
The location where your data resides and applicable local laws play a key role in drafting a data classification plan. SaaS providers that offer choice and control over jurisdiction, processing and management of your data are simply better than providers that don’t. Not all providers are transparent about locations of their data centers so you might have to take responsibility of finding that out yourself.
The ability to protect in-transit data through encryption or encrypting only sensitive data minimizes chances of unauthorized access. SLA (Service Level Agreement) should be clear about data breach and loss processes and should be aligned with business’s regulatory, compliance and risk management obligations. CIF Code of Practice for Cloud Service Providers is a great starting point for identifying data and security governance processes and policies.
The security processes, policies and controls of an enterprise should be aligned with those of a provider and be risk-based. If a provider is compliant with standards such as ISO-27000 or has other certifications, it’s worth double-checking if those certifications are still valid and the provider is committed to allocating resources to them in the long-run. User activity and access should be auditable via all possible routes and security roles should be clear in the SLA.
Vendor Relationships and Partnerships
It’s important to understand provider’s relationships and partnerships with vendors, especially if an enterprise is working in multi-vendor environments. In such cases the services should be compatible and integrate with a larger ecosystem of services you need support for. For example, CRMs provide more value if they can be integrated with other systems such as marketing and finance.
Service dependencies and subcontractors should be clear before signing up for any cloud-based service. Most SaaS providers built services on existing platforms (IaaS), so it must be clear how the provider is delivering its services.
In some cases a cloud service might be delivered by a sophisticated network of subcontractors/connected services, which makes it important to ensure that the primary provider discloses about them and guarantees service across the board. As a general rule, it’s better to avoid providers that have a long chain of sub-contractors, especially when you are dealing with mission-critical data.
Service Level Agreement (SLA) and Contracts
SLAs can be difficult to understand and can get quite complex, which is partly due to the lack of industry standards. The Service Level Agreement should be clear about:
- Service delivery: definition of the service, roles and responsibilities of each party, service availability and management and service continuity
- Business terms: fees, operational reviews, insurance, commercial terms, policies, publicity
- Data assurance: data security, data management, data conversion and ownership and usage rights
- Legal protection: warranties, limitation of liability, indemnification, intellectual property
Although the SLA can get very complex, it should clearly define service level objectives, exclusions and remediation policies, incentives and penalties.
Performance and Service Reliability
One of the most obvious parameters for checking performance is to compare the performance delivered (preferably last 6–12 months) with what was promised in the SLA. It’s not practical to expect no down time at all, but what really matters is how the provider deals with downtimes. Provider’s monitoring/reporting tools should work with your own reporting and management systems and should be adequate enough for drawing evidence-based conclusions.
SaaS providers that rely heavily on proprietary components can lock you in and make data portability very difficult, if not impossible. The lesser a provider uses proprietary technologies, the easier it would be for you to migrate. However, you also have to balance the benefits of working with a few providers/subcontractors with becoming locked-in with only one provider. The exit strategy should be clear in the SLA, including data transition, storage and access.
Financial stability and business health are important indicators when choosing a service provider, but there is a lot more to the equation. Previous track record and legal issues help shortlist potential vendors, while commitment to specific technologies/vendors ensure that your business IT goals are aligned and compatible. Case studies and testimonials from existing customers can help in this regard, but you’d still have to dig deeper to validate certifications, service dependencies, performance and reliability.