To be or not to be… in the Cloud. Examining the Motivation

“The undiscovered country from whose bourn no traveller returns” (William Shakespeare)

Yes, it is 2014 and there still are thousands of ISVs who are selling their software in the old, on-premise model.  Surely, many of them are doing quite well, with a large, happy customer base, which is paying for upgrades, new versions and the yearly 20% maintenance fees.
Nevertheless,  I doubt  there is even a single board of directors that is not considering going to the Cloud.
Everyone wants to be in the Cloud. Many ISVs have started offering their services as a Hosted solution (claiming that they provide SaaS) just to have a presence there, and have added a little cloud to their logos or landing page to enhance that impression.

The Motivation
I have been advising ISVs for over a decade on their move to the Cloud (or SaaS as we old-timers still call it).  It is surprising though, how many of the companies I consulted to couldn't articulate why they were doing it.
I always begin with a Motivation session where the C-level staff is gathered to discuss what their thoughts on the matter are, and I find out, time after time, that there is no consensus on this matter.
Since the transition from a Product company to a Service company is so profound, the paradigm change so deep and the costs are not trivial (sometimes they could bring a company to its knees), it is crucial to understand why  the ISV is willing to set on this adventure.
The discussion below outlines the various reasons why an ISV should invest in this process.

Everyone is in the Cloud
Yes, it is fashionable, and I don’t belittle this motivation.  Sometimes a company must have a presence in the Cloud for marketing purposes, just because it is expected and the company brands itself as a forward looking endeavor.  But is this a good enough reason ? I would look into the next items to try to justify the move which is by no means a simple one.

The employees are demanding it
As flimsy as it may sound, this is not dissimilar to the previous motivation. The workforce is getting younger (in age and in mentality). Employees who think that the company is not ‘with it’ might start looking elsewhere, to companies that are more on the bleeding edge of the technology and market. Although this should not be a major consideration, it still is a consideration and might tip the balance toward a decision.

The competition is offering it
As we all know, SaaS solutions are very attractive from many perspectives. If there are a number of new, pure-play SaaS companies that are starting to bite into your customer base, this is a serious consideration. But, it should not be the only consideration; one must examine and compare exactly what the competition is offering. Many times, SaaS companies will offer a small subset, or an over-simplified solution of what your product does. If the competition is up-to-par in most aspects of your solution, you may already be fighting a retreating battle. If not, it is possible that you may lose the smaller customers but could still have an advantage in the larger companies. If this is the case, you should consider the transition to SaaS, while maintaining your advantage, rather than compete with the smaller players.

Your customers are demanding it
That is a very compelling argument. No one knows better that your own customers. If customers are requesting an Cloud solution, the company should listen carefully. Still, it is important to engage with the customers and understand exactly what it is they are looking for in a SaaS solution. Perhaps it is the recurring payment option – that could be done with an on-premise solution as well. Perhaps they are looking for certain features. Maybe it would make sense to offer new options in an integrated version, rather than rewrite the whole application from start.

You want to expand into a new customer base
Often times, the SaaS option will allow a company to reach out into a large customer base that was below the radar because of price or complexity.  While you were selling to the high end customers, there might be a vast group of smaller businesses that could benefit from your solution, but were always out of reach. If this is the great motivator, one should carefully examine what should be offered. Is it the same set of features? Is it a light weight version, or a subset? Are your potential, future SaaS customers different from your existing customer base, not only in size but in their needs ?

You want to expand into new territories
One of the advantages of SaaS is “Anytime-Anywhere”. While the old model necessitated local presence for sales and professional services, the SaaS model will allow the company to sell around the globe without the need to have ‘boots on the ground’.  If your local market is saturated, SaaS is a great venue to reach out to the other side of the globe without the expensive and complex logistics it used to take to make that happen. Here again, it is important to articulate what will you be to selling the customers in the geographies; not necessarily the same as the local offering.

To be – Of course
The discussion above does not suggest that after examining the motivation, one would conclude NOT to offer a Cloud solution. Of course every ISV will have to be there sooner or later, otherwise it will become obsolete. But going through this thinking exercise will allow you to define your approach. Understanding the motivation will help identify the target market, the go-to-market approach, the timing and the offering itself.

As an example:  A large British ISV I worked with, wanted to switch to SaaS by taking its flagship product to the Cloud. After going through the process we came to the conclusion that their product was a cash cow for the foreseeable future, and there was no reason to dive into such a large undertaking at this stage. Instead, the decision was to develop a LITE solution to offer to different customer types in new geographies. This allowed the ISV to experiment with a less demanding task, while learning the ropes of the new architecture and new market approach. I am happy to say that they are launching their SaaS solution these days in two new territories.

SaaS Customer Success – Best Practices (Part 2)

“There are two rules for success:
1. Never tell everything that you know”     (Roger H. Lincoln)

Company Culture and Customer Success
In my previous post, I discussed perspectives that dealt with the technical and formal issues of improving customer success. It suffices to remember one fact – companies are more successful when their customers are more successful. In this article I will talk about a crucial facet of SaaS: company culture - that not only affects Customer Success, but many other aspects of running a successful SaaS operation.
(I have written about Culture in a number of articles in the past – some posts are pointed out)

Multiple Touch Points
In the on-premise business model, the touch points with the customer moved slowly from one part of the organization to another: Sales and Pre-sales were engaged with the customer at the beginning; then Professional Services engaged with the customer until implementation was complete. Following that stage, the ISV did not interact much with the customer. There may have been a yearly status call; sometimes the customer inquired about bugs or perhaps sent a request for features that was pushed into a waiting list. (The product may even have been sold through a VAR, leading to an even larger disconnect).

In the SaaS model, at any given moment there could be multiple touch points with the customer: The end users may be speaking with Support, while the customer IT is talking with the Ops group; the customer business manager is engaged in a call with Sales, while the CIO is speaking with the SaaS CEO about the latest outage, and Finance on both sides are figuring out last month’s bill. Some SaaS companies assign Technical Account Managers to large customers, but that would not alleviate the problem if end users continue calling Support, or IT happens to be talking with the network manager in the Ops group. In any case, TAMs are only assigned to a few, large enterprise customers and this will not work out if the company has hundreds or thousands of active customers.  
Mapping the touch points of the customer is therefore essential, and making sure that everyone who might have contact with the customer is using the CRM (or equivalent - I know, it is not cheap).

Need for Speed
Everything switches to Fast-Forward in SaaS. The sales cycles are shortened by at least an order of magnitude. The release cycles are shorter through agile methodologies and DevOps technologies; the impact of bugs is immediate (the new version is released at night and the following morning thousands of users interact with the software) and the response from the customers is almost instantaneous. Customers expect a fast turnaround and Information about success or failure travels as fast as the latest Tweet. Numerous customers may be added in a single day through self-service, or might churn at the end of the month.

Therefore, SaaS companies must shift into high gear. Especially if they come from the old, legacy, on-premise world, where the staff is used to much longer cycles in every aspect (I have been giving seminars at these old-world companies to emphasize that fact and push for cultural change). Quickness of response, of decision making, and pro-activity result from the elements discussed below: Transparency, Communications, and Openness.

Transparency
I have written in the past about Transparency and it is still a valid article. I do not wish to recycle old material but suffice to say that customers will not only appreciate the openness and honesty as a virtue; they can also benefit from the knowledge while helping your company improve. When service is down, or slow, or erroneous, covering it up will not make your customers feel more confident. If you discuss the issues with them (s**t happens, you know,) you may work out together how to deal with service degradation in the future; that will help them become more successful.

When you promise a certain feature that you know will not be delivered on time or as expected, you may gain a few weeks of industrial peace, but that will clearly not make your customers more successful. If, instead, you openly share the status of your release, your customers would be better prepared. Working together, you may formulate an alternative solution that will allow the customer to succeed while reinforcing the ties between the companies.

Communications and Openness
The fact that almost anybody in the company might be in touch with someone on the customer’s end and that everything has sped up means that inter-department communications is crucial and internal transparency is a must. There is not time for ego games, or gaining an edge by holding important information close to one’s chest.
Transparency within the company is crucial (there usually is a correlation between external and internal transparency). If you promote a culture of openness and acceptance of mistakes, problems will be reported earlier and be dealt with the maximum available information, therefore reducing their negative impact. Both the company and its customers will benefit.
(Recommendations for periodic meetings can be found in my article on Inter Department Communications)

Service Level Agreements
The Support staff usually take the first hit when bad things happen, but every employee must understand the impact of service degradation. Make sure people empathize with what it is like not to be able to complete the task that the end user is evaluated on.
SLAs are usually regarded as a necessary evil, forced upon the SaaS provider by a standard expectation in the market, and is usually reduced to the minimal accepted level. (read more about SaaS SLAs).
But, imagine a company that takes it SLAs seriously, that thinks about the Service Levels that it provides its customers and that is proud of what it can offer to the end users and is open about it.
Imagine that someone within that company actually read the SLA and thinks about how to improve the Service Levels, not only the dead horse of the Availability section. Imagine what that might do to enhancing customer success!

A Point about Priorities
Some companies emphasize that the ‘Customer is Always right’ and keeping the customer satisfied is the top priority of the establishment. With other companies, making the shareholders happy is the major driving force.

The following observation is based on my subjective experience and understanding and has no scientific or statistic corroboration:
If you manage to make your Employees Proud, Dedicated and Happy, they will make your Customers Paying, Loyal and Happy, which will make your Shareholders Fat, Supportive and Happy.

This is why company culture is so crucial. Getting people excited and unified behind a common goal of excellence and customer success will result in Excellence and Customer Success.

SaaS Customer Success – Best Practices (part 1)

 “The only place where success comes before work is in a dictionary” (Vidal Sassoon)

Nostalgia
In 2003 I was managing the operations of Mercury Managed Services (today, HP SaaS). A large Mercury customer was about to give up on the product as he could not manage the complex in-house requirements, and was suffering from too much downtime. The capable account manager convinced the customer to switch to the SaaS model for a higher (!) price than what they were originally paying.
After a complex migration project the customer switched over and in the first week of the service we noticed a problem with the migrated data causing errors in the process. I called the application manager and apologized that we needed to take down the service for two hours until we fixed the problem (We abhorred the idea of more than a few minutes of downtime). The guy was ecstatic, happy as a puppy with two tails. I cautiously inquired why he was so pleased when I informed him of the service being unavailable. He told me that in the old model, no one would notice there was a problem, and when IT was notified of the issue it would take them two days to respond and a week to fix, and here we knew of the problem in real-time and service will be restored within two hours!
Obviously, customer satisfaction is a matter of expectations; within a few months this particular one got used to high availability and started complaining of less than outstanding response times.

So then, customer success is a combination of real value, of perceived value and TLC – Tender Loving Care.

Do it right the first time
As I have written in a previous post, the cost of acquiring new customers is between five to seven times more expensive compared to retaining existing customers, yet most SaaS CEOs/VP Sales are focused on new customers, optimistically hoping that ‘once a customer always a customer’.  
From a recent poll conducted by Totango it is evident that the fastest growing SaaS companies “…have a significantly better record on churn and upsell, underscoring the critical role of managing revenue from existing customers…”. In other words, being successful in the SaaS model means that you have to make your customers successful.
Bellow, I provide a list of best practices that a SaaS company should follow to improve Customer Success; of which Customer Satisfaction is a crucial but not sufficient factor.

Real Value – Perceived Value
Let’s start with something as trivial as bringing value to the customer. Obviously your service/product has to provide an advantage to the business that was not there previously, but many times the users may not be even aware of the real value. If the end user is coerced by her boss to use a certain business process without her seeing the value in it, it is not going to fly. Or, if the service was procured by a business manager that wanted a simple function that was not available or affordable prior, it could be that the users are not even aware of the full range of functionality (‘value’) of the offering.
Therefore it is crucial that the SaaS company be aware of the reasons why people are using (not using) the service, what their expectations are and how they perceive the value. This can only be done through engaging the end-user, not just the business entity that is paying for the service.
Which is a perfect segue into the next item…

Customer engagement
Remember the ‘good’ old days where R&D defined the product, the needs and the functionality? We’ve come a long way since, with Product Marketing defining the offering and releases; still, it is not clear how much real feedback is being collected and integrated into the roadmap.
How do you know what makes your customers successful? Ask them. Direct calls, forums, surveys, any means available to you. Involve the customer in the process. Ask for feedback on the product, workflows, and features. The end users typically would love to voice their opinion, to know that what they think is important.
The best venue for this kind of engagement is building a community around your service. Whether using a LinkedIn or FaceBook group or building your own community page in the corporate site. Create forums, discussion groups, a Q&A/FAQ section, an expert panel and blogs. This serves both as an invaluable source of knowledge into your customer’s deepest desires but also enhances loyalty. Consider gamification to promote participation in the community.

Branding
The community engagement is highly important for building your Brand Name. You want people to remember your name, and in a positive way. Twitter, FaceBook and other social media will kill you as easily as promote you. You must be aware of what is being discussed, chatted or Tweeted about you on any network and try to engage angry users and deal with their issues, real or imaginary.

Tell them they are successful
If you, as the service provider, know what brings the customer value, make sure they know it as well and can gauge it. Provide ‘success’ reports and ‘success’ dashboards as part of your product offering. Whatever metrics that you can define as gauging success, let them know how your service improves it, every time they use your software.

Know what is going on
“If you can’t measure you can’t improve”. There are two areas in which you must make sure you know what is going on. The first is Churn Management. You should be able to collect every bit of information on why customers left you, after how long, how big were they (revenue and company size), who was responsible for the engagement, etc. Only by analyzing, trending and reviewing this data will you be able to predict future behavior, identify telltale signs and reduce your churn.
The other area is how your product is being used by your customers. You could analyze log files and perhaps fields in your web pages, or use ready-made solutions such as Totango. Totango’s analytics and reports allow you to identify behavior indicating loss of interest, or patterns leading to disengagement. In addition, they can show you which components of the service are being used by whom, and when (e.g. EOD, Weekends), and which paths are abandoned in the midst of the flow. This can all be fed back to Product Management to improve the service and the experience, and therefore the customer’s success.

Integration
While your solution may be the best thing since sliced bread, your users do not live and work in a vacuum. There have been business processes in your client’s organization and other SaaS and onsite software in place long before you came into the picture. You must make sure that your SaaS application blends seamlessly into your user’s working day. This means allowing them to import or export data and tasks to the other applications they are already using the run their business and smoothly switching between applications (through SSO). SaaS entrepreneurs tend to focus so much on building a great application that they sometimes forget that true success occurs when you users start to see you not as an application but as a platform. Integrations are one of the ways to become a platform.

Having a good base of integrations also makes your customers decision to buy & use your product a much easier one. There is a wide variety of integration consulting companies and integration and SSO SaaS solutions out there. There is also a new breed of companies like Bondable which enable SaaS businesses to build integrations with other SaaS businesses, without having to constantly maintain these integrations.

Keep in mind that the more you are integrated with other services, the more ‘stickiness’ it adds to your solution and the more difficult it becomes to disengage.

Culture
In the next post I will talk about company culture and its direct impact on customer success. It is important enough to merit a standalone post.

STORM™ For Dummies (part two)

This is the second part of my previous post.
 
Communication Management

Back in the days of shrink-wrapped software, the ISV usually had a single touch point with the customer, i.e. IT. All issues on the customer’s end were addressed by their IT department, and what they could not resolve would find its way to Support (sometimes, months later). 

But with SaaS this is no longer the case. The customer CIO may have a direct line to the SaaS CEO. IT may be in touch with professional services, and customer business managers could be speaking with the Program Management group. The Ops group will inevitably be in touch with supervisors or IT managers on the customer side, and Sales will have developed personal relationships with managers on the customer’s side, as they nurture the relationship to expand the sales in-house. And, of course, the end users might be in daily contact with Customer Support.

If all these functions within the SaaS company do not talk to each other, if they do not share the info about the customers, there is potential for embarrassing situations that lower customer confidence and loyalty.  E.g. imagine a Sales rep calling the customer to up-sell a service, and that customer informs the rep that the service is down right now and that he might consider switching to the competition.

The Ops group is the hub of all the service activity. It deals with R&D, QA, Professional Services, Customer Support, Sales, the Customers and the Service Providers. It should initiate and manage daily, weekly, bi-weekly, monthly and quarterly meetings with the various functions and provide communication channels with the end users and the customer’s managers. 

Communication with customers takes many shapes and forms. It can be via email, phone calls, quarterly meetings, an RFO, notifications on the application message board or via the Status Page web site.

You won’t find ‘Communication Management’ in any ITIL/ITSM vocabulary, but the importance of it cannot be overestimated.

Release Management – um, DevOps?

So, we want to upgrade to the newest features or bug fixes. In today’s very complex environments, with multiple configurations, possibly geographically distributed, some on real servers, some on virtual ones, the management of a release update could be a grueling task. This is where automation becomes crucial. This is a growing discipline with many cool products and tools, making strong use of virtualization. 

Although it has become the norm in the industry that DevOps is all about configuration automation scripts, I would argue that DevOps is nine parts communication, one part automation, 

I claim that between Change and Asset Management, with agile development and Continuous Delivery, Release Management is not much of a discipline of itself, but part of the orchestration and conversation between Product, Engineering, QA and Operations.

Operations Intelligence - OI

There are other aspects of STORM™ that are not covered in this short article (e.g. Churn Management,  Cost Management, Service Continuity, Team Building, Product Serviceability), but a crucial derivative of a good STORM solution is Operations Intelligence.

Collecting and compiling all the reports of the STORM practices in a repository allows the management of the SaaS vendor to gain insight into the Operation of the company, assess progress and plan for next steps to improve the overall Service Operations of the provider.

The executive team must be able to answer questions such as:

•  How are we really doing vis-a-vis our SLAs?
• How long since our last downtime?
• What do we invest our next dollar in?
• What are the main causes of our customer churn?
• How many changes have succeeded, failed, rolled-back?
• Which components are most troublesome?
• What customers might be affected by changes to this particular asset?
• How are our TOP 10 customers fairing?
• Are we improving with our incident management?
• How do the last twelve trailing months look like?

The ability to gain insight into the various aspects of the Service Operations allows to plan more sensibly, focus efforts and resources where needed and improve the clockwork, therefore improving customer satisfaction and loyalty

The Dummies

The title “STORM™ for Dummies”, is not just a marketing play on the ‘X for Dummies’ series – there is a philosophy behind it as well. Software developers are bright, creative, out-of-the-box thinkers that may disregard the rules in search of a better solution. Smart, creative people do not necessarily make a good operations team.

Service Operations is a routine, day-to-day, unimaginative process. You want to have the best people at your disposal and to have them respond in creative ways to unexpected events. But, you want to reduce the unexpected events to a minimum and make sure you cover all bases. And when an unexpected event does occur, you want to make sure that lessons have been learned, so that next time it will become part of the routine.

The Dummies will benefit from the fact that all they have to do is follow a rigorous routine, so they can go home, have a beer and play with their kids instead of staying around late and figuring out creative ways to deal with the current crisis (now tell me, who is the dummy?).

STORM™ For Dummies

This is the first of a two-post article. As I promised in my previous post, Taking the Cloud by STORM™, I will elaborate here on the various practices.

Change Management
Curiosity killed the cat? Change is what killed the cat – I’m talking about Schrodinger’s cat, and if you don’t know what I’m referring to, just keep in mind that a tiny change in a subatomic particle is what caused the cat’s permanent downtime.
In a broad sense, Change is what causes all service degradation, whether full downtime or bad response times. In other words, “if it ain’t broke, don’t fix it”. But changes are always needed in your SaaS environment, whether adding another web server to the load balancer, changing a configuration file or upgrading the software overnight. Add to that the fascinating fact that between 60%-70% of service disruption is caused by the human factor.
So, Change must be done very carefully. There are so many things that can go wrong, that one needs a disciplined routine that takes as many factors into consideration as possible, and done in a rigorous manner, following precise instructions. It includes the Change Request, the Change Calendar and Window, the CAB, the Operations Maintenance Plan, the SOPs and the Change recording. This is what Change Management is all about.
 In my many years in the field of SaaS Service Operations I have witnessed all the possible horror scenarios at SaaS companies where Change Management was at best very meager, and usually nonexistent.

Asset Management
Changes are done to Assets. An Asset could be as large as a datacenter (new router that affects all boxes), it could be a database cluster (upgrade of the Oracle RAC) or as small as a JPEG file embedded in an HTML document. In an ideal world, a SaaS company would deploy a CMDB (Configuration Management Database) with a team of administrators that do nothing but maintain it. But in the real world, as SaaS companies grow from two to four to ten boxes and beyond, the assets are maintained, in a best case scenario, on an excel  worksheet on the sys-admin’s laptop.
When a change is performed on an asset there is a need to understand the possible impact on other assets, or on customers, and it needs to be documented. An Asset Management solution records each asset with relevant information (name, IP address, location, function, make etc.), records the relationship to other assets and maps that asset to a customer (or group of customers). When change is performed to an asset, the Change Management system will point to the relevant asset and record the history of modifications to that asset.

Event Management
With the understanding that changes to assets cause bad vibes, we need to look out for changes and understand their effects. That is done mainly by monitoring and responding to reported changes. Look at as many attributes of your assets and detect when things have changed. High CPU, low disk space, an OS service that has stopped functioning, long response times, etc. But detecting the change is not enough; how do you respond to the changes, when do you determine that a change is cause for trouble? How much automation should you employ? (short answer: a lot). What do you do when a threshold is reached? How do you control Alert Overloading? How do you build Escalation into the alert mechanism?  This is what Event Management deals with.

Incident Management
OK, so you are now practicing a robust Change Management regime, with all your Assets accounted for and monitored with a good understanding of impact of changes to your service. You are in much better state than before, but will service disruptions still happen? Of course they will! They will bite you when and where you least expect them to. What to do! What to do?
One option is running around hysterically screaming “the sky is falling” and shooting in all directions, while making sure you cover your behind in anticipation of the blame game that will surely take place after the crisis is over.
Another option is to implement Incident Management. IM covers all aspects from Detection, through Recording, Classification, Notification, Escalation, Diagnosis, Resolution, to Closure. All in a cool headed manner, following a well trained routine that will allow the company to analyze the incident and apply lessons learned so that you will not face this particular crisis again.

SLA Management
And then, some (or all) of you customers will require that you adhere to your SLA; but who knows if it was breached? Sometimes it is very clear- the system was down for an hour - everybody was affected and the SLAs were breached. But many times, it could be degradation of the service, or partial downtime. Who knows which customer was affected by what and for how long? This is where SLA Management comes in, and why it is so important to have Incident Management in place, so that one can compare the actual damage with the particular SLA. The other option is going through a bunch of printed documents (if you can even find them), trying to figure out for each customer what their agreement covered, and if it was breached, should they be compensated and how much.



In the next post I will discuss Communication Management, Release Management (DevOps), Operations Intelligence and The Dummies.

Taking the Cloud by STORM™

STORM™ - SaaS Tactical Operations Resource Management

Like an experienced and greasy auto mechanic, there is not a single mistake that I have not done (or witnessed) throughout my years as managing Operations from Fortune 500 companies to startups.  I have learned from my experience and painstakingly put together a set of practices that dramatically improve the quality of life for the whole team and the satisfaction level of the customers. IT JUST WORKS! There is no reason for a SaaS company to improve only after making mistakes that have previously been made by others.

Extraordinary people, great products, domain knowledge, specialization and wonderful intentions are the ingredients that bring and make success; yet sloppy SaaS service operations management will break that success.
SaaS companies always end up paying a heavy price for doing something they do not excel in – Service Operations.

STORM™ - SaaS Tactical Operations Resource Management, is a comprehensive methodology for managing the Service Operations of a SaaS Company. It includes a set of practices that have been defined over years of building Operations at SaaS companies and consulting to SaaS companies on excellence in Service Operations.

SaaS – While using ITIL terminology, STORM is not for general IT. Nor is it for any general service provider. The Methodology was devised specifically for the unique needs and characteristics of SaaS companies.

Tactical – Other methodologies offer high-level frameworks. STORM defines how to handle every aspect of the Service Operations, providing workflows, reports and templates and defining tools, so that a SaaS company could very quickly adopt these practices and put them to use.

Operations – the hub around which all the service revolves, in a SaaS company. Connecting Engineering, QA, PS, Sales, Finance and Customer Service.

Resource – Dealing with all the assets of the service – Px4 (People, Programs, Practices and Property)

Management – comprehensive methodology giving management visibility and decision making tools

STORM Principles
At the highest level, STORM  deals with three notions:
1.    Enabling a smooth, efficient and effective day-to-day management of the Service Operation:
 While dramatically reducing the human error factor, the smooth operation ensures that although the service is up 24X7, the staff can enjoy a good night's sleep and weekends with their families.
2.    Allowing management to view, control  and understand the components the Service Operation:
 Keeps the decision makers on their toes and provides them with the visibility of the status of various parts that make up the service.
3.    Provide a better customer experience:
Thus keeping your customers happy, growing the revenue and reducing churn

STORM Practices
The methodology contains a number of crucial practices that cover every aspect of the service operations of a SaaS company. These are (mostly using ITIL parlance):

• Asset Management
• Change Management
• Incident Management
• Event Management
• Release Management (as part of DevOps)
• SLA Management
• Churn Management
• Costs Management
• Communication Management

SaaS Operations Intelligence
A central component of STORM is SaaS Operations Intelligence, or SOI.
Through a smart collection of data from the various practices (which require tools to collect that data), reports are produced to derive crucial strategic insights of the Service Operation and enhance decision making as to what may be lacking in the service and where to invest the next dollar.

Samples of these reports are:

• Change Analysis
• Incident Analysis
• SLA Analysis
• Churn Analysis
• Customer / Asset Mapping
• Impact Analysis
• Costs Analysis

Why  STORM?
ITIL or eTOM (Enhanced Telecom Operations Map) just don’t cut it for SaaS. There are too many unique characteristics of a SaaS operation that are not being addressed by existing methodologies. (I will explore this theme in a future article).
Throughout the years I have written extensively on SaaS Service Operations.

• Most SaaS companies that I have worked at and consulted to, have similar traits and are suffering from the same problems (see Your Typical SaaS Operations).
• Most SaaS companies have a problem with Operational discipline and are suffering from Operational Fatigue (see Discipline (or lack thereof) and Operational Fatigue).
• Most SaaS companies are not doing a good job managing their SLAs (see SLA Management for SaaS).
• Most SaaS executives cannot answer basic questions about their service since they do not collect the metrics (see Questions that SaaS executives must be able to answer - KPIs that matter).
• In many companies Change Management is akin to wishful thinking and usually results in disastrous events. (see Change Management and the Sanctity of Production).
• I have seen (and worked at) SaaS companies that do not exchange critical information in real time thus causing inefficiency and embarrassment (see Inter Department Communications).
• Fast growth is a blessing but SaaS companies break at the seams on scalability issues (see 2 x E-cube = S-cube - Simple math for SaaS Scalability Success and SaaS, Scalability and the Three Little Pigs).

A methodology that is addressed specifically at SaaS companies, dealing with real issues that plague most SaaS companies is needed.
The STORM methodology has been successfully fully or partially implemented at SaaS companies and has delivered immediate results.

STORM Automation
STORM methodology contains practices that can be implemented using simple tools (I have employed MS-Word, Excel, Google Calendar, some scripting, HTML and Bugzilla).
However, STORM’s full value is realized when it is supported by automated workflows, data entry forms and data bases. The SOI component is very hard to realize without an SQL database, tools capturing the data and report generators.
Still, a great value can be derived just from following the practices in a disciplined manner, using productivity tool templates and simple repositories.

In the next article I will expand on the various practices and in future ones I will differentiate it from ITIL (and somewhat, from eTOM), and layout the basic principles.

Bring Ops back into DevOps

“Ownership is yet another of the endless forms of arrogance engaged in by the lower self.”
― Bryant McGill

Two items caught my attention in the past week.
One was an invitation for a DevOps event in Tel Aviv. Lots of flair, keynote speakers, demos, you name it. On the bottom, underlined, it was written “registration for developers only”.
What? Really?

A few days later I saw a recruitment ad for Director of Operations for an upcoming SaaS company, in Silicon Valley, no less. “… the Director of Operations will report to the VP of Engineering”.
I even read an article (don’t remember where – I should have bookmarked it) that DevOps is great since it returns control over production to Engineering, like in “the good old days”.

It felt like a trip in a time machine that landed me in the early 2000s.

Looking up DevOps  in a Google search, it is all about configuration automation for Release Management, scripting languages as Ruby, courses for developers  and such. No wonder Engineering feels so much at home.

When I took my first job as VP Service Operations in a SaaS company, I had to wrestle Production out of the hands of Engineering. I had to change the passwords to the production servers and wean the developers off the habit of changing the environment when they had a ‘safe and quick’ fix. They went home to their families in the evening. They were not on the 24x7 call list.
It took some time for the VP Engineering to come to terms with the new reality; imagine having to report to him while doing the job.

And yes, we used configuration automation scripts even back then, but they lacked the aura of ‘DevOps’. It was all about discipline, Change Management, Asset Management and careful planning, as covered in my previous post.

Chef, Puppet, Docker and the other mechanics are great tools, but they should enhance DevOps, not replace it. The first principle of DevOps is a culture of collaboration / cooperation / communication. Making the Ops team feel like an outsider is not going to help.

At the end of the day, Ops is left with task of keeping the light on, responding to outages 24x7, and taking the rap for service degradation.

So, just as SaaS is more about the Service than the Software, so is DevOps about the Operations more than Development.

Let the cowboys do what cowboys do best, and bring the ranchers back into the farm.

Hey developers – you’re missing the point of DevOps

DevOps and SaaS Service Ops

“Besides black art, there is only automation and mechanization” - Federico García Lorca

DevOps is not just Automated Configuration
If you Google “DevOps”, it seems synonymous with automated configuration tools. Almost everywhere DevOps is driven by the Development team, not the Operations team. While these tools are an important means of achieving Continuous Integration, Continuous Deployment and Continuous Delivery, and they provide a higher level of software quality that gets delivered to the production environment; they do not ensure the other 90% of the DevOps principles.

DevOps is all about breaking barriers, mutual respect, inter department communications, building operations-able software and working as one team with a common goal. In the world of corporate IT, this sounds almost as fictional as “they lived happily ever after” but in the world of SaaS it is a do-or-die principle.

DevOps tries to bridge between the maverick, out-of-the-box, change-or-die attitude of the Development team and the conservative, no-change policy, if-it-ain’t-broke-don’t-fix-it approach of the Operations team. (see also)

DevOps is not a new thing, just a new term. I have been practicing it since 2000 when I was hired by Mercury Managed Services (MMS) to build their US operations group
(As an aside, MMS, now the “HP-SaaS” division following the acquisition of Mercury by HP, was one of the largest SaaS providers at the time, if not the biggest. It was selling around $100M worth of ‘hosted/managed/multi-tenant’ services annually [2004], quietly, without the noise that SFDC was generating at the time)
Back then it meant a highly collaborative effort between R&D and Ops, and a respect by Engineering for the operations team, their practices and the automated tools they developed.
These principles were further forged when I became VP Service Ops in Contactual and then Transera Communications (both SaaS companies in the call center arena) where downtime and degradation of service were devastating for the business.

The DevOps Components
I have written enough about the various aspects of SaaS Service Operations and I don’t intend to repeat it in this post, but I would like to point out the aspects that relate to DevOps

• Communications & respect

Engineering, remember: You have a single customer, and that is the Operations group, so start treating Ops as you would treat a customer; listen to their needs and requests. Schedule a bi-weekly meeting between R&D and Ops at the highest level and discuss issues and plans. Have QA and Support represented as well.
An important aspect of the success of a functioning DevOps undertaking is to build the initial and leading members of the Ops team Ops team from ex software engineers who can speak with R&D at eye level. This will ensure simpler communications and the needed respect from the developers. (see also)

• Configuration Management and Virtualization

Automation is one of the important principles of a smooth SaaS operation, in order to reduce human error, which is the number one cause of downtime. And replicating environments is a crucial factor to ensure that code that was running smoothly in Dev, in Testing, in Staging will run the same in Production.
So, yes, one does need the virtual servers and the configuration automation tools. There are many of those and different developers swear by their favorite tools. Capistrano, CFEngine, Chef, Puppet, Vagrant, Docker, to name a few, all play an important role in ensuring a smooth transition between environments and reduce human error.
But guess what – things still break down in the production environment, and when that happens, the Operations guys are driving the process and managing the crisis, not the über smart R&D guys.

• Sanctity of the production and Change Management

Developers - Lay off! You have no business nor privileges to get near Production. Respect the sanctity of it and respect the Ops teams when they call the shots.
Perhaps the most important aspect of all practices – if you ensure a robust CM process, the probability of downtime diminishes substantially and the recovery should be fast. The development team has to partake in CM. (see also)

• Incident Management

Without detailing the practice, Engineering must be an integral part of the response team, and should have a representative in the real or virtual 'war room'.

• Product features and architecture

Perhaps it is obvious these days that a SaaS product must be built as a highly available and scalable system. And perhaps automatic on-boarding of customers is supported. But what about the other operational-ready features that always get pushed back in favor of the user driven product requests? The list is long, but features should include Instrumentation, Self-serve, De-provisioning Ops-Console, Billing, Dashboards, Customer Notification, Retention policy and Data migration to name a few. (see also)

To conclude, the principles of DevOps should be driving the success of delivering a useful service to the company’s customers, and they are Automation, Communications and Respect.

IT and the Cloud – the 'Value Paradox'

Cloud influence on IT activity and the changing role of the IT manager.

On Paradox - “If you try to fail, and succeed, which have you done?”  ― George Carlin

I know what IT did last summer 
Since the advent of packaged software , IT staff spent a great deal of their time making software available to their internal customers.  What did that entail?

• Comparing optional vendors and offering
• Procurement – negotiating and finally purchasing the software
• Designing and customizing the solution
• Securing the hardware and installing the software – sometimes this would take months to purchase and install the servers, operating systems and the software.
• Testing the environment and the software
• Deployment and training
• Maintenance – expanding resources, upgrades, etc.

All this work revolved just around ‘keeping the lights on’, and IT was usually understaffed with tasks continually piling up.

While it was crucial to have the software up and running',  IT could not devote the necessary attention to derive more value from the application, because just making the application available exhausted what little time and resources IT had at the end of the day.

Shift of Focus
In the world of SaaS - Cloud applications – many of these tasks are becoming extinct.

Procurement is done in many organizations by the business manager, and even if IT is involved, the decision is usually made by the Line of Business manager.

Securing and installing hardware is no longer needed, and neither is installing the software and testing it.

Maintenance is usually non-existent or negligible as well as deployment.

Training is also downshifted as most SaaS applications are designed for simplicity and intuitiveness.

In the Age of Cloud, IT is shifting from Managing Software to Managing Applications - As SaaS applications take a larger share of the companies’ portfolio , IT will have less “traditional” tasks, and therefore more time to concentrate on bringing value to the business.

What value would that be?

• Performance – a better end-user-experience, understanding when and where and for whom the application is not delivering acceptable response times.
• Subscription management – save the business unnecessary expenses by ensuring the right number and level of subscriptions were purchased (e.g. don’t continue to pay for employees that have left the company, or don’t pay premium subscriptions for users that are utilizing only the basic functionality)
• Application utilization – discover usage pattern, optimize the usage, ensure that the applications are being used in the way they were meant to, point out where training may be needed. Know how the application is used, by whom, when and where from.

The Value Paradox
Herein lies the paradox - On one hand, the cloud enables IT to start focusing on the important stuff ( bringing true value to the users and aligning itself with IT), but on the other hand, because of the Cloud’s ‘cloudiness’,  IT cannot deliver the benefits since it has no visibility into what’s going on.

The CIO has a debilitating blind spot when it comes to monitoring Cloud applications. All the communication in SaaS is done between the end user and the service provider. All traffic flows between these end points without IT having any visibility of who is using what, when, from where, how and how much. 
There are a number of tools available on the market that, although not designed for this particular challenge, provide partial information on various aspects. They include SSO, Synthetic transactions, APM, License management and log analysis. 

For example, Symantec recently released O3 Gateway while Salesforce is now delivering Identity Force SSO. Both solutions may provide a limited view of some of the knowledge needed.

Each one of the solutions above can give some visibility into this dark matter, but In order to resolve the “Value Paradox”  a new generation of tools will be required and they will need to be simpler, less costly, insightful and better fitting for the SMB market.

On Blindness – The Cloud Veil

“Living is Easy with Eyes Closed” ― John Lennon

Cloud is good, but…
Perhaps the single most powerful appeal of the Cloud – the ability of business managers to circumvent IT and get immediate IT resources - is also the most problematic aspect of it.

No wonder there is still a large group of CIOs and IT directors that shudder at the thought of letting go and have the business managers, or anyone in the organization, go out and purchase these resources with a swipe of a plastic card.

The fact that IT can be bypassed by the process is really neat: It save lots of time, there is zero bureaucracy, it is probably cheaper, and it is available anytime/anywhere. The fact that there is no go-between gives the business users all these advantages but in the same time leads to a debilitating blindness.

What we can’t see
Since all communications are done between the end user and service provider, there is zero visibility on the following information:

• What Cloud resources/applications are being used by the organization? Have various business units subscribed to services without IT’s consent or knowledge?
• Who is using what and how much? Perhaps the organization is paying for many subscriptions of employees that have left the company, or simply not using the app? 
• What modules are being used? Maybe the business is paying for the Unlimited Edition, while most of the users are only using modules of the Basic Edition – the difference can be significant – in some cases ranging from $5 to $350 per user, per month.
• What is the user experience like? Are the applications performing as expected? Which browser performs best per given app? Are the services providing similar results in the different office locations?
• How are the applications being used? Are all the modules accessed, and if not perhaps training is needed? Are the apps used as expected? E.g. if a CRM is used only between 4-5 PM every day or perhaps once a week, one would suspect that the service is not used as intended. 
• Compliance – how do we know that we are compliant to the various PCI, HIPPA, GLBA, FISMA requirements if we have no idea how the applications are being provided, or are being used by our employees?

Back in the days where all the applications were in-house, on-premise, IT could (in principle) know exactly what systems are running, who is using them, what the performance behavior of a given solution is and how the applications are being used.

Tools such as Network Sniffing, APM, and log analysis could be deployed in the network and monitor the traffic between the end users and the applications. For services that were offered outside the organization, one could use synthetic transactions to monitor performance and end user experience.

But what do you do if all the traffic is outside of your reach? How do you know what is really going on?

Single Sign On
Some companies use SSO to give them a measure of visibility into the application usage. While SSO has its merits, it is also limited in a number of ways. First, one must ensure that all employees are using the gateway to access the application. If employees have been using a certain SaaS service for a while, there is no guarantee that they will stop accessing it directly, and in any case, IT may not even know what apps are being used.

Even if IT manages to enforce the policy that every user in the org, accessing a certain Cloud app, will go through the company’s gateway, (whether from the office, on the road or from home), even then, the knowledge of the usage is limited to the single fact that user 'U' logged on to application 'A' at a certain time. Did that user ever advance from the login page or did she log out immediately afterwards? Did she stay signed in for three days, what modules did she use and at what frequency? What was her user experience? All these questions remain unanswered.

Service Provider Logs
A very small percentage of Service Providers have started making available usage logs for their customers. Potentially, these logs are quite helpful, as they can give a detailed view of the usage of the Cloud resources.

The drawbacks in this solution are threefold: First, as mentioned, only a small fraction actually does provide such reports, at different levels of detail. Second, each report is formatted differently and therefore, one needs to study each report, try to normalize the data and build a dashboard to capture the information. (bare in mind that some organizations consumes dozens of SaaS apps). Finally, this is simply data. To create actionable, insightful reports will require a huge investment in time, resources and ingenuity that I doubt many IT departments will consider.

Where is IT?
Perhaps in the future, businesses could thrive without an internal IT (just as we make do with power and utilities today). There is a hot discussion going on right now on the various internet forums, as to what shape IT will have (if at all) in the future. But right now and for the foreseeable future, IT is here, and will be needed to resolve a multitude of technical and procedural issues.

Therefore, even if one is a big believer in Cloud (as I am), IT will need to be involved. At the end of the day, all the problems will be brought to the helpdesk (even if IT was not involved in the process of purchasing and setting up the Cloud apps). Issues of performance, usage, security, compliance and integration will remain in the realm of IT, because the business managers and individual user will not be capable of handling them.
And, therefore, the blindness must be cured. Tools allowing visibility and reports providing actionable insights must be made available.

7 Considerations for Transitioning to SaaS

“Beware of missing chances; otherwise it may be altogether too late some day” - Franz Liszt

Not there yet?
We are nearing the end of 2012 and there still are thousands of ISVs that have not yet transitioned to the Cloud. For some, the effort might be too big and they fear it will mean an optional death. For others, they might have a steady, captive audience, and their customer base is still strong – perhaps not growing, but enough to sustain them for the short term. What I am certain of, is that no ISV is oblivious to the Cloud revolution, and not thinking of the implications and next steps.

I have been advising ISVs on this process since 2004 and have developed a program that I implement at my customers who went through the process. Some decided to postpone, others have launched successfully. Following are considerations that are the cornerstone of my methodology.

1.    Motivation
There are many compelling reasons to transition from the on-premise model to the Cloud, but many companies do it for the wrong reasons.
I believe that the vast majority of ISVs will transition to SaaS, or cease to exist, so don’t get me wrong – the transition is necessary, but it is also very important for the company to understand why they are doing it. The transition is a Strategic Business Model change, and don’t fool yourself otherwise.

The fact that Everyone Else is Doing It should pop the questions ‘So What’? Fashion alone is not a reason to change your business model. If you are going to be a ‘me too’ company, or put a little cloud on your logo hoping that it will appease your customers, it will not bring you success. Are you losing your customer base, are your customers demanding a web solution? Are you doing it to capture new markets, new geographies, or expand services within your space?
These questions are critical to define your strategy.

2.    Define Goals. Market and Offering
This seems almost too obvious, but one would be surprised at how little this is practiced. At many companies, the drive to offer a SaaS service is driven by a customer request, an initiative of a product manager, or a ‘me too’ attitude. Hence, they decide to play it safe and to first "test the water" by starting the SaaS initiative by offering “something” in order to watch the market’s response. They think that once the motivation is clear, the target market will be better understood, and the offering could be defined. This is a pretty sure fire way not to succeed.
The strategic goals must be defined prior to the transition:  Are you reaching out to the same customer base with improved services? Are you reaching out to smaller customers that were previously below the radar? Will you be offering the same product or a simplified version to smaller customers? Could you expand to new geographies that were out of reach because of the previous need to establish costly local operations?

3.    Go-To-Market
The go-to-market strategy is very much a derivative of goals, product and target market, but it is important to understand the relationship between them all. Think of the possibilities. Will you be going after your own customer base with the old school, of elephant hunters and wining and dining and 18 months sales cycles? Will you go after a wider audience with inbound marketing and a low-touch approach? Will you place your service on a market place (e.g. AppExchange, ApplicationMarketPlace) with a zero-touch approach? What would be the role of the Channel in the new service?

These decisions will weigh heavily on the design of the product and most probably on the technology, not to mention the support, sales and marketing functions within the company.

4.    Think outside of the Box
SaaS is not just another way to reach a larger market with your existing product – the Cloud offers so many new opportunities that were not possible before. The idea is not just to recreate your client-server application on the web, but use the web as fertile ground for stuff you could not do before. Just think of all the usage data you have now - the ability to understand what your customers are using and how, share that knowledge with the community, or sell the benchmarking data as a service or add features and modules to your service that you were not able to provide before. Since everything is available in the Cloud, you can integrate value added services without the need for a scary, time consuming PS project.
Drive a brainstorming session and ask the employees what they think can can be done in the Cloud. You would be surprised at how many fresh, original ideas will surface.

5.    Understand the Pain
As I have written in numerous occasions – the move to SaaS is not expanding through another channel – it is a total paradigm shift and it will affect every silo within the organization. If you do not grasp the enormity of the shift, there is a good chance that you will either fail in the process, or come out on the other side weakened and exhausted. You must understand the effects it will have on every group and the implications, and by "every group" I mean Product, R&D, QA, Support, Marketing, Sales, Finance, Legal, Professional Services and Operations.
If your strategic sessions lead you to conclude that the shift to SaaS is inevitable, you must enhance your chances of success by first understanding the impact, identifying the problem areas and tackling them through buy-in, education and sometimes, yes, the need to let people go.

6.    Spawn Out the Cloud Service
Because of the paradigm shift that comes with switching from a product-centric model to a service-centric one, and because it will affect the way things are done in every department, one must consider a near complete separation between the on-premise and SaaS teams. Whether by spawning out a satellite company, or creating a new division, it is necessary for the success of the SaaS offering without trashing the old customer base. Having the same team working on both models, (whether product, engineering, QA, Marketing, Support or Sales), will, at best, make things difficult, create conflict of interest and will risk the success of the new endeavor.

You should definitely create this new team from your best existing employees and perhaps strengthen it with a few outside recruits. You could begin with a product manager and a small team of young (in spirit) developers, those that thrive on new technology. Challenge them to deliver a new Cloud offering in record time – you would be surprised to find out how much can be achieved in a very short time. (When I started out, over a decade ago, there were so few tools and environments available – one had to build everything from scratch. Now the Cloud provides hosting and eco-systems that allows one to build full-fledged services with billing, integration, monitoring and BI almost out-of-the-box.) Make sure that they report to a C-level in the company that will take this initiative as a personal goal.

7.    Vision & Leadership
There are numerous examples of companies that succeeded in the transition, despite the hardships and challenges. (Concur being the ultimate example) The common thread was the executive leadership's belief that they are doing the right thing and their ability to carry their enthusiasm to their employees.
There are also quite a few examples of companies that failed in the process. Some of them paid dearly for that move (Mercado as an example of a very promising company that depleted itself through the process, and basically evaporated). I believe that the common trait of these failures was a lack of leadership and/or understanding of the managerial and strategic resources needed for the transition. Either the process was carried out by an enthusiastic director who got a mandate to "test out the water" as a sideline project, or that the Sales team stepped in and bungled the attempt as they perceived it contrary to their agenda, or the company tried to run both models in parallel with the same teams.
It is not enough that the CEO believes in the model. She must make sure that the board of directors is behind her and that every C-level is on the team, understands the issues, the opportunities and the difficulties, and propagates the enthusiasm all the way down to the entry-level employee. Bring the sales team on-board at an early stage and get them excited. They have the most to lose in the short term and they can be a royal pain in the backside if they chose to.

And yes, listen to your customers – one of the downsides of on-premise software is that you don’t really know if and how your software is being used.

There is a lot of misunderstanding about Cloud; too much hype has been thrown around. It is important to educate the staff and create a common vocabulary, to facilitate effective discussions in the board room and next to the coffee machine. Make sure that the most junior level worker has a clear understanding of the goals and the path to achieve them and get them excited about the prospects.

All the Right Reasons for not adopting the Cloud (Scientifically speaking, of course)

“Just as no one can be forced into belief, so no one can be forced into unbelief” - Sigmund Freud

Last week I participated in an expert-panel in a Cloud-meeting for CIOs. The conference started with an hour long CIO panel, then the vendors displayed their goods and finally, the expert panel.

What was obvious, was that different CIOs had completely differing opinions on whether Cloud should be embraced or not. There were those that were completely for Cloud and were actively seeking how to consume more Cloud services while others explained why the idea was mostly ludicrous.

When asked to summarize my impression of the meeting, my observation was that the difference in attitude towards embracing Cloud and SaaS had nothing to do with the size, or business or  type of enterprise these CIOs were representing, but with the psychological makeup of the CIO.

Perfect Reasoning
If you are for the Cloud, then the TCO and ROI clearly indicate that Cloud is the logical choice. If you are against the Cloud, you could prove how it ends up being more expensive.

If you do not want to adopt SaaS you can always pull out the regulatory winning card.

If you are for Cloud, you can talk about the flexibility of using SaaS. If you are against, you talk about how inflexible SaaS is without the ability to customize.

If you are a SaaS seeker, you tell the audience how much better the security of SaaS providers was than your own facility, but if you feel threatened by SaaS, you bring up those horror stories to justify not going there.

Que Sera Sera
I have no doubt that the train has left the station and that the old-school CIOs will, with time, become a minority. But then, you still hear some scientists arguing that Global Warming is fiction and they have scientific proof.
I don’t know what the future will look like, and what trends will dominate a decade from now, but Cloud is here to stay. Mind you, there are still mainframes running business on COBOL code, forty years later, so one would assume that on-premise will still be around in one way or another.

But as for the arguments, like religion, faith and whether the Sun revolves around Earth, no “scientific proof” will be able to change people’s minds.

Give me Freedom – Give me SaaS

“You can have peace. Or you can have freedom. Don't ever count on having both at once” - Robert A. Heinlein


I really like LinkedIn. 

[ I dabbled with Facebook for a little while, but truth be told, I gave it up. Even though I know that every company that respects itself has a presence there, it still feels a little silly to share my professional views on a social network where my kids exchange juvenile videos, girlfriend status or tomatoes on Farmville.]


The professional groups on LinkedIn can generate very lively discussions on things that matter to their members. Recently, I participated in a comment-war-of-attrition (over 50 extensive comments) on one of the larger CIO groups on LinkedIn. The origin of the discussion was a simple question of how to evaluate SaaS vendors, but the discussion quickly shifted to the concept of SaaS and then to the idea that SaaS limits the freedom of the CIO.

Lack of Freedom?
One of the participants was especially passionate against SaaS and kept talking about the idea that SaaS takes away your freedom because of vendor lock-in, because there is no control over the servers and the application and because there was no option to customize the software. Another point was that SaaS was totally dependent on the Internet to function (my refrigerator is totally dependent on the electric grid; is that a reason not to buy one? I find it hard to believe that any modern business is NOT dependent on the internet whether it has SaaS or not).


It’s not about IT and it’s not about the CIO
Let’s examine the kinds of freedom that this CIO is talking about. Owning and maintaining your own hardware. Wow! You have the freedom to research, negotiate, purchase, rack, stack, connect, test, maintain and upgrade. Yea! Are your users in HR thrilled about that? Are they applauding the efforts and wonderful results? Does all that effort get them closer to a solution or is it a justification for the IT budget?

IT has the freedom to research, purchase, install, test, integrate, maintain and upgrade the software package. Yea again! It did take nine months to get here, but guess what? we have our own software!
 
The Sales department might ask you why couldn’t we have done that nine months ago, using a SaaS solution, but' heck, what do they understand about IT’s needs. Oh yes, forget about the new versions that came out since – now we have the freedom NOT to upgrade (actually, we are scared s**tless about touching production after finally stabilizing the system).


I believe that the freedom the CIO was talking about was mostly about the freedom to stay in charge and have the business units dependent on IT.

[I do agree that in some cases, maintaining control of on-premise software has merit or it is governed by regulations; but that should be the exception, not the rule.]


Freedom to Customize
But, aha, IT will say, we have the freedom to customize the application to our heart's content. We own it! We can do whatever we want with it. But do we really want to customize the application? Is our hospital so different than thousands of other hospitals that our WFM software must be customized to our specific needs? Would customizing the Travel Expenses software give our bank the market edge?

SaaS applications embody the best practices of hundreds or thousands of robust businesses that share 90% of the business processes.  Most solid SaaS applications provide a level of configuration that should take care of an extra 5% of specific business processes.
On any day, nine out of ten business managers will prefer to have a working solution today that does 95% of the work, rather than wait twelve months for characterizing, prioritizing, designing, coding, testing and installing a solution that provides the 100%.


Real Freedom
SaaS gives IT and the business:

• Freedom from hardware purchases
• Freedom from racking, stacking, configuring, installing.
• Freedom from the endless maintenance and firefighting
• Freedom from the upgrade nightmares
• Freedom to choose – SaaS almost always gives you free trials to play with before you make the heavy commitment
• Freedom to change your mind  - if you are not happy, you can switch (yes, I know it is not simple, but at least in early stages you can do it with minimal damage while with on-premise software you are stuck with your decision for years) 
• And that means freedom from long-term, substantial, financial commitments
• And finally, Freedom to say NO to the business units that absolutely insist on that extra feature that will be forgotten by the time it is implemented

I am surprised that in 2012 we are still having these discussions, but apparently the veteran CIOs are still around fighting to maintain the old world order (see my previous post on Democratization of IT).