Why and How to Transition to SaaS Cloud Enterprise Applications
Maximize efficiency and minimize costs while unlocking the full potential of cloud-based solutions for sustainable growth and competitive advantage.
Join the DZone community and get the full member experience.
Join For FreeMany CEOs and CIOs have grappled with whether to migrate their applications from on-premise (the traditional route) to public cloud-based infrastructure. With an increasing array of cloud services available today, organizations can subscribe to a combination of different cloud services with their portfolio, including a mix of public, private, or hybrid cloud services.
Public cloud services can be grouped into three broad categories:
1. IaaS – Infrastructure as a service
2. PaaS – Platform as a service
3. SaaS – Software as a service
Shifting responsibilities between customers and different types of cloud services.
This article focuses on the strategies and steps to evaluate and transition SaaS cloud enterprise application services, which are often available as subscription services.
As companies transition to SaaS applications, they should focus on delivering core and differentiating business capabilities at the right costs and in a timely fashion while leveraging a combination of SaaS, on-premise packaged applications, and custom applications. They also need executive support to drive workforce behavior and strategies so they can use the right vendor solutions for the appropriate business capabilities and transform application footprints.
Steps for Planning Transition to SaaS
1. Evaluate On-Premise application support: Assess the support timeline for on-premise packaged applications and align the transition with the end of on-premise support.
2. Check existing Enterprise Licensing Agreements (ELAs): Review existing ELAs for on-premise packaged applications to consider utilization of unused licenses to trade-off for part or all of ongoing cloud SaaS application subscriptions.
3. Compare overall costs: Evaluate the overall costs, including the transition to the cloud including, re-implementation costs, and ongoing subscription costs for SaaS cloud applications.
4. Review vendor viability: Assess the financial viability, customer base, and footprint size of potential vendors.
5. Analyze impact: Evaluate the impact of shifting to SaaS applications on the organization's trade balance concerning SaaS cloud vendors.
6. Consider constraints: Analyze constraints, if any, of moving to SaaS applications hosted by vendors on competitor’s hardware.
7. Review Functional and Technical Capabilities: Assess the functional and technical capabilities offered for SaaS cloud versions of enterprise applications to ensure the cloud versions meet similar or greater organizational requirements.
8. Assess Scalability, Security, configurability, and overall ease of integration.
9. Evaluate the overall Enterprise Application landscape: Complete an analysis of public cloud SaaS applications in enterprise infrastructure and architecture.
Guiding Principles for Evaluating SaaS Solutions
1. Fit: Ensure that solution capabilities are a ‘good’ fit to meet the required business requirements/capabilities.
- Balance of trade: Avoid shelfware; do not use software because “it is there” (in spite of poor fit).
- Limit the overlap of capabilities across SaaS platforms.
2. Integration: Ensure that interfaces from/to other systems are well-defined and loosely coupled.
- Common APIs and microservices-based architectureto abstract SaaS capabilities.
- iPaaS (e.g., Boomi) to enable dynamic integration and decoupling from vendors.
- Ensure any workflow-level integration is easily replaceable.
3. Customization: Enforce discipline to minimize customizations on vendor platforms.
- Enable ‘approved’ extensions (compatible with upgrades) or configurations.
- Do not use the SaaS platform as a PaaS platform if a new capability needed is not available from your SaaS vendor.
- Where possible, use customer cloud-native application development standards to deliver customizations outside of the vendor applications.
4. User Interface (UI): Where applicable, abstract capabilities into a customer IP-based UI that you own and control.
- Enable better holistic information integration across multiple platforms (SaaS or other) and supports mobile-first.
- Apply to niche usage situations (not applicable for power / active users)
5. Data: Make sure that all relevant data within the SaaS solution is ‘replicated.’
- Leverage Data Lake to make data available in canonical form and ensure transition if needed.
- Consider localized / country-specific compliance requirements in premise-specific deployment analysis.
- Avoid replication of Customer enterprise data out to SaaS solutions to support SaaS capabilities/analytics.
6. Team: Establish a SaaS Management COE Team to consult and govern SaaS engagements throughout the lifecycle.
- Will require business acknowledgement and support.
7. Minimize Cost prohibitive vendor lock-in situations while maintaining partner and SaaS vendor relationship by following these strategies:
- Minimize customizations within vendor applications, starting with SaaS solutions.
- Encapsulate and decouple vendor solution through an internal customer owned API layer, with dynamic application/data integration to present SaaS capabilities as enterprise IT services.
- Leverage cloud-native architecture approaches and microservices to implement scalable and reusable integrations.
Evaluation Score Card For Comparing SaaS Solutions
Tenet |
Evaluation Criteria |
Score Range (1-10) -- (1 lowest, ten highest) |
Fit |
Do the solution capabilities being evaluated fulfill current user requirements? |
|
Are the licenses purchased fully utilized? Is the solution in the right tier? |
|
|
Integration |
Are we using API gateways and Service based integration? |
|
How easy is it to implement new integration requirements? |
|
|
Customization |
What is the level of customization is done to the solution? What is the spend after the initial solution implementation? |
|
Do the customizations follow Industry architecture standards? |
|
|
User Interface (UI) |
Does it have an Customer IP-based UI abstraction layer? |
|
Does it provide mobile first UI? Mobile native or modified to fit? |
|
|
What is the level of customization on UI? |
|
|
Data: |
Are the data available in canonical form to ensure transition? |
|
Are the localized /country-specific compliance requirements being met? |
|
|
Are customer enterprise data replicated out to SaaS solutions? |
|
|
How flexible is the data migration post decommissioning? |
|
|
Team: |
Level of SLA based support for Customer issues is available from Vendor team. |
|
Cost |
Cost of transition to SaaS cloud |
|
Ongoing annual subscription costs for support and maintenance of Customer’s SaaS cloud instance |
|
|
Any internal Customer IT costs for ongoing support |
|
Ideally SaaS applications being evaluated should score above eight on each individual question and should have an overall score of 150 or above.
After the evaluation is completed, below are recommendations for next steps.
- Executive and internal key business stakeholders’ alignment.
- For the shortlisted SaaS solution and vendor, ensure executive buy-in from the roadmap, cost, the balance of trade, and ROI perspectives.
- Obtain key stakeholder alignment from the organization, which will be the primary users of the SaaS solution on the solution capabilities and support model perspectives.
- Interlock with Digital Transformation program for cloud native architectures and APIs – Application portability.
- Acknowledge opportunities for customizations to support differentiation and leverage cloud-ready development to support application portability.
- Establish a SaaS Management team to manage and govern the engagement lifecycle Market recognition and competition across SaaS solution offerings.
- Enterprise architects must always keep current with alternative options for SaaS solutions, with a concerted focus within the last two years of the contract.
- Finalize go-forward strategy and plans for major SaaS apps.
- For existing SaaS major-spend footprint, identify lock-in areas.
- Create/implement plans to reduce or remove the lock-in (e.g., implement abstractions through APIs, services, and/or UIs, move capabilities, etc.)
- Implement guiding principles with any new SaaS applications.
The decision to migrate enterprise applications to the public cloud on a SaaS platform is a major crossroad in an enterprise IT roadmap. CIOs and their teams will be better prepared to make the transition by following the steps outlined in this article. Utilizing a score card to measure and evaluate different SaaS solutions and vendors will make the process transparent, objective and evidence-based, thereby helping in achieving stakeholder alignment for this key decision.
Opinions expressed by DZone contributors are their own.
Comments