Beyond Recurring Revenue

Technological Advantages of Migrating to SaaS

For ISVs, the conversion to SaaS has long been known to hold several widely agreed upon benefits. Regular “recurring” revenue is something that Wall Street has embraced, as evidenced by the 4-8x multiples enjoyed by most SaaS firms while their “regular” counterparts enjoy multiples in the 2-4x range. With overall SaaS revenue still growing at rates over 25% annually, we are clearly still in the middle of the sea change.The ability to avoid IT’s involvement during the evaluation and sales process is one advantage that has allowed SaaS companies to sell and grow more quickly than their traditional counterparts. Sales teams and their customers are able to move more aggressively and rapidly when there aren’t a litany of IT requirements (architecture, resource footprint, maintenance overhead, hardware requirements, etc.) to overcome.  And customers have appreciated the emergence of SaaS as it allows them to get their jobs done without too much IT involvement and little IT veto power.  Finally, smaller up-front outlays have made purchases somewhat less painful and easy to manage, even though lifetime costs (and ISV revenue) might be the same or even greater over the long haul.While fully concurring with these merits, we have come across several hidden benefits of a SaaS approach for ISVs – benefits that are often overlooked in the strategic analysis. The benefits mentioned herein are most apparent when an ISV takes a “SaaS Only” approach.  ISVs that choose to straddle the fence and support both SaaS and On Premises (On-Prem) deployments will not fully recognize these benefits.1. Architecture The first benefit is an architectural one. Many application software companies have been built, and will continue to be built, via a combination of organic development and M&A.  In both cases, but primarily in the latter, there is typically a mix of architectures and technologies involved in an eventual integrated solution. Often, however, the perfect integrated solution would involve re-writing much of the code so that the assembled components share a platform, a stack, and an architecture. In On-Prem solutions this is critical, as most customers wouldn’t accept a solution that isn’t well integrated or that uses redundant architectures or infrastructure. For instance, a cobbled together integration that mixes a .NET stack with a Java stack, a Linux with a Windows OS, or a MySQL database with an Oracle database would not score high on the IT evaluation grid.  In addition, it might consume excess hardware and thus have a larger Total Cost of Ownership (TCO) than its competitors. However, in a SaaS-only deployment, such architectural “shortcuts” and temporary solutions can be hidden “behind the curtain” in the ISV’s data center (or at the CSP’s data center to be precise). What the technology advances of the past 10 years have shown us  – speaking about cloud provisioning, virtualization, web services, XML APIs, etc. – is that enterprise applications can be integrated for the user’s benefit via some simple and non-obtrusive techniques from the end-user perspective (client-side Javascript, single sign-on, web services integration, etc.). These integrations, while on paper not elegant because of their redundant underpinnings, often add formidable capabilities yet with reasonably simplistic and low-risk coding and integration techniques.2. DevelopmentThe second substantive benefit has to do with development teams and development cycles. It has yet to be proven that a major enterprise application can be successfully developed and maintained, over the long haul, with both SaaS and On-Prem targets. While SaaS applications typically target small bite-sized releases every 3-6 months, On-Prem applications typically target major releases every 18-24 months with more frequent minor releases. Furthermore, On-Prem applications provide the customer with the ability to control when he or she upgrades, and have to support upgrades often skipping a major release (such as supporting a seamless upgrade from version 6.x to version 8.x of a major product).  While a few major software companies are trying (most notably Microsoft with Office365 and its related On-Prem counterparts and Oracle with Fusion and Fusion On-Demand), the early indications are that the problems arising from the approach are not adequately being addressed and these efforts are destined for failure. By going all of the way, to SaaS-Only, an ISV can simultaneously transform its development approach to a SaaS-centric agile methodology and avoid the pitfalls that come with trying to serve multiple masters – pitfalls that include code management complications, sluggish development compared to pure SaaS competitors, and extra service and support requirements associated with overly complex upgrade paths.3. HomogeneityThis last issue highlights what is otherwise the single most important factor in the success of high-growth SaaS platforms – that is the “power of one”. The pure SaaS players have been successful in their singular focus.  All customers are using the same product and version at the same time. Thus, all of the energy of the ISV is on improving and supporting that product. No worries about versions that are 3 years old or about one-off upgrade cycles. By going pure SaaS an ISV can recognize not only the obvious business benefits, but also this array of technology and engineering advantages that have been leveraged by the high growth, pure play, SaaS players.For more information regarding Bulger Partners or technology oriented strategy consulting please email us at info@bulgerpartners.com

Posted on August 14, 2013 in Insights, Technology Industry