Wednesday, April 02, 2014

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.

Saturday, March 15, 2014

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.

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.

Friday, February 28, 2014

SaaS Customer Success – Best Practices (part 1)

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

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.

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.

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.

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.

Friday, February 07, 2014

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?).

Wednesday, February 05, 2014

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.

Monday, February 03, 2014

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

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.

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.

Monday, January 27, 2014

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.