Over the last 16 years, our Director of Product Management Michael Nash has seen Signiant through some critical times as we transitioned from solely developing enterprise on-premises software to SaaS.
Mike has been managing Media Shuttle (our first SaaS solution) since its inception. Recently, I had a chance to ask him a few questions about what it took to bring Signiant fully into the cloud era.
What are the main benefits of moving from on-prem to SaaS development?
Mike: With on-premises software you don’t really have a good way to know how people are using the products. Other than contacting customers directly or finding out through bug reports, it’s difficult to know what’s working for them and what isn’t.
With SaaS, you actually know what percentage of your customer base is using different features through anonymous reporting. We can’t see the particular activities of any one company — that would violate privacy policies — but we can see which aspects of the products are being adopted or not in very near real time. That way we can quickly alter the user experience or the feature function in response to how customers are using it. We can also do things like A/B testing to see how people prefer to use different features or interfaces.
It might take eight months in traditional on-premises deployments to see the product or feature in action on customers’ infrastructures, and by then their businesses may have moved on or compensated in other ways. SaaS just gives you much better insight into the software and your customers’ needs.
Another big benefit is being able to focus on your core competencies. When you are making the transition from enterprise to SaaS, you have to get really clear about what PaaS providers are giving you to build on to and how it’s going to impact what you do and don’t do anymore. Cloud providers give you things like compute power, storage, database technologies, messaging technologies, queuing technologies, etc, which allows you to focus on the problems your technology is really trying to solve. Also, because cloud providers spread their costs and resources across a huge global customer base, you can provide high availability of your product and be able to change things quickly.
What were some of the biggest challenges transitioning to SaaS?
Mike: The whole process was a long one, and required setting goals and really sticking to them through the more difficult stages. You don’t decide overnight that you’re going to become a SaaS company.
One of the biggest steps was changing our approach from waterfall to Agile development methodologies. The way on-prem software development is traditionally project managed is through a model called “waterfall,” where progress towards a product or feature release follows a predictable stepwise process downwards through conception, initiation, analysis, design, construction, testing, production or implementation and maintenance. But developing SaaS with the same approach inhibits your ability to take advantage of the insight you can gain into your customer’s use of the product, like we were speaking about before, as well as some of the key advantages of building in a cloud environment.
Completely transitioning to SaaS means changing the entire way you go about developing and supporting software, so something called Agile methodologies have arisen to guide best practices. Agile helps teams respond to unpredictability by using incremental work cycles called “sprints” that usually last a few weeks and a management framework called “scrum” that allows teams to build and release properly tested code or products on an iterative basis. Scrum is really all about getting feedback and utilizing it to continuously improve your product.
A few modern best practices for software development are pretty much impossible to produce without Agile, like micro services so we can deploy new pieces of software and make them available without impacting other pieces of the software, giving our customers zero down time. And other goals like autoscaling and continuous deployment are part of adopting Agile engineering practices.
To make Agile successful, there is a lot more transparency and collaboration that needs to happen. You no longer have the “idea guy” dictating what everyone should do, which can be challenging for some people that prefer to just follow directions. In waterfall, you might have someone in my role as product manager writing a market requirements document, handing it over to development and waiting. With Agile, you bring problems to the team rather than telling them how to design software. And, you can focus on small incremental deliveries that enable you to make changes.
And, because you are in much closer communication with your customers, you have to take the good and the bad into consideration all the time. You don’t have the honeymoon phase where you think your product is the height of perfection and nothing will ever go wrong, until it does. With Agile, the level of collaboration, communication and trust goes up, but the barriers also come down across the organization.
Do you think there was anything unique about Signiant or your devops team that supported such a successful transition to SaaS?
Mike: I think the size of our organization helped a lot. Because we are not a huge company, but we are stable and have a very solid background in our technology space, we were able to fully transition more easily. It’s always easier to move quickly with a small, tight and elite unit. Often bigger companies have to recruit a team and sort of do it on the side, which makes it difficult to transform the whole company. Also, larger technology companies just have a lot more inertia to get through and also feel more pressure to check the box beside “cloud ready” on their spec charts. So they often end up just taking their enterprise software and sticking in on a cloud provider’s network. But those short cuts cost their customers some major benefits of cloud software, especially if they try to operate it at scale. They have to do things like manage security and virtual machines or pay someone else to, which would be included in true SaaS.
Developing true SaaS requires a lot more investment in new functions within the organization, such as a devops (development operations) team that is responsible for monitoring ongoing health and change control, deployment rollbacks and more. It’s just a totally different way of looking at software.
Signiant’s Ottawa Office of Research and Development with our 2015 Emmy Award, Mike is hiding in the back