Typically as the name suggests, an ISV (Independent Software Vendor) could be one of the following:
A) Traditional Software Product companies: Companies who build and sell software products
B) Web based Software companies offering their products as “Services” typically known as SaaS companies
C) Software intensive companies offering services to a market using a software. The main business of such companies is not to sell Software or even SaaS but to “use” them as their tool to sell their services. A typical example of such a company would be one providing “subscription based” clinical information, or a subscription based access to a vast patent database and so on. In such cases, they do not sell software or service instead they sell “information” using a software.
D) A start-up company who intends to become one of the above three.
For the purpose of the article and for ease of reference, let us refer the above as – A-type ISV, B-Type ISV , C-Type ISV or D-Type ISV respectively.
This article is an attempt to provide a clarity to these ISVs as to which of the cloud services they need / should / may need to consider to embark on for the success of their business.
As briefly explained in my previous article, there are three different aspects to cloud computing i.e.– SaaS (Software as a Service), IaaS (Infrastructure As a Service) & PaaS (Platform as a Service). If you are a B-Type ISV, then I am sure you do not need any more explanation of what SaaS is. Also if you are C-Type ISV then too, you may not be too interested in SaaS as selling software isn’t the main business you are in to. But may be you wish to know more on these other aspects such as PaaS & IaaS.
So this is an attempt from me to put few points across to provide a clarity to all the ISVs out there.
SaaS
If you are A-Type ISV, embarking the SaaS route may be an option for various reasons. It is all about entering a new spectrum of market with a complete new spectrum of operational differences as compared to the on-premise sale model. This new deployment and licensing model fundamentally changes the business model of an ISV, impacting many parts of the organisation – marketing, the sales force, presales engineering, deployment, support, finance, and product engineering and maintenance. It is no longer just sell a license, ship a copy of the product and provide support for an annual support contract. For your customers, your product (or service) is now an OpEx cost and no longer a CapEx cost.
These are the few fundamental questions an ISV should ask themselves
- Are there a large proportion of potential customers who do not buy your product due a higher up-front CapEx (in short is your on premise product expensive)?
- With your current product are you able to cater to all sizes of customers – i.e. Small, Medium, Large?
- Are you into selling a software solution which customers may only want to buy after they try it out?
- Would you like to add to your customer list, a mass volume of small customers over and above your existing amount of medium & large customers?
All the above questions are attractive reasons for an ISV to move to a SaaS based delivery model. But as mentioned earlier this impacts fundamentally all parts of the organisation right from presales to support, marketing to maintenance, product development to deployment. If you are a successful A-type ISV, and if your potential target market is reachable with your current offering, then there is no need for you to take the SaaS route. No one would suggest to get away with the current on-premise model and embrace the SaaS way of delivery (if you are already successful). But providing SaaS based delivery as one more option makes a huge sense to cater to many smaller potential customers.
In my next article I shall provide a detailed analysis of what it takes for an ISV to move to SaaS along with comparisons, pros and cons of this delivery model. As soon as this article is ready I shall change this text to point to that article for ease of reading.
Technically there are three ways of moving to / or extending your product to SaaS:
a) Using PaaS to build a new SaaS version of your product
b) “Extend” your product to enable it to be offered as SaaS
c) Completely re-architect a new SaaS version of your product
Option c) may be the best long term option but it is the most riskiest.
Option a) is the easiest option but in a long run may not be cost effective. (Details in my next blog).
Option b) could be a potential option to choose if the existing architecture is modular, flexile enough to accommodate a SaaS version of it too.
The below chart gives you a high level glimpse of your existing product architecture and whether it allows you to move to a SaaS based delivery too. It also states, what it takes for an existing product to move to be offered as a SaaS – depending upon the type of the product
Microsoft has categorised every SaaS based application in to 4 different maturity models. Please refer to this article from Microsoft for the definitions of these 4 maturity models for reference.
Please note that the above chart should be only used as a reference for a faster way to get into SaaS from a traditional on-premise software and may not necessarily the best way to achieve the same.
An ISV should ideally start thinking over to offer their product offering as SaaS with choosing one of the 3 options above with Option C being the most complex and the most expensive one and Option A would be the more modern method and Option B would be a starting point to extend the existing investment on the on premise software.
No comments:
Post a Comment