Maintaining Feature Velocity and Stability While Concurrently Delivering a SaaS and On-Premise
By virtue of having been in the enterprise software security space for more than a decade, we’ve had the fortune to see many product companies making “transformational” shifts from on-premise product to a cloud deployed product. However, while this shift is always driven by market forces – e.g. new markets, protecting your customer base, etc – it is important to consider the impacts on engineering architecture and processes.
At Similty we have successfully figured out concurrently delivering not only on SaaS but also on-premise while maintaining a high level of quality as well as feature velocity.
There is so much to write about the journey, the decisions, the process, the people impact, etc. but for this blog I’m going to summarize this in two major areas
- Feature Velocity
- Quality of Releases
A Note about our Journey While a lot of companies have gone from on-premise to the cloud, our journey has been the other way around – e.g. from cloud to on-premise. This has allowed us to bring a modern big-data and machine learning ready stack seamlessly to an on-premise world while maintaining the same code base.
Feature Velocity Concerns
Invariably, having more than one form factor creates a number of issues that end up impacting feature velocity. We’re discussing the key ones here that we came across along with our approach to dealing with them.
Single Code Base
Most companies struggle with managing teams that work on SaaS vs. on-premise and often end up splitting the code base. This ends up creating a lot more overhead internally, not to mention the diverging feature sets that customers (especially your hybrid customers) get.
The first step is to figure out your release velocities. E.g. do you want it to go out once a day, week, fortnightly, quarterly, etc. Once you’ve locked that in – make sure that you use your SaaS (or your higher frequency release) as your main code branch.
The idea is to keep version-tag this main branch every time you either create a new SaaS or an on-premise (typically lower release velocity) build. When you fix bugs, fix it in the branch that they were reported in and have a way to merge it back to the master.
End of Life Policy
In a SaaS delivery model there is no concept of an explicit end of life policy since the time your new build is pushed in to production the older one has automatically gone end of life (for simplicity we won’t consider the rollback scenario). However as soon as you have an on-premise build you need to consider when your release is going to be not supported – since without it you will incur high costs since your customers will be on different builds consuming precious resources on an ongoing basis to support them. So a few things to consider in your end of life policy:
- What is a typical upgrade velocity that your target customer base is comfortable with
- e.g. banks won’t want to upgrade enterprise software beyond once or twice every 6 months
- How many releases do you want to be supporting at any given time – typically 3 is a good number to pick since you want to account for unforeseen issues that may prevent your customer to upgrade.
- Do you want to create a period when you’re supporting it but won’t create engineering driven patches/fixes
- i.e. a period where you’ll provide work arounds but no code changes to the old product
Ensuring High Quality
Regardless of the form factor – every customer will demand a high quality product. When you get into a multi deployment environment, you need to figure out a way to optimize your testing strategy to ensure that you not only support the high quality, high velocity requirements but do it in a lean way. Here are a few considerations that we went through.
Strong SaaS testing; Higher “Production Test” Time for On-Premise
The most important aspect is to optimize your testing around your high velocity SaaS product. This ensures that you do it right once, and can use it multiple times in the future without concerns. The key activities we did in this area included
- Do an in depth testing during the SaaS (high frequency) release cycle
- Ensuring that we automate everything – manual testing was kept to a minimum (if not zero)
- Ensure that unit tests and QA tests are integrated into the build process so that every build already has gone through those tests
Once the SaaS build has gone live there may still be some issues that may come up but by and large, by the time it’s ready to release your on-prem release (quarterly for Simility) the features have already gone through an elongated in production run time with the SaaS customers.
This is important because in the SaaS environment, as a product vendor you still have access to the systems in case something goes wrong. This kind of flexibility is just not present in the on-premise environment so a higher level of testing period goes a long way in building customer and internal confidence in those releases.
Internal Flexibility to Release Features as an “Early Preview”
As a company (and especially a startup) you thrive and evolve with new features. However, while it’s easy to deploy them in a SaaS environment, the risk of doing this faster on-premise is much higher. So you need to figure out a way to be able to be nimble while ensuring that the quality of the product isn’t impacted.
A good way to do this is to make sure that you can enable the new feature as an early preview since it’s already gone through the first level of testing with your on-premise environment. However be wary in terms of calling a new functionality generally available since it can create misalignments with your EoL policy, support readiness, documentation, etc.
Sometimes the ability to showcase a feature as a demo in your private SaaS environment will go a long way to win the customer who’s evaluating not only your coding capabilities but also on how you’re focusing on the quality of the product being delivered.
The above two sections are just a couple of key points that I’ve discussed. I’m happy to discuss more based on the feedback from this blog. Reach out to me here.
Latest posts by Swastik Bihani (see all)
- Maintaining Feature Velocity and Stability While Concurrently Delivering a SaaS and On-Premise - March 13, 2018
- Trade Surveillance: Going Beyond Regulatory Requirements - March 2, 2018
- Omnichannel Fraud Prevention for the Digital Age Banks - December 26, 2017