Dani's Perspective on SaaS

Implementing SaaS Solutions Reduces Security Concerns

2011-12-12T08:12:00.000-08:00

"The user's going to pick dancing pigs over security every time" - Bruce Schneier"

In this post I am publishing an article by a guest contributor - Rashed Khan (rash799@hotmail.com) who points out interesting study results...

Software as a service (SaaS) for application delivery is a hot topic when it comes to questions of security. Adding SaaS components in any form is something that seems to generate acute anxiety in anyone who takes the time to consider it. Fears about the loss of privacy and other related security issues top the list of current concerns.

On the other hand, those who are already using SaaS solutions or have added elements of SaaS to their systems are considerably more confident about security issues than non-users. When it comes right down to it, SaaS appears to be something that one must experience in order to trust.

Forrester Research has recently completed a study that supports this premise. In companies where SaaS was already in use, having replaced a complete solution, concerns over security are noticeably lessened. This is also true in companies where the decision to replace a complete solution with SaaS had already been made and was about to be implemented.

By contrast, companies that were only contemplating or planning to augment their solutions with SaaS, or in companies that were using just a few SaaS components, anxieties over safety were still running high.

Miroslaw Lisserman, analyst at Forrester Research, believes this to be a strong validation of the future of SaaS technology. Lisserman had this to say about the findings: “To me, this means the following: SaaS solutions are more secure than perceived by many, since once SaaS applications are deployed and used, the security concerns decrease.” Apparently, SaaS technology performs so well that it has to be experienced to be believed.

Analyst Krishnan Subramanian, an independent researcher, feels that the security concerns related to the SaaS technology itself have been overworked. He said that the real issue related to this application has more to do with people. Regarding these concerns, Subramanian had this to say: “It is the responsibility of the SaaS vendors to educate users about their people-centric security practices. It is the responsibility of the SaaS users to get to know these details from the vendors.”

Moving away from concerns about the security of SaaS technology and turning attention instead to security concerns related to the technology's providers and users is a measure of the maturing of this technology. It's a sign that SaaS is ultimately coming into its own.

The growth of the sector itself testifies to this belief. There has been rapid expansion of SaaS solutions with Enterprise Resource Planning (ERP) software functions. Additionally, there is growing use of the ERP system by both small and mid-sized manufacturers. The manufacturing software is also used more frequently by industry distributors and in job shops.

Small companies who are part of large supply chains, along with the supply chain members they deal with, are all discovering significant benefits and greater functionality in SaaS-based ERP when employed as a comprehensive manufacturing software solution. Home-grown and standalone applications fall short by comparison, making SaaS both the wave of the future and an increasingly intelligent choice.

The Black Swan Event in SaaS Operations

2011-12-01T05:33:00.000-08:00

"I find that the harder I work the more luck I seem to have." - Thomas Jefferson

Nassim Taleb’s eye-opening books 'Black Swan' and (to a lesser extent) 'Fooled by Randomness' discuss the rare, unexpected and almost impossible to predict events that have a major impact (and usually tend to be disastrous). He calls these events Black Swan events, and gives samples such as World War I, stock market crashes, the PC, the Internet, and 9/11.
Interestingly enough, all the Black Swan events are easily rationalized after the event, by hindsight.

The Black Swan analogy is borrowed from the notion that while one can induce a hypothesis from observational data - e.g. all swans are white - one cannot prove that hypothesis, since after observing numerous white swans, it takes only a single black swan to refute it. Karl Popper, the science philosopher, made that notion popular in his discussion of the Scientific Method (The Logic of Scientific Discovery).

SaaS and the Black Swan
Have you ever lost your database only to find out that the backup files were deleted the previous day? Have you ever hit a major problem with a component in the system, only to find out that the support contract expired last month?

My own experience and the experience of the numerous companies I have worked with, have taught me that the next Black Swan is just around the corner, lurking in the dark and will hit you when you least expect it to. Heck, that’s the nature of a Black Swan.

The systems we deal with are so complex and interdependent that one could never analyze (let alone predict) the interconnections that govern the behavior of the services we offer. Luckily, statistics are on our side, so that most SaaS applications are stable most of the time and on average, we can predict the behavior over time. But that is just what creates a Black Swan – we observe s certain behavior for so long, that we tend to accept it as a scientific fact; until it bites us in the behind.

Running a complex SaaS operation with dozens (or hundreds) of servers, network boxes, configuration files, erratic software and all the dependencies we have on our infrastructure providers (power, internet, hardware, communications) is like driving a high speed car on a congested highway, blindfolded. We have no appreciation of how much Lady Luck is involved.

Keep in mind that the longer good things happen, the harder is the effect of the Black Swan event - remember the dot.com and the real-estate bubbles; most of us are still licking the wounds.

The Butterfly Effect
All it takes is an overflowing log file, that incapacitates the disk, that will bring the system down. Or a minor, forgotten gadget installed on one of the servers whose license has expired. A pipeline of requests starts filling up and there goes the system.
How about setting up an image of a new VM, whose IP and the DNS IP were reversed by mistake. Put it in production and slowly the wrong DNS IP starts propagating in the system. After a while the servers are not communicating with each other and the system freezes.
These tend to be catastrophic events, since they are so hard to detect and resolve. Many times, restarting the whole system is the chosen quick solution, praying that the problem will resolve itself. But in these cases, the system will behave just as badly, and by the time one realizes what is happening, major damage to the customers and your brand has been done.

Words of Wisdom
Do not despair. I am not suggesting that since a Black Swan event is unpredictable, there’s nothing you can do about it. The opposite is true.
The first step is to internalize the fact that it will occur, as the famous quote goes “s**t happens”.

“Prepare for Failure” is my motto. Take into account that at any given moment something might break.

A number of practices should be implemented early on:
Change Management: To ensure that the events are indeed rare and that one may recover quickly with the knowledge of what went wrong.

Event Management: To be able to detect early on, what is hitting the fan, and respond to it.

Availability Management: Analyze your Single Points of Failure and impact of component failure. Build your backups, your DRP and practice recovery.

Incident Management: Make sure you cover these practices: Detection, Recording, Classification, Notification, Escalation, Investigation, Diagnosis, Restoration and Closure.

The Wise and the Smart ones
I was approached by a few (emphasis on few) CEOs and COOs that felt uncomfortable about the fact everything was going smoothly. Some were on the verge of fast growth and wanted to assure themselves that they were better prepared to hit the highway. Others had a feeling in their bones that “too good for too long” was a recipe for disaster, even if they did not read Nasssim Taleb’s book.

But many potential customers I spoke with assured me that they really do not need my services since they are doing very well, thank you. Some are still doing very well and others had a large hat to eat and many letters of regret to write their customers.

CAC, LTV, MRR - Translating SaaS Financials into Actions

2011-10-03T10:32:00.000-07:00

“If people do not believe that mathematics is simple, it is only because they do not realize how complicated life is.” - John Louis von Neumann

I’m sure that most of you have seen the various metrics floating around with CMRR, CLTV, Churn Rate and ASC starring in equations that sometimes cause one to cringe while sipping the day’s first coffee.

Let’s look at one of the basic formulas for SaaS Financials:
CAC < CLTV

This simply says that if you want to become profitable one day, you must make sure that your Customer Acquisition Costs should be less than your Customer Lifetime Value. In other words, the total amount of revenue you will generate from a customer, throughout the years or months that they derive value from your SaaS offering, should be more than the cash you spend on acquiring that customer.

Simple? It almost doesn’t pass the DUH Test. But in this article we'll look more carefully at the implications.

Acquisition vs. Retention
There is a notion in the industry that the costs to acquire a new customer are 5 to 7 times more expensive than the costs to retain an existing customer. Whether one agrees with the numbers or not, it is widely accepted that acquisition is more expensive than retention, yet most SaaS companies will spend far more resources and executive attention on growth through new customers than keeping the current customers satisfied, or in other words, reducing the Churn and up-selling to the current base. In fact, in every company I have consulted, the issues of Churn Management and Operational Excellence were far down on the priority list.

I guess hunting is far more exciting than farming.

Therefore, we will examine on how to grow the right hand side of the equation - the CLTV, not on how to lower the left side - the CAC.

Breaking down the CLTV

CLTV = Lifetime * ARPU * Gross Margin.

I hope I am not losing you here. Take another sip from your Latte. It is not complicated – sixth grade math. Stick with me, the actionable items will follow shortly.

ARPU means the ‘Average Revenue Per User’ for the time period defined as Lifetime. So if you count by months, Lifetime would be the number of months the customer remains loyal, and the ARPU would be the average that the customer would pay per month. If your value is calculated by years (lucky bastard!) then Lifetime would be how many years you retain the customer and the ARPU is average revenue per year from the customer.

Gross Margin is the ratio of total Revenue to the Costs Of Goods Sold (COGS) – how much does it cost you to give service to your customer.

For the Gross Margin to grow, the COGS should shrink, or at least stay stable as your revenue grows. So the lower the COGS are, the more you retain for your Christmas party.
As a simple example, let’s assume that your average customer sticks around for 19 months, that the average monthly payment from a customer is $430 and that your gross margins are 72%, then the CLTV = 19 * $430 * 0.72 = $5882.4.
Just imagine that with a little effort you could cause the Lifetime to grow to 21, or the ARPU to $460 and multiply the new CLTV by the number of customers...

What can we do about it?
Without going into details of how the various numbers are calculated we can still learn much about these equations and derive actions from them.
The bottom line is that you want to have the highest CLTV value possible. Looking at the equation, it means that your Lifetime, Gross Margin and ARPU values should grow.

Needless to say that for each of these three values, books could be written. Nevertheless, the paragraphs below cover the main points and map the actions one can take, and their direct impact on the equation’s variables.

Lifetime
In order for this value to grow, a SaaS provider should invest managerial attention into customer retention, or lower Churn. That means improving your customer service and responsiveness. Meassure and monitor the support KPIs. Run a weekly Customer Success meeting with Support, Operations, Sales and PS. Build a community and best practices around your product to enhance loyalty.
Be as transparent with your service levels as you can. Award loyalty with small gifts. Document your Churn data and analyze it – understand the reasons customers leave you and determine the trends.
Provide meaningful SLAs and act on them.

Average Revenue Per User
Translate ARPU into: “up-selling you service”. This means a strong group of farmers in your sales team. Use software to monitor user behavior. Think of value-added services that you could sell for a fraction of the recurring cost. Identify and keep in touch with your champion inside the customer’s organization and seek opportunities to sell more services or branch out to new groups within the organization.

Gross Margin
Lowering COGS means an effective and efficient Service Operations. This starts with a good team of dedicated professionals, a rigorous set of practices such as Change Mgmt, Incident Mgmt, Event Mgmt, etc. and a robust monitoring and alerts infrastructure.
Automation and Delegation - maximize what silicon and your customers can do instead of having people on your end doing it. That means create as much automation as possible around manual processes. Provide self-help, self-registration and self-configuration for your customers to run.
Understand the financials of the hosting services you are using. Don’t stick to the current solution just because you have been doing it for a long time. Circumstances would have changed, new solutions are offered every month, and a fresh look might save a lot of recurring costs.

In conclusion, we looked at one of the equations that every venture capitalist (i.e. your board members) tells you to watch, and transformed it into actionable items that your company should deal with. To pass that threshold of profitability, it probably won’t happen with that “major deal we’re about to sign”, but with improvements across the board in every aspect that tilts the right side of the equation.

For some good readings on SaaS Financials there are Bessemer’s 5 Cs, and Joel York’s excellent articles on the financials of SaaS.

SaaS and SLA - State of the Art

2011-08-21T23:20:00.000-07:00

"You can get assent to almost any proposition so long as you are not going to do anything about it." (Chapman, John Jay)

Lately, I have been approached by a number of frustrated CIOs, asking me about what can be expected from a typical SLA in the industry and which provider offers an SLA with some beef.

A Typical SLA
Let’s see what a basic SaaS SLA should look like:
• Service Availability
• System Response Time
• Customer Service Response Time
• Customer Service Availability
• Service Outage Resolution Time
• Failover Window For Disaster Recovery
• Reclaiming Customer Data
• Maintenance Notification
• Proactive Service Outage Notification
• RFO (Reason for Outage)

Nice. Now let’s see what a typical SLA in the SaaS industry looks like:
• Service Availability

Is that it? Yeah, that’s about it. (Sometimes you may find Customer Support response time as well, the Lord be praised). The standard SLA in the industry only discusses ‘uptime’ and even that is usually very iffy, with mostly zero or negligible penalties.

Recently I have been meeting with CXOs of successful SaaS companies and asking them what their SLAs offer. Not surprisingly, their answers were reflective of the typical SLA above. Some did not even offer an SLA and one said, half jokingly, that they (the customers) should say ‘thank you’ for even having the service available. When asked about the future of SLA in the industry, the collective answer was that nothing will probably change, customers will not demand better SLOs (Service Level Objectives) and that the whole issue was quite irrelevant. One CEO suggested that the only concern of the CIO is ease of integration.

Is that so? Or are these guys burying their heads in the sand? When I asked about how many dealt with CIOs (as compared to business units), only one said that he did, and that it was an unpleasant experience.

How would you explain this discrepancy between what CIOs want and what SaaS CXOs would offer? And why is the state of SLAs in the industry is so pitiful?

A Quick Historical Review
I think the answers lie in the history of SaaS and how it penetrated the market. Around 12 years ago we started seeing the first SaaS applications (although no one came up with the name until a few years later). SaaS mostly targeted the SMBs who had no access to the enterprise software that was available to the larger companies. Either from a cost, or complexity or support point of view, the on-premise applications were out of reach for the smaller companies. When they started becoming available over the Web, the SMB were so delighted to even have a solution they were not going to bitch about the service levels being offered in the contracts. They were just happy that the apps were available. So, SaaS companies offered a 99% uptime which seemed pretty good (except that it translated into four days of downtime!). Nobody could talk about performance, as the dependency on the customers’ own network and on their ISPs allowed the providers an easy escape from accountability.

The Corporate Business Unit
Even though SaaS initially targeted the SMB, the big breakthrough came from the business units that found freedom in circumventing IT and getting their needs answered quickly (and in the process, flipping a bird to IT). The heads of the business units were mostly concerned with features and did not care much about SLAs. Even if they did, they did not have the experience and knowledge, that IT has accumulated over the years, on what to demand, how to verify that their service levels are met, etc.

The New IT Manager
More than ten years have passed with SaaS slowly establishing itself as mainstream, and conquering more and more territories. Old habits die hard and the sad state of SLAs remained where it had been a decade ago. Now, SaaS is finally entering the enterprise through the front door. There is a new generation of CIOs that are not threatened by SaaS and understand the freedom it offers them. They want to get back into the driver’s seat, clean up the mess that a decentralized SaaS policy created and control what is entering their domain.

As for the CIOs with the old-timer’s attitude, the Cloud hype has forced them to pay attention. When the CEOs caught on (hey, we can save a lot of money here) the pressure was on the CIOs to start acquiring Cloud Applications – SaaS. And, like it or not, there are numerous integration issues that demand that IT be in the picture.

Slowly, we are seeing a shift in the market. More and more CIOs and IT managers are in the picture. And when they see the lack of real certification or the famished SLAs offered by the vendors, they are probably baffled, at best, if not furious.

I believe that gradually, as more CIOs enter the picture, the SaaS providers will have to prove themselves as more mature, attentive and accountable vendors. I think that the IT customers will step-up the pressure and changes will occur. SaaS providers will succumb to provide a serious document with real numbers and repercussions.

In short, the differentiator is no longer the fact that a vendor offers SaaS, nor the feature set, nor the pricing. To distinguish oneself, a SaaS vendor will have to excel in every aspect of the service and provide the assurances for the service levels that CIOs are expecting.

The CIO's Dilemma – Adopting SaaS as a Strategy

2011-07-04T03:46:00.000-07:00

“Luke, you're going to find that many of the truths we cling to depend greatly on our own point of view” (Obi-Wan, Star Wars, episode VI)

'IT-Avoidance' Mechanism
SaaS adoption has become an outstanding success, not in the only SMB which it targeted originally, but at the business-unit level in the larger corporations. SaaS became the ultimate IT-avoidance mechanism for the business department heads that were tired of waiting for many months (or years) for their IT needs, weary of investing huge budgets just to find out that the software did not deliver what was expected, or was outdated by the time it was implemented. With SaaS, they could start a free trial immediately and gain value of the solution with minutes, hours or days. IT managers sometimes found out that their internal customers were using SaaS software many months after it was a done deal.

It’s All About Control
This paradigm shift from transitional on-premise to SaaS (which is somewhat reminiscent of the PC revolution that empowered the end users and removed some of the dependency they had on IT), was not looked upon favorably by IT managers.

I believe that the main reason for IT's resentment towards SaaS, is the loss of control partly based on real problems caused by IT-Avoidance and partly is based on an emotional response to the notion of various business units not “needing” IT as much as before.

My premise is that CIO’s must adopt SaaS – it delivers the goods and it is happening anyway – but for the adoption to be successful, they must regain control of the situation.

Security
IT usually brings up the ‘security’ excuse to kill SaaS deals, but I believe that many times the ‘security’ they are talking about is their 'job security', afraid to let go of assets that everyone is dependent on.

So let’s examine the real security issue. As I have mentioned in numerous talks and presentations, Cloud companies, as a rule, will do a much better job at data security and privacy than a hospital or a car manufacturer (or a bank, credit card company or NASA judging by the publications on the subject).
Still, there is a major issue regarding SaaS accounts when they are not controlled by IT. Any business manager can swipe a credit card, and order 40 seats for her staff to start using an HR app. The manager knows nothing of security, nor does she bother much with it - the point is to get productivity up. The users are provisioned, not by IT, but by the business unit. When an employee leaves the company to work for the competition, IT is supposed to disconnect that employee from all the assets in the company. But how can they de-provision the employee if they have no access (or knowledge) of the various SaaS applications that person was using? Who can guarantee that this employee will not access company data from home or from the new employer’s premises?...

Lack of Visibility
Not only does the IT manager have incomplete knowledge of who is using what, even if they know that an employee has a SaaS account, there is no way to know if that user is accessing the software, how it is being used and what, if any problems are there. There is no visibility into performance issues. IT also has no knowledge of what part of the organizations’ data is stored where. And could it be that some of the same data is residing at different SaaS providers, and could it be that information at one provider is inconsistent with some information at another provider?

Vendor Selection
One of the areas of expertise of IT is the ability to select software solutions and evaluate the vendors. The business units do not have that ability, and frankly, they don’t give a damn. They want quick solutions within their monthly budgets and all other topics regarding security, integration, service continuity, financial viability, and SLAs are stuff that IT traditionally dealt with (and hence took forever to make a decision). So, IT is not involved in the solution/vendor selection process exposing the enterpise to bad choices and their consequences.

Lack of Efficiency
It is not uncommon in large, distributed companies, that different departments are consuming the service from the same SaaS vendor (or different departments are using similar solutions from different vendors) with multiple contracts in place, and perhaps different integration schemes. Of course this reduces the chances for bulk discounts and is inefficient in all aspects of organizational learning and business intelligence.
Another aspect of control is the lack of ability to access, backup and analyze the company’s data or to impose regulatory constraints on the user.

Lack of Strategic Planning
The fact that each department is an independent SaaS consumer and that IT is not driving and controlling the company’s solution is a great impediment to multiyear strategic planning. The individual business units do not have a high-level view of the company’s needs and strategy.

The lack of strategic planning reduces the company’s ability to ensure security and to employ cross company data analysis (the data is distributed across multiple vendors) and may cause compliance and regulatory issues in the future.

What to do, what to do?
A following article will outline strategies to employ in order to get hold the SaaS situation. But it will suffice to say that IT needs to restore control and bring itself to the forefront. This means that, first and foremost, the CIO has to embrace SaaS and not fear it. Start by defining the strategic goals of Cloud computing in the organization. Understand who is consuming what in the organization. Review your upcoming upgrades and begin a process of considering SaaS to replace your on-premise solutions.

SaaS is not a threat but a wonderful opportunity for the enterprise and the IT organization. Don’t play a defensive game; rather, become a leader in this area for your company.

Organizational Culture and Company DNA – What Makes a Successful SaaS Company.

2011-05-30T03:52:00.000-07:00

“No people come into possession of a culture without having paid a heavy price for it” (James A. Baldwin)

It was always clear to me that success with SaaS was not about technology, but about execution. This week I got a clear reminder.

The SaaS CEO Forum
For the past few months I have been running a SaaS CEO Forum that meets every six weeks or so, each time hosted at a different SaaS company, by a member of the Forum . The forum consists of a select group of successful SaaS companies, that have been selling their service for a number of years and are dealing with issues such as growth, operations, sales, marketing and customer satisfaction. Every meeting has a theme such as running a fabulous inside sales teams, SaaS Service Operations, knowledge-as-a-service, etc.. Yesterday the forum was hosted by Avinoam Nowogrodski, founder and CEO of Clarizen, a fast growing, market leader on collaborative project management. Beyond the very interesting review of the company’s clockwork marketing and sales operation, Avinoam gave a presentation on what makes a SaaS company successful.

Successful SaaS Company
No one can argue with the success of Clarizen, having grown 400% year over year, with an ever-growing community of happy customers, so it was worthwhile listening to Avinoam’s credo.

Clarizen’s CEO was talking about managing a company where execution is paramount and where Customer Success always comes first. He has been careful selecting an executive team that he regards as ‘A’ players and nurturing a culture of Respect, Modesty, Openness, and Accountability.

Among the factors Avinoam mentioned was “checking your ego at the door”, willingness to take risks, and acceptance of mistakes as part of the ever changing environment and conditions. Delegating Authority, Hands-on in your domain, Transparency and above all – Measure, Measure, Measure every aspect of the company’s operation; sales, marketing, conversion between each stage of the pipeline, responsiveness, costs.

The SaaS Angle – Fast Forward
While I agree wholeheartedly with all the above criteria being critical for a successful company, I asked for the SaaS angle. The answer was obvious even before I finished asking the question: “Pace”. In a SaaS company everything is fast-forwarded. The cycles in almost every aspect shorten and therefore the margins of error are ever so narrow. In a company that caters for the SMB in a low-touch model, the sales cycles are measured in days, not quarters, the software releases are shortened to weeks. The discovery of bugs usually occur within hours (or minutes) after a new version is introduced. Hence, Openness and Transparency are paramount and there is no time for ego games or controlling vital information (I have written about these aspects in the past: Transparency & Communications).

To reiterate – in a fast-pace, ever-changing, 24X7 environment, the need to feel the operational pulse, the need for responsiveness and open communications, the need for a listening ability and accountability are vital for success. Time spent on BS, on analysis-paralysis, on political games, on territorial squabbles, is time spent away from making sure your customers are successful, and that will be evident on the company’s bottom line and eventually, on the quarterly bonuses.

System Integrators’ Cloud Strategies – React or Lead?

2011-05-07T11:22:00.000-07:00

“A leader takes people where they want to go. A great leader takes people where they don’t necessarily want to go, but ought to be.” (Rosalynn Carter)

Recently a number of medium-sized System Integrators (SIs) have approached me to help them either define their SaaS/Cloud strategy, validate their strategy or help them with the realization of their strategy.
It seems that, the shoe has dropped. It took two years of relentless Cloud hype for the System Integrators to finally understand that major changes are occurring which will impact their customers and therefore – them.

New Breed of System Integrators
There is a new breed of Cloud System Integrators (up to a year ago they were called “SaaS System Integrators”) including companies such as Appirio, Astadia, Bluewolf & Model Metrics, that are dedicated to providing SaaS based services. Being newcomers, they are quite small compared to the large players, but their growth rates are phenomenal (e.g. Appirio has been growing in triple digits since 2008). So far they are have not been big enough to pose a visible threat to the old timers, but I suspect that the Dinosaurs are starting to feel a bit uncomfortable with the quick mammals that are infiltrating their territories.

Lack of Strategy – Tactical Approach
Having studied approaches of the major players in the market I have come to some interesting observations:

There are around 15 Cloud services that SIs could offer their customers. Examples are: billing/integration/SSO services, PaaS development (Azure, Google Apps Engine, Force.com), SaaS-oriented testing, training, 24X7 NOC, etc.
Judging by my engagement with some of the SIs, most are not even aware of what those services are, and are therefore concentrating on a few obvious choices.
Most of the SIs are offering only one or two Cloud services from the list, and therefore:
Most large SIs do not have a SaaS/Cloud strategy, or, their strategy is to wait and see how the market develops.

A number of large players have chosen to become a single application integrator. Examples are:
Accenture is a Salesforce.com partner. Ernst & Young are helping implement EmployU and HumanWave. Deloitte is with Workday and Genpact is a Netsuite implementor.
Capgemini is working with AWS to provide a Cloud Computing COE.

Considering the size and nature of the business of these players, it seems that these services are not high on the priority lists of the big SIs. It is quite obvious (to me) that these giants have not defined a SaaS strategy, rather they are reacting in an opportunistic manner to the market - akin to a “me too” tactic, just to have something 'Cloudy' or 'SaaSy' on their web site.

Cloud Strategy – React or Lead
As mentioned, many SIs have adopted tactical approaches, at the Cloud Service level, rather than a strategic approach. Further analysis led us to the conclusion that by zooming out, grouping and mapping the above Cloud Services. we can define five Cloud Strategies for System Integrators:

SaaS Aggregator – Provide Applications on the cloud
SaaS One-stop-Shop for Software Vendors
Cloud/SaaS Adoption for IT
Private cloud technologies
BPasS - Could Integration

Note that Strategies 4 and 5 are "smaller" in scope and could either be included in one of the first three. Each Strategy includes between four to twelve of the above mentioned Cloud Services.

Using this prism, we could say that a number of players have chosen a strategic path:
IBM’s GBS and Wipro are offering services that we define as SaaS One-stop-shop for ISVs (strategy 3). KPMG is offering Roadmap for SaaS Adoption (strategy 5) while Infosys is acting as a SaaS Aggregator for enterprise IT (strategy 1). Smaller players such as iProcess are offering BpassS (Strategy 2)

Even though adoption rates are growing very fast, the hype of Cloud Computing is a couple of years ahead of reality, especially in the larger organizations that are the natural customers of the leading SIs. Some SIs have chosen to play it safe: not invest up front in new technologies and methodologies and watch the market carefully. Since they will still be milking many fat cows for a few years to come, the decision not to decide could be considered a smart, conservative strategy.

Others, though, have taken leadership positions, risking investments without a clear date on the ROI. They have the advantage of defining the market trends and have a better chance of emerging as the de-facto leaders in a few years when all the players, that are currently sitting on the fence, will have to define their strategy and see what bones are left to pick.

Automating SaaS Operations

2010-12-24T03:26:00.000-08:00

"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency" - Bill Gates

This is an article which I posted at the Nolio blog site as a guest blogger back in 2009. Not only is is relevant today, but perhaps even more so...

The Next Killer App
If I had a great idea for the next killer app (I have, actually) and if I had unlimited funds (I don’t, actually) I would have built the software as an on-demand offering.

I would have spent half my funds on building the operational support systems – provisioning, billing, retention policy, self-service, report generator, etc. The other half would be invested in building instrumentation, redundancy, automation, integration, application level monitoring, silent upgrades, customer notifications, and so on.

The rest of the money (you may wonder about my math, but hey, I’ve got unlimited funds) would go towards building the actual application.

Most SaaS vendors out there (and they are growing fast) have chosen the predictable path of building the application first, and worrying about serviceability later. This is the fastest way of getting to market with low costs. The next step is choosing some viable hosting solution and off we go, offering the world our ever better CRM.

Growth
Many months and dozens of customers later, reality hits with all the issues of servicing the software, rapid growth and dealing with labor intensive tasks that are the humdrum of daily life in a SaaS operation. Provisioning/de-provisioning, configuration changes, customized reports, and the most dreaded – upgrades, task the team as a whole, especially when the product is successful and the number of customers is growing daily.

It is not that SaaS executives, architects and engineers are lacking in any way. On the contrary, they are mostly smart, inventive, and creative and have a deep understanding of their customers’ needs in the specific domain. The problem is that they are product people, not service people. Practically none of them come from IT and cannot envision the life of a service operations engineer.

At this point, automation becomes crucial to the survival of the business.

Whether it is built into the next version (many architectures make this quite difficult) or done externally, automation is needed to reduce costs, physical labor, frustration and mainly, error-prone manual procedures. Repeatability, which is a derivative of automation, is also crucial.

Automation is needed across the board. Be it in setting up a new server, or building a new application instance. It could be a manual procedure regarding provisioning of application resources, or building a seamless upgrade procedure.

Outages happen. How quickly can you recover from a service disruption and ensure that the recovery does not create it own problems? Automation not only provides the routines for quick recovery, but instills a discipline of thinking out the necessary steps, discovering dependencies and planning ahead. An added benefit of automation is that it documents the process so you can go back and review the best and worst of your procedures.

In my next post I will take a closer look at the SaaS Upgrade Nightmare.

2 x E-cube = S-cube - Simple math for SaaS Scalability Success

2010-12-16T13:16:00.000-08:00

"The circumstances of human society are too complicated to be submitted to the rigor of mathematical calculation" (Marquis De Custine)

Recently I posted a discussion on the link between success with SaaS and scalability and how, therefore, the Service Operations needs to be geared to handle scale and deal with fast growth.

On a recent consultation engagement, I gave a presentation to the board members of a SaaS company that decided to penetrate the SMB, following their hardships in securing big deals in the enterprise market.

As part of the thought process and brainstorming session I came up with a marketing catchphrase to make a point. At the time I did not think much about it, but as I was working on the board presentation, I realized that there it was much deeper than I had originally thought.

I would like to share this with you.

The First Cube

What I drew on the white-board was roughly this artistic creation:

Announcing: “E-cube is the winning formula!”

Easy to Buy
Easy to Implement
Easy to Use

Easy to Buy - Their product is very easy to implement, and easy to on-board a new organization, (although it is a complex product). There is a technical issue that involves an architectural change, so that became part of the plan.

Easy to Use - the product has a great user interface and intuitive flow. They need to add tutorial videos.

Easy to Buy – That was lacking and that was what we decided to focus our efforts on. It included a lead generation program, a no-touch free trial and an improved landing site.

The Second Cube

As I was working on what it would take from the company’s end to deliver scalability, I realized there was another E-cube involved:

Easy to Sell
Easy to Scale
Easy to Maintain

It is all nice and well if you can bring thousands of leads to your site with the E-cube formula, but if you cannot convert these leads into paying customers and then give them the best service on a controlled budget, you will have not achieved your scalability goals.

So, Easy to Sell means - a simple pricing model and a top-notch insides-sales team (not easy to come by though) backed up by funnel management software.

Easy to Scale means - a solid, configurable, multi-tenant architecture, self service features and automated procedures.

Easy to Maintain means – a full featured Operations Support System, Service Operations practices and the discipline to enforce them.

So with two E-cube guidelines one can achieve SaaS Scalability Success.

Ergo: 2 x E³ = S³

Q.E.D.

The SaaS Consumer’s Point of View – Negotiating an Agreement

2010-12-09T10:23:00.000-08:00

“The food was superb, the atmosphere was great, the service was outstanding; it was those goddamned customers that had to ruin it all”. (Morris Green, restaurateur, NYC, 1987)

This short article is an introduction to an interesting blog post that was published recently by Derek Singleton from ERP Software Advice, but before I let you go, I want to take this opportunity to talk about the customer’s perspective.

My writings, presentations and webinars have been mostly dedicated to the point of view of the software provider, whether SaaS or SaaS-to-be. I would like to present a different point of view.

Throughout the years of being on the software provider’s side I have learned a thing two on what makes a happy customer and that is the guiding light I have been trying to follow for years.

I believe that if we understand the customer’s perspective we have a better chance of providing a good service and creating a happy, loyal customer base.

Who is the customer?

SaaS adoption has been mostly done in a haphazard fashion throughout the years. Many of the early adopters were business managers at the department level in the enterprise.

Even within smaller companies, the decision to consume SaaS was usually a point solution, for a particular issue to handle and not as part of a well thought process and methodology.

In many cases the IT department and CIOs were kept out of the loop in defining needs, selecting the service, negotiating the deals and the process of provisioning and de-provisioning. In the extreme, IT found out about their company consuming a web application only when a user would call the help desk and ask for support.

As more CIOs are ‘getting it’, as more IT departments are becoming cloud-oriented they are becoming that target customers, rather than the end users. They are usually better equipped (once their fears are neutralized) to judge the provider, the application, the integration and to negotiate a better deal for the organization.

These IT professionals should be planning a Roadmap for SaaS so that the consumed applications become part of a coherent plan rather than something the cat dragged in.

We should start focusing on this new generation of SaaS customers.

An interesting article covering the negotiations with a provider is therefore presented.

SaaS, Scalability and the Three Little Pigs

2010-11-13T08:51:00.000-08:00

“We have the wolf by the ears, and we can neither hold him, nor safely let him go” - Thomas Jefferson

A few days ago I gave a talk at a SaaS Business Challenges conference and I would like to share the main theme with my readers.

It’s the Service, Dummy!

When SaaS burst upon the scene about ten years ago, the first consumers were of two types: Those that used on-demand as an ideology, having foreseen the cloud revolution early on, and those that had no choice, because the other option was an expensive, time consuming and complex solution.

Back then, there were few SaaS application or service choices, so customers had to be very forgiving about the service levels and were willing to put up with reduced functionality, outages and low response times. SLAs, if they even existed, were non- binding and lacked both depth and breadth.

These days, however, when there are dozens of SaaS applications for every need, the differentiator is no longer the functionality. Most SaaS applications offer a similar set of capabilities, and as applications change on a bi-weekly or monthly basis, features are added on an on-going basis.

Even if one comes up with a revolutionary solution and provides the only SaaS offering of its kind, it is safe to say that within a year, three new SaaS companies will offer the same, or an improved set of capabilities.

So what differentiates one SaaS offering from another? It’s the Service, dummy!

Features don’t make a loyal customer – outstanding service does.

Scalability

There aren’t many SaaS companies out there that service a few dozen Fortune 200 companies while keeping the profitability high. The general rule is that margins are small and that profitability is achieved through hundreds or thousands of customers.

Giving great service to 20 or 30 customers is a no-brainer. Just throw more bodies at the problem and you will achieve a highly satisfied customer base.

But what happens when these numbers multiply rapidly? You’ll soon find out that what worked for a few dozens might collapse at the next order of magnitude.

When I approach SaaS companies at the stage when they already have a growing customer base and warn them about the perils of scaling up, the usual response I get is:

“I wish I will have to deal with that problem”, meaning that they would love to have 200 hundred customers that cause strain on the infrastructure and operations and deal with those ‘good’ problems then. It is only human to postpone these issues when they are not burning your behind.

To those CEOs I would say: “Pack your stuff, return the money to your investors and go look for another job elsewhere”.

Your investors did not give you their hard earned dollars for a proof of concept.

They invested in you because they believed that you will bring in thousands of customers.

My best clients are SaaS companies that come to me when they are in pain. They start loosing customers because they did not build an operation capable of handling the scale which they had wished for.

As I have stated time and again – SaaS companies usually consist of outstanding, creative developers that build great technology, but they don’t have the IT and/or operational experience. They lack the know-how and especially the methodology for building a successful, scalable operation.

Building Operations for Scalability

I have written much about these issues and they can all be found in previous blog postings.

Suffice to say that the setup you need to build for a scalable service operations includes:

· Methodology – the framework of practices, templates, workflows and tools

· Operations Support Systems – everything else your engineering team left out of the product.

· Executive buy-in and awareness -define the metrics, and provide tools to capture and analyze those metrics.

Can a Huff and Puff Blow Your House Down?

So what has all this to do with the Three Little Pigs?

The first little pig built a house of straw, since he didn’t have time to invest in operational infrastructure and wanted to make a quick exit. He ended his career as wolf poop.

The second little pig invested in a better infrastructure but did not pay attention to the practices and processes. He lasted longer in his wooden structure but was huffed and puffed and blown away by the competition.

The third little pig took his time and invested executive attention in doing it right from the start. He lived happily ever after.

So even if you cannot afford a brick house from day one, you should have the blueprints ready and the determination to add the bricks when they become available.

By the time the Scalability Wolf arrives, you should have a sturdy enough structure and react quickly to threats, to survive and prosper.

Private Clouds – What’s in a Name?

2010-06-10T04:57:00.000-07:00

“Happiness is like a cloud, if you stare at it long enough, it evaporates” - Sarah McLachlan

Remember when all of our secretaries and stewardesses turned into office managers and flight attendants overnight? Remember when all the co-los and server-hosting companies became cloud providers overnight?

(To alleviate all suspicions – as my readers know, I am an ardent advocate for Cloud computing and SaaS in particular, so this post is not about arguing the merits of this constructive and disruptive trend).

Cloud means different things to different people – but mainly it means “a cool way to market my same old, tired stuff”. I worked with a co-lo provider a couple of years back. A few months ago I went to their site to check prices and lo and behold: They became a Cloud Provider! They had clouds splashed all over their site and every solution they sold was a Cloud solution. I called up a sales person and asked about their elasticity and time units. Turns out they were elastic in one direction – you could always order more servers – and you only had to commit to one year in advance. On a geological time scale that is quite flexible. When I laughed and asked what was ‘cloudy’ about their offering, the guy got confused and said that his manager will get back to me.

So what is all this newspeak about Private Clouds?

Guess what is happening to the good ol’ data center? As David Linthicum aptly puts it in his latest blog post: “the reality is that ‘private cloud’ is just another term for on-premise systems”.

Point number one is that I find the term an Oxymoron:
Cloud means that it is ‘somewhere out there’; location is transparent. Cloud means sharing; resources are transparent. The physical server I used this morning might be used by someone else this afternoon.
Private means it is in my back yard and only I get to play in the sandbox.

Point number two is that even if we apply the Cloud concepts to the enterprise, it will be relevant to a very small number of very big players. Those enterprises that are truly global and distributed. They could take advantage of the peaks and troughs, of the "follow the sun" model, of the large numbers and justify the investment of a Cloud player.

And what about the rest of us mortals? Let’s assume that a certain percentage of our IT services will not transition to the cloud – be it regulation, compliance, perceived loss of control, or the illusion of maintaining job security. We should be using Cloud-enabling technologies, to make a smarter use of our resources and data centers. That means virtualization, automation, orchestration and auto-provisioning technologies. We only get the silver lining – not the cloud.

So the Private Cloud, in essence, is a wonderful opportunity for the big vendors out there to sell to the enterprises - new equipment, new systems and new services.

The SaaS VP Operations as Product Manager

2010-05-21T11:03:00.000-07:00

SaaS Operations Support Systems

“'Tis not enough to help the feeble up, but to support them after” - William Shakespeare

Every SaaS company needs to deal with numerous functions that are not necessarily part of the technological stack that originally came with the application, namely the Operations Support Systems.

If a SaaS start-up had unlimited time and funds to plan and build the perfect solution, they would probably all be in the Caribbean islands doing what people with unlimited time and funds do.

Just Do It!
Because of the nature of monetizing SaaS, companies try to get to market as soon as possible, getting subscriptions fees streaming in. Sometimes, they even launch with a half baked solution that will provide added value to the customers at the expense of future operational headaches.
The logic behind this is that dealing with a scalability problem, is a good thing. In other words - who doesn’t want to reach the stage when too many customers are taxing the team? We’ll deal with that when it becomes a problem.

These days, numerous PaaS offerings or SaaS frameworks offer built-in operational support systems functionality, but many of the necessary features are not supported.
Most of the SaaS application in the market were not built with these frameworks for various reasons. The most prevalent are that they were not available a few years ago, and that engineers have a tendency to build everything from scratch, or using frameworks (e.g. LAMP, Java, .Net, RoR) that they are familiar with.

When the typical SaaS service is launched, it lacks functionality that would support the scalability of the service operation. It is left to the Service Operations team to deal with all the 'maturity' functionality that the product lacks.

Let us examine some of the Operations Support Systems functions that are typically not handled by the application.

On-boarding new customers
One would expect most SaaS systems to have automatic provisioning. While that is true in many cases, a lot of the systems allow the customer to define users, but creating a new customer entity is left to the Support or Operations team. That may require generating a new database or schema, or setting up storage, etc. If the company is adding one customer a week, it may be manageable, but at a higher rate this is a taxing job and error prone.

De-provisioning
While it is expected that some level of automatic provisioning is provided with the product, very few SaaS applications provide a simple (never mind automatic) mechanism for removing existing customers. Very few SaaS developers design with of the prospect of loosing a customer in mind. Beyond the task of removing dependencies from the database, there are issues of releasing resources, and removing customizations.

Billing
Such a basic function, (one would think, for a company that lives or dies by subscriptions) is typically lacking from most SaaS infrastructures. While the situation is improving dramatically with the advent of PaaS and SaaS development frameworks, many systems still start out with excel sheets and a lot of manual work. Customer data must be extracted by some ad-hoc solution form the application database or is duplicated in the CRM, which causes endless synchronization errors. Ad-hoc solutions are implemented (either in-house or SaaS billing solutions) as the billing becomes ever more complex but until that occurs the brunt of the work falls upon the Operations team.
Metering is a whole new layer of complexity, if the billing is more complex than a fixed amount per seat per month.

Retention Policy
Some SaaS companies plan ahead for resource consumption by their customers, bur many start dealing with the issue only when they begin running out of storage, or when their storage costs are starting to hurt. Most customers want to retain their data forever on the provider’s disks, but that is impossible. So a retention policy must be defined and followed (such as delete files that are older than X months or larger than Y gigabytes).
The problem is that the application does not support that, so manual work is requried or ad-hoc solutions have to be built around the product.

Failover and Backup
Automatic recovery and failover are rarely built into the initial solution and are usually managed by the Operations team via building complex solutions with networking boxes.
This is true for backup and recovery mechanisms as well. The Operations team frequently has to build mechanisms around the production to support backup and recovery and most often they require much manual labor.

Application Monitoring
Well designed software is packed with instrumentation that is easy to turn on and off and easy to monitor and interpret. Not all SaaS systems have that built-in capability and the Operations team has to create an application-specific, monitoring infrastructure that can detect and react quickly to service degradation.

Seamless Upgrade
Upgrades are the recurring nightmare of any Operations team, especially on applications that have a demanding uptime SLA. Few SaaS systems are designed with that goal in mind. It usually takes a level of maturity and a sizeable customer base to get Engineering to consider revising the code to allow some sub-systems a no-downtime upgrade.
The problem is that is usually requires major revisions of the code if the system was not designed a-priori to handle a silent upgrade.

SLA Management
Whether you are using automated SLM or not (chances are you are not), you need to take into consideration the various aspects of your service that need to be metered, tracked and compared against a set of Service Level Objectives.

End User Broadcasting
Sometimes it is necessary to communicate with all of you users, or a sub group of them in real time. What a better option is there that to pop up a message on the end-user’s browser that you can compose on the spot or pull from a list of canned messages? The operations team need an integrated solution with the product to be able to do that.

Operations Console
And to tie it all up, a separate application that controls all the operational aspects of the service is needed. Included should be: provisioning/de-provisioning customers, password management, real-time login view of current users, real-time view of application usage, customer communication console, production environment control, etc.

There are many other operational features that are typically not found in a SaaS application as it leaves the factory floor. Just to mention a few: Integration, Reporting engine and reporting Database, Security, Scale-up and Scale-out capabilities, Sandbox, Status Page.

Development and Product management Experience Required

The VP Operations (or whatever title the job carries) is required to be a product manager of sorts, and a background in software development is almost a must. The Operations manager should be highly involved in the product roadmap and insist on having a say in defining future releases. There will be a contention between investing in Serviceability versus Functionality. Since the paying customers require more functionality, it is usually an uphill battle to gain service upgrades to the product.

While building an organic set of solutions into the product may practically take years, Operations cannot continue to throw bodies at solving scalability and downtime issues. So beyond influencing the product group on the direction in which the application should be developed, the Operations manager needs to build a set of tools addressing the Operations Support Systems needs as stated above. One option is to nurture a relationship with VP Engineering and get resources from her group to build well defined solutions that could each be completed in a couple of weeks of work. This is especially true in early stage companies where the Operations team is small and the engineers take the brunt of many of the operations’ tasks. The VP Engineering would appreciate the need as members of her team are feeling the pain as well.
In a more established company, the VP Operations must make sure that there are coding/scripting capabilities in the team, so simple projects and tools could be developed within the team, with minimal aid from the Engineering group.

Change Management and the Sanctity of Production

2010-03-18T06:47:00.000-07:00

“Most people are afraid of change. We love it!” (Sign of a beggar on a street in San Francisco, 2004)

Change is the greatest cause for service interruption in any IT operations. Period. Stop. Exclamation mark.
In the extreme, one might argue that change is the cause for every service interruption if one counts hardware or software malfunctions as a change as well.
SaaS operations tend to suffer more from a lack of proper change management for two reasons: First, the consequences of a service outage for a company whose entire existence depends on its service, is dire. Second, SaaS engineers, as I have written in numerous posts, lack the discipline that is more inherent in IT departments.

And yet, my experience has been that in most SaaS companies, changes are unsupervised, undocumented, unauthorized, unplanned, (sometimes unnecessary), underestimated and un_____ (fill in the blanks).

The importance of Change Management cannot be overstated and it is the first practice that I have implemented at companies that I worked at (or for). I wince when I recall the casualness which I have witnessed at various SaaS companies about making changes in the production system. I can quote my former boss, Mansur Salame, CEO of Contactual, saying that “production should be treated as sacred, with utmost respect appropriate to holy places” (or something of the sort). And, boy, were we sacrilegious back in those days!

In the Chapter on Change Management in the upcoming book, I will present my SaaS ITIL adaptation with much detail.

In this post I will outline some guidelines for sane change management.

Sixty Seconds on Change Management
Below are listed the objects that comprise a comprehensive Change Management practice.

RFC – Request for Change document. Must initiate the process, regardless how small or major the changes are. It should include the what, the why, the when, the risk, the potential impact (on customers or components), and a checklist of notifications and tests that should/should not be done.

A Change Window must be defined, clearly notating what type of changes to what subsystems are allowed at which days, during what hours.

Change Calendar – which might be implemented in a number of static or automatic formats, must represent the ‘Change Window’, and depict all planned changes by the company, service providers and customers, and must be part of the RFC process.

Change Advisory Board or CAB is the pre-determined group or people who scrutinize and approve the RFC. The CAB may be large or small but it should include at least one person who is not involved in the request and planning process. The CAB may meet on a recurring schedule or as needed.

A Change Record is a record describing a change that occurred in production or the eco-system. It could be implemented as a database or excel or within a ticketing system. It should include the what, when and impact (on customers or components). Much important information could be derived from this data store that pertains to the Incident and Availability Management practices.

The Maintenance Plan is a detailed document defining the pre-requisite tasks, the maintenance tasks, rollback tasks and post-maintenance tasks. Each task should have a description, an owner, a time and duration. In most cases the plan must be scrutinized to the lowest detail level, and practiced in a Pre-Production environment that should mimic the production environment as much as possible.

The sixty seconds are over. This was just a teaser. Obviously there are templates, workflows and a sleuth of details that tie all of these objects into a well-oiled practice. The book will expand on the details and include the workflows, the templates and methods for automation.
To summarize; as the market matures and competition thrives, the big differentiator will be the second ‘S’ in SaaS and customers will become less and less forgiving. If a SaaS company does not practice a robust Change Management practice it will end up paying in a frustrated staff and customer churn.

SLA Consequences to Service Operations

2010-01-31T16:04:00.000-08:00

"What, me worry?" (Alfred E. Neuman)

In my previous post I discussed some basic concepts about SLAs, SLOs and penalties. As promised, I am addressing the ‘who cares?’ question.

From a Service Operations point of view, you may shrug your shoulders and claim that these are issues with the Legal and Finance departments. Most likely you were brought on board later in the game and never viewed an SLA until your were forced to do so.

As the person responsible for keeping all the services up and running, it may be best to keep the SLA to a minimum. After all, a document containing vague language, with little commitment and liability would be hard to wave in front of your face when the service levels drop.

I will argue that vagueness will play against you. A tough SLA will require the company to adhere to the high service levels they are committed to, and yes, pay the penalties for breaching these agreements. Keep in mind that if your service level drops one time too many, the legalese you will be hiding behind will not save your butt when customers drop from the service or simply do not renew.

I would take it even one step further. I advocate that the Service Ops managers bonuses are tied to achieving those SLOs that will keep a smile on the customers’ faces. (typically up-time and response time, but in some cases there are other objectives that are crucial to the customers). The carrot and the stick should work nicely to assure that you are doing the utmost to live up to the agreements.

Commitments
Another issue that concerns you (Service Operations) is that Sales are making commitments that you are suppose to keep, usually without you ever knowing about it. Operations needs to initiate a fact finding effort to learn what is there. You need to know what you are capable of providing. Everybody likes to state that they are five nines (99.999% uptime) but how many companies out there really are? You need to monitor and test your service over a substantial period of time before you commit to those numbers.

Another point in favor of having a good grasp of your SLA is that you, as a consumer of services would be conscience of your requirements vis-à-vis your service providers.

That will include the hosting services, your ISP, your communications provider, and whatever cloud services you are using. In my past positions as VP Service Operations I have been appalled by the contracts that my predecessors have signed with service providers. Some of them had no consequences to service level degradation. Others had ridiculous clauses such as 'for every hour of downtime, the credit would be for one hour prorated service cost' which meant that there was no real penalty. Another contract stated that we could get out of the agreement if for three months in a row(!) the service provided was available for less that 75% of the time.
We would have been out of business by then.

Where are those damn SLAs?
As we have seen, SLAs that are broad and meaningful will be complex. Add to that various service levels such as Standard, Gold and Platinum and the fact that some customers have negotiated special terms for themselves, and you are dealing with a mean, slimy problem.

To compound that problem, nine times out of ten, these documents are sitting on someone’s laptop in a PDF format with perhaps a hard copy in a dusty folder, in the cabinet below the espresso machine.

Imagine the exercise of figuring out if an SLA was breached for a particular customer, and if that breach carries a penalty.

I have painfully gone through that exercise too many times, and believe you me - I had much better things to attend to following a service outage. The process was extremely slow, finding the various documents, looking up the terms and comparing the events with them.

Then a calculation was needed as to how much credit was due. And all this was done for a single customer. Multiply that by the number of customers that may have been affected and you have just wasted many good hours of Solitaire.

SLA Management Tools
There are multiple tools out there (some are offered as SaaS) to manage your SLAs. Many of them provide a full cycle of defining SLOs, creating SLAs, generating the documents, monitoring performances against obligations, computing compensation and generating reports. I have not used any of them (although I used to work at an SLM ISV), so am not about to promote any single one, but there are very slick solutions available.

If you are at an early stage, it would be hard sell for you to justify to management that you need to start paying for a service that possibly no one in the company comprehends.

Typically, when a SaaS company starts out there are very simple, non-abiding, fixed SLAs, so there is very little attention paid to this aspect of the business.

As with any aspect of SaaS Service Operations, scalability issues hit you when you least expect them.

As most (all?) SaaS companies do not start with Service Level Management software, by the time it becomes a burden they will have many dozens, or hundreds of such SLAs. The effort of converting them to an automated system is daunting.

Therefore, you can start structuring your existing and future SLAs into a simple excel, or DB so that they are easily accessible, and comparable.

An example of a typical SLA would be stored in a table such as below.
The values for the various SLOs in the table were automatically populated from the definitions in the pre-defined Platinum and Gold tables (which state the default values for these SLAs). They may be overridden by specific values, following negotiations for a particular customer.

Cust.	Calia	…	Google
Cust ID	123	…	213
SLSLA	Gold	…	Platinum
Uptime	99.9	…	99.99
Response time	under 6 sec	…	under 4 sec
Support Response time	2 hours	…	30 min
Support Avail.	12X6	…	24x7
Major Outage Resolution	1 hour	…	30 min
Partial outage resolution	4 hours	…	2 hours
Minor Outage Resolution	12 hours	…	6 hours
Maint. Notification	10 days	…	2 weeks
FTP	12 hrs	…	6 hours
Outage Notif.	Email 1 hours	…	email + call 30 min

In the book I will elaborate on the structures and the tools and how to automate the compensation computations.

SLA Management for SaaS

2009-11-12T21:39:00.000-08:00

“God does not ask about our ability, but our availability.” (Source unknown)

(Yet another chapter in the book - keep the feedback coming!)

As the second ‘S’ of SaaS indicates, the on-demand company is all about providing a service and therefore one would expect Service Level Agreements to be well defined and understood in this industry, but the facts tell another story. Few SaaS companies pay much attention to the SLAs, few companies really invest in it and most customers are quite clueless about it as well.

SLAs are tricky. Every SaaS provider is supposed to adhere to its service level commitments but on the whole, it is a document that most providers tend to keep out of the limelight and out of the conversation with customers. Judging from my experience, many SaaS companies use a single, non-abiding, standard SLA for all customers, keeping to a minimum their commitments and consequences.

An SLA, as its name suggests, is an agreement between the service provider and the consumers, consisting of sections regarding the various commitments to service levels that will be matched or exceeded.
Each section is defined as a Service Level Objective (SLO).

A typical SaaS SLA should have the following SLOs:

Service Availability – define the availability of the service represented in percentage (e.g. 99.95% uptime)
System Response Time – define response time of various transactions represented in seconds. (e.g. login should not take more than 9 seconds)
Customer Service Response Time – a response on customer enquiries should take no more than an allotted time for various services (e.g. enabling a service for a new group should take less than two business days)
Customer Service Availability – hours of availability of customer service represented in a ‘hours per day’ notation. (e.g. 11X5 for regular customers, 24X7 for platinum customers)
Service Outage Resolution Time – the times it takes to restore a service after an outage has been reported. Represented in minutes and hours (e.g. 30 minutes for a full system outage)
Failover Window For Disaster Recovery - how long will it take to restore the service in a disaster recovery site, if disaster disables the main datacenter.
Reclaiming Customer Data – a commitment to transfer all (agreed) data in an agreed format in case the customer leaves the service.
Maintenance Notification – the advance notice that the provider will notify customers of planned service outages, represented in days. (e.g. a planned downtime that will take more than one hour requires 10 business days notification)
Proactive Service Outage Notification - the time it takes for the provider to inform the customer that there are service issues, represented in minutes.
RFO (Reason for Outage) – a report to customers following a service outage explaining the circumstance, the incident and steps taken to remedy the problem. (For more information see the chapter on Incident Management). Some customers require an RFO automatically; in some SLAs it is written that an RFO will be generated only following a specific customer request. Usually the company commits to three business days following the service disruption.

Note the emphasis on should when referring to the SLOs of the document. The SLA provided by most on-demand companies consists of two or three paragraphs at most, regarding uptime, customer service availability and perhaps another one of the items above.
Many providers have additional services such as daily reports, daily data aggregations, or FTP services. Each one of these services merits an SLO that should be part of the document.

Some SLOs override others. In the example of an service outage, the Availability SLO takes precedence over the Response Time SLO, as you would not expect the performance of the system to be up to par when the system is down. On the other hand, this will kick start other SLOs such as Outage Notification, Resolution Time and Support Response Time.

Customer Expectations
Not all SaaS companies are created equal. They will vary by maturity, by the vertical they are serving, by the company size they cater for and, of course, by the type of application.
Some applications are core and some are peripheral. Some applications are used around the clock, like metering or call centers and the customers have zero tolerance for downtime. Other applications are rarely used outside of office hours, (e.g. payroll, talent management) and if the system is down, the price is a handful of irritated end-users that will need to take a coffee break earlier than they planned.
Larger customers tend to have more rigorous demands while lower paying customers will usually be more tolerant of the system’s performance and support availability.
Therefore, your SLA should reflect the relative position of your service along the following three vectors:

Customer size (reflecting subscription [potential] size)
Core vs. periphery
Downtime tolerance

So if you are providing a mission critical application to a large customer, whose downtime will cost the customer real dollars, your SLA should be taken very seriously.

Service Level Breaches and Penalties
We have seen the promises that come with the SLAs, but many of these agreements fail to state the consequences to the provider of not meeting the terms.
Each SLO should also define the penalties for breaching the service level commitment.
Penalties are typically specified as a prorated credit for the following month’s subscription fees.
From the customers’ point of view, the penalties should not be flat rated but increase as the service deteriorates, so that the second outage will carry a heavier penalty than the first outage. It is rare that customers insist on this point but those that do will need to negotiate these terms separately.

There is typically a maximum. It is unusual that accumulated penalties will top the monthly subscription costs. There is a catch here. As an extreme example, if your service was down for the duration of the whole month, the customer will be exempt from paying a full month’s service fee – but this is ridiculous of course. The damage to you customers is typically orders of magnitude higher than the subscription costs.
Many SaaS customers commit up front to a year or more of service, for a reduced subscription price. A good SLA will include a section that allows the customer to breach the extended commitment if the provider failed to adhere to the service levels for, say, three consecutive months.

The next chapter will outline what all of this means to the Service Operations group and why should you care about issues that initially seem to be in the domain of Sales, Legal and Finance.

Inter-department Communications

2009-11-08T21:30:00.000-08:00

(Yet another chapter in my upcoming book on SaaS Service Operations - Your feedback has been great so far; thanx and keep it coming.)

"The Problem with Communication is the illusion that it has been accomplished" - George Bernard Shaw

While it is true of any institution, communications between the various silos of the organization is particularly vital for the successful operations of a SaaS company.

The reason are that things happen much faster in an on-demand company, customers are in constant contact with the company and expectations are high for a fast turn around.

At a product company, when bad things happen to the application, nine times out of ten, the software company doesn’t even know about it, and the customer’s IT deals with it. The end user is rarely in touch with the product provider. The product salespeople tend to ‘shoot and forget’ once the commission has been paid. If things go bad, the customer can mostly blame itself for not deploying or maintaining the software correctly or for not doing its due diligence.

Multiple channel interaction
At a service company, on the other hand, a typical customer will interact through multiple channels continuously. The CIO may have a direct line to the SaaS CEO. The IT department may be in touch with professional services, and managers of the service on the customer end could be speaking with the Program Management group. Members of the Operations 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.

Customers, naturally, will be irritated when things aren’t going smoothly regarding any one of multiple scenarios. It may concern a delayed service initialization, an undelivered bug fix, an incomplete customization, an unsatisfactory report, or (ouch) a service outage. Part of the allure of on-demand service is a much faster turn around time in every aspect. The customers believe it and expect it.
Imagine the customer’s frustration when they call in any one of their contacts within the company to inquire about unresolved issues, and that person has no idea what they are talking about.

Disconnect between the groups
Typically, a SaaS company will be using a CRM that serves Sales and Customer Service. In many organizations the Sales view is radically different from the Support view and information available to one is not available to the other.
It is rare that other members have access to the CRM. Operations, Engineering, Professional Services and Program Management keep their own records in different systems for various reasons and are not trained in using a CRM.
Not surprisingly, the different silos do not have much knowledge of what each department is doing, and I have seen continuous tension between various groups and quite a lot of finger pointing when bad things happen.
It is also typical to see a startup company, where everybody occupies a single open space office, yet where so little communication takes place between the groups and political affiliations begin to form.
Resources are always limited and the demands are constantly growing; how does one prioritize the tasks and attention to a particular customer?

Service Outage and Communication
To illustrate through an acute, but none too rare, example: Many a time I had experienced a service outage that, for obvious reasons, took everybody’s focus and energy. A couple of offices down the hall sat the Sales team and across the continent were various regional Sales reps. They were not informed of the outage since they play no role in detecting, classifying or resolving the issue, and all those that knew about it were busy trying to fix it, or taking customer calls. Often the customers, especially the senior members who have established a close relationship with the sales reps, would call Sales or Program Management immediately asking for updates. The uninitiated sales rep would answer that they are not aware of any outage and perhaps the problem is local to the customer (This would usually trigger a nasty remark about the incompetency of the provider). The experienced sales rep would mutter something in embarrassment and then storm over to the Ops group demanding an explanation why, once again, Sales was not notified of the outage. Not only does the company look bad, but it also raises unnecessary tension between the groups
(This issue will be addressed in the chapter on Incident Management)

Recurring Mandated Meetings
Inter-department communication is the answer. If the managers of the different departments talk to each other on a regular and formal basis, issues can be addressed before they get out of control, plans can be communicated and a deeper understanding of the challenges of each department can be better understood.
Since Operations is at the center of it all at the end of the day, and since Operations will take the blame for whatever incident that occurs, VP Ops group should initiate these meetings. This initiative and meetings will also serve as an important PR tool for the service operations group.
Following are the inter-department sessions that should be standard in a SaaS organization to improve communication and visibility and to help prioritize tasks and address issues before they boil over.

Name: Daily Operations Sync
Frequency: Daily
Suggested Time: Late afternoon
Participants: Operations, Support, Program Mgmt
Agenda: Burning issues, Service outages, Planned maintenance, Delayed deliveries, Staffing

Name: Customer Success
Frequency: Weekly
Suggested Time: Monday
Participants: Sales, Program Mgmt, Support, Operations, Professional Services, R&D
Agenda: Customer Success Score sheet, Updates, Delays, Priorities. Address Red and Orange flags

Name: Operations-Engineering Sync
Frequency: Bi-Weekly
Suggested Time: Anytime
Participants: Operations, Engineering, QA
Agenda: Requirements, Releases, Known issues, Bugs, Dev/staging environment

Name: Company Fridays
Frequency: Bi-Weekly
Suggested Time: Friday Afternoon
Participants: All employees + food & beer
Agenda: Announcements, updates and department presentations

(In the book, these meeting would be discussed in more detail)

I cannot emphasize enough the importance of these meetings. Not only do they facilitate the smooth operations of the company, but they also foster better relations between the company’s groups.

Introduction to the book on SaaS Service Operations

2009-11-02T16:27:00.000-08:00

"You can't handle the truth!" (Col. Jessep in 'A Few Good Men')

As I have mentioned in a previous post, I am working my way through writing a book on SaaS Service Operations. Using the web as a collaborative tool, I have decided to share my work, bit by bit (three chapters, so far) to test it within the community and get live feedback from those who matter, potentially those that would read and recommend it.
Following is the (draft) introduction chapter. I would dearly appreciate your feedback on content, style, typos, grammar and whether you might find such a book an interesting read.
My initial thoughts about the title are along the lines of 'Survival Guide' or 'A day in a SaaS Emergency Room'.
I am not fishing for compliments - it will beat the purpose, and yes, I can handle the truth.
Many thanx,
Dani

Introduction – or Why am I Writing This Book.

Well, someone has to write it. Numerous words have been exhausted over the years on matters SaaS, but I have seen very little being written about SaaS Service Operations, and there are no books on this subject that I am aware of.

As SaaS is becoming mainstream, it has also become the most visible and mature service in the Cloud stack. Consumer expectations have elevated such that they are demanding fast response times and a service that delivers on the availability slogan of ‘anytime-anywhere’. These expectations do not refer only to the application; but also it is expected of the customer and professional services as well. SaaS companies often excel when it relates to the first ‘S’ of SaaS, i.e. Software, but fair quite poorly with regards to the second ‘S’ – Service.

What started as an experiment of the few and the brave, will soon become the major force in the software market, and what will differentiate one company from the rest is no longer the on-demand allure or the feature set, but the level of service it provides.

I am a war veteran in this respect and have many scars to parade. There are probably very few mistakes that I have not made. Being a descendant of Homo Sapiens Sapiens, I like to think of myself as one who has learned from his mistakes and taken steps to remedy them.

‘Operational Fatigue’ is a term I coined after the umpteenth time I was awoken in the wee hours of the morning to handle an outage that occurred yet once again, after having seemingly fixed the problem two weeks prior. I could have just as well created this phrase after the two hour scheduled downtime to upgrade the service. The upgrade turned into a nine hour nightmare that was finally resolved (a couple of minutes before our major customers started their workday) by some engineering heroics. As always, these were followed by heart wrenching phone calls to the CEOs of our customers to explain what went wrong (again) and why it would not repeat.
No wonder I grind my teeth at night.

Throughout my years of practice in this space I have discovered a number of traits across the industry:

Most SaaS companies are structured and behave in a similar fashion
Most SaaS companies lack the discipline, the tools and the practices to provide an efficient and effective service operation
Most SaaS companies, therefore, end up paying the price of not meeting their SLAs, which leads to customer dissatisfaction, customer churn and ‘Operational Fatigue’

The intended audience for this book is whomever is responsible for the quality of customer service. That includes the CEO, the CTO, VP Engineering, VP-Director-Manager of Operations and VP-Director-Manager of customer service. All of these functions must work in unison to ensure a smooth operation both outwardly and internally.

This book is divided into four sections:

The first section introduces concepts about SaaS, the evolution of the market and why the model is here to stay. Enough has been written about the subject so I will stick to some of my observations without going into a long dissertation.
The second section contains insights on service operations in an SaaS company. It includes various posts published on my blog (‘Dani’s Perspective on SaaS’), over the past year. It discusses typical SaaS operations, discipline, transparency, outsourcing in the Cloud, metrics, inter-department communications, etc.
The third section covers Operational Support Systems that might or might not be supported by the product. They include: Billing, On-Boarding, De-provisioning, Integration, Retention Policy, Communication and more.
The final section is instructional and lays out the principles of my adaptation of ITIL for SaaS Service Operations™ . It explains what ITIL is and why I chose ITIL as a basis for defining the practices of running an efficient and effective service operation. It covers six practices that I have developed and refined throughout the years at various companies with whom I worked either as an employee or as a consultant.

By following the practices, following the workflows and deploying the tools outlined in this book, SaaS companies can instill the discipline needed to reap the benefits in a surprisingly short time.

It is not complicated, it is not expensive, nor is there sorcery involved - it only requires awareness and leadership.

Cloud IaaS: Sorry, not very Interesting

2009-10-25T18:53:00.000-07:00

“There is an incessant influx of novelty into the world, and yet we tolerate incredible dullness” – Henry David Thoreau

Don’t get me wrong. Infrastructure-as-a-Service is a wonderful, useful and logical development. I do not need to sing the praise of it here. I believe in it and I am sure that it will provide a growing, significant percentage of computing needs around the globe.

But, it is just not very interesting, although it is the rage in all IT circles and hype generators. The technologies that enable it are basically: high speed bandwidth, virtualization and sophisticated management software. Now, I do not belittle these technologies. They are the product of years of development of ingenious engineers and some fast acting companies that had the ability to put one and one together and come up with the offering. And kudos to Amazon Web Services on leadership, ideas and execution.

Still, I believe that it is the domain of the few, and although every datacenter and ISP out there is starting to offer a ‘cloud’ solution, the end result will be a few very large companies that are big enough to invest in a model that makes economic sense and are sophisticated enough to pull it through.
So what does that say for technological companies that are thinking of providing IaaS-enabling software or hardware? There will survive only a handful of those companies, since they will be competing in such a small market.

So why is it such a hype, and why is it burning like a bushfire in the Kalahari savannah, while it took almost a decade for SaaS to become mainstream? Because the idea of IaaS is very simple and straightforward. IT gets it. Any old CIO can understand the concept, because hardware is a commodity and has been for a long time. Because many enterprises have been hosting in co-los for decades, acting as if their hardware is in their datacenter.
Once you get over the fear of losing control and get through the blah-blah of security, the idea of IaaS is very simple, and therefore, not interesting.

SaaS on the other hand is all about Applications. And applications are not perceived as a commodity (although many of the non-core applications are beginning to assume that role – and that’s a good thing). Therefore, once the hype will run its course and the dust Clouds will settle, IaaS will become mainstream. Every enterprise will choose how much of its infrastructure will lay outside of its firewalls and to what extent it will use the flexibility of the solution. SaaS will still be the interesting item, since every ISV will offer an on-demand solution, and the competition will continue to generate innovation and breakthroughs.

SaaS 70 – Nextgen Certification for On-demand companies

2009-09-08T16:37:00.000-07:00

“A certified lunatic is certified nonetheless” (Dani, 2009).

I was asked by one of my readers (note the plural) to include a chapter on SAS 70 in my upcoming book on SaaS Service Operations. I must admit that I was not sure if he was advocating SAS 70 or he wanted me to discuss certifications for SaaS, since I am not a fan of the former but a promoter of the latter.

Confusion is defining the SaaS market when it comes to certification.
Enterprise IT personnel certainly do not know what questions to ask, so they generate these long RFPs that are very similar to the on-premise RFPs, and they slap on top of it security questions that make their CSO officer feel important with a multitude of acronyms that are either relevant or not. Most on-demand ISVs wouldn’t know how to define a ‘certified’ SaaS either.

The good news is that the customer base is demanding assurances. While a few years back, the concerns were mostly security and mostly compared to on-premise solutions, the market is maturing and now there are a myriad on-demand solutions for every vertical or horizontal aspect of applications.
So how does an IT professional distinguish between the good and better solutions? How can she judge whether the SaaS provider will stand up to its SLAs, whether the data is secured and operational procedures exist and are followed?

SAS 70
The truth is, there are no authoritative answers to these questions nowadays. With a glowing lack of SaaS certification the only default out there is SAS 70.

Statement on Auditing Standards No.70 (SAS 70) is an internationally recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA) in 1992. It is used to report on the "processing of transactions by service organizations", which can be done by completing either a Type I or a Type II audit. A SAS 70 Type I is known as "reporting on controls placed in operation", while a SAS 70 Type II is known as "reporting on controls placed in operation" and "tests of operating effectiveness" (http://www.sas70.us.com/what-is/definition-of-sas70.php)

(Disclosure: I have not undergone a SAS 70 audit in the companies I worked for. My knowledge is based on reading and sharing other companies’ experiences)

What’s good about SAS 70
The fact that SaaS companies want to take the extra (expensive) step to distinguish themselves from the rest of the pack, shows a level of maturity and seriousness about their business. SAS 70 requires that you have a set of practices and that you are following them.
This in itself is a big step forward for most SaaS companies – they actually have a set of defined practices.
Sorry, only two short paragraphs on the benefits.

The shortcomings of SAS 70
This audit was not defined for SaaS. It was developed in 1992, years before even ASPs were in vogue. It is a general audit for service organizations and covers a wide range of businesses, from credit processing, to medical insurance and data processing.
There are no specifics for an on-demand software company. Heck, there are no specifics for a software company either.

Please note the language “A SAS 70 audit helps companies meet regulatory compliance…”, and “a SAS 70 audit provides an additional layer of accountability…”
Nowhere does is state that it certifies the company at any level, other than the fact that the audit was done.
It reminds me of cosmetic advertizing “makes your skin feel younger” – how very scientific.
There are no recommendations, no standards to meet, no right or wrong. It merely states that you have practices (good or bad) in place, and that you are following them.

As mentioned, the mere fact that there are defined practices exhibits a level of maturity, so I do not belittle the exercise, but there are no provisions in SAS 70 to avoid documenting your bad practices and following them through.

SaaS 70
There is a dire need for a certification program for SaaS companies as the domain matures and SaaS becomes a major component of IT.
IT wants to know that you are a competent service operator, that you are running a tight shop and that the service will be around next Thanksgiving.
I am suggesting a certification program, currently named SaaS 70 (to demonstrate my famous wit), which includes three elements:

Service Operational Maturity – Has the company defined and implemented practices and procedures for running a robust operation, to ensure that SLAs are met? This would include Change Mgmt, Release Mgmt, Incident mgmt, Event Mgmt, Availability Mgmt, On-boarding, de-provisioning, integration, data retention, etc.

Security – covering all aspects of password policies, data separation, vulnerability testing, virus protection, privacy, etc.

Service Continuity – examining the financial viability of the company and what plans are in place to continue providing the service even if the ISV goes belly-up.

Within each component the company will score a level of maturity beyond a pass/fail that comprises coverage, depth, documentation, and tools. And, of course, the report will include recommendations for improvement and scaling up the maturity ladder.

Only with such a specific, SaaS-centric, verifiable and accountable program, will the consumer of these on-demand services know that a company can or cannot meet their expectations.

Discipline (or lack thereof) and Operational Fatigue

2009-08-20T09:37:00.000-07:00

“Half of life is luck; the other half is discipline - and that’s the important half, for without discipline you wouldn’t know what to do with luck”- Carl Zuckmeyer

Creative and nonconformists
SaaS companies are mostly composed of a group of highly capable software engineers. These techies are, by nature, creative, imaginative, out-of-the-box engineers, inventing new ideas or new ways of achieving better results. They tend to adopt the latest and greatest technologies and are always looking forward to the next best thing.
Naturally, these engineers are nonconformists and not inclined to follow rules or to stick to routine.
Almost always, they do not come from an enterprise IT environment, where rules and regulations are stricter and operational practices are followed almost religiously.
With the nascent state of SaaS, if the engineers have prior experience, it would mostly come from on-premise, product companies that emphasize features, versatility and usability.
They rarely had to deal with customers, and bugs that were found were handled according to their priority to be fixed in the next release (which could be months away).
Therefore, typical SaaS engineers lack the necessary discipline to run a 24X7 service, and are usually hostile to restrictions imposed on them.

What, me worry?
The lack of discipline manifests itself mainly in Change Management and consequently in Asset Management and, then, consequently in Incident Management.
This refers to what changes are allowed to be done when (‘hey, just to let you guys know, I installed the new patch during lunch break’), how are they approved and communicated (‘yeah, no prob, I tested the code on my laptop – it is foolproof, just a small change in the parsing engine’) how they are recorded and rolled back if necessary (‘don’t worry, I keep all changes in a dedicated notepad on my machine’).
There usually are no rules about touching production. Typically, every engineer has full SUDO access to all servers in the data center, using a single super-user login, so that activities cannot be traced to any specific person.
One-offs can be installed on a particular server and not be documented. Months later when a new version is installed or a server replaced, things fail to work and it may take hours for someone to remember that a special component is not functioning any more.
Lack of a fully functional staging environment may cause an engineer to ‘temporarily test’ some feature on a production machine that either causes service disruption or is forgotten until the fan turns brown.

Operational Fatigue
Operational Fatigue is a term I coined after years in the trenches, of waking up at 3:00 AM to deal with the same problem that hit us three weeks ago; of the stress of dealing with an incident at peak time when Management is hysterical, when Sales are complaining, when Support is overwhelmed with frustrated customers; of making the calls to the high profile customers, explaining, apologizing, promising; of having to explain to the Board why we lost so many customers this quarter.
It gets to you. You discover new gray hair and develop a fear of answering the phone.

The point is – it is avoidable. Instilling the practices and discipline can make life so much easier and allow the ops team to plan and improve instead of fighting fires all the time.

Educating the young
Like toddlers, engineers crave for guidance and discipline, but as most parents would testify, they will make every attempt to break the rules and stretch the envelope to test the boundaries of their environment. Experienced parents will tell you that the young children feel much more secure when they know the rules and when the rules are being enforced. It has been my experience that when I introduced a new set of regulations such as in Change Management, there is always an initial push-back, mumbling about bureaucracy and attempts to circumvent the rules in the beginning. But I have always seen a quick adoption of the new regulations, followed by a realization that life would be so much better if we only stick to the rules – these guys are smart, you know. Many a disaster was avoided by playing the game by the new rules and I found out how quickly the engineers embraced the discipline and started devising ways to improve on and automate the processes.

Just do it!
I recently participated in a round table hosted by HP on the subject of Change Management. Most of the participants were from large IT shops and were talking about adapting to new Change Management processes in terms of six to twelve months. I was astonished. I concede that my background has been with much smaller groups, and I had the full backing of the executive management, but twelve months? Jeez!

The process in my experience was:
· Prepare the documents, templates and work-flows.
· Make a compelling Power Point presentation.
· Present to the Engineering, Ops and Support groups.
· Emphasize the consequences of not following the practice (genitalia hanging at high altitude)
And Voila - It works! A few weeks later you have a spiritual following of admirers, because the fruits of the labor are so obvious in a very short time.

Transparency in SaaS Service Operations

2009-08-13T11:17:00.000-07:00

“Life is filigree work. What is written clearly is not worth much, it's the transparency that counts.” - Louis-Ferdinand Celine

Companies like to boast about their transparency, but in practice, information dissemination is highly controlled. At an on-demand company, hiding the backstage operations seems like a smart thing to do. As long as you are servicing the customer, and as long at the customers do not complain, why should you wash your dirty laundry in the public?
So what about SLAs? The guiding principle seems to be ‘Don’t worry about them if your customers do not demand them’. And even when they do, there are SLAs and then there are SLAs. There are so many ways to interpret these elusive numbers (assuming you even know the real ones) that most companies will portray better results than those that reflect reality.

Varying degrees
There are different modes of Transparency communications; from the non existent to the reactive, the proactive and full disclosure.

The reactive type is the common case where there are service disruptions and customers call in to complain. In this case you will determine how much information you would like to divulge. This could be done with a customer call, an RFO (Reason for Outage) that is sent to particular customers or a message on the corporate site.

A proactive approach would have a Service Status Page depicting the current service availability of the various production systems.

A full disclosure mode will provide customers with a historical view of production systems availability and response time such at Salesforce’s Trust or SAManage’s Status Page .

Advantages of Transparency
My experience has been that the more transparent you are with your customers, the better relationship you will foster with them and the more forgiving they will be when things turn sour. And things do turn sour; it is unavoidable.
Your customers are not dumb (in general, that is – I can relate many amusing stories of individuals that should have not been awarded fourth grade graduation, but that is another story). The people on the other end generally understand that you are dealing with a complex environment with many factors that are not always under your control. They will be willing to accept that scheisse happens, but they also must know that you are ready to accept responsibility and learn from these events. There should be a closure process for each event including Incident Recording, Post Mortem, RFO communication (more on that in Incident Management).
Of course, nothing beats a good, reliable, available and responsive service. If you are not able to provide that, you will end up loosing your customers regardless of how much camouflage and finger pointing are used to cover the smell.

How transparent should you be?
I am not advocating that you have to run out and tell the guys every time you messed up or that you should bombard the customers with a technical exposition as part of the RFO document.
Striking the balance is an art that comes with practice and common sense. If an incident occurred that did not disrupt services, you must undergo the full Incident life-cycle practice to ensure that lessons are learned and the incident will not repeat. But you do not necessarily have to go and boast about it.
As for the RFO, in my days I have been asked to put my signature on many customer facing documents that had a bland, general, canned message that meant nothing to the reader. (“service was lost do to a system failure”). I realized that customers will not trust the messaging and choose to either ignore it while snorting in disgust or have a techie call in and start drilling the poor customer service rep for technical details which would be hard to provide.
I have also seen RFOs that contained multiple pages and read like a PHd dissertation in electronic engineering. I do not know who approved these RFOs and if the purpose was to wear down the suffering reader so that further RFOs will never be requested.

Company Culture
And finally, keep in mind that if the company’s culture tolerates half-truths and spins when facing the customer, you run the risk of it percolating through the company’s internal activities and reports. Don’t you expect your employees to be truthful, accountable and not shy away from reporting mistakes, even if it makes them look not too great? Your customers have to expect your company to do the same. And, if the results of truthful reporting will cost you a customer then something was probably wrong with the relationship to begin with, and the customer may have been looking for an excuse to break away.

Can SaaS Companies Go Back to Basics?

2009-07-20T07:51:00.000-07:00

"Change is a bouncing ball on the circumference of a circle"

I was recently at an AWS conference and met with a substantial number of SaaS companies that are running their full production on the Amazon EC2 and S3, albeit all were relatively early stage, smaller companies. I spoke with half a dozen VP Ops or their equivalents, and all stated that they were satisfied with the service and the uptime, and did not experience major outages.
I have also met recently with a number of successful SaaS companies that we under 20 people total – and that includes R&D and Sales & Marketing and running the 24X7 operations.

So it got me thinking that if SaaS companies can do well without the need to deal with hardly any aspect of the infrastructure we may be approaching a completion of full circle.

History 101

Since the dawn of time (January 1, 1970 – Unix time, that is) there were software companies. If they were successful, they excelled at writing software and testing it, and with time developed good professional services capabilities. And of course they needed to know how to market themselves and sell, and partner – but that was true of any company out there, whether they were manufacturing rubber gaskets or CAD software.

Fast forward to the post-boom, post-ASP era, and a new breed of software vendors appeared on the scene. As they were pioneering the new on-demand model; they all owned their infrastructure, and probably some of them were even hosting the hardware in their own back office.
These new SaaS vendors had to have expertise in their domain and their software, of course, but also in operations, 24X7 customer support, servers, power, storage, DBs, networking, security, performance and load testing, on top of the mastering the model of selling services rather than software.

As the market rapidly expanded, SaaS enablement companies grew around these new vendors, and started offering hosting at first (real estate and power), then networking capabilities, and then basic network monitoring services.

Two trends developed. On one hand, Managed Services companies (e.g. IP-Soft) offered to take over all the routine operations of managing the infrastructure up to the application level. That included monitoring and maintaining the network gear, servers, storage, DBs, Web servers and their respective operating systems.
On the other hand one saw the rise of Managed Hosting companies (e.g. Rackspace).that rented out the hardware itself on top of the real estate and offered ever growing services around the hardware.

And, there are companies (such as OpSource) that offer everything from hosting, to servers, storage, application management, 1st and 2nd tier helpdesk, as well as reading you bedtime stories.

Now we are seeing companies that offer QA services (especially performance, but not limited to), security services, integration services (AKA Professional Services), 24X7 answering services and tucking you into bed.

It is too early to tell how successful this ecosystem will turn out to be, and what percent of SaaS companies will subscribe to this model, but the emerging trend is clear – SaaS companies are offered the opportunity to go back and do what they do best – write software.

Nobody Does it Better

The question is where do you draw the line? Keep in mind that the success of a SaaS company relies mostly on the second S (Service) and less on the first S (Software), or put another way – depending on the execution more than the quality of the software.

I see a number of areas that must be directly managed by the SaaS staff:

Product development
Customer relationships
Application management

As for functional testing, performance testing, security testing – they may all be outsourced, but never relinquish control of these processes.
Ditto for professional/integration services – you may hire an outsourcer/partner to perform these functions, but ultimately, the customer success lies at your door.

My friend and SaaS networking expert, Gil, says that you should never outsource the infra or the management of it because nobody will take care of your baby as good as yourself.

I recently had a conversation with a managed services account manager that confided in me that managing the infra of SaaS companies is far more difficult than that of your average enterprise IT, since the SaaS companies are far more sophisticated, have deeper technological understandings and higher availability and response requirements.

Another question is at what point do you want to take back ownership? Does a certain size and complexity of the service and business justify bringing in your own teams of experts to handle those tasks listed above? The cost of doing it yourself will probably start going down as you grow, but the company’s values might dictate sticking to the core competencies – Hey, isn’t that what the SaaS offering is all about?

Questions that SaaS executives must be able to answer - KPIs that matter.

2009-05-20T17:30:00.000-07:00

“There is much pleasure to be gained from useless knowledge” (Bertrand Russell)

It has been my experience that SaaS executives have trouble answering the most basic questions about their service operations, and mind you, this is what the business is all about.

Again and again, I keep coming back to the conclusion that the fact that state of SaaS Service Operations is so dire is due to the fact that on-demand companies are built on the first ‘S’ (software) and not the second 'S' (Service).

SaaS entrepreneurs are, in general, bright, creative, out-of-the-box thinkers. They are software developers and have no clue about IT practices and disciplines.

The age old premise “if you can't measure it you can't manage it” somehow escapes SaaS companies across the globe, until it becomes a huge problem.

Have you gone through the numbing process of presenting a specific customer with their real SLA adherence? I have. On average, it would take me a few hours of going through multiple sources of data to come up with (sometimes) accurate data.

Following are a number of questions (an incomplete list) that every SaaS executive should be able to answer in her sleep, or at least with a click of a button.

1. Availability management

What are your real uptime numbers?
How do the trialing twelve months (TTM) look like
Are we better than we were six months ago?
How many outages have you had in the last M months?
What is the breakdown, based on severity?
What is the breakdown, based on downtime causes?
How many service disruption incidents were repeated?
How quickly do you recover from outages?
How many days have gone by without a critical, major outage?

2. SLA Management

How does your availability match up to your customer commitments?
Which customers were affected most (even if they do not complain)?

3. Change Management

How often are changes made to the production environment?
What is the breakdown of changes by category?
What percent of changes did you have to roll back?

4. Asset management

What is the status of your inventory? What box is located where?
What function or customer would be impacted by a loss of a certain box?
When do your support/software contracts expire and what might it affect?

5. Cost Management

What are the actual costs of the operations?
How is the budget allocated among the various components?
How much does each new (N) customer(s) cost?
Are we getting the full value from our supply chain?

6. Churn Management

How many customers have you lost in the past 6, 12, 24 months?
Is your customer retention improving over time?
What percent is your customer churn out of your customer base?
What is the average retention time of your customers?
What is the breakdown, based on reasons for churn?

I am well aware of the fact that there are no integrated solutions for the SMB supporting a database for these crucial KPIs, but every company should have some form of repository capturing at least some of the data and a easy way of extracting it.

The important issue here is that SaaS companies should be aware of these KPIs and start asking these questions, even if they do not yet have all the answers.

Maturity Model for SaaS Service Operations

2009-03-21T17:49:00.000-07:00

Given the state in which most SaaS companies are, and the fact that within a very short time span, ISVs will be equated with SaaS, I believe it is time to offer a Maturity Model for SaaS Service Operations.

A methodological approach would be to create a table of practices and mark a numeric value, in order to quantify the maturity state of a company. But that is too simplistic and doesn’t take into account that various practices will exist in some form at each maturity level.

The following is a proposal (a first draft), and I invite all to comment and help zero in on the right model.
Note: Release management is not covered in this model. It is arguably a role shared by the Product, Engineering and Ops groups.

Level 1:
This is probably where most of the SaaS startups are right now. The Ops team is either non existent or consists of a sys admin, help from engineering and a cat. None of the ITSM processes are defined, and there is no orderly asset management in place. Customer support may be handled by a small dedicated team, or even by Engineering.
In the latter case, 24X7 support consists of the cell phones of the CEO and VP Engineering.
Event management is at a very basic level, reporting whether a server is up or down.
Perhaps, a daily backup of the database is in place.

Level 2:
A small operations team is in place. Probably run by a manager/Director level person. A network engineer and a sys-admin make up the team with some help of a part time DBA.
Asset Management consists of a number of excel sheets, not necessarily up-to-date or all inclusive.
A half baked Change Management process is defined, but not really adhered to. Engineers still have access to the production system. A customer support team is in place. Not yet a 24x7 operations. Incident Management consists of people running around like chickens with their heads cut off, but there is a recording of the incident in the CRM, or perhaps a ticketing system. Event Management is implemented through a tool like Nagios or Cacti (freebies, of course) and email alerts are sent on threshold breach. There may be thousands of email alerts sent a day, so that real alerts drown in the flood.
A full daily backup of the database is in place and an hourly differential backup is taken.

Level 3:
A VP Service Operations runs the team of Customer Support and Operations. Change Management and Incident Management are defined and implemented. There is an Asset Management DB which is linked to Change and Incident. Change Window is defined and a Change Calendar is used. A semi automated notification process is in place (internal and external notifications). A staging environment is in place, although it does not fully reflect the production environment. Event Management is better controlled, noises are filtered out from the alerts, and some application level instrumentation is incorporated.
Getting individual customers’ SLA is still a manual process, though the information should be available.
A seed of a disaster recovery site is in place. It may take many hours to get it up and running (including transferring the data), but an alternative site with the basic functionality is available.
SAS 70 Type I should be in place at this stage, or at least have a good story about how you vendors are all SAS 70 Type II. (Mind you, I am not an advocate of SAS 70, but it seems like the industry is pushing for this, or at least a bunch of compliance consultants are)

Level 4:
Event Management is fully implemented: Application level monitoring is in place. Synthetic transactions are generated from multiple global locations. Alerts have context sensitive pointers to knowledgebase. A 24x7 NOC is implemented with a dashboard of all event feeds.
An Incident DB is implemented, which is used to generate SLA reports, incident analysis and availability analysis. A Change DB is in place used for Change analysis and for Incident Management. A CAB (Change Advisory Committee) is defined and regular meetings are scheduled. A Service Status page is in place with up to the moment status reports on the services. Customer and Internal notifications are automated and a full Incident Management closure process is implemented. Management reports are available for service status, trailing N months, SLAs across customers, availability across customers and production systems.
Customer/Component mapping is in place.
A Staging environment exists, fully mimicking the production functionality (not necessarily the network/server setup).
A secondary site is up and running with full functionality and a synched database. Switching between sites should take less that one hour.
SAS 70 Type II compliance is in place.

Level 5:
Bliss. ITIL practices are implemented across the board. (I am not advocating ITIL proper, but I am using the vocabulary to describe the practices). A functioning, up-to-date CMDB is the heart of the system (yeah, dream on). Application management automation is in place. A full Staging environment is in place, fully representing the production environment 1:1.
Quality of service takes a leading role and continuous improvements are sought.
Transparency and customers communication is at the highest level. Executive management has full visibility into every aspect of the service operations. All practices are linked and managed through a comprehensive ITSM management suite.
A complete disaster recovery site is up and running with the ability to switch between sites on the fly.

There. Step one in defining the Maturity Model for SaaS Service Operations is complete.
I hope to get feedback to validate the model.

SaaS and Automated Application Management

2009-03-17T17:36:00.001-07:00

A quick blog this time.

I have been asked by a great new company Nolio, to write a few blog posts for their new blog site.

Nolio automates all key processes needed to service and manage applications across your data center, improving application uptime and quality, while streamlining operations for immediate productivity gains.

I have seen their product and was impressed to the point that I am hooking them up with a number of SaaS companies.

Please read the two blog posts. A third is on the way.

Of Dinosaurs and Men – Why Traditional ISVs Will Fail On SaaS

2009-01-24T16:19:00.000-08:00

Dinosaurs were an extremely successful model. They roamed the earth and multiplied and were the indisputable rulers of this planet for hundreds of millions of years.

They were not very fast, necessarily, nor even nice to their customers (some of them are reputed to have actually eaten their customers), but they were successful because they had spent millenia adapting to the existing environment, perfecting their model to make the most out of it.

Then an unexpected event occurred (some scientists believe a meteor hit the earth creating a nuclear winter while others claim it was fast, cheap internet and tightening IT budgets) and soon all dinosaurs went extinct. Well, not all. Two groups were not annihilated. There were those alligators that stayed in their swamp (niche) and are doing pretty well, thank you, still today. The other group consisted of small reptiles that were driven to grow wings since the larger crawlers ate up all the easily available resources. These birds were lucky to be able to adapt quickly to the changing environment and survive the downfall of their relatives.

The fast moving, warm blooded mammals were better equipped to deal with the new brave world and many have grown to become true behemoth.

In a previous post I revealed the fact that I have mostly stopped advising the traditional on-premise, enterprise, perpetual, software vendor on the transition to on-demand, subscription model, i.e. SaaS.

This is not because I do not believe that it is a smart move, or that the ISVs would not benefit from the transition. Far from it! I envision a world, not too far in the future, where on-premise software would be the exception, not the rule, and even that exception would point to a dwindling model that would survive in niche markets only (swamps) .

My experience, which is supported by many famous (SAP and Avaia for starters) and less famous companies, has been that most traditional, on-premise, enterprise ISVs will fail miserably in the transition to SaaS. I have advised to companies that started out with great enthusiasm that dwindled to a silent death. They simply do not have the DNA for it.

I am talking about the right STUFF that is inherently lacking in established enterprise ISVs that will allow them to make the successful transition. This is not a comment about these companies’ value or success. It is usually inversely proportionate. The more successful the company is, the more entrenched it is likely to be in doing things the ‘right way’ – right, as far as the traditional model dictates.

These ISVs have a product view, not a service view. Their emphasis is on features not serviceability. There is a lot of push back from every silo in the organization, for change, in general, and the SaaS change in particular. It requires a paradigm shift in the organization, and the bigger, more established that organization is, the more difficult it is to bring about that change. (See Impact on the ISV Organization July 02, for a detailed account)

Until a couple of years ago, one could say that most ISVs just don’t get it. But that is no longer the case.

Many traditional ISVs saw their market share being cannibalized by these fast moving SaaS companies. Many heard their customers ask about an on-demand offering and many understand that it is vital that they have a “me too” offering. One cannot ignore the changes in the market and shrug it off as a fad. SaaS used to be a way to work around IT; now CIOs are building on-demand strategies for their business and even starting to use on-demand tools in IT.

So, there is a much deeper understanding of the need to offer an on demand service, but very few ISVs understand that it means a total commitment from the executive level and down.

Not that it is impossible. I have worked with a company whose board made the decision to go Services. They replaced the CEO, who in turn replaced all the senior staff, save the VP engineering. The new VP Sales brought in a fresh new sales force. Then they went through the process of rewriting most of the application from scratch. This process took about a year. They are now a successful SaaS vendor, but they got as close to re-encoding their DNA as possible.

And, of course, there known successful enterprises such as Oracle on demand, HP SaaS (former Mercury Managed Services) and others that had successfully launched their on-demand services, but they are the exception to the rule.

Dinosaurs were magnificent creatures and it sad that we don't have them around any longer (except on isolated islands in the Pacific), but their only fault was that they were too successful for the 'old world' model. I wonder how many software alligators will still be around a decade form now.

Quick response to a silly blog

2008-08-14T17:32:00.000-07:00

Normally, I have my own plans for what I want to post on my blog and I leave the fencing for the US women's Olympic team.
BUT, this morning I received an email from a friend who is also a CEO of a SaaS company, pointing out a new post with an outrageous title Why You Should Steer Your Customer Away from SaaS , for Now asking me to comment on it in my blog.

Frank's argument was that since Goggle's Gmail had an outage " just mention Google and Amazon's problems and a shadow of doubt can be place over the whole hosted applications market" He goes on to say that cloud computing (SaaS) "is just a pipe dream" and that we should resort to good old reliable client server technology.

I told my friendly CEO that it is such a non-issue that I don't think I should waste a good posting on it, but I did add a comment to the blog.
As the day went by and my comment was neither posted nor acknowledged, I decided to use this forum to respond.

So, my comment went something like this:

I can't believe we are even having this discussion. This is not 2003 when people were discussing the merits of this novel delivery system. As Dave Rosenberg pointed yesterday in his Negative Approach blog "Software-as-a-Service is so common it's actually boring at this point"
Frank's argument is as valid as steering customers away from motor cars back to horse drawn carts, because accidents happen.
SaaS companies make a living out of providing these services. Although I do not have the statistics, I know from numerous interactions with many companies that your average SaaS uptime figures are far better than your average IT department's.
Part of the success of SaaS has to do with the fact that IT was simply not delivering the goods, not in performance nor availability, so the business units went out looking for someone who could deliver a better service, NOW.

There. I don't think I need to splash in the mud much more. I must say though that I feel like I'm playing out a scene from Back to the Future IV.

Your Typical SaaS Operations

2008-08-07T15:27:00.000-07:00

Personal note: For those avid fan(s) that have wondered why I have disappeared for such a long time. I took a long, forced vacation, having been sucked into what is not commonly known as the SaaS Operations Black Hole. I went under the radar as VP Operations and Services in a SaaS company, and although it did not leave me time to write blogs or visit the bathroom, I have collected an arsenal of good stuff from hands-on experience, both good and bad, which I intend to share, time allowing.
(One of the reasons I changed my vocation as a consultant to on-premise companies who were contemplating going on-demand, was my realization that it was mostly a futile attempt. It is the equivalent of turning slow moving, cold-blooded dinosaurs into fast, warm-blooded mammals without the benefit of a few hundred million years of evolution. But more on that in a future blog.)

Very well, back to the subject at hand. I have been visiting, talking to, sharing with, advising many SaaS startups in the SF Bay Area in the past year and a clear (actually murky) state of affairs seems to emerge

Company Profile:

Name: YTSC (Your Typical SaaS Company)

Age: 3-4 years in the making.

Staff: between 20-40 people, possibly a small dev team offshore in Southeast Asia or one of the former Soviet Union republics.

Technology: Being relatively fresh, YTCS technology is multi-tenant, customer-centric, with (hopefully) an automatic customer on-boarding mechanism, and they surely have an integration with Salseforce.com (or perhaps NetSuite, SugarCRM, MSDynamics, etc.). Some fancy configuration capabilities should be built into the product and Web Services integration options are available.

Platform: most probably a LAMP shop. Let’s start with all the free stuff and hope to reach profitability before loading the heavy guns. And, hey, we’re big advocates of open-source.

Sales force Compensation: Hmm, we read all the papers, attended the webinars. We think we’re getting it right, but why does the Sales department feel like Grand Central Station?

Customers: A lot of mom & pop shops, a bunch of WEB 2.0 companies with flamboyant logos, a number of departmental customers with big names that we flash on our web site.

Profitability: Surely by next year.

YTSC is now poised for accelerated growth. The customers seem to like the service and the price, and it looks like the numbers will grow rapidly; at least this is what YTSC’s newly acquired VP of Sales has projected.

So how is YTSC prepared for this rapid growth? Do they have the People, Practices and Programs (P-cube) in place? Are they ready to scale from dozens of customers to hundreds and, hopefully, thousands?

My guess is NO. Let me think about that for a moment… Naw.

So why does it look unpromising? Being typical, YTSC Operations has the following traits:

Operations is under the auspices of Engineering. There is no VP of Operations; there is no Operations group. A Sys Admin is managing the production servers and probably doing office IT on the side.

The CTO is responsible for uptime, availability and performance. Does the CTO have an Operations background? I'll bet my lunch money that he doesn't. Is there a Staging platform? Probably not. Can the engineers log into production servers and modify configurations? Yeah. Actually we just fixed that nasty bug during lunch break.

There is no application-level monitoring in place, or trend analysis.

Is Customer Churn being tracked and analyzed? (What? What was that?)

There is no 24X7 support, although YTSC claims it is a 24X7 shop.

Are the following crucial practices defined and followed?

Change management – the cause of over 60% of downtime is caused by good intentioned modifications to the platform. Is there a proper process in place? Is there an RFC (Request For Change) form and procedure? A change committee?

Incident Management – are Support, Operations and Engineering aligned in a well rehearsed routine; roles and responsibilities defined? Is there an Incident management system in place? How about a knowledgebase?

Configuration Management – are hundreds of moving parts accounted for? Are they linked into the Change Management process – actually, we don’t have a Change Management practice.

Availability Management – how do you analyze unavailability? How do you “budget” downtime? Do you know where to invest your next Dollar to ensure optimal availability? It should be all tied into an Incident management system. But, wait we don’t have one.

Release Management – how, when, how often, naming conventions. How does it tie into Change Management and Configuration Management?

SLA Management – Are we providing what we promised? Are we tracking effect of incidents on customers? Are we compensating them according to our contractual commitments? Is it tied into our (hosted) CRM solution? Hard to do without an Incident Management system.

Are we any better than we were last month, last year? Can anybody tell?

No doubt, parts of these practices have been in place with less fancy names. Otherwise YTSC would not have survived this far. But Excel and Notepad will not suffice for a large scale operation.

Most companies understand that (or maybe that is wishful thinking), but when having to chose between investing the next Dollar in great features that customers have been begging for, or that ugly, boring, misunderstood, 800 pound gorilla, they will opt for the former. Pay now or pay later.

I will cover some of these practices in future posts, Google willing.

The Central Role of Operations

2006-12-07T14:09:00.000-08:00

"Computers are useless. They can only give you answers." (Pablo Picasso)

The Operations group is an odd duck for the traditional, on-premise, enterprise ISV. Those ISVs that are transitioning to the SaaS model are typically not familiar with this group, its role and perhaps its reason for being, and in some cases you might find Operations reporting to the CFO as a ‘cost center’.

But in a SaaS shop, the Ops group is the hub of all activity. Its crucial and main job, of course, is to ‘keep the lights on’ and do that in a highly available, quality performance fashion. Maintaining a scalable, fail proof service is a task that the Ops group should, in time, perfect to the notion of ‘auto-pilot’, implementing the Automate and Delegate principles (see Reducing SaaS Operational Costs).
But that is not where the job ends; indeed it is only the beginning.

In some early stage SaaS operations (either a pure SaaS player or an ISV in transition), R&D and IT provide that function. IT is usually incapable of running, scaling and maintaining the application; its tool set, capacity and pace are so removed from an application level, 24X7 operation. R&D is in shock and awe: “you mean we have to use the damn product!!??” – they are usually the least capable of understanding how the application should work or the value to their customers.
Whereas R&D used to have dozens, hundreds or thousands of customers, Operations is now the only customer (or in a hybrid solution, the largest). All and every feedback to product marketing would come from the Ops group. It must develop a keen understanding of the application, not just the infrastructure supporting it, and it has to be in constant contact with its customers – the SaaS consumers – to gather feedback, compile it in an orderly and prioritized manner and be able to communicate it to R&D.
Since an Operations Support System (OSS) will be lacking in most early SaaS implementations, the Ops group will be the one presenting the technical solutions either through building its own tools, buying those apps or though cooperation with Engineering to provide the solutions. In any case, Operations will be the authority on the architectural needs, security, storage, the OSS, service-ready features and the application in general. Therefore Operations should be highly involved in the product roadmap.

In some organizations, ownership of the customer success may be in a separate silo that does not include Operations. But one must keep in mind that the Ops group works on a daily basis with the Network Operations Center (NOC) which doubles as the customer support center. Even if Ops and Customer support are not part of the same organization (which I believe they should be) the daily interaction between the groups means that Ops owns the customer success in many ways and deals with the customer directly as a Tier 2 support.

Operations needs an in-depth understanding of its infra and application performance issues and of principles of performance testing/monitoring. They need to work closely with the QA group to test and resolve load issues. In each rollout of a new version, Ops has the ownership of the project, the dates, process definition and should work in conjunction with R&D, QA, Marketing and customer support.

If the Service offered through this model allows for project based business, Operations will tend to be involved in defining offerings, help with the pricing and participate in scoping projects.
And based on my own experience, the Ops team, as the owner of the application and service, worked closely with a team of Expert Service engineers who provided the end consumers with domain-level expertise to drive more value from the application. (See IPaaS) Ops engineers also participated in user forums with the customers to provide best practices and tips n' tricks.

"OK! Fine!" I hear you shouting from the back rows "We are convinced of the central role of Operations. So what?"
So just keep in mind when you are about to launch this endeavor that you will need to assemble a good team of professionals to play in this game. Not just seasoned systems engineers, a network manager and a good DBA, but operations engineers that ideally have an engineering background, that are innovative, customer oriented and business savvy. Nothing short of the Fantastic Four

Reducing SaaS Operational Costs (II)

2006-10-09T16:08:00.000-07:00

In the last post Reducing SaaS Operational Costs I discussed how utilizing two strategies, Automate and Delegate can enable economies of scale, so that the cost of adding new customers is marginal.

Following is a review of some of the areas in which these strategies will prove to be cost effective over the long run, and reduce the probability of the operation collapsing under pressure.

Professional Services
Remember - “customization – OUT; configuration - IN”. The software should be designed to allow maximum configuration without altering the code. This includes branding the software and, more importantly, allowing the customer to define names and custom fields to various entities of the product.
Build the architecture to support Web Service for painless integration with in-house systems, then Let your customers do the integration.
Train the trainer. Find the champion of your solution at the customer, and grow her. Help her promote the product and build a well trained team that will take the burden off your shoulders, including some of the sales and marketing efforts.

Operations
Provisioning should be a seamless process with no (or minimal) human involvement. A customer should be able to sign up to the service and the resources should be provided automatically. A customer-centric application is essential and administration should be delegated to the customer with multiple-hierarchy supported.
Client side components should be downloadable with self-installation. If the application supports an on-premise agent, it is essential that the backend application is version-backward compatible, to avoid the upgrade nightmare.
In order to ensure that the application is up, available and performing to the SLA requirements automation should be used to the maximum. This begins with monitoring the network, resources and the application. A dashboard should depict the status of all resources with the ability to drilldown to sub systems and components. Alerts should be used and crossed referenced in order not to create false alarms. Use automation scripts for self recovery whenever possible and keep extensive logging for postmortem of downtimes, because they are going to happen no matter how good you are.
And while we’re at it, make sure that R&D provides well-tested, easy-to-use data migration tools for version upgrades. Utilize change management and patch management tools and processes to lower costly human errors.
Maximize self help systems – FAQs & online knowledge base - to reduce customer calls.
Add new services seamlessly – build the capability into the application management systems.

Sales
Naturally, a SaaS offering reduces greatly the need for direct marketing and sales. Cyber sales will take most of the burden and referrals will become an important sales tool. Design a good interactive demo site and allow customers to test the application for a limited time as a proof of concept. This process should not involve human intervention on the ISV side.
If your service is becoming a commodity, allow for self registration and on-line payments. This will greatly reduce the sales cycle and the number of people involved.
Automate the metering and thus, the billing process.

Customer Support
Remember that a SaaS customer service rep replaces some of the functions of the customer organization's HelpDesk. That means that your reps will be getting a LOT more traffic than your average packaged software company. And when bad things happen, everybody will be screaming bloody murder and bog down your communication lines. Therefore have an updated status page where customers can view the responsiveness and availability of your production system(s).
A self service portal will go a long way to reduce the call volume. A rich and well maintained knowledge base will do that as well (check out all the Freemium sites - they will not invest in a non-paying customer, yet they want happy customers as bad as you do). User forums are also a great way to harness the goodwill and knowledge of the community to save on training and problem resolution resources.

In conclusion
The OSS (operations support system) should at least support provisioning, access, self admin, metering, and report tools. There are a number of available platforms for purchase that provide the OSS. They may be a good solution for your operation.

I have touched upon many areas and providing for full automation and the technology enabling delegation may not be available from day one. It is therefore imperative for the Ops team to work closely with product marketing, R&D and QA and to participate in product discussions and development planning.

Reducing SaaS Operational Costs

2006-10-09T15:18:00.000-07:00

"Say, Tom, let me whitewash a little." (Tom Sawyer, Mark Twain)

Remember that quote of Ben from the timeless Tom Sawyer, who gladly gave up his apple to have the opportunity to do Tom’s work?

Cute, but how does that relate to reducing operational costs in a SaaS house? Well, at least fifty percent of the magic formula “Automate and Delegate”

In my numerous interactions with pure SaaS startups as well as with established ISVs transitioning to on-demand, I have encountered time and again the lack of planning for a robust Operations Support System (OSS).
Whenever I bring up the potential hazard of non-scalability I hear the same response “we wish that were our problem” or “we’ll deal with it when that becomes an issue”, secretly wishing that it will become an issue fast enough.
The logic being - let’s make sure our software works as a service and that we get traction. When we’ll have more customers than we can currently support efficiently that would be a success milestone.

I’m sorry to break the news but when that happens you might find yourself with a catastrophe waiting to happen (see Chronicle of a Death Foretold).

The profitable SaaS operation utilizes economies of scale when the cost of deploying, say, 100 customers is just marginally more expensive than a single customer. In an ideal world, the hardware and software infrastructures costs should remain the same; bandwidth utilization should not change dramatically; storage needs will expand more or less proportionally to the number of new customers, while the support staff should remain steady and perhaps increase slightly.

So what costs are involved with the growing SaaS business? There is the hardware, bandwidth, software licenses (e.g. databases), customer care, and the inevitable marketing and sales. Human resources are still the greatest expenditure for a software vendor.

Careful planning – ‘doing things right the first time around’ can make the difference between a profitable operation and one that is bleeding the company.

In order to maximize your margins, you must reduce human intervention in every aspect possible. There are two strategies, that when applied in concert, can do just that. They are Automate and Delegate.
Automate means let technology do whatever task that would otherwise require manual work.
Delegate means enable your customer to do whatever task that would otherwise require your team to handle. Remember Tom Sawyer?
Obviously these stategies will necessitate a technological infrastructure to support it.
By carefully planning your application and operational environment you may achieve a high level of automation and delegation.

In my next post, I will review the areas in which these principles can play a major role.

IPaaS

2006-08-29T16:43:00.000-07:00

No, it is not a typo, and neither am I contemplating adding another acronym to the alphabet soup. I am simply emphasizing an important aspect of the business - Intellectual Property-as-a-Service. IPaaS is the upper tier of SaaS, what might be known in the industry as ‘Managed Services’ or ‘Expert Services’.
An enterprise software vendor should be delivering more than a software tool. If it also provides a methodology, best practices, and subject matter expertise, then the differentiating value of that ISV is clear. It is (supposed to be) the hub of knowledge of all of its customers on how to do ‘It’ right. ‘It’ may be document, process, or project management, or business intelligence, or performance testing, or CRM, ERP, ABC and XYZ.
Its products are expected to encompass years of experience at a particular vertical or a process by interacting with the customers, heeding to their needs and compiling all of their usage history into the product and the company’s knowledge base.

There are countless tools out there being offered on-demand: email, webex, Google’s Apps and Microsoft Live, to name a few.
What differentiates these services from IPaaS is that they do not require a domain-level expertise. Almost anyone can log into a web-based tool such as webmail and start deriving value from it.

But, one may claim, this domain-level expertise is true for any ISV that offers vertical or complex, process driven systems. So why is this more compelling in the SaaS model?

There are three reasons.

The first is that SaaS vendors can channel their resources into offering a higher level experience for their customers. Most traditional ISVs devote most (if not all) of their professional services’ talents to installation, customization and upgrades/maintenance. If you take these activities out of the equation in the SaaS model, the ‘Professional Services’ can be upgraded to ‘Expert Services’ and dedicate the manpower to helping their customers derive more value from their products.

The second, and even more compelling, reason is that in the SaaS model the software vendors can generate another revenue stream from offering project-based, domain-level expertise. In the traditional model, no company in its right mind would buy and install an enterprise system to run a year-end financials project or a pre-launch performance testing project. Now this is possible with the on-demand model. The software vendor - the ‘expert’- owns the infrastructure; the systems are already installed and ready to use. Send in the expert team (this is a figure of speech of course, the beauty is that you can do it remotely) to run the project and extract a high price for this valued service.

The third, and most important, is the fact that no one has as much visibility into the domain as the SaaS provider. It can view how the software is being used, what kind of data is kept and how it is being manipulated. It can run queries on aggregated data and provide benchmarks and best practices.

Very few companies today make a use of this source of knowledge (and, yes, power) but I predict that it will become an important differentiator in the near future.

Chronicle of a Death Foretold (III)

2006-08-15T15:53:00.000-07:00

or 'How to aSaaSinate your Business' (part 3) (view part 2) (view part 1)

The BizEye story is fictitious of course, but one that describes a possible scenario, though not likely in its extremity. Allowing the state of affairs to deteriorate to such a low level without management intervening at an earlier stage amounts to gross negligence. Such a company probably would not have achieved the state of prominence that they have in the market.
Still, it is worth looking at the various actions that were taken or neglected to be taken. This article is focused mainly on the technical and operational aspects, but it is worth noting that other bad decisions were taken at BizEye, which made the profitability of an on-demand offering even harder to achieve. They include an over-simplified pricing mechanism and lack of planning with other functions within the organization, such as finance, sales, and customer and professional services.

So, what could have BizEye Technologies done differently to avoid the dilemma that they are facing? Of course, they should have done their homework, better estimate costs and especially, raise the red flag at a much earlier stage. But beyond these obvious observations, there are a number of SaaS- pecific issues they should have tackled early on.

C-Level commitment
The switch to a SaaS model from an on-site perpetual model requires an understanding that it is not simply another delivery mechanism, but rather a paradigm shift. The company needs to align itself to start selling a service, rather than a product. (see Impact on the Organization)
The switch involves every organization within the company, and some departments will clearly push back the initiative. Being a strategic move, it is the CEO's perogative to make sure that the executive staff is on the same page and not just paying lip service. Without a commitment of all C-level and VPs, to work towards a successful implementation, any company will likely experience many of the difficulties that plagued BizEye.

A Pilot is just that
A pilot project is a inherent step in the process, unless the company is a pure SaaS player. This proof of concept should not cloud the minds of the SaaS champions. It must be limited in time and scope and have a sunset strategy. The pilot would be a very good time to test the concept, learn of the problems, processes and solutions and feed back into product marketing and R&D. These latter two should already have personnel dedicated to the next phase of a hosted offering, whether it is built into the product or integrated with existing application management solutions.

Think Big
Plan in advance a solution that will allow for incrementally scaling up of very large numbers, as that is the end goal of a SaaS offering. This does not necessarily mean large upfront investments, but it does mean having a path in mind that will not necessitate changes in the future of architecture, process or hosting solution. Nine times out of ten, the architecture and planning are geared for a 'proof of concept', with the champions saying that these problems are "good problems" that we will be happy to deal with, when they happen. By the time that happens they are not "good problems" any more, rather they may end up killing the business.

Technology and Automation
Since staffing is still the most expensive line item on your budget, incorporate technology and automation in every aspect of the operation. This includes automating processes like customer on-boarding and provisioning, delegated authority for every administrative activity, self configuration, automated billing, self healing infrastructure to mention but a few.

Bottom line: Economies of scale will prove very profitable when and if the business grows at an exponential rate of the staffing growth.

Automation and Delegation are a subject of a separate article that I will post in the future. Beyond all that has been written above, these are the crucial components that can make or break a SaaS business.

Chronicle of a Death Foretold (II)

2006-08-02T11:42:00.000-07:00

or 'How to aSaaSinate your Business' (part 2) (view part 1)

Cracks were starting to show.
The operations team complained that they are drowning in customer requests and are not keeping up with hardware and hosting requirements. The business growth was accommodated by throwing bodies at problems:

Adding a new customer consisted of setting up a new environment, provisioning resources, filling out an excel sheet with the customer information. Adding users to the system needed manual intervention and any administrative function required a Customer Service Representative (CSR) to process a change request.

Billing also was managed through an excel sheet, since the financial model did not integrate with the perpetual model’s existing financial systems; so any modification required manual labor.

The CSRs, who often escalated to the Operations team, handled customer-specific configuration requests with an-ever lengthening resolution time.

By now, the operations team was handling 35 customers with hundreds of users. Combined, they consumed 35 dedicated systems, and were becoming increasingly unhappy with the responsiveness and degradation of the service levels. Some angry calls were received at the helpdesk center.

An upcoming release of the perpetual version, with exciting new features was starting to look like a nightmare. The field had already installed it in about 50% of the customer base, but the hosted services still had the old version. The upgrade date was being postponed time after time, as they could not figure how to simultaneuosly upgrade 35 different systems. One option was to do it incrementally, but that would mean that they had to maintain two different versions, and keep track of which customer had which version.

Curt and Diane lamented that the whole SaaS trial was going to blow up in their collective face. It was clear that they must stop accepting new customers and quickly get technical solutions. By now, the operations team had accumulated vital knowledge of how to do things ‘right’ but that demanded R&D, QA and Services resources.

Diane reported to Sanjib and he called a meeting with the executive team. Diane laid out the plan, showed the growth rates, enthusiastically presented the huge opportunities and requested a commitment from the C-level to make the new model a success.
Bill, VP R&D explained that his resources are stretched thin because of all the ‘real’ customers out there, a new release that is way off schedule and still many issues with the last release that has half his team working with QA to resolve some serious bugs. He couldn’t see how more than three dedicated people would be available to look at an on-demand solution. In any case they won’t have anything ready in the next two quarters.
Joana, the CFO, suggested that if they hiked the price of the service to make the margins, that would justify enlarging the allocated funds of an endeavor that has, so far, just been bleeding the company.
Raul, VP of customer services, claimed that his team was getting a disproportionate number of calls from the SaaS customers, and his CSRs were not really equipped to deal with the users’ requests. He needed a dedicated team just to deal with the hosted customers and he does not have the budget for it.

Sanjib, who was a cautious supporter of the SaaS initiative, realized that he was only partially informed of the state of affairs and faced a true dilemma. He knew that BizEye could not abruptly drop the service, loose face and 35 customers, but he understood that the SaaS solution was not realizing the promised economies of scale and, with the current state of affairs, his best case scenario was to break even.

He assigned Diane, Joana and Bill to a committee to review possible options and report within two weeks, and he required from Diane a post-mortem on why such a promising prospect has turned into a nightmare.

Curt sat in the corner, biting his fingernails.

Next posting: Conclusions

Chronicle of a Death Foretold

2006-07-25T10:31:00.000-07:00

or 'How to aSaaSinate your Business' (part 1)

BizEye Technologies, the well-recognized leader in enterprise Business Intelligence software, has been considering developing an on-demand version of its application. Software-as-a-service is recognized as the latest and most disruptive industry trend; BizEye feared that if they were not involved in its adoption, they could become irrelevant.

Diane, the VP Product Marketing took a special interest in this new area, especially after many customers started inquiring about a SaaS offering by BizEye. After reading a number of articles and attending two conferences, Diane became a champion of SaaS within the company and assigned Curt, Director of Product Marketing to explore this opportunity and evaluate the marketplace and the costs & opportunities associated with developing the SaaS application. The initial evaluation looked good and Curt quickly became an advocate himself of the on-demand model. There were interested customers and a whole new market of SMBs to target. A simple calculation indicated that the operation will break even on the fifteenth customer.

Diane presented the business case to Sanjib, founder and CEO of BizEye. Snajib knew that sooner or later BizEye would need to face the question of SaaS. He therefore approved a small budget for an on-demand pilot project. Curt was assigned to lead this initiative. He assembled a task force of professionals from IT, Customer Service and R&D. They selected one of company’s products, the Analytics and Reporting tool, as a pilot project; a proof of concept.

As the software was not built on a multi-tenant architecture, and did not recognize a ‘Customer’ entity, the pilot was built as a dedicated architecture solution. This was not viewed as a problem, since there were only six customers that signed up, and it was a temporary solution anyway. The customers were extremely happy: Time-to-value was reduced from many months to a couple of weeks, and each customer was assigned a named account manager that was pouring love and attention on them. Every need was immediately handled, and all one had to do to add more users or tweak a report, was to call the account manager and the task was taken care of within the day.
Diane reported to Sanjib that the pilot was going fine and the customers are ecstatic about the service. She managed to secure another budget to build a small operations team to support the solution and the customers.

As “temporary” solutions go, a business was growing around this offering. More customers were added, as word-of-mouth spread on the first-class service they were getting. Curt, now Director of SaaS Operations, was eager to add more clients as the concept was proving to be a successful one, though not quite yet profitable. The future looked sweet.

To be continued...

SaaS and SOA

2006-07-14T08:18:00.000-07:00

I have encountered numerous people that, when I mention Software-as-a-Service, they say “ah, yes, SOA”, at which point I go into a well rehearsed speech about what SaaS is, as a business model and how different it is from SOA, being a technology trend.

But are these concepts so far removed? Is there a reason why so many professionals confuse the two? So, giving it some thought I realized that there are many points of similarity and interaction between the two concepts.

First, both have been around for a long time. SOA has its roots in the term ‘Software Engineering’. We all know how far apart are the disciplines of writing software and assembling pieces of hardware, but that was the guiding principle. Object Oriented programming, arriving in the late 60’s, promised to change all that with the concept of component programming. Then came CORBA, which was supposed to do the same at the system level, but never really took off.
Software-as-a-Service has even older roots if you consider the Timesharing-Multitasking model that allowed running the same software from a mainframe, on multiple terminals, and all of its subsequent versions. And then, the ASP model which basically evaporated with the dot.com bust.

It seems now, that both concepts have arrived at a point of general acceptance. They just make sense, and the adoption rate is growing, albeit, implementing a good SOA solution is more an art than a science. I believe we will see a higher adoption rate of SaaS than SOA in the near future.

SOA is also a venue enabling SaaS. Many SaaS offerings are now using Web Services as a means to integrate with the backend legacy software and other vendor offerings.

SOA and SaaS are both disruptive (perhaps destructive) technologies. They are changing the way CIOs think about their businesses, and both serve to help IT manage their service easier and more cost effectively. And of course, both are generating a lot of hype.

But think of this: SOA is, after all, software as a service, albeit a different kind of software and a different kind of service. When we think of the Software in SaaS, it is a full, stand-alone application, whereas in SOA the chunks of code are smaller, performing a single business process. And of course the term Service is used differently; in SaaS it is referred to as a business service, not a system service, like in SOA.

Granularity is one of the arts needed to be mastered in SOA. One would like to write a service that is small enough to cater for all applications, but big enough to provide as much functionality as possible. Sounds like the similar dilemma one finds in SaaS; the old 20/80 rule. One would like to write an application with as much functionality as possible, but on the other hand it should be general enough to provide for all consumers.

Now, let’s fast-forward to the future and play the ‘Zoom-In/Zoom-Out” game. Imagine SaaS vendors writing chunks of code that are big enough to accommodate a business process but not a whole application. An example would be code validating a credit card purchase. These modules will provide an interface (standardized) to interact with other modules engineered by the same or different software vendors. Imagine the IT purchasing these modules and assembling their application in-house, from these Leggo service blocks.
These services could reside on-premise or at a service provider. It should not matter nor change the model.
In that perfect world, where SOA has become a reality in IT, the subject of ‘Build vs. Buy’ becomes a non-issue. The need for external applications, provided by ISVs is reduced significantly, whether installed on-premise or delivered as a service. When that happens, the whole ISV landscape will drastically change, and many of the software application vendors will either disappear or transition into providing the service widgets to be consumed by the enterprise.

And in that futuristic world, where software components from different vendors will talk to each other via a standard interface, elephants will be fluttering their butterfly wings on their way to the grand ballroom…

Impact on the ISV Organization

2006-07-02T18:09:00.000-07:00

“It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.” — Charles Darwin.

An ISV transitioning from the traditional, perpetual licensing model to the on-demand model is not simply adopting a new delivery mechanism; it is a paradigm shift that involves switching from selling a product to selling a service, and it will affect almost every silo in the company.

An enterprise software vendor that is ready for SaaS adoption is probably aware of a number of issues that have been getting a lot of attention in this space, namely:
· Technical – how to enable my software to be delivered as a service (read that as multi-tenant)
· Pricing – how do I switch from a perpetual model to a subscription one
· Operational – how do we support a 24x7 hosted environment

But do ISVs understand how switching to the SaaS model will affect almost every business unit of the organization? Are they aware of the potential pushback from different groups within the company that may make life difficult, if there is no commitment from all stakeholders to make it a success?

Following is an overview of the different silos in the organization and how they will be affected by the move. (short version of a paper I wrote)

Engineering
Not only will there be a need to modify (if not totally rewrite) the architecture, but there are a myriad of new service-ready features. Examples include:
Billing, Provisioning, Multi-level hierarchy and delegation, Service levels, Retention policy, Security, on-the fly configuration.
Engineers’ skill set may be lacking, requiring training/hiring.
Extreme programming may be required as software lifecycles are likely to shorten.

Quality Assurance
The QA practices that have so far included mostly functional testing will radically change, now that performance and high availability and end user experience will become paramount.
Testing expands from the QA lab to pre-production while different tools and skills are required and dev/test lifecycles shorten.

Operations
A new group is needed to ensure a smooth delivery of the service; responsible for the 24X7 uptime and availability. Consisting of account managers, systems, DBAs, and operations engineers, it will work closely with R&D, QA, IT, sales, professional and customer services.

Sales
The sales organization should be expecting substantial changes. This is an essay in itself, but suffice to say that switching from perpetual licenses to subscription and from a product to a service will change the rules of the game. There are two major factors.
1. The target market is now expanding to the SMB or the line of business.
2. In the recurring revenue model, the sales person cannot deploy a shoot-and-forget policy; rather the customer must be kept satisfied throughout the term of the engagement. This will also affect sales force compensation
On the other hand, sale cycles are likely to shorten, and cyber-sales will play an increasing role.

Customer Services
The CS group will need to switch to a true 24X7 mode. The knowledge set of the CSRs will need to be upgraded from set-up/configuration to domain level expertise and systems/application problem resolution.
User experienced must be positive to grow the subscription, therefore CS has a more important role than before, and perhaps higher skills (higher compensations) will be needed.

Finance
Revenue stream and revenue recognition will change dramatically with an effect on the company’s financial outlook. Financial systems capturing and forecasting deferred revenue will be needed. Billing will become more complex, dealing with metering, service level compensation and renewals and these new capabilities will need to integrate with the existing financial systems.

Professional Services
With the on-demand model, setup, installation and upgrades will no longer be the focus of PS. The post sales engineers will deliver application and domain-level expertise. Much of the traveling time and costs will be reduced.
Education services will drop part of the curriculum pertaining to installation and maintenance.

Changes are expected in yet other departments. I will just mention that Marketing, Legal, Compliance and Channels/Partners will be affected as well.

Summary
In conclusion, switching to the new model should be seen as a strategic move and not merely as a tactical one. Selling software as a service is not a delivery mode change, it should be viewed as a new business model, requiring a new skill set. An early awareness of the potential fault lines will reduce the shockwaves.
There is a need for an executive directive to seep through all the silos down to the lowest level of operation.
There is a need for an educational process across the company, and finally, there is a need for a fully committed taskforce that will include high level representatives from all business units to ensure that transition will be smooth.

Yet another Blog on SaaS

2006-07-01T17:47:00.000-07:00

So why do I bother adding more clutter to the Internet?

I have been looking at publications on SaaS in the past six months and, although I found a lot of fascinating, eye opening articles, blogs and the such, I could not find perspectives that were similar to many of the thoughts I have swirling around my head.
Perhaps, this is indicative of an emerging market where for every 'worker bee' you are apt to find three 'consultant bees' that have much to say about anything, but there few people with hands-on experience of actually transitioning from the enterprise model to the on-demand offering.
I have met with quite a few ISVs in the past months in various stages of adoption and realized that many just don't get it. Many CEOs I spoke to were considering the move as a an unavoidable evil they would need to contend with at some point. Others understand that they will need to offer on-demand, but not just now ("call me at the end of the year").

I have found myself evangelizing a lot and I must say that it surprised me that after such a hype deluge, there is still need for an advertising campaign.

On a positive note, I met one company last week in the arena of publication and technical documentation management. The company has redefined itself as a SaaS provider, repalcing most of the C-level and their marketing and sales staff because they get it! It almost brought tears of joy to my eyes. They understand that switching to SaaS is not a tactical move but a strategic one. With their permission, perhaps I will report more about them in a future posting.

So, this blog is dedicated to all you enterprise ISVs out there. I hope to shed some light on the SaaS space, help out with tips on the business model, on the needed steps to achieve a profitable on-demand business and discuss operations considerations.