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...
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
Tuesday, July 25, 2006
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)