To SaaS or not to SaaS

Many companies servicing specific industries have technology assets that could be transformed into a Software as a Service (SaaS) offering. Your business may have a unique, proprietary technology that your industry could use. So packaging your intellectual property into a SaaS offering may make sense; you could essentially rent your ‘savoir faire’ to your industry, or even to multiple industries depending on how generic the technology is. For example, if you know how to process insurance claims effectively for your own business, could you offer an Insurance Claim SaaS platform to your industry? When done properly, offering a SaaS solution could open the doors to new revenue and a more predictable revenue model based on a subscription model for example. And of course, if you are considering a SaaS offering, it may even be possible to transform your technology offering into a more developer centric solution as a PaaS offering; so the following discussion applies equally to PaaS enabling your technology stack.

What’s my low hanging fruit?

To begin answering the question of whether or not you should consider building a SaaS offering, you want to make an inventory of the high level technologies you have built over the years. It may be related to licensing, data transfer, security models, industry-specific calculations, a mathematical model and so forth. Or it could be as simple, or generic, as business card transactions that you feel is unique to your industry because of compliance requirements or other constraint.

Once you have established this list, find the technology that is likely the easiest to package. If the technology is well understood by your staff, if you own all the rights to the technology, if the technology does not need too much rework to be used by multiple customers, and if making the technology available to the competition won’t put you out of business, then you may have a winner!

What else is involved?

If you identify a technology that makes sense to package as a SaaS offering, you need to evaluate the energy involved in creating your offering. By energy I mean associated costs and servicing readiness of your company. From a cost standpoint, you may need to invest in making your technology more generic to handle a greater variety of conditions that your online customers will need; or perhaps you may need to redesign a component in your technology to handle multiple customer requests at once.

From a servicing standpoint, will you need to build a management portal for your SaaS offering? Will you need to train your staff into the new kinds of issues that your technology may face when exposed publicly? Keep in mind that building an online service may require your company to be prepared to function like a software company, with release management, higher quality control, patch management and so forth.

Example of a failed service

Although creating a SaaS offering can be lucrative, it is usually not easy to build and service over time. Some services seem to make sense, but the technology stack, or the actual customer demands are such that it may not be a viable financial option in the long run. A technology that does not scale very well to an increasing number of users could spell doom for your SaaS ideas.

Although there are many services that failed over the years, I am cherry picking the Azure Reporting Service as the prime example because it was put together by a company that now builds cloud services as part of its mainstream business: Microsoft. Of course, Microsoft has built many successful online services (SaaS, PaaS and IaaS), and as such is developing a leading expertise in packaging and bringing to market remarkable solutions. And yet, the reporting service offered a couple of years ago failed from a business standpoint. The service itself was certainly in high demand; configuring an onsite Reporting Services environment is complex, and hard to maintain. So a SaaS/PaaS offering made sense for this service because of the demand for simpler configuration. However, the technology is likely very hard to scale; running reports can use a lot of resources, which makes it difficult to predict (and contain) the amount of resources used by hundreds (or thousands) of customers. Ultimately, while the offering was awesome (and so was the service itself), it did not appear to be scalable enough, which means that Microsoft probably pulled the plug on this offering due to the high operating costs (high operating costs meant a high price point for the service itself, which as a result impacted negatively customer demand).

Conclusion

If your business services a specific industry, transforming an existing technology you built over the years into a SaaS (or PaaS) offering could provide a new and more scalable business model to your company, and create a more predictable revenue stream over time. One way to enter this business model is to leverage your own technology stack and repurpose what you already do well into a publicly available service. However it can be challenging to transform your business into an online operation. If your company is considering entering this space, you should consider the various business impacts of running a SaaS service, including whether or not your technology needs to be upgraded and how you may need to change your business to function like a software company.

About Herve Roggero

Herve Roggero, Microsoft Azure MVP, @hroggero, is the founder of Blue Syntax Consulting (http://www.bluesyntaxconsulting.com). Herve's experience includes software development, architecture, database administration and senior management with both global corporations and startup companies. Herve holds multiple certifications, including an MCDBA, MCSE, MCSD. He also holds a Master's degree in Business Administration from Indiana University. Herve is the co-author of "PRO SQL Azure" and “PRO SQL Server 2012 Practices” from Apress, a PluralSight author, and runs the Azure Florida Association.

Print | posted @ Wednesday, January 28, 2015 10:58 AM

Comments on this entry:

Comments are closed.

Comments have been closed on this topic.