Companies such as Google, Amazon and even Microsoft have shown that providing key IT services such as email, compute and office productivity software successfully as online "on demand" services. This has opened the floodgates across the market, with more and more services these days being provided to consumers and businesses in an on-demand delivery model.
I recently was at a large multinational company that was trying to determine how best to offer their software as an online "on-demand" service. While they have a rather unique set of challenges before them, there were still a set of questions that I felt any company who might be considering moving into the online delivery model should really ask themselves before taking the plunge.
This question is not as silly as it may sound. Sometimes a business gets excited or ahead of themselves and the market, whether from reading about online service successes in other industries in the press or a Gartner analyst report. While moving your products "online" might be that key angle that might help you beat your competition or gain significant market share, you need to look at how big of a leap it might be for the market and your customers. If customers are familiar with using your software through thin clients or clean latency agnostic web service calls, and/or you are already losing sales because the up front costs and hassle for equipment and IT support for your customer is just too high for them to bear, then it might be a great move. If, however, you are providing more traditional thick clients, and/or are providing software that tightly integrates with other internal software and systems, you may want to do much more legwork to see whether or not providing your services in an externally hosted manner is viable.
Have you been confronted with requests to provide your services in an on-demand online way? Are there competitors in the market who have offerings that are provided in a Software as a Service model? Have you seen customers wanting to move more of their costs from capex to opex? Are there challenges with customers who want to see their costs more accurately reflecting their usage in order to get away from the trap of having to cover arbitrary license fees or having to scale up for some peak load that happens for only short periods during the year? Are your customers frustrated at the level of skill and customer service that their own internal IT departments provide? Any of these may be a good reason to seriously consider creating an on demand offering.
If, however, your customers are all scared by the concept of externally hosted solutions, either for security and control reasons, or worse they feel threatened that you might take away their jobs, you might need to ask yourself whether the market is ready yet for such an offering. While it may still be possible, if you find yourself constantly in a missionary sales mode to potential sales leads who really like your software but are extremely skeptical of an online delivery model, you may need to either significantly bolster the strength of that model (and the way you sell it), or back away from it for the time being.
Providing service offerings is hard. You need to get a lot more things right in order to ensure that you can not only provide a service that customers want to buy, but that you can make a profit while doing it. The first thing that you need to understand is if your service is perceived as usable by your customers in an online delivery model. This means that you need to understand how they will access it, how they will work with it, and what sort of performance they will be expecting. When I was at Yahoo!, we used to look very closely at people's behavior to better understand what their expectations were for product performance. We noticed that people had different expectations depending upon what they were doing. If they were reading text they would have different expectations than toggling through an interface, and different again for consuming feeds, which even varied on the type of feed, and again there were differences in expectations of performance for watching videos. When we began to understand these, it heavily influenced our architecture and deployment models. We could perform a variety of very neat tricks that made things look and act responsive, even over dodgy internet links. We even became sophisticated with how we would pair and serve solutions, and how and where we would host them. Without understanding more about our customers, we would have just been stabbing in the dark.
Another aspect is what does the cost structure look like for running your service. Are you able to provide your services in a multi-tenant way, or do you have to have standalone setups for each customer? Does your service require beefy and expensive systems that significantly stairstep your costs or can you scale horizontally with cheap systems? Do you require expensive software licenses and vendor solutions that significantly push up your costs? Can you match these costs to a sensible charging model that doesn't simply look like a pile of up front costs like they would see if they hosted it internally, yet still allows you to make a profit, even if it is down the line? If the charging model is use-based, can it be sensibly measured in a way that actually ties to a customers usage (and optimally to their sense of value) and not an itemized list of the underlying systems, licenses and support costs? Many get this wrong, which is unfortunate.
The final elements are arguably the most important, which is are you and any partners/suppliers you are dependent upon capable of providing a sufficiently high level of service for your customers while being cost competitive and without destroying your bottom line? Providing your services as an on-demand utility pushes customers to expect a far higher level of service than they could cobble together themselves. They expect that you are going to be responsive and reliable, and are not going to lose their data or lock them out. They do not want to have to think of or ever be concerned about what IT ugliness might be going on underneath the covers of your offerings. They will want the services to always be available when they want them. They will also want things like upgrades to be seamless and not require any effort or inconvenience on their part. These are all very difficult to meet, however are often what can make the sale if you can confidently provide it.
Building and supporting a SaaS solution is very different than doing it for the same solution offered as shrinkwrap software. You are now responsible for running the service, meaning that you can no longer hide behind a customer's internal IT group and environment. You are responsible for designing, building and supporting the full stack that provides the service, and are expected to do it at a level far superior than any standard IT organisation. That is hard, and requires a very different approach and thinking end to end.
First, you need to ensure that you are creating a design and architecture that is resilient and supportable. You need to think about how tightly coupled various subsystems are with each other. You need to think about every way that your service can fail and try to ensure that it will fail gracefully if not seamlessly. You will have to think through how to instrument up your entire stack to allow for better monitoring and management of it. You will find that this will need to be far more than just heuristics style monitoring, but also will require understanding usage patterns and how the various subsystems perform on their own and with one another. You need to think about how you handle data, how you can manage and ensure its integrity, and how you can clean things up and keep any necessary separation between users and customers. You need to also think through access management at all levels, both within the service as well as across the entire service ecosystem, including the infrastructure. Related to this, you will need to think through all security elements, including things such as intrusion detection, denial of service attacks, security perimeters, and how to ensure the sanctity of your environment.
Then there are the build and deployment aspects that need to be thought through. How large and frequent are releases? How are things built, packaged and configured? Are deployments manual or automated, and can they be rolled back and reproduced? How upgradable is the service and infrastructure, and does it require downtime? How are changes sized up for their risk levels, and who makes those decisions? These all sound fairly straightforward, though most companies get these very wrong.
Finally, do you have the skills and staff required to run and support your service operationally? Can they monitor it and ensure its uptime and integrity? Can they handle incidents and requests quickly and effectively? Are they well versed in security and service continuity, always thinking about the safety of the environment and how to make it more robust yet still manageable? Can they effectively work and coordinate with suppliers, ensuring both incidents as well as requests are handled quickly and seamlessly to both you as well as your customers? Are they constantly aiming to and are able to continually improve the service and how they are able to manage it? Have you thought through how your customers will engage with you from an operational and support standpoint across the service lifecycle, including onboarding, during run, as well as some eventual offboardings that may happen?
I recently was at a large multinational company that was trying to determine how best to offer their software as an online "on-demand" service. While they have a rather unique set of challenges before them, there were still a set of questions that I felt any company who might be considering moving into the online delivery model should really ask themselves before taking the plunge.
What are the Drivers for Making the Move?
What is the Market Landscape?
If, however, your customers are all scared by the concept of externally hosted solutions, either for security and control reasons, or worse they feel threatened that you might take away their jobs, you might need to ask yourself whether the market is ready yet for such an offering. While it may still be possible, if you find yourself constantly in a missionary sales mode to potential sales leads who really like your software but are extremely skeptical of an online delivery model, you may need to either significantly bolster the strength of that model (and the way you sell it), or back away from it for the time being.
What is the Legal/Regulatory Landscape?
Many businesses have to work within a rather tough legal and regulatory environment. Whether it is banking, medical, utilities, telecommunications, broadcasting, aerospace, government or some other industry, each has its own peculiarities with systems, security and data handling that needs to be well understood before diving in. Some of these, such as safe harbor rules, severely restrict where data can be held and who can handle it how, often with not just organisational boundaries but even geographic and political boundaries as well. They are complicated and often tough to deal with. However, there are very few that, with awareness backed by solid systems, controls and policies in place to handle them, that cannot be overcome. It is often a bar that is set extremely high, often by people who are scared of or highly skeptical of any software that sits outside of systems that they can physically touch and stare at the blinking lights on the chassis. I have dealt with many of the toughest ones out there. In more than one instance I found myself in situations where the regulator was at first convinced it wouldn't work. It was always tough, but by understanding what they were looking for and why we always managed to get through.
If you provide solutions for these sorts of industries and cannot effectively speak to and prove your compliance, you will either need to put in the investment to be able to do so or not offer them. As a side benefit of getting your act together is that it not only helps strengthen you message, but if you do it right it can help you understand if you can provide your services effectively.
Can Your Software be Sold Profitably as a Service?
Another aspect is what does the cost structure look like for running your service. Are you able to provide your services in a multi-tenant way, or do you have to have standalone setups for each customer? Does your service require beefy and expensive systems that significantly stairstep your costs or can you scale horizontally with cheap systems? Do you require expensive software licenses and vendor solutions that significantly push up your costs? Can you match these costs to a sensible charging model that doesn't simply look like a pile of up front costs like they would see if they hosted it internally, yet still allows you to make a profit, even if it is down the line? If the charging model is use-based, can it be sensibly measured in a way that actually ties to a customers usage (and optimally to their sense of value) and not an itemized list of the underlying systems, licenses and support costs? Many get this wrong, which is unfortunate.
The final elements are arguably the most important, which is are you and any partners/suppliers you are dependent upon capable of providing a sufficiently high level of service for your customers while being cost competitive and without destroying your bottom line? Providing your services as an on-demand utility pushes customers to expect a far higher level of service than they could cobble together themselves. They expect that you are going to be responsive and reliable, and are not going to lose their data or lock them out. They do not want to have to think of or ever be concerned about what IT ugliness might be going on underneath the covers of your offerings. They will want the services to always be available when they want them. They will also want things like upgrades to be seamless and not require any effort or inconvenience on their part. These are all very difficult to meet, however are often what can make the sale if you can confidently provide it.
Do you have the skills/know-how to Build and Support a Service?
First, you need to ensure that you are creating a design and architecture that is resilient and supportable. You need to think about how tightly coupled various subsystems are with each other. You need to think about every way that your service can fail and try to ensure that it will fail gracefully if not seamlessly. You will have to think through how to instrument up your entire stack to allow for better monitoring and management of it. You will find that this will need to be far more than just heuristics style monitoring, but also will require understanding usage patterns and how the various subsystems perform on their own and with one another. You need to think about how you handle data, how you can manage and ensure its integrity, and how you can clean things up and keep any necessary separation between users and customers. You need to also think through access management at all levels, both within the service as well as across the entire service ecosystem, including the infrastructure. Related to this, you will need to think through all security elements, including things such as intrusion detection, denial of service attacks, security perimeters, and how to ensure the sanctity of your environment.
Then there are the build and deployment aspects that need to be thought through. How large and frequent are releases? How are things built, packaged and configured? Are deployments manual or automated, and can they be rolled back and reproduced? How upgradable is the service and infrastructure, and does it require downtime? How are changes sized up for their risk levels, and who makes those decisions? These all sound fairly straightforward, though most companies get these very wrong.
Finally, do you have the skills and staff required to run and support your service operationally? Can they monitor it and ensure its uptime and integrity? Can they handle incidents and requests quickly and effectively? Are they well versed in security and service continuity, always thinking about the safety of the environment and how to make it more robust yet still manageable? Can they effectively work and coordinate with suppliers, ensuring both incidents as well as requests are handled quickly and seamlessly to both you as well as your customers? Are they constantly aiming to and are able to continually improve the service and how they are able to manage it? Have you thought through how your customers will engage with you from an operational and support standpoint across the service lifecycle, including onboarding, during run, as well as some eventual offboardings that may happen?
Final Thoughts
Software as a Service solutions are the way of the future. It democratizes the market, lowering the barriers of entry for both customer as well as supplier. It greatly reduces the level of cost and friction between customer and supplier, and should allow for customers to experience a level of quality and resilience that they cannot afford to provide internally. However, it requires a great deal of end-to-end thinking in order to create a successful SaaS offering.
No comments:
Post a Comment