What is SaaS for the Big 4 of IT Operations ?

For all of the last 20 years, the Big 4 have dominated the Enterprise IT Management market. They have contributed a lot to the innovation with the level of engagement they had with customers and end users. However a lot of these learnings have become best practices and common knowledge and the barrier to entry of new players have reduced.

However these organisations itself have not evolved with the times and stick to the high cost business model where consultants and marketing teams still play a major role in winning and maintaing customers.

Now with the slow but sure evolution of Software to move as a Service (SaaS), these IT Management vendors are finding it hard to adopt and move towards a SaaS model for delivering IT Management. The biggest challenge for these vendors seem to be :

1) Technology
2) Business Model

Technology Challenge:
The biggest challenge from the technology point of view is their agent based approach to monitoring and the product Client (GUI). Most of the software they use is an agentbased model, which had its benefits in the early days when packaged applications did not have a management instrumentation of its own. Another technology challenge is their outdated Client Interface. They also have to work on a web client to make it work for a SaaS model.

The technology part is probably something they can overcome over a period of time, but ofcourse they have the risks associated with rewriting software code.


The biggest challenge for them is changing the Business Model.


Having being addicated to getting 6 and 7 digit software license revenue , they will find it hard to move to the norm that is come to be seen in the SaaS model - Subscription based pricing. Subscription based pricing involves getting license cost per year and more predominantly on a monthly basis.

The bigger problem is for those who are Public Companies. They can't afford to show a lower revenue for a quarter, let alone for a whole year due to shareholder pressure. This is the case even though it is clear that Subscription model prices even out on the long run.

The movement of applications to the cloud is sure. The dominance of the Big 4 in the past is an established fact. However the emergence of a Smart Fifth is also a possibility;

..... unless the Big 4 and other vendors are willing to be more agile.

Reasons why Subscription Model Pricing is Better than Perpetual Model

Is Subscription Model Pricing is Better than Perpetual Model ? Well I am sure we can argue it either way, but let me give probably some non-obvious reasons why Subscription is better.

Well before that let me define what each is. Subscription Model Pricing is where you charge the customer a specific amount for using your services or product every year or month. In SaaS Services monthly billing ius very common.

Perpetual License Model or "License Model" usually default Licnesing Type and more popular one in traditional software, is where you pay one time for using the software and never have to pay again. This normally does not entitle you for upgrades and support. That comes as an additional.

It is common to have a formula like
Perpetual Model Price = 2.5 Times Subscription Prices + 20% Annual Maintenance & Support

Now what are the not so obvious benefits of Subscription Model ?

1)If you are a product company, by embracing a Subscription Model, you are making yourself ready for the movement to Software as a Service. Normally in a SaaS model, Services are offered in the Subscription Model as seen in Zoho and other services.

2) Since customers pay you monthly, renewals or "subscription money" will bring in a more steady revenue stream in the long term.

3) Since you are paid only monthly or yearly, you do not get access to the whole loot in one go :-) You tighten your spending in the begining itself and hence will eventually have a better run business. This is because lesser money comes upfront and it gives you that discipline in keeping expenses in check.

4) You make a more useful service. You earn the renewal money by making your customer happy. This is really critical as when you see users dropping off, you know your service is lacking. You can take immediate action. This added advantage helps you creating a better product in the end.

Code Rewrite : why it is bad ?

Well what is code rewrite ? It is a strategic decision to scrap all code you have ever written for a software product and rewrite it from scratch, thinking that will give you better quality code & will be easy to maintain.

Stay away from rewriting a whole code base thinking the old one is terrible.

I have personally seen that being a bad decision many times. Joel on software has very interesting real stories to tell here.

Why it is bad ? Here are some reasons I have felt -

1) Lots of developer effort going down the drain.
The old code base say it was 3 to 5 years old has had lots of development effort already go in. Notwithstanding while writing the new code base do you have better developers and designers than what you had previously ? Otherwise you could end up with a code that may no seem readable and hence maintainable but not really superior.

2) Quality Assurance person's time. Your QAs would have already done lots of testing. Now, to get back a fresh piece of code to that quality is not a simple task. Have you documented all test cases / use cases ?

Fresh Code to reach the quality of Old code with all Use Cases handled will take time.

3) What about the hundreds of invaluable testing already done by customers ! Think about it. There are lots of customer environment specific issues. How did you fix it or what was the fix ? Can you reproduce that in your labs and support it ? BTW those 100s of small enhancements took that extra week each to support.

4) If you are going to maintain the old one too, then its going to be a bigger nightmare because you are going to distribute your work on 2 code bases. That is going to slow you down.

5) Remember Customers do not buy your software after reading your code. But they want the software to work, otherwise they are going to complain. Complain real loud.

6) When you rewrite code, cultutrally people expect a better featured product from what was previously present. Most people comment on the GUI as that's all they really see. Now these expectations futhur increase the time taken to go to market.

Ofcourse code rewrite for a small piece of software is absolutely fine. The above post is more from a perspective where there is a major rewrite from scratch of a full software product maybe which had over 500 man years of development effort.

So what should I do when I have feel there is a need to rewrite code ? Well Follow the 80 - 20 rule. Most probably 80% of the problems are caused by 20% of the code. Even here first identify the problematic code and be very straight to the point on how you fix. Do only Design fixing where it is absolutely needed. Fix only the flow problems or the design problems - meaning creating interfaces, and deciding on the right approach etc and donot take up anything that does not need to be touched. Do not evaluate new frameworks especially for DB persistence etc. Also look at the revision history. If the code has not been touched for years, then you may not have to even change it as it is actually working.

To summarize I guess code rewrite is bad especially for large projects. The main reason being the difficulty to get the new code to reach the quality and richness as the old.

About this blog

This blog is going to talk mainly about Performance Management, Product Management, SaaS, Application Performance Management, Business Service Management and other interesting things that I come across.

Please note this is a personal blog and the content I write in this blog does not represent the company I work for.