3 things to consider when creating a new SaaS product – Automic blog post
You want to create a new product. At the same time you want to create a new delivery model – e.g. Software-as-a-Service (Saas) – for your new product.
Of course – these days – you also want to create a new pricing model for your product. And you want to increase delivery speed while maintaining product quality, of course, as high as it always was.
Ultimately you also want to keep the consistent flow of upgrades, patches, and hotfixes, for your existing enterprise product landscape intact.
Challenging? Yes. Impossible? No.
1. Deal proactively with the risk of technical debt
Creating something of this complexity within such a short timeframe can easily lead to artefacts being developed that play together well in the first place but never ever scale to the extent that an enterprise ready product would need to.
A clear architectural separation of concern between entities while at the same time keeping focus on a concise end-to-end architecture for all building blocks is key for avoiding technical debt right from the beginning.
One approach of achieving that focus is, of course, to invest heavily into upfront creation of architecture and design specifications.
However, this approach might just not serve the goal of a short time-to-market sufficiently.
Hence, the only way of maintaining the path and thereby reducing technical debt is to create just enough specs to form the boundaries within which a team of brilliant technologists can quickly develop the MVP – the minimal viable product – to be pushed out and at the same time stay focused on the path of the broader goal.
2. Be DevOps from the beginning
One might consider the creation of a new product within a new delivery model (like SaaS) to be just another product development.
Here at Automic we have a lean product development process in place based on agile patterns and already tailored to our customers’ needs with regards to fast change request and hotfix delivery.
However, approaching SaaS with this speed instantly surfaces the need of something new in that space. Hence – along with a concise architecture specification – you need to create not only a DevOps oriented tool chain but at the same time a DevOps culture between the involved organizational units.
DevOps – if implemented end-to-end – changes your delivery, maintenance and operations pipeline completely. Developers are challenged by the fact that their deliverables are instantly deployed to a QA system, test engineers change their focus from testing to end-2-end test automation in order to support automated production deployments and operations start to deal with an application centric rather than a system centric view onto their environments.
Setting the stage by creating a DevOps funnel from the very beginning is key to delivering not only the MVP but also its constant continuous enhancements.
3. reate a consistent architecture model of Automation and Orchestration
Having a solid enterprise ready SaaS-ified product in place is a major challenge in itself. Creating a solid delivery framework of support services for operations and business processes clearly adds a significant level of complexity.
The cornerstone of this is a strong Automation layer defining its capabilities into clearly separated building blocks for the respective purposes (e.g. customer instance management, component packaging, user provisioning, etc.). Put them into the entities they clearly belong to.
Do not put capabilities (logic, functionality) into a building block or component that actually serves a different purpose. Create small functional entities within the Automation layer and orchestrate them into a support service for a well-defined purpose within the framework.
Holding these paradigms high during the minimal viable design process as well as during the rapid – somehow prototype-like – creation of the MVP will later allow you to decouple and re-bundle entities along the path of scaling your building blocks and your entire delivery framework. Of course, a strong Automation product tremendously eases achieving this goal.
Are you involved in creating a SaaS product? What have you learned from the experience? We’d be keen to get your thoughts in the comments below.
( This post was also published in the official Automic company blog: http://blog.automic.com/3-things-to-consider-when-creating-a-new-saas-product )
