So when are you planning to implement a SaaS (Software as a Service) solution? Very soon, if not already! Yes, the SaaS adoption trend is on the rise and it’ll certainly gain momentum in coming months and years. The concept is not totally new to most of us, as we have already seen hosted-services for several years in the form of various ASPs, or the better known Google Apps, Dropbox and Microsoft 365 services. But it is just recently that we have observed the phenomenal growth and adoption of SaaS solutions across business functions. According to Gartner, the total spending on SaaS is going to reach above US$ 22 billion by 2015, with a growth rate of above 16% globally, which is three times the overall growth rate of IT spending. There are various factors contributing to this expansion, few primary ones are:

Improved technology infrastructure, particularly internet speed and reliability.
Advances in cloud computing.
Wider range of business automation solutions on SaaS, more than the standard email and word processing apps
Compressing business cycles that are putting immense pressure on the businesses for quicker turnaround and ability to scale up and scale down.
For some businesses, SaaS provides an excellent opportunity to get rid of their internal IT that has become inefficient from both the speed and cost perspectives (a wake-up call!).

Let’s keep the discussion on business value, justification and merits of SaaS for another time. Today we’ll look at the 3 most common technical challenges that can test and possibly disrupt the SaaS adoption plans. In my opinion these should be top of the list for any Project Manager leading the enterprise SaaS implementation.

1- System Integration

System integration has always been a big challenge for any large-scale IT solution implementation. For SaaS, it gets a lot tougher due to the excess of business process intersections and the hosted nature of the software. This means that you first need to work through a maze of firewalls, data security constraints and probably the hosting space and network limitations to reach an intermediate stage where you can seriously start evaluating technologies and options for the actual system integration work. At that stage, you may get a bigger shock that the integration options provided by your SaaS vendor cannot fit squarely with your own technologies and standards, and it may cost you significant time and money to find a workaround. But on the other hand, the timelines and savings you have committed to justify the “buy” for SaaS will come to haunt you as the scope and budget of system integration work expands.

So what are the few steps you can take to manage this risk? Firstly, nothing can beat a good analysis and scope definition of system integration work. It should not only consider the need of integration at every layer i.e. UI, Middleware Business Logic components or Database; but also complete analysis of the basic attributes like volume, variety and required freshness of the data. Secondly, it’s good to consolidate the enterprise integration points using a middleware component and then link to SaaS platform though a single (or fewer) integration point. Finally, you may consider a step-by-step approach starting with a basic integration option, like a secure ftp connection, before progressing to a more sophisticated messaging or web-services solution.

2- Data Migration

This challenge can be avoided if you are doing a green-field SaaS solution, or you are fortunate to have business partners who agree to discard the legacy data. Otherwise, you have to take up this challenge in order to manage this transition and maintaining operational continuity. Interestingly most of the data issues discovered during this stage are not caused by the SaaS implementation per se; rather these were present all along like skeletons locked in a closet and they’ll pop up during the data migration. So what kind of issues you may encounter? Well it could be anything ranging from the difference in date-time field formatting, length of fields, data normalization schemes to the locale & character-set settings (God bless if you have to move data stored in Asian charset!)

Few steps you can consider to manage this risk. First, analyze the data migration needs in detail. Is the data being transferred static in nature? Or are you dealing with transactional data that change every second? Can we survive with few weeks old data? Or does it need to be hot and fresh as a pizza? Are there any data rules handled by application layer in previous solution that may create eccentricities during the data migration? Such information will help you plan and manage these issues in advance and prevent rollout delays and noisy meetings. Second, it’s worthwhile to explore if rollout can be divided into batches based on geography, teams or other attributes. It’ll help to reduce the risk and also allow the team to learn and improve with each passing phase. And finally, understanding your real business needs and encouraging your business partners to reduce the legacy data migration as much as possible is the most effective approach. After all, they have a common interest with you to avoid angry users and deluge of incident reports on the go-live day.

3- End-user Experience

This may seem very non-technical at first look. But there are typically 2 key technical factors that have a profound impact on the end-user experience during a SaaS rollout.

First one is the network reliability and bandwidth. This is mostly an issue with emerging or under-developed markets where telecom services are still constricted and unreliable at places. Therefore, if the planning and decision-making for a SaaS global rollout is done in a developed market (e.g. US or Europe); it’s good to get a sanity check from your remote teams right from the planning phase. You can greatly increase the chances of a successful and smooth rollout by investing sufficient time and efforts in doing network connectivity and performance tests at all the locations, or at least the high-risk ones.

Second factor is the plethora of end user devices, including desktop, laptops, mobile devices and the various operating systems and apps running on them. This could be a serious challenge if your organization follows a liberal policy for the end user devices. For managing this risk, build a repository of device configurations that is reconciled and refreshed on a regular basis. This information can then be shared with the SaaS vendor for the solution customizations and rollout planning. It’s also better to involve the onsite team members who understand the local environment at the onset of rollout planning and also engage them during the compatibility and acceptance tests. If you find it difficult to involve the full range of end-users, try having a reasonable representation in the form of power-user groups at least. Remember, you cannot leave the end-user connectivity and device compatibility checks to the UAT; it would be too late to manage any major setbacks at that stage.

Well these are the 3 key technical challenge and some ideas on how to tackle them; and I guess some might be wondering why the information security or data sovereignty issues didn’t appear in the top 3. Couple of reasons for that – first, I consider it to be more of a business operations and risk question than pure technology; and second, information security is too broad to discuss here and that’ll probably require a separate article.

However I do hope this article gives some useful tips and direction. Wish you a pleasant SaaS journey!