SaaS Architecture Can Make All the Difference for Buyers - Over the Long-Term

The topic of SaaS architecture is gaining increasing attention, and that is a very good thing for buyers. Enterprise buyers need to be aware the underlying architecture can have a huge impact on their long-term SaaS ownership experience, even when the screens from two SaaS vendors show the same functionality.

In business terms, the underlying SaaS architecture helps determine the long-term solution value in many ways by asking questions such as:

• Data Flexibility – Can client-defined fields be added? Can they be put anywhere on the screens? Are they reportable? Can they be acted on by business logic such as process workflows?
• Process flexibility – Can processes and screens be fully configured to adapt to the enterprise’s vernacular and workflows?
• Reporting – Are all data elements reportable? Is reporting real-time? Is reporting available 24×7? How fast is typical access to reporting?
• Ease of integration – How many off-the-shelf integrations are there? More importantly in an enterprise context, how quickly can the software be integrated with the on-premise ERP/HRIS backbones with enterprise-specific configurations?
• Performance and Scalability – How fast are the typical screens? As the SaaS solution’s data and user volumes grow, how will it perform and scale?
• Longevity – How long will the current architecture last without requiring rewrites or re-architecture – 5 years and 10x data/user volumes? 10 years and 100x the volumes? How efficiently can the provider adopt new UI technologies for mobile and future unknown access methods?
• R&D Efficiency – How much R&D effort does the SaaS provider put into functionality vs. architecture layers?

The last point is one of the long-term benefits of true SaaS over on-premises software – almost all R&D for a SaaS provider should be targeted at new functionality on the SaaS provider’s single optimized technology stack, rather than (for on-premises software) having to port across many underlying technologies, having to support and maintain the software on all permutations, and maintaining dozens of old versions of installed software on a mixture of technology stacks. The more R&D a SaaS provider puts into a proprietary database or programming tools – or if they eventually have to rewrite a component of their solution – the less they have for future free functionality.

With on-premises software, you get exactly the features in the current release that you install. With true SaaS software, you also get all the future features that the SaaS provider creates (with free automatic upgrades), so the SaaS provider’s going-forward product roadmap, R&D investment level and efficiency, and the underlying architecture should be key considerations in the decision process when selecting a SaaS solution.

(Also cross-posted on IQNavigator.com's blog)