Amazon Customers Can Now Get A Placebo Cloud

That would be the new Virtual Private Cloud (VPC) by Amazon.

I am a big proponent of the public cloud but I am a bigger proponent of giving what the customers really want. Amazon had resisted offering a private cloud but they finally gave in and offered a private cloud or at least this is what they want the customers to believe. The bloggers are already questioning whether VPC is a true private cloud. Regardless of the arguments whether the VPC is really a “virtual” private cloud or a “virtually" private cloud, I believe, this placebo cloud is likely to help the customers overcome the cloud computing adoption barriers:

Security: The placebo cloud would alleviate the perceived risk of adopting the cloud computing. The perceived risk is based on the customers’ past experiences. The customers believe that anything that they can connect using VPN must be safe even if they are tunneling into a set of shared resources. The customers will get an environment what they believe is safe and secure to deploy and consume the applications.

Ownership: The VPC does not let the customers own the computing but still provides a sense of ownership. If Amazon’s marketing engine does a good job the customers would be less wary about the lack of ownership.

Virtualization: The customers are not necessarily clear about the real differences between virtualization and the cloud and they necessarily don’t care as long as their business goals are realized. The VPC would allow the customers to work with the existing technology stack that they already understand such as VPN and network-virtualization. The VPC would also empower the partners to help the customers build the bridge from their on-premise systems to the cloud to create a hybrid virtualization environment that spans across various resources.

Even if I personally favor the public cloud I do want to see the customers buy into the cloud computing and later make a decision whether they should move to the public cloud to leverage the cloud in its true sense.

SOAP may finally REST

Lately I have observed significant movement in two transformational trends - adoption of REST over SOAP and proliferation of non-relational persistence options. These two trends complement each other and they are likely to cause disruption sooner than later.

The enterprise software that required complex transactions, monitoring, and orchestration capabilities relied on the SOAP-based architecture and standards to realize their SOA efforts. The consumer web on the other side raced towards embracing RESTful interfaces since they were simple to set up and consume. There are arguments on both the sides. However, lately the market forces have taken the side of REST even if REST has significant drawbacks in the areas such as security and transactions. This once again proves that a simple and good enough approach that conforms to loose contracts outweighs a complex solution that complies to stricter standards even if it means compromising certain critical features. The web is essentially an unreliable stateless medium and any attempts to regulate it is less likely to work in our favor.

Many argue that the self-describing standards for SOAP are its strength over the RESTful services that lacks such features. However designing a RESTful service is fairly trivial since it allows to learn and experiment by being iterative unlike a relatively complex upfront learning process associated with the SOAP-based architecture. There has been a flurry of activities in the messaging middleware by Google that makes these RESTful interface even more compelling. This includes Google Wave Federation and PubSubHubbub. The developers are more likely to prefer these messaging protocols against SOAP and that would mean more RESTful APIs in the Pushbutton Web. Easy consumability reduces the initial adoption barrier and that's the key to success in many cases.

Since I last blogged about the continuum of the database on the cloud from schemaless to full-schema new persistence options have emerged such as RethinkDB and HadoopDB and many debates have spurred questioning the legacy of the RDBMS. For a cloud-like environment the statelessness, ad hoc persistence design, and instantaneous horizontal scale go well with the RESTful architecture. The growing popularity of SimpleDB and CouchDB along with many discussions on how to achieve CRUD with REST signal that the persistence is becoming more RESTful and schemaless.

I was convinced quite some back that REST was certainly the future for the consumer web but the latest trends have made me believe that the REST will see its adoption in the enterprise software accelerated much sooner than I had originally expected. This is like Java and Internet; the organizations embraced Java and the Internet at the same. The same will be true for the cloud and REST. When the companies consider moving to the cloud they will reconsider their SOA and persistence strategy and will likely adopt REST and alternate persistence models.

The cloud might be the last nail in the SOAP coffin.

SaaS 2.0 Will Be All About Reducing The Cost Of Sales

A clever choice of the right architecture on right infrastructure has helped the SaaS vendors better manage their operational infrastructure cost but the SaaS vendors are still struggling to curtail the cost of sales. As majority of the SaaS vendors achieve feature and infrastructure cost parity, reducing the cost of sales is going to be the next biggest differentiation for the SaaS vendors to stay competitive in the marketplace.

Direct sales model is highly ineffective and cost-prohibitive for the SaaS vendors as it does not scale with the volume business model that has relatively smaller average deal size. The role of the direct sales organization will essentially get redefined to focus on the relationship with the customers to ensure service excellence and high contract renewal rates in addition to working on long sales cycles for large accounts.

How can a SaaS vendor reduce the overall cost of sales to maintain healthy margins and growth?

This is a difficult nut to crack. There are no quick fixes. There is no easy way to optimize the tale end of the process without holistically redesigning the entire SaaS life cycle.

Self-service demos to "self-selling" trials:

Fundamentally the direct sales model for an on-premise software sales has been all about initial investment into the right demos to model customer scenarios and align the sales pitch to match the solution needs. The SaaS vendors moved away from this model as much as they could and replaced it with the self-service demos or trials. However these demos are not "self-selling" and still requires intervention from the direct sales people at various levels.

The SaaS vendors need to move from self-service demos to the self-selling ones that are not only fully functional out-of-the-box but also articulate the solution capabilities implicitly or explicitly. The demo is not just about showing what problems you are solving but it is also about how well it maps to the customers' pain points. It is like buying a hole and not a drill. The demo and the product should scream out loud the value proposition without making customers go through a webinar or a series of PowerPoint slides.

Customer acquisition to customer retention:

SaaS companies have traditionally focused their sales and marketing budget on customer acquisition against retention. While customer acquisition is a necessity the increasing SaaS competition could result into the current customers ditching the vendors. Customer support is the new sales model. Design your customer support organization and operations to retain customers. Don't let the contract renewals slip through the cracks.

Your customers are the biggest asset that you have. Market new solutions to them as an up-sell. One of the powerful features of a SaaS platform is to be able to integrate and push the new products effortlessly to the existing customers and have them try it out before they start paying you. Modernize your internal tools to track the usage analytics to better understand your customers, sales activities and effectiveness of the marketing campaigns. You have a problem if you cannot tell which customer is using what, who are the right partners, who needs training and support etc. If you haven't lately looked at the tools that your sales people use this is the right time. I would not expect a SaaS vendor to reduce the cost of sales without empowering the sales force with the true customer, competitior, and partner intelligence.

Low-touch persuasions to hi-touch interactions:

Low-touch one-to-one selling does not scale. Replicate the Avon model. Design a great ecosystem of your channel partners to whom you can pass on the cost of sales. Align the incentives and encourage the partners to sell but ensure the customer support and overall brand integrity. This strategy would require an extensive partner program with sizable investment in training and tracking what and how the partners are selling but this investment will go long way.

Reserve the direct sales force engagement for large hi-touch CIO type deals where you are required to go whole nine yards before you get a contract. The key is to have a highly variable sales force and extremely efficient compensation model to deal with a variety of prospects and customers. One size does not fit all.


Low-barrier adoption to zero-barrier productivity:

The SaaS model pioneered the low-barrier adoption empowering the LOB to sign up and start using the software without an approval or help from the IT. Eliminate any and all barriers to further penetrate the adoption. Do not enforce upfront credit-card requirements and even skip the registration if you can. Let the customers use the software with the minimum or no information up front. Demonstrate value when asking for more information e.g. Picnik lets you manipulate image in any way you want but would ask you to register if you want to save images. There should be no paper work whatsoever, not even a physical contract. Allow customers to bring in the content from other sources such as Flickr, Facebook etc. Allow the customers to have access to a live sandbox as a step before the dedicated trial. Starting from a blank canvas could be a hindrance to evaluate a product.