By Debashis Banerjee, Director and Site Lead, SAP Ariba India
With software as a Service (SaaS) surging ahead as a common delivery model for numerous business applications it is interesting to look back to see how the process of software creation has changed over a period.
On premise software was historically built in a waterfall model. This sequential mode of development evolved with the rise of agile which allowed for continuous delivery and interaction with the customer depicted in the illustration below.
As SaaS took off, further factors inherent to the cloud way of development meant the process had to further evolve. Here are some of the factors that accelerated this change.
Changing Time to Market expectations: Large enterprise customers who often took years to deploy on premise software could not afford the luxury of time as speed to market became the need of the day. This meant that code had to go into production in days or weeks thereby impacting thousands of enterprises with a single deployment in the SaaS model via agile methods.
Move from On Premise Equipment to Hardware Managed on Cloud: In the SaaS world managing hardware moved from managing installed hardware devices on premise to the cloud. SaaS hardware needed to scale horizontally and vertically based on demand. Peaks had to be planned into cloud systems since they could be triggered as simply as a Ferrari accelerating from 0 to 60 in just a few seconds, thereby causing cloud traffic to go up 10X time. during that journey.
Changing profile of hiring infrastructure for SaaS: As the SaaS world allows customers to choose from hiring platform or infrastructure as a service or owning the whole public cloud, the pattern of hiring has moved to seeking developers with a cloud mindset capable to working on all layers – from infrastructure to backend to front end to user interface.
The changed face of partnering for the cloud: On premise software allows heavy individual customization like code recompiling to heavily customized UI and deeper customer specific software. In SaaS, partnering means setting expectations of allowable customizations and build with a customer but for the complete cloud. This needs abstracting out a domain specific problem into a generic reusable cloud solution.
Advent of the single production code branch: On premise requires the need to have versions of several code branches which could be codebases of several years apart. In SaaS development, the latest qualified code is in production.
The disappearing “customer patch”: A favorite weapon of developers of offering a customer specific patch to specific on premise devices, is fast disappearing. That is due to SaaS code, being locked with parameters, configurable on/off switches for features onto a multitenant system and appropriate logical and physical separation of concerns.
The need to automate “almost” everything: With the disappearing customer specific patches and the advent of agile single deployments the need for automation increased significantly. Be it UI or API automation, SaaS demands qualification at speed with near complete modular automation.
Performing deeper SaaS estimations: Estimation for the cloud involves calculating hardware storage for a file, nodes, distributing processing to user interface requiring work breakdown estimation across layers. Comparatively on premise estimation involves scale with the cost of the hardware in the installed customer’s systems.
Rise of usage as a metric of customer adoption: Adoption of software in a device or a target computer and its usage is crucial for billing for software. On premise software development does this via license checks, try and buy tracking or upfront selling of licenses. Engineers built software to track installs more than usage. In SaaS environment usage became far more important. Other than seats – usage of a feature determines financials.
Advent of the SaaS “NOC” (Network Operations Center): Health tracking of on premise software was focused on how the systems were doing in the installed base. SaaS ensures overall cloud health sanity across multi tenancy almost like a NOC.
Thus, these factors resulted in a SaaS cloud based development broadly depicted in the illustration below.
*These are the personal views of the author and do not reflect the views of the company