"Computers are useless. They can only give you answers." (Pablo Picasso)
The Operations group is an odd duck for the traditional, on-premise, enterprise ISV. Those ISVs that are transitioning to the SaaS model are typically not familiar with this group, its role and perhaps its reason for being, and in some cases you might find Operations reporting to the CFO as a ‘cost center’.
But in a SaaS shop, the Ops group is the hub of all activity. Its crucial and main job, of course, is to ‘keep the lights on’ and do that in a highly available, quality performance fashion. Maintaining a scalable, fail proof service is a task that the Ops group should, in time, perfect to the notion of ‘auto-pilot’, implementing the Automate and Delegate principles (see Reducing SaaS Operational Costs).
But that is not where the job ends; indeed it is only the beginning.
In some early stage SaaS operations (either a pure SaaS player or an ISV in transition), R&D and IT provide that function. IT is usually incapable of running, scaling and maintaining the application; its tool set, capacity and pace are so removed from an application level, 24X7 operation. R&D is in shock and awe: “you mean we have to use the damn product!!??” – they are usually the least capable of understanding how the application should work or the value to their customers.
Whereas R&D used to have dozens, hundreds or thousands of customers, Operations is now the only customer (or in a hybrid solution, the largest). All and every feedback to product marketing would come from the Ops group. It must develop a keen understanding of the application, not just the infrastructure supporting it, and it has to be in constant contact with its customers – the SaaS consumers – to gather feedback, compile it in an orderly and prioritized manner and be able to communicate it to R&D.
Since an Operations Support System (OSS) will be lacking in most early SaaS implementations, the Ops group will be the one presenting the technical solutions either through building its own tools, buying those apps or though cooperation with Engineering to provide the solutions. In any case, Operations will be the authority on the architectural needs, security, storage, the OSS, service-ready features and the application in general. Therefore Operations should be highly involved in the product roadmap.
In some organizations, ownership of the customer success may be in a separate silo that does not include Operations. But one must keep in mind that the Ops group works on a daily basis with the Network Operations Center (NOC) which doubles as the customer support center. Even if Ops and Customer support are not part of the same organization (which I believe they should be) the daily interaction between the groups means that Ops owns the customer success in many ways and deals with the customer directly as a Tier 2 support.
Operations needs an in-depth understanding of its infra and application performance issues and of principles of performance testing/monitoring. They need to work closely with the QA group to test and resolve load issues. In each rollout of a new version, Ops has the ownership of the project, the dates, process definition and should work in conjunction with R&D, QA, Marketing and customer support.
If the Service offered through this model allows for project based business, Operations will tend to be involved in defining offerings, help with the pricing and participate in scoping projects.
And based on my own experience, the Ops team, as the owner of the application and service, worked closely with a team of Expert Service engineers who provided the end consumers with domain-level expertise to drive more value from the application. (See IPaaS) Ops engineers also participated in user forums with the customers to provide best practices and tips n' tricks.
"OK! Fine!" I hear you shouting from the back rows "We are convinced of the central role of Operations. So what?"
So just keep in mind when you are about to launch this endeavor that you will need to assemble a good team of professionals to play in this game. Not just seasoned systems engineers, a network manager and a good DBA, but operations engineers that ideally have an engineering background, that are innovative, customer oriented and business savvy. Nothing short of the Fantastic Four
Software-as-Service as a disruptive trend and how it affects the traditional, ISVs and IT moving to the Cloud. Considerations in the transition to the new model and expertise on SaaS Service Operations - STORM™ and DevOps
Thursday, December 07, 2006
Monday, October 09, 2006
Reducing SaaS Operational Costs (II)
In the last post Reducing SaaS Operational Costs I discussed how utilizing two strategies, Automate and Delegate can enable economies of scale, so that the cost of adding new customers is marginal.
Following is a review of some of the areas in which these strategies will prove to be cost effective over the long run, and reduce the probability of the operation collapsing under pressure.
Professional Services
Remember - “customization – OUT; configuration - IN”. The software should be designed to allow maximum configuration without altering the code. This includes branding the software and, more importantly, allowing the customer to define names and custom fields to various entities of the product.
Build the architecture to support Web Service for painless integration with in-house systems, then Let your customers do the integration.
Train the trainer. Find the champion of your solution at the customer, and grow her. Help her promote the product and build a well trained team that will take the burden off your shoulders, including some of the sales and marketing efforts.
Operations
Provisioning should be a seamless process with no (or minimal) human involvement. A customer should be able to sign up to the service and the resources should be provided automatically. A customer-centric application is essential and administration should be delegated to the customer with multiple-hierarchy supported.
Client side components should be downloadable with self-installation. If the application supports an on-premise agent, it is essential that the backend application is version-backward compatible, to avoid the upgrade nightmare.
In order to ensure that the application is up, available and performing to the SLA requirements automation should be used to the maximum. This begins with monitoring the network, resources and the application. A dashboard should depict the status of all resources with the ability to drilldown to sub systems and components. Alerts should be used and crossed referenced in order not to create false alarms. Use automation scripts for self recovery whenever possible and keep extensive logging for postmortem of downtimes, because they are going to happen no matter how good you are.
And while we’re at it, make sure that R&D provides well-tested, easy-to-use data migration tools for version upgrades. Utilize change management and patch management tools and processes to lower costly human errors.
Maximize self help systems – FAQs & online knowledge base - to reduce customer calls.
Add new services seamlessly – build the capability into the application management systems.
Sales
Naturally, a SaaS offering reduces greatly the need for direct marketing and sales. Cyber sales will take most of the burden and referrals will become an important sales tool. Design a good interactive demo site and allow customers to test the application for a limited time as a proof of concept. This process should not involve human intervention on the ISV side.
If your service is becoming a commodity, allow for self registration and on-line payments. This will greatly reduce the sales cycle and the number of people involved.
Automate the metering and thus, the billing process.
Customer Support
Remember that a SaaS customer service rep replaces some of the functions of the customer organization's HelpDesk. That means that your reps will be getting a LOT more traffic than your average packaged software company. And when bad things happen, everybody will be screaming bloody murder and bog down your communication lines. Therefore have an updated status page where customers can view the responsiveness and availability of your production system(s).
A self service portal will go a long way to reduce the call volume. A rich and well maintained knowledge base will do that as well (check out all the Freemium sites - they will not invest in a non-paying customer, yet they want happy customers as bad as you do). User forums are also a great way to harness the goodwill and knowledge of the community to save on training and problem resolution resources.
In conclusion
The OSS (operations support system) should at least support provisioning, access, self admin, metering, and report tools. There are a number of available platforms for purchase that provide the OSS. They may be a good solution for your operation.
I have touched upon many areas and providing for full automation and the technology enabling delegation may not be available from day one. It is therefore imperative for the Ops team to work closely with product marketing, R&D and QA and to participate in product discussions and development planning.
Following is a review of some of the areas in which these strategies will prove to be cost effective over the long run, and reduce the probability of the operation collapsing under pressure.
Professional Services
Remember - “customization – OUT; configuration - IN”. The software should be designed to allow maximum configuration without altering the code. This includes branding the software and, more importantly, allowing the customer to define names and custom fields to various entities of the product.
Build the architecture to support Web Service for painless integration with in-house systems, then Let your customers do the integration.
Train the trainer. Find the champion of your solution at the customer, and grow her. Help her promote the product and build a well trained team that will take the burden off your shoulders, including some of the sales and marketing efforts.
Operations
Provisioning should be a seamless process with no (or minimal) human involvement. A customer should be able to sign up to the service and the resources should be provided automatically. A customer-centric application is essential and administration should be delegated to the customer with multiple-hierarchy supported.
Client side components should be downloadable with self-installation. If the application supports an on-premise agent, it is essential that the backend application is version-backward compatible, to avoid the upgrade nightmare.
In order to ensure that the application is up, available and performing to the SLA requirements automation should be used to the maximum. This begins with monitoring the network, resources and the application. A dashboard should depict the status of all resources with the ability to drilldown to sub systems and components. Alerts should be used and crossed referenced in order not to create false alarms. Use automation scripts for self recovery whenever possible and keep extensive logging for postmortem of downtimes, because they are going to happen no matter how good you are.
And while we’re at it, make sure that R&D provides well-tested, easy-to-use data migration tools for version upgrades. Utilize change management and patch management tools and processes to lower costly human errors.
Maximize self help systems – FAQs & online knowledge base - to reduce customer calls.
Add new services seamlessly – build the capability into the application management systems.
Sales
Naturally, a SaaS offering reduces greatly the need for direct marketing and sales. Cyber sales will take most of the burden and referrals will become an important sales tool. Design a good interactive demo site and allow customers to test the application for a limited time as a proof of concept. This process should not involve human intervention on the ISV side.
If your service is becoming a commodity, allow for self registration and on-line payments. This will greatly reduce the sales cycle and the number of people involved.
Automate the metering and thus, the billing process.
Customer Support
Remember that a SaaS customer service rep replaces some of the functions of the customer organization's HelpDesk. That means that your reps will be getting a LOT more traffic than your average packaged software company. And when bad things happen, everybody will be screaming bloody murder and bog down your communication lines. Therefore have an updated status page where customers can view the responsiveness and availability of your production system(s).
A self service portal will go a long way to reduce the call volume. A rich and well maintained knowledge base will do that as well (check out all the Freemium sites - they will not invest in a non-paying customer, yet they want happy customers as bad as you do). User forums are also a great way to harness the goodwill and knowledge of the community to save on training and problem resolution resources.
In conclusion
The OSS (operations support system) should at least support provisioning, access, self admin, metering, and report tools. There are a number of available platforms for purchase that provide the OSS. They may be a good solution for your operation.
I have touched upon many areas and providing for full automation and the technology enabling delegation may not be available from day one. It is therefore imperative for the Ops team to work closely with product marketing, R&D and QA and to participate in product discussions and development planning.
Reducing SaaS Operational Costs
"Say, Tom, let me whitewash a little." (Tom Sawyer, Mark Twain)
Remember that quote of Ben from the timeless Tom Sawyer, who gladly gave up his apple to have the opportunity to do Tom’s work?
Cute, but how does that relate to reducing operational costs in a SaaS house? Well, at least fifty percent of the magic formula “Automate and Delegate”
In my numerous interactions with pure SaaS startups as well as with established ISVs transitioning to on-demand, I have encountered time and again the lack of planning for a robust Operations Support System (OSS).
Whenever I bring up the potential hazard of non-scalability I hear the same response “we wish that were our problem” or “we’ll deal with it when that becomes an issue”, secretly wishing that it will become an issue fast enough.
The logic being - let’s make sure our software works as a service and that we get traction. When we’ll have more customers than we can currently support efficiently that would be a success milestone.
I’m sorry to break the news but when that happens you might find yourself with a catastrophe waiting to happen (see Chronicle of a Death Foretold).
The profitable SaaS operation utilizes economies of scale when the cost of deploying, say, 100 customers is just marginally more expensive than a single customer. In an ideal world, the hardware and software infrastructures costs should remain the same; bandwidth utilization should not change dramatically; storage needs will expand more or less proportionally to the number of new customers, while the support staff should remain steady and perhaps increase slightly.
So what costs are involved with the growing SaaS business? There is the hardware, bandwidth, software licenses (e.g. databases), customer care, and the inevitable marketing and sales. Human resources are still the greatest expenditure for a software vendor.
Careful planning – ‘doing things right the first time around’ can make the difference between a profitable operation and one that is bleeding the company.
In order to maximize your margins, you must reduce human intervention in every aspect possible. There are two strategies, that when applied in concert, can do just that. They are Automate and Delegate.
Automate means let technology do whatever task that would otherwise require manual work.
Delegate means enable your customer to do whatever task that would otherwise require your team to handle. Remember Tom Sawyer?
Obviously these stategies will necessitate a technological infrastructure to support it.
By carefully planning your application and operational environment you may achieve a high level of automation and delegation.
In my next post, I will review the areas in which these principles can play a major role.
Remember that quote of Ben from the timeless Tom Sawyer, who gladly gave up his apple to have the opportunity to do Tom’s work?
Cute, but how does that relate to reducing operational costs in a SaaS house? Well, at least fifty percent of the magic formula “Automate and Delegate”
In my numerous interactions with pure SaaS startups as well as with established ISVs transitioning to on-demand, I have encountered time and again the lack of planning for a robust Operations Support System (OSS).
Whenever I bring up the potential hazard of non-scalability I hear the same response “we wish that were our problem” or “we’ll deal with it when that becomes an issue”, secretly wishing that it will become an issue fast enough.
The logic being - let’s make sure our software works as a service and that we get traction. When we’ll have more customers than we can currently support efficiently that would be a success milestone.
I’m sorry to break the news but when that happens you might find yourself with a catastrophe waiting to happen (see Chronicle of a Death Foretold).
The profitable SaaS operation utilizes economies of scale when the cost of deploying, say, 100 customers is just marginally more expensive than a single customer. In an ideal world, the hardware and software infrastructures costs should remain the same; bandwidth utilization should not change dramatically; storage needs will expand more or less proportionally to the number of new customers, while the support staff should remain steady and perhaps increase slightly.
So what costs are involved with the growing SaaS business? There is the hardware, bandwidth, software licenses (e.g. databases), customer care, and the inevitable marketing and sales. Human resources are still the greatest expenditure for a software vendor.
Careful planning – ‘doing things right the first time around’ can make the difference between a profitable operation and one that is bleeding the company.
In order to maximize your margins, you must reduce human intervention in every aspect possible. There are two strategies, that when applied in concert, can do just that. They are Automate and Delegate.
Automate means let technology do whatever task that would otherwise require manual work.
Delegate means enable your customer to do whatever task that would otherwise require your team to handle. Remember Tom Sawyer?
Obviously these stategies will necessitate a technological infrastructure to support it.
By carefully planning your application and operational environment you may achieve a high level of automation and delegation.
In my next post, I will review the areas in which these principles can play a major role.
Tuesday, August 29, 2006
IPaaS
No, it is not a typo, and neither am I contemplating adding another acronym to the alphabet soup. I am simply emphasizing an important aspect of the business - Intellectual Property-as-a-Service. IPaaS is the upper tier of SaaS, what might be known in the industry as ‘Managed Services’ or ‘Expert Services’.
An enterprise software vendor should be delivering more than a software tool. If it also provides a methodology, best practices, and subject matter expertise, then the differentiating value of that ISV is clear. It is (supposed to be) the hub of knowledge of all of its customers on how to do ‘It’ right. ‘It’ may be document, process, or project management, or business intelligence, or performance testing, or CRM, ERP, ABC and XYZ.
Its products are expected to encompass years of experience at a particular vertical or a process by interacting with the customers, heeding to their needs and compiling all of their usage history into the product and the company’s knowledge base.
There are countless tools out there being offered on-demand: email, webex, Google’s Apps and Microsoft Live, to name a few.
What differentiates these services from IPaaS is that they do not require a domain-level expertise. Almost anyone can log into a web-based tool such as webmail and start deriving value from it.
But, one may claim, this domain-level expertise is true for any ISV that offers vertical or complex, process driven systems. So why is this more compelling in the SaaS model?
There are three reasons.
The first is that SaaS vendors can channel their resources into offering a higher level experience for their customers. Most traditional ISVs devote most (if not all) of their professional services’ talents to installation, customization and upgrades/maintenance. If you take these activities out of the equation in the SaaS model, the ‘Professional Services’ can be upgraded to ‘Expert Services’ and dedicate the manpower to helping their customers derive more value from their products.
The second, and even more compelling, reason is that in the SaaS model the software vendors can generate another revenue stream from offering project-based, domain-level expertise. In the traditional model, no company in its right mind would buy and install an enterprise system to run a year-end financials project or a pre-launch performance testing project. Now this is possible with the on-demand model. The software vendor - the ‘expert’- owns the infrastructure; the systems are already installed and ready to use. Send in the expert team (this is a figure of speech of course, the beauty is that you can do it remotely) to run the project and extract a high price for this valued service.
The third, and most important, is the fact that no one has as much visibility into the domain as the SaaS provider. It can view how the software is being used, what kind of data is kept and how it is being manipulated. It can run queries on aggregated data and provide benchmarks and best practices.
Very few companies today make a use of this source of knowledge (and, yes, power) but I predict that it will become an important differentiator in the near future.
An enterprise software vendor should be delivering more than a software tool. If it also provides a methodology, best practices, and subject matter expertise, then the differentiating value of that ISV is clear. It is (supposed to be) the hub of knowledge of all of its customers on how to do ‘It’ right. ‘It’ may be document, process, or project management, or business intelligence, or performance testing, or CRM, ERP, ABC and XYZ.
Its products are expected to encompass years of experience at a particular vertical or a process by interacting with the customers, heeding to their needs and compiling all of their usage history into the product and the company’s knowledge base.
There are countless tools out there being offered on-demand: email, webex, Google’s Apps and Microsoft Live, to name a few.
What differentiates these services from IPaaS is that they do not require a domain-level expertise. Almost anyone can log into a web-based tool such as webmail and start deriving value from it.
But, one may claim, this domain-level expertise is true for any ISV that offers vertical or complex, process driven systems. So why is this more compelling in the SaaS model?
There are three reasons.
The first is that SaaS vendors can channel their resources into offering a higher level experience for their customers. Most traditional ISVs devote most (if not all) of their professional services’ talents to installation, customization and upgrades/maintenance. If you take these activities out of the equation in the SaaS model, the ‘Professional Services’ can be upgraded to ‘Expert Services’ and dedicate the manpower to helping their customers derive more value from their products.
The second, and even more compelling, reason is that in the SaaS model the software vendors can generate another revenue stream from offering project-based, domain-level expertise. In the traditional model, no company in its right mind would buy and install an enterprise system to run a year-end financials project or a pre-launch performance testing project. Now this is possible with the on-demand model. The software vendor - the ‘expert’- owns the infrastructure; the systems are already installed and ready to use. Send in the expert team (this is a figure of speech of course, the beauty is that you can do it remotely) to run the project and extract a high price for this valued service.
The third, and most important, is the fact that no one has as much visibility into the domain as the SaaS provider. It can view how the software is being used, what kind of data is kept and how it is being manipulated. It can run queries on aggregated data and provide benchmarks and best practices.
Very few companies today make a use of this source of knowledge (and, yes, power) but I predict that it will become an important differentiator in the near future.
Tuesday, August 15, 2006
Chronicle of a Death Foretold (III)
or 'How to aSaaSinate your Business' (part 3) (view part 2) (view part 1)
The BizEye story is fictitious of course, but one that describes a possible scenario, though not likely in its extremity. Allowing the state of affairs to deteriorate to such a low level without management intervening at an earlier stage amounts to gross negligence. Such a company probably would not have achieved the state of prominence that they have in the market.
Still, it is worth looking at the various actions that were taken or neglected to be taken. This article is focused mainly on the technical and operational aspects, but it is worth noting that other bad decisions were taken at BizEye, which made the profitability of an on-demand offering even harder to achieve. They include an over-simplified pricing mechanism and lack of planning with other functions within the organization, such as finance, sales, and customer and professional services.
So, what could have BizEye Technologies done differently to avoid the dilemma that they are facing? Of course, they should have done their homework, better estimate costs and especially, raise the red flag at a much earlier stage. But beyond these obvious observations, there are a number of SaaS- pecific issues they should have tackled early on.
C-Level commitment
The switch to a SaaS model from an on-site perpetual model requires an understanding that it is not simply another delivery mechanism, but rather a paradigm shift. The company needs to align itself to start selling a service, rather than a product. (see Impact on the Organization)
The switch involves every organization within the company, and some departments will clearly push back the initiative. Being a strategic move, it is the CEO's perogative to make sure that the executive staff is on the same page and not just paying lip service. Without a commitment of all C-level and VPs, to work towards a successful implementation, any company will likely experience many of the difficulties that plagued BizEye.
A Pilot is just that
A pilot project is a inherent step in the process, unless the company is a pure SaaS player. This proof of concept should not cloud the minds of the SaaS champions. It must be limited in time and scope and have a sunset strategy. The pilot would be a very good time to test the concept, learn of the problems, processes and solutions and feed back into product marketing and R&D. These latter two should already have personnel dedicated to the next phase of a hosted offering, whether it is built into the product or integrated with existing application management solutions.
Think Big
Plan in advance a solution that will allow for incrementally scaling up of very large numbers, as that is the end goal of a SaaS offering. This does not necessarily mean large upfront investments, but it does mean having a path in mind that will not necessitate changes in the future of architecture, process or hosting solution. Nine times out of ten, the architecture and planning are geared for a 'proof of concept', with the champions saying that these problems are "good problems" that we will be happy to deal with, when they happen. By the time that happens they are not "good problems" any more, rather they may end up killing the business.
Technology and Automation
Since staffing is still the most expensive line item on your budget, incorporate technology and automation in every aspect of the operation. This includes automating processes like customer on-boarding and provisioning, delegated authority for every administrative activity, self configuration, automated billing, self healing infrastructure to mention but a few.
Bottom line: Economies of scale will prove very profitable when and if the business grows at an exponential rate of the staffing growth.
Automation and Delegation are a subject of a separate article that I will post in the future. Beyond all that has been written above, these are the crucial components that can make or break a SaaS business.
The BizEye story is fictitious of course, but one that describes a possible scenario, though not likely in its extremity. Allowing the state of affairs to deteriorate to such a low level without management intervening at an earlier stage amounts to gross negligence. Such a company probably would not have achieved the state of prominence that they have in the market.
Still, it is worth looking at the various actions that were taken or neglected to be taken. This article is focused mainly on the technical and operational aspects, but it is worth noting that other bad decisions were taken at BizEye, which made the profitability of an on-demand offering even harder to achieve. They include an over-simplified pricing mechanism and lack of planning with other functions within the organization, such as finance, sales, and customer and professional services.
So, what could have BizEye Technologies done differently to avoid the dilemma that they are facing? Of course, they should have done their homework, better estimate costs and especially, raise the red flag at a much earlier stage. But beyond these obvious observations, there are a number of SaaS- pecific issues they should have tackled early on.
C-Level commitment
The switch to a SaaS model from an on-site perpetual model requires an understanding that it is not simply another delivery mechanism, but rather a paradigm shift. The company needs to align itself to start selling a service, rather than a product. (see Impact on the Organization)
The switch involves every organization within the company, and some departments will clearly push back the initiative. Being a strategic move, it is the CEO's perogative to make sure that the executive staff is on the same page and not just paying lip service. Without a commitment of all C-level and VPs, to work towards a successful implementation, any company will likely experience many of the difficulties that plagued BizEye.
A Pilot is just that
A pilot project is a inherent step in the process, unless the company is a pure SaaS player. This proof of concept should not cloud the minds of the SaaS champions. It must be limited in time and scope and have a sunset strategy. The pilot would be a very good time to test the concept, learn of the problems, processes and solutions and feed back into product marketing and R&D. These latter two should already have personnel dedicated to the next phase of a hosted offering, whether it is built into the product or integrated with existing application management solutions.
Think Big
Plan in advance a solution that will allow for incrementally scaling up of very large numbers, as that is the end goal of a SaaS offering. This does not necessarily mean large upfront investments, but it does mean having a path in mind that will not necessitate changes in the future of architecture, process or hosting solution. Nine times out of ten, the architecture and planning are geared for a 'proof of concept', with the champions saying that these problems are "good problems" that we will be happy to deal with, when they happen. By the time that happens they are not "good problems" any more, rather they may end up killing the business.
Technology and Automation
Since staffing is still the most expensive line item on your budget, incorporate technology and automation in every aspect of the operation. This includes automating processes like customer on-boarding and provisioning, delegated authority for every administrative activity, self configuration, automated billing, self healing infrastructure to mention but a few.
Bottom line: Economies of scale will prove very profitable when and if the business grows at an exponential rate of the staffing growth.
Automation and Delegation are a subject of a separate article that I will post in the future. Beyond all that has been written above, these are the crucial components that can make or break a SaaS business.
Wednesday, August 02, 2006
Chronicle of a Death Foretold (II)
or 'How to aSaaSinate your Business' (part 2) (view part 1)
Cracks were starting to show.
The operations team complained that they are drowning in customer requests and are not keeping up with hardware and hosting requirements. The business growth was accommodated by throwing bodies at problems:
Adding a new customer consisted of setting up a new environment, provisioning resources, filling out an excel sheet with the customer information. Adding users to the system needed manual intervention and any administrative function required a Customer Service Representative (CSR) to process a change request.
Billing also was managed through an excel sheet, since the financial model did not integrate with the perpetual model’s existing financial systems; so any modification required manual labor.
The CSRs, who often escalated to the Operations team, handled customer-specific configuration requests with an-ever lengthening resolution time.
By now, the operations team was handling 35 customers with hundreds of users. Combined, they consumed 35 dedicated systems, and were becoming increasingly unhappy with the responsiveness and degradation of the service levels. Some angry calls were received at the helpdesk center.
An upcoming release of the perpetual version, with exciting new features was starting to look like a nightmare. The field had already installed it in about 50% of the customer base, but the hosted services still had the old version. The upgrade date was being postponed time after time, as they could not figure how to simultaneuosly upgrade 35 different systems. One option was to do it incrementally, but that would mean that they had to maintain two different versions, and keep track of which customer had which version.
Curt and Diane lamented that the whole SaaS trial was going to blow up in their collective face. It was clear that they must stop accepting new customers and quickly get technical solutions. By now, the operations team had accumulated vital knowledge of how to do things ‘right’ but that demanded R&D, QA and Services resources.
Diane reported to Sanjib and he called a meeting with the executive team. Diane laid out the plan, showed the growth rates, enthusiastically presented the huge opportunities and requested a commitment from the C-level to make the new model a success.
Bill, VP R&D explained that his resources are stretched thin because of all the ‘real’ customers out there, a new release that is way off schedule and still many issues with the last release that has half his team working with QA to resolve some serious bugs. He couldn’t see how more than three dedicated people would be available to look at an on-demand solution. In any case they won’t have anything ready in the next two quarters.
Joana, the CFO, suggested that if they hiked the price of the service to make the margins, that would justify enlarging the allocated funds of an endeavor that has, so far, just been bleeding the company.
Raul, VP of customer services, claimed that his team was getting a disproportionate number of calls from the SaaS customers, and his CSRs were not really equipped to deal with the users’ requests. He needed a dedicated team just to deal with the hosted customers and he does not have the budget for it.
Sanjib, who was a cautious supporter of the SaaS initiative, realized that he was only partially informed of the state of affairs and faced a true dilemma. He knew that BizEye could not abruptly drop the service, loose face and 35 customers, but he understood that the SaaS solution was not realizing the promised economies of scale and, with the current state of affairs, his best case scenario was to break even.
He assigned Diane, Joana and Bill to a committee to review possible options and report within two weeks, and he required from Diane a post-mortem on why such a promising prospect has turned into a nightmare.
Curt sat in the corner, biting his fingernails.
Next posting: Conclusions
Cracks were starting to show.
The operations team complained that they are drowning in customer requests and are not keeping up with hardware and hosting requirements. The business growth was accommodated by throwing bodies at problems:
Adding a new customer consisted of setting up a new environment, provisioning resources, filling out an excel sheet with the customer information. Adding users to the system needed manual intervention and any administrative function required a Customer Service Representative (CSR) to process a change request.
Billing also was managed through an excel sheet, since the financial model did not integrate with the perpetual model’s existing financial systems; so any modification required manual labor.
The CSRs, who often escalated to the Operations team, handled customer-specific configuration requests with an-ever lengthening resolution time.
By now, the operations team was handling 35 customers with hundreds of users. Combined, they consumed 35 dedicated systems, and were becoming increasingly unhappy with the responsiveness and degradation of the service levels. Some angry calls were received at the helpdesk center.
An upcoming release of the perpetual version, with exciting new features was starting to look like a nightmare. The field had already installed it in about 50% of the customer base, but the hosted services still had the old version. The upgrade date was being postponed time after time, as they could not figure how to simultaneuosly upgrade 35 different systems. One option was to do it incrementally, but that would mean that they had to maintain two different versions, and keep track of which customer had which version.
Curt and Diane lamented that the whole SaaS trial was going to blow up in their collective face. It was clear that they must stop accepting new customers and quickly get technical solutions. By now, the operations team had accumulated vital knowledge of how to do things ‘right’ but that demanded R&D, QA and Services resources.
Diane reported to Sanjib and he called a meeting with the executive team. Diane laid out the plan, showed the growth rates, enthusiastically presented the huge opportunities and requested a commitment from the C-level to make the new model a success.
Bill, VP R&D explained that his resources are stretched thin because of all the ‘real’ customers out there, a new release that is way off schedule and still many issues with the last release that has half his team working with QA to resolve some serious bugs. He couldn’t see how more than three dedicated people would be available to look at an on-demand solution. In any case they won’t have anything ready in the next two quarters.
Joana, the CFO, suggested that if they hiked the price of the service to make the margins, that would justify enlarging the allocated funds of an endeavor that has, so far, just been bleeding the company.
Raul, VP of customer services, claimed that his team was getting a disproportionate number of calls from the SaaS customers, and his CSRs were not really equipped to deal with the users’ requests. He needed a dedicated team just to deal with the hosted customers and he does not have the budget for it.
Sanjib, who was a cautious supporter of the SaaS initiative, realized that he was only partially informed of the state of affairs and faced a true dilemma. He knew that BizEye could not abruptly drop the service, loose face and 35 customers, but he understood that the SaaS solution was not realizing the promised economies of scale and, with the current state of affairs, his best case scenario was to break even.
He assigned Diane, Joana and Bill to a committee to review possible options and report within two weeks, and he required from Diane a post-mortem on why such a promising prospect has turned into a nightmare.
Curt sat in the corner, biting his fingernails.
Next posting: Conclusions
Tuesday, July 25, 2006
Chronicle of a Death Foretold
or 'How to aSaaSinate your Business' (part 1)
BizEye Technologies, the well-recognized leader in enterprise Business Intelligence software, has been considering developing an on-demand version of its application. Software-as-a-service is recognized as the latest and most disruptive industry trend; BizEye feared that if they were not involved in its adoption, they could become irrelevant.
Diane, the VP Product Marketing took a special interest in this new area, especially after many customers started inquiring about a SaaS offering by BizEye. After reading a number of articles and attending two conferences, Diane became a champion of SaaS within the company and assigned Curt, Director of Product Marketing to explore this opportunity and evaluate the marketplace and the costs & opportunities associated with developing the SaaS application. The initial evaluation looked good and Curt quickly became an advocate himself of the on-demand model. There were interested customers and a whole new market of SMBs to target. A simple calculation indicated that the operation will break even on the fifteenth customer.
Diane presented the business case to Sanjib, founder and CEO of BizEye. Snajib knew that sooner or later BizEye would need to face the question of SaaS. He therefore approved a small budget for an on-demand pilot project. Curt was assigned to lead this initiative. He assembled a task force of professionals from IT, Customer Service and R&D. They selected one of company’s products, the Analytics and Reporting tool, as a pilot project; a proof of concept.
As the software was not built on a multi-tenant architecture, and did not recognize a ‘Customer’ entity, the pilot was built as a dedicated architecture solution. This was not viewed as a problem, since there were only six customers that signed up, and it was a temporary solution anyway. The customers were extremely happy: Time-to-value was reduced from many months to a couple of weeks, and each customer was assigned a named account manager that was pouring love and attention on them. Every need was immediately handled, and all one had to do to add more users or tweak a report, was to call the account manager and the task was taken care of within the day.
Diane reported to Sanjib that the pilot was going fine and the customers are ecstatic about the service. She managed to secure another budget to build a small operations team to support the solution and the customers.
As “temporary” solutions go, a business was growing around this offering. More customers were added, as word-of-mouth spread on the first-class service they were getting. Curt, now Director of SaaS Operations, was eager to add more clients as the concept was proving to be a successful one, though not quite yet profitable. The future looked sweet.
To be continued...
BizEye Technologies, the well-recognized leader in enterprise Business Intelligence software, has been considering developing an on-demand version of its application. Software-as-a-service is recognized as the latest and most disruptive industry trend; BizEye feared that if they were not involved in its adoption, they could become irrelevant.
Diane, the VP Product Marketing took a special interest in this new area, especially after many customers started inquiring about a SaaS offering by BizEye. After reading a number of articles and attending two conferences, Diane became a champion of SaaS within the company and assigned Curt, Director of Product Marketing to explore this opportunity and evaluate the marketplace and the costs & opportunities associated with developing the SaaS application. The initial evaluation looked good and Curt quickly became an advocate himself of the on-demand model. There were interested customers and a whole new market of SMBs to target. A simple calculation indicated that the operation will break even on the fifteenth customer.
Diane presented the business case to Sanjib, founder and CEO of BizEye. Snajib knew that sooner or later BizEye would need to face the question of SaaS. He therefore approved a small budget for an on-demand pilot project. Curt was assigned to lead this initiative. He assembled a task force of professionals from IT, Customer Service and R&D. They selected one of company’s products, the Analytics and Reporting tool, as a pilot project; a proof of concept.
As the software was not built on a multi-tenant architecture, and did not recognize a ‘Customer’ entity, the pilot was built as a dedicated architecture solution. This was not viewed as a problem, since there were only six customers that signed up, and it was a temporary solution anyway. The customers were extremely happy: Time-to-value was reduced from many months to a couple of weeks, and each customer was assigned a named account manager that was pouring love and attention on them. Every need was immediately handled, and all one had to do to add more users or tweak a report, was to call the account manager and the task was taken care of within the day.
Diane reported to Sanjib that the pilot was going fine and the customers are ecstatic about the service. She managed to secure another budget to build a small operations team to support the solution and the customers.
As “temporary” solutions go, a business was growing around this offering. More customers were added, as word-of-mouth spread on the first-class service they were getting. Curt, now Director of SaaS Operations, was eager to add more clients as the concept was proving to be a successful one, though not quite yet profitable. The future looked sweet.
To be continued...
Friday, July 14, 2006
SaaS and SOA
I have encountered numerous people that, when I mention Software-as-a-Service, they say “ah, yes, SOA”, at which point I go into a well rehearsed speech about what SaaS is, as a business model and how different it is from SOA, being a technology trend.
But are these concepts so far removed? Is there a reason why so many professionals confuse the two? So, giving it some thought I realized that there are many points of similarity and interaction between the two concepts.
First, both have been around for a long time. SOA has its roots in the term ‘Software Engineering’. We all know how far apart are the disciplines of writing software and assembling pieces of hardware, but that was the guiding principle. Object Oriented programming, arriving in the late 60’s, promised to change all that with the concept of component programming. Then came CORBA, which was supposed to do the same at the system level, but never really took off.
Software-as-a-Service has even older roots if you consider the Timesharing-Multitasking model that allowed running the same software from a mainframe, on multiple terminals, and all of its subsequent versions. And then, the ASP model which basically evaporated with the dot.com bust.
It seems now, that both concepts have arrived at a point of general acceptance. They just make sense, and the adoption rate is growing, albeit, implementing a good SOA solution is more an art than a science. I believe we will see a higher adoption rate of SaaS than SOA in the near future.
SOA is also a venue enabling SaaS. Many SaaS offerings are now using Web Services as a means to integrate with the backend legacy software and other vendor offerings.
SOA and SaaS are both disruptive (perhaps destructive) technologies. They are changing the way CIOs think about their businesses, and both serve to help IT manage their service easier and more cost effectively. And of course, both are generating a lot of hype.
But think of this: SOA is, after all, software as a service, albeit a different kind of software and a different kind of service. When we think of the Software in SaaS, it is a full, stand-alone application, whereas in SOA the chunks of code are smaller, performing a single business process. And of course the term Service is used differently; in SaaS it is referred to as a business service, not a system service, like in SOA.
Granularity is one of the arts needed to be mastered in SOA. One would like to write a service that is small enough to cater for all applications, but big enough to provide as much functionality as possible. Sounds like the similar dilemma one finds in SaaS; the old 20/80 rule. One would like to write an application with as much functionality as possible, but on the other hand it should be general enough to provide for all consumers.
Now, let’s fast-forward to the future and play the ‘Zoom-In/Zoom-Out” game. Imagine SaaS vendors writing chunks of code that are big enough to accommodate a business process but not a whole application. An example would be code validating a credit card purchase. These modules will provide an interface (standardized) to interact with other modules engineered by the same or different software vendors. Imagine the IT purchasing these modules and assembling their application in-house, from these Leggo service blocks.
These services could reside on-premise or at a service provider. It should not matter nor change the model.
In that perfect world, where SOA has become a reality in IT, the subject of ‘Build vs. Buy’ becomes a non-issue. The need for external applications, provided by ISVs is reduced significantly, whether installed on-premise or delivered as a service. When that happens, the whole ISV landscape will drastically change, and many of the software application vendors will either disappear or transition into providing the service widgets to be consumed by the enterprise.
And in that futuristic world, where software components from different vendors will talk to each other via a standard interface, elephants will be fluttering their butterfly wings on their way to the grand ballroom…
But are these concepts so far removed? Is there a reason why so many professionals confuse the two? So, giving it some thought I realized that there are many points of similarity and interaction between the two concepts.
First, both have been around for a long time. SOA has its roots in the term ‘Software Engineering’. We all know how far apart are the disciplines of writing software and assembling pieces of hardware, but that was the guiding principle. Object Oriented programming, arriving in the late 60’s, promised to change all that with the concept of component programming. Then came CORBA, which was supposed to do the same at the system level, but never really took off.
Software-as-a-Service has even older roots if you consider the Timesharing-Multitasking model that allowed running the same software from a mainframe, on multiple terminals, and all of its subsequent versions. And then, the ASP model which basically evaporated with the dot.com bust.
It seems now, that both concepts have arrived at a point of general acceptance. They just make sense, and the adoption rate is growing, albeit, implementing a good SOA solution is more an art than a science. I believe we will see a higher adoption rate of SaaS than SOA in the near future.
SOA is also a venue enabling SaaS. Many SaaS offerings are now using Web Services as a means to integrate with the backend legacy software and other vendor offerings.
SOA and SaaS are both disruptive (perhaps destructive) technologies. They are changing the way CIOs think about their businesses, and both serve to help IT manage their service easier and more cost effectively. And of course, both are generating a lot of hype.
But think of this: SOA is, after all, software as a service, albeit a different kind of software and a different kind of service. When we think of the Software in SaaS, it is a full, stand-alone application, whereas in SOA the chunks of code are smaller, performing a single business process. And of course the term Service is used differently; in SaaS it is referred to as a business service, not a system service, like in SOA.
Granularity is one of the arts needed to be mastered in SOA. One would like to write a service that is small enough to cater for all applications, but big enough to provide as much functionality as possible. Sounds like the similar dilemma one finds in SaaS; the old 20/80 rule. One would like to write an application with as much functionality as possible, but on the other hand it should be general enough to provide for all consumers.
Now, let’s fast-forward to the future and play the ‘Zoom-In/Zoom-Out” game. Imagine SaaS vendors writing chunks of code that are big enough to accommodate a business process but not a whole application. An example would be code validating a credit card purchase. These modules will provide an interface (standardized) to interact with other modules engineered by the same or different software vendors. Imagine the IT purchasing these modules and assembling their application in-house, from these Leggo service blocks.
These services could reside on-premise or at a service provider. It should not matter nor change the model.
In that perfect world, where SOA has become a reality in IT, the subject of ‘Build vs. Buy’ becomes a non-issue. The need for external applications, provided by ISVs is reduced significantly, whether installed on-premise or delivered as a service. When that happens, the whole ISV landscape will drastically change, and many of the software application vendors will either disappear or transition into providing the service widgets to be consumed by the enterprise.
And in that futuristic world, where software components from different vendors will talk to each other via a standard interface, elephants will be fluttering their butterfly wings on their way to the grand ballroom…
Sunday, July 02, 2006
Impact on the ISV Organization
“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” — Charles Darwin.
An ISV transitioning from the traditional, perpetual licensing model to the on-demand model is not simply adopting a new delivery mechanism; it is a paradigm shift that involves switching from selling a product to selling a service, and it will affect almost every silo in the company.
An enterprise software vendor that is ready for SaaS adoption is probably aware of a number of issues that have been getting a lot of attention in this space, namely:
· Technical – how to enable my software to be delivered as a service (read that as multi-tenant)
· Pricing – how do I switch from a perpetual model to a subscription one
· Operational – how do we support a 24x7 hosted environment
But do ISVs understand how switching to the SaaS model will affect almost every business unit of the organization? Are they aware of the potential pushback from different groups within the company that may make life difficult, if there is no commitment from all stakeholders to make it a success?
Following is an overview of the different silos in the organization and how they will be affected by the move. (short version of a paper I wrote)
Engineering
Not only will there be a need to modify (if not totally rewrite) the architecture, but there are a myriad of new service-ready features. Examples include:
Billing, Provisioning, Multi-level hierarchy and delegation, Service levels, Retention policy, Security, on-the fly configuration.
Engineers’ skill set may be lacking, requiring training/hiring.
Extreme programming may be required as software lifecycles are likely to shorten.
Quality Assurance
The QA practices that have so far included mostly functional testing will radically change, now that performance and high availability and end user experience will become paramount.
Testing expands from the QA lab to pre-production while different tools and skills are required and dev/test lifecycles shorten.
Operations
A new group is needed to ensure a smooth delivery of the service; responsible for the 24X7 uptime and availability. Consisting of account managers, systems, DBAs, and operations engineers, it will work closely with R&D, QA, IT, sales, professional and customer services.
Sales
The sales organization should be expecting substantial changes. This is an essay in itself, but suffice to say that switching from perpetual licenses to subscription and from a product to a service will change the rules of the game. There are two major factors.
1. The target market is now expanding to the SMB or the line of business.
2. In the recurring revenue model, the sales person cannot deploy a shoot-and-forget policy; rather the customer must be kept satisfied throughout the term of the engagement. This will also affect sales force compensation
On the other hand, sale cycles are likely to shorten, and cyber-sales will play an increasing role.
Customer Services
The CS group will need to switch to a true 24X7 mode. The knowledge set of the CSRs will need to be upgraded from set-up/configuration to domain level expertise and systems/application problem resolution.
User experienced must be positive to grow the subscription, therefore CS has a more important role than before, and perhaps higher skills (higher compensations) will be needed.
Finance
Revenue stream and revenue recognition will change dramatically with an effect on the company’s financial outlook. Financial systems capturing and forecasting deferred revenue will be needed. Billing will become more complex, dealing with metering, service level compensation and renewals and these new capabilities will need to integrate with the existing financial systems.
Professional Services
With the on-demand model, setup, installation and upgrades will no longer be the focus of PS. The post sales engineers will deliver application and domain-level expertise. Much of the traveling time and costs will be reduced.
Education services will drop part of the curriculum pertaining to installation and maintenance.
Changes are expected in yet other departments. I will just mention that Marketing, Legal, Compliance and Channels/Partners will be affected as well.
Summary
In conclusion, switching to the new model should be seen as a strategic move and not merely as a tactical one. Selling software as a service is not a delivery mode change, it should be viewed as a new business model, requiring a new skill set. An early awareness of the potential fault lines will reduce the shockwaves.
There is a need for an executive directive to seep through all the silos down to the lowest level of operation.
There is a need for an educational process across the company, and finally, there is a need for a fully committed taskforce that will include high level representatives from all business units to ensure that transition will be smooth.
An ISV transitioning from the traditional, perpetual licensing model to the on-demand model is not simply adopting a new delivery mechanism; it is a paradigm shift that involves switching from selling a product to selling a service, and it will affect almost every silo in the company.
An enterprise software vendor that is ready for SaaS adoption is probably aware of a number of issues that have been getting a lot of attention in this space, namely:
· Technical – how to enable my software to be delivered as a service (read that as multi-tenant)
· Pricing – how do I switch from a perpetual model to a subscription one
· Operational – how do we support a 24x7 hosted environment
But do ISVs understand how switching to the SaaS model will affect almost every business unit of the organization? Are they aware of the potential pushback from different groups within the company that may make life difficult, if there is no commitment from all stakeholders to make it a success?
Following is an overview of the different silos in the organization and how they will be affected by the move. (short version of a paper I wrote)
Engineering
Not only will there be a need to modify (if not totally rewrite) the architecture, but there are a myriad of new service-ready features. Examples include:
Billing, Provisioning, Multi-level hierarchy and delegation, Service levels, Retention policy, Security, on-the fly configuration.
Engineers’ skill set may be lacking, requiring training/hiring.
Extreme programming may be required as software lifecycles are likely to shorten.
Quality Assurance
The QA practices that have so far included mostly functional testing will radically change, now that performance and high availability and end user experience will become paramount.
Testing expands from the QA lab to pre-production while different tools and skills are required and dev/test lifecycles shorten.
Operations
A new group is needed to ensure a smooth delivery of the service; responsible for the 24X7 uptime and availability. Consisting of account managers, systems, DBAs, and operations engineers, it will work closely with R&D, QA, IT, sales, professional and customer services.
Sales
The sales organization should be expecting substantial changes. This is an essay in itself, but suffice to say that switching from perpetual licenses to subscription and from a product to a service will change the rules of the game. There are two major factors.
1. The target market is now expanding to the SMB or the line of business.
2. In the recurring revenue model, the sales person cannot deploy a shoot-and-forget policy; rather the customer must be kept satisfied throughout the term of the engagement. This will also affect sales force compensation
On the other hand, sale cycles are likely to shorten, and cyber-sales will play an increasing role.
Customer Services
The CS group will need to switch to a true 24X7 mode. The knowledge set of the CSRs will need to be upgraded from set-up/configuration to domain level expertise and systems/application problem resolution.
User experienced must be positive to grow the subscription, therefore CS has a more important role than before, and perhaps higher skills (higher compensations) will be needed.
Finance
Revenue stream and revenue recognition will change dramatically with an effect on the company’s financial outlook. Financial systems capturing and forecasting deferred revenue will be needed. Billing will become more complex, dealing with metering, service level compensation and renewals and these new capabilities will need to integrate with the existing financial systems.
Professional Services
With the on-demand model, setup, installation and upgrades will no longer be the focus of PS. The post sales engineers will deliver application and domain-level expertise. Much of the traveling time and costs will be reduced.
Education services will drop part of the curriculum pertaining to installation and maintenance.
Changes are expected in yet other departments. I will just mention that Marketing, Legal, Compliance and Channels/Partners will be affected as well.
Summary
In conclusion, switching to the new model should be seen as a strategic move and not merely as a tactical one. Selling software as a service is not a delivery mode change, it should be viewed as a new business model, requiring a new skill set. An early awareness of the potential fault lines will reduce the shockwaves.
There is a need for an executive directive to seep through all the silos down to the lowest level of operation.
There is a need for an educational process across the company, and finally, there is a need for a fully committed taskforce that will include high level representatives from all business units to ensure that transition will be smooth.
Saturday, July 01, 2006
Yet another Blog on SaaS
So why do I bother adding more clutter to the Internet?
I have been looking at publications on SaaS in the past six months and, although I found a lot of fascinating, eye opening articles, blogs and the such, I could not find perspectives that were similar to many of the thoughts I have swirling around my head.
Perhaps, this is indicative of an emerging market where for every 'worker bee' you are apt to find three 'consultant bees' that have much to say about anything, but there few people with hands-on experience of actually transitioning from the enterprise model to the on-demand offering.
I have met with quite a few ISVs in the past months in various stages of adoption and realized that many just don't get it. Many CEOs I spoke to were considering the move as a an unavoidable evil they would need to contend with at some point. Others understand that they will need to offer on-demand, but not just now ("call me at the end of the year").
I have found myself evangelizing a lot and I must say that it surprised me that after such a hype deluge, there is still need for an advertising campaign.
On a positive note, I met one company last week in the arena of publication and technical documentation management. The company has redefined itself as a SaaS provider, repalcing most of the C-level and their marketing and sales staff because they get it! It almost brought tears of joy to my eyes. They understand that switching to SaaS is not a tactical move but a strategic one. With their permission, perhaps I will report more about them in a future posting.
So, this blog is dedicated to all you enterprise ISVs out there. I hope to shed some light on the SaaS space, help out with tips on the business model, on the needed steps to achieve a profitable on-demand business and discuss operations considerations.
I have been looking at publications on SaaS in the past six months and, although I found a lot of fascinating, eye opening articles, blogs and the such, I could not find perspectives that were similar to many of the thoughts I have swirling around my head.
Perhaps, this is indicative of an emerging market where for every 'worker bee' you are apt to find three 'consultant bees' that have much to say about anything, but there few people with hands-on experience of actually transitioning from the enterprise model to the on-demand offering.
I have met with quite a few ISVs in the past months in various stages of adoption and realized that many just don't get it. Many CEOs I spoke to were considering the move as a an unavoidable evil they would need to contend with at some point. Others understand that they will need to offer on-demand, but not just now ("call me at the end of the year").
I have found myself evangelizing a lot and I must say that it surprised me that after such a hype deluge, there is still need for an advertising campaign.
On a positive note, I met one company last week in the arena of publication and technical documentation management. The company has redefined itself as a SaaS provider, repalcing most of the C-level and their marketing and sales staff because they get it! It almost brought tears of joy to my eyes. They understand that switching to SaaS is not a tactical move but a strategic one. With their permission, perhaps I will report more about them in a future posting.
So, this blog is dedicated to all you enterprise ISVs out there. I hope to shed some light on the SaaS space, help out with tips on the business model, on the needed steps to achieve a profitable on-demand business and discuss operations considerations.
Subscribe to:
Posts (Atom)