Today, software as a service (SaaS) is a mainstream model for application consumption, with industry-specific and business process-focused offerings increasingly available. Flexibility, reduced time to market and cost benefits are the top advantages and selling points of SaaS offerings.
SaaS-powered business processes allow businesses to provide feedback in real time, thus enabling a smooth change management process. The agility of such applications also generates higher user-community satisfaction and engagement. As a result, Gartner’s recent forecast predicts the SaaS market size will grow at a compound annual growth rate (CAGR) of 18 percent in the next four years, reaching $127.6 billion USD in 2021.
Despite the apparent benefits, SaaS models carry their own set of disadvantages, especially when the application impacts key underlying business processes. These processes are typically unique to an organization and are seldom available out-of-the-box (OOB). The specific changes an organization needs often proves a solution inadequate and in need of major customization and permissible extensions.
If the design of the solution is stretched too far from the originally intended logic of the software, it can cause major disruptions to future upgrades of the SaaS solution. An alternative to customization is simplifying business processes so they fit into OOB features. However, business users resist adopting a new simplified process, particularly when the process in question is a perceived differentiator. At the same time, it is not in the best interest of vendors to modify their design, catering to the requirements of just a few organizations.
The Crucial Role of Architecture
Business process architecture must be harmonized with solution architecture. That is why architecture plays an essential role in SaaS implementation. Business process architects need to quantify the criticality of business processes and leverage the insights to build consensus among stakeholders, which include business users, SaaS providers and IT departments. The solution architects, on the other hand, should ensure alignment between business process requirements, downstream enhancements to an offering’s capabilities and future readiness of IT to handle upgrades.
Architects now empowered with business process and solution architecture should identify business KPIs that drive SaaS adoption and measure the impact on process performance. Gap and impact analyses tools can be used by architects to identify gaps between business requirements and OOB features of SaaS products. These analyses tools will result in a list of customizations, which need to be further evaluated.
SaaS Evaluation Framework
Each customization made to the SaaS application should be assessed on two dimensions:
- Potential business impact/criticality: When evaluating the potential business impact, architects should start by identifying sources of differentiation. Differentiation may arise from enhancement in customer-facing capabilities or improvement in operational efficiency—or both. Mapping measurable quantitative outcomes such as CSAT ratings, turnaround time, etc. can help define potential differentiation.
- Ease and cost of customization: Overall cost of ownership should serve as the primary way to evaluate the ease of customization, and right-size the trade-off between ease of implementing customizations with the ease of maintaining the solution. While the parameters to measure ease and cost of customization need to be defined, considerations include design types, the time and effort required for development, maintenance and upgrading activities (e.g. plug-in/script development).
The above proposed assessment must also identify the following:
- Impact of not having requested features.
- Technical challenges in configuring/customizing the solution to meet each requirement.
- Ability to upgrade SaaS application without having to reapply customizations.
- List of actions to bridge identified gaps between proposed SaaS solution and existing process requirements.
As displayed in the graphic above, customization needs to be treated differently based on which quadrant it gets mapped to.
Appropriately Prioritizing Customizations
Customizations that are easy to implement but don’t yield any measurable benefit to the business should be avoided as much as possible to eliminate risk, save effort and allow investments elsewhere.
Similarly, customizations that are difficult to implement and carry no clear benefit or impact on outcomes, must be avoided. Instead, IT will have to convince the business to adopt OOB processes.
On the other hand, critical customizations that are easy to implement and maintain should be shortlisted for further steps. Since there is a clear business case warranting customization, architects should ensure that the design approaches are recommended and supported by the vendor.
Must-have business functions requiring difficult customization must be carefully examined. Consider the following questions: Will it still provide perceived time-to-market advantage? Will it increase overall cost of development and ownership? Will it impact scalability, upgradability and integration capability?
In some cases, the SaaS provider may have feature enhancements in its pipeline that would help implement these must-have requirements. If so, the IT team should collaborate with the provider, influencing and defining upcoming product features.
If that’s not an option, an alternative is to implement critical functions outside the SaaS solution and then connecting through well-designed back- and front-end integrations. For example, some SaaS providers allow customers to build composite apps on their platform as a service (PaaS). These apps can provide differentiated features without having to change the core SaaS solution. However, keep in mind that PaaS apps will need real-time integration with SaaS apps to achieve this.
As explained above, not all business processes deem a customization of the SaaS solution. A structured framework should be used to classify which customizations will play a crucial role in any organization’s SaaS adoption journey.
All customizations should be reviewed and approved by the program steering committee consisting of stakeholders from IT, business leadership and the SaaS provider. All parties involved need to have a clear understanding of why the customization is critical—that means business stakeholders need to provide justification for why a workaround or process change is not viable. Similarly, IT and the SaaS vendor need to articulate a plan of action and a road map for upgrades. In doing so, businesses will reap the full benefits of moving toward SaaS.
Manish Gupta is founder and CEO of 
Craig Rosen is vice president and CISO at 
Kamesh Pemmaraju leads product management, product marketing, and technology partnerships at 