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.

Designing An Innovation Incubator To Prevail Over Innovator's Dilemma

The large scale software companies often deal with the tension between incremental and revolutionary innovation. They know that if they only keep listening to their customers' requests the very same customers will put them out of the business. Clayton Christensen has captured this phenomenon in The Innovator's Dilemma. Over a period of time these companies have managed to execute the incremental innovation really well to deliver the same software release after release and occasionally introduce new products. However most of these companies struggle to incubate revolutionary innovation inside the company since it is fundamentally a different beast. The executives are often torn between funding the revolutionary initiatives to ride the next big wave and funding the incremental innovation that the current customers and the market expects. It is absolutely imperative for the executive management to differentiate between these two equally important but very different types of innovation opportunities. Many companies have set up in-house incubators to bring revolutionary innovation to the market but in most cases the incubators are set up as yet another department inside the company that shares the same legacy and bureaucracy. Following are some suggestions on setting up and running an incubator to avoid the innovation disappear down the rat hole:

6x6 cubicle in Iowa won't cut it: There is nothing wrong with Iowa but I won't build an incubator there. Pick a location that emanates entrepreneurial spirit, attracts talent, and is surrounded by good colleges. Scout for a location that has good work-life characteristics where people feel the energy and have social outlets - pubs, hiking trails, good restaurants etc. San Francisco and Palo Alto in the Silicon Valley are a couple of examples of such locations.

I cannot overemphasize the impact of an inspirational physical space that fosters innovation and drives people with insane urge to be creative and build something disruptive. Ditch Steelcase and shop at IKEA. Have a loft-like set-up with open seating, project rooms instead of conference rooms, and have all the furniture on the wheels. Can you write on all the walls? Have alternate comfortable seating all over the places - bean bags, red couches, chairs and coffee tables with tall bar stools. Innovation does not happen in a cubicle. Have an entire team paint the loft with bright colors as a team-building exercise. Pay a mandatory visit to IDEO and d.school in Palo Alto if you haven't already been there.

No process is the new process: The incubator should not inherit your organization's legacy processes. You cannot expect your employees to behave differently to solve a problem if they are restricted by the same process overhead. Throw your application policing process out of the window and let people experiment with whatever works well for them. One of the main reasons why incubators fail because they rely on the organization's product roadmap and capabilities. Don't pick up any dependencies instead simply consider your organization's capabilities as one more source that you can evaluate for your needs. Use open source as much as you can, build your own partner relationships, and OEM whatever you can.

Pizza-size multidisciplinary teams: Can your entire product team be fed on two large pizzas? Smaller and tighter teams reduce the communication overhead, churn, and produce amazing results. Don't follow your corporate headcount calculations. Go for smaller teams. Hire I-shaped and T-shaped people to form a multidisciplinary team. Have a good mix of internal people who understand the business that you are into and the external people that are entrepreneurs or have worked in incubators. Get help from the external recruiters to find the right people since the internal recruiters may or may not have expertise to find and hire the kind of people that you are looking for.

Be agile and design think everything: Design thinking and agile methodology empower the teams to apply an ambidextrous and iterative approach to take on the revolutionary ideas in highly ambiguous environment. Encourage wild ideas, defer judgment, and be iterative. Be visual in storytelling, stay close to your customers and end-users, and have persuasive, catalysts, and performance design. Focus on useful over usable. Have a good-enough mindset and ship often to get continuous feedback to keep improving. Iterate as fast as you can and keep your sprint cycles small.

Seed, Round A, and Round B: This is where many organizations get hung up on an upfront $200M business case to qualify the business opportunity as incubation-worthy. If all the start-ups required to have a detailed upfront business model we would not have had Twitter, Facebook, Google, Craigslist etc. The same incremental business case mindset simply won't work for revolutionary innovation. The disruptive innovation has characteristics that many people haven't seen their in their lifetimes. The organization need to adopt the VC model and embrace the high risk high reward business environment. There will be plenty of failures before you hit a jackpot but that's the fundamental premise of VC funding. Have a separate budget and an investment decision process that provides autonomy to an incubator to make their own decisions without going through a long chain of command. Have multiple rounds of funding to ensure that you are tracking the potential of the innovation right from the seed to the maturity.

Explore all exit strategies: Don't expect to go-to-market with everything that comes out of an incubator. The mainstream product teams in your organization may or may not embrace and support the innovation citing the reasons "not invented here" or "too radical". Focus on your customers and success stories. If you are successful people will come to you instead of you selling the outcome to the organization. Be courageous and kill the products that are not working out and experiment with other exit strategies such as spin-offs, outright sale etc. Try to keep the product portfolio moving. High volume and turnover is a good thing for an incubator. Financial success is not the only success that counts; happy customers, re-invigorated organization, and global visibility as an innovation player are equally important KPI.

Reward high risk behavior: People work for uncertain and highly ambiguous projects for two reasons - higher reward for higher risk and passion to build something new. Design your compensation structure that is fundamentally different than your corporate title-driven compensation and includes a generous equity option. The titles don't mean much when it comes to an incubator. What really matters is the skills, attitude, and the knowledge that people bring to the table. The career path in an incubator is very different than a conventional corporate ladder. Make sure that all the people that are part of an incubator truly understand what they are signing up for and are passionate for the work rather than simply waiting to be a "Chief Innovation Officer".

Debunking The Cloud Security Issues

Forrester recently published a report on the security of cloud computing that grossly exaggerates the security threats. To point out few specific instances:

"Users who have compliance requirements need to understand whether, and how, utilizing the cloud services might impact your compliance goals. Data privacy and business continuity are two big items for compliance. A number of privacy laws and government regulations have specific stipulation on data handling and BC planning. For instance, EU and Japan privacy laws demand that private data—email is a form of private data recognized by the EU—must be stored and handled in a data center located in EU (or Japan) territories"

This is a data center design 101. One of the biggest misconceptions the organizations have about the cloud computing is that they don't have control over where their information is being stored. During my discussion with the Ron Markezich, corporate vice president of Microsoft Online, at the launch of Microsoft's Exchange on the cloud he told me that Microsoft already supports the regional regulatory requirements to store data in regional data centers. Cloud is fundamentally a logically centralized and physically decentralized medium that not only offers utility and elasticity but also allows the customers to specify policies around physical locations.

"Government regulations that explicitly demand BC planning include the Health Insurance Portability and Accountability Act (HIPAA) ...."

Amazon EC2 fully supports HIPAA [pdf] with few customers already using it. It is rather strange that people think of cloud as a closed and proprietary system against an on-premise system. A CIO that I met few weeks back told me that "on-premise systems are like an on-premise vault that you don't have a key to". The cloud vendors are under immense pressure to use open source and open standards for their infrastructure and publicize their data retrieval and privacy policies. In fact many people suggest that the United States should force the public companies to put their financial information on the cloud so that SEC can access it without any fears of the companies sabotaging their own internal systems. The cloud vendors have an opportunity to implement a common compliance practice across the customer. The customers shouldn't have to worry about their individual compliance needs.

"The security and legal landscape for cloud computing is rife with mishaps and uncertainties."

And the rest of the landscape is not? What about T.J. Maxx loosing 45.7 million credit and debit cards of shoppers, Ameritrade loosing backup tapes that had information of 200,000 of its customers, and UPS loosing Nelnet's backup tape that had personal information of approximately 188,000 customers?

"With the rising popularity of cloud computing and the emergence of cloud aggregators and integrators, the role of an internal IT security officer will inevitably change—we see that an IT security personnel will gradually move away from its operations-centric role and step instead into a more compliance and requirements-focused function."

Staying in current operational role still requires the IT to be compliant. Just because the information is stored on-premise it does not automatically make the system compliant. I would expect the the role of operational IT to change from a tactical cost center to a strategic service provider. If the IT does not embrace this trend they might just become a service consolidation organization. The role of a security officer will evolve beyond the on-premise systems to better understand the impact of the cloud and in many cases help influence the open cloud standards to manage and mitigate the security risks.

"In other cases, the division is not quite so clear. In software mashups, or software components-as-a-service, it can be difficult to delineate who owns what and what rights the customer has over the provider. It is therefore imperative that liability and IP issues are settled before the service commences."

I partially agree. The customers should absolutely pay attention to what they are signing up for and who will own what. The critical aspect of the IP is not the ownership but the IP indemnification. After the SCO case customers should know what are their rights as a customer if someone sues a cloud provider for IP infringement.

"Other contractual issues include end-of-service support—when the provider-customer relationship ends, customer data and applications should be packaged and delivered to the customer, and any remaining copies of customer data should be erased from the provider's infrastructure."

This is what happens when we apply the same old on-premise contracts to the new SaaS world. There are no copies of the software to be returned. Customer simply stop receiving the "service" when the relationship ends. Vendors such as Iron Mountain advocates the role of a SaaS escrow for business continuity reasons. It is up to the customers to decide what level of escrow support they need and what's their data strategy once the relationship with a SaaS vendor ends. It is certainly important to understand the implications of SaaS early on but there is absolutely no reason to shy away from the cloud.

Chief Sustainability Officer - the next gig for a CIO

CIO no longer means Career Is Over. CIOs should not underestimate their skills and organizational clout to lead the company in its sustainability efforts by being a Chief Sustainability Officer (CSO).

Leverage relationship with the business: As a CIO you work closely with the business and have holistic understanding of the challenges that the business faces and the growth opportunities that they aspire to go after. You can leverage the relationship with the business to own and execute the sustainability strategy and effectively measure and monitor the progress using the expertise and investment into the IT systems. You can walk your business folks through your scenario-based architecture to help them quantify the business impact of the sustainability initiatives and estimate the required transformation efforts.

Start with Green IT and lead the industry: Start with the area that you are most familiar with. Reduce the carbon footprint of your IT systems by improving the PUE of the data centers and better manage energy consumption of the desktops. If you do decide to disinvest into the data centers and move tools and applications to the cloud it will not only reduce the energy cost but would also result in consuming cleaner energy. Share your best practices with your industry peers and lead your industry in the sustainability efforts.

Make Sustainability a business differentiation: For many organizations sustainability is not just a line item in the corporate responsibility report, it is actually the future growth strategy and a sustainable competitive advantage over their competition e.g. sustainable supply chain, higher operating margins, end-to-end environmental compliance etc. As a CIO you have the right weapons and skills in your arsenal to transform the organization in the sustainability initiatives. You could innovate your company out to grow leaps and bounds by focusing on the sustainability. This could be a blue ocean strategy for many organizations that are struggling in the red ocean to beat the competition. You do have an opportunity to empower your customers in their mission to be sustainable by providing them the data that they need e.g. a bill of material with the carbon footprint and recycle index, realtime energy measurement etc.

Redefine the program management office: The sustainability projects are very similar to IT projects in many ways - make a large set of stakeholders to commit without having much influence on them, work with internal employees, customers, and partners etc. Traditionally you have been running the program management office for technology and information management projects. Apply the same model and leverage skills of your program managers to run sustainability projects internally as well as externally. Sustainability is fundamentally about changing people's behavior. Promote alternate commute program tools such as RideSpring, carbon social networks such as Carbonrally, and employee-led green networks such as eBay Green Team. Run targeted campaigns to reduce energy and paper consumption, increase awareness, and solicit green ideas. Right kind of tools with an executive push and social support could create a great sustainable movement inside an organization.

Chief Sustainability Officer is an emerging title. Your ability to work across the organization, leverage relationship with the business to sell them on the sustainability goals, and manage the tools that are penetrated in all parts of your organization make you well suited for this role. A CSO does not necessarily have to be a domain expert in sustainability. In fact I would expect a CSO to be a people-person that can make things happen with the help of the sustainability experts and visionaries.

Now you know what your next gig looks like.

Structure 09 - Cloud Computing Is Here To Stay And Grow

I was invited as a guest blogger to Structure 09 - a day long event by GigaOM focusing on cloud computing. It was a great event with an incredible speaker line-up of thought leaders in the domain of cloud computing. The panel and keynote topics included persistence on the cloud, hosting web apps on the cloud, infrastructure design etc. I won't attempt to summarize everything that I saw and heard, instead here are some impressions:

Solving interoperability with Open Source: A founding developer of Wordpress, Matt Mullenweg, strongly advocated open source for the cloud for two reasons. The first reason is to achieve interoperability and the second is to ensure the business continuity when certain vendors cease to exist. As I have argued before there is a strong business case for open source on the cloud. It was great to see the reaffirmation that other thought leaders feel the same way.

Operational excellence: Javier Soltero, CTO of Management Products at SpringSource, emphasized the operational excellence as a key differentiation for a company to achieve a competitive advantage. Vijay Gill, a senior manager Engineering and Architecture at Google, also feels the same way. He believes that having the lowest cost platforms capable of providing good enough service is going to be a competitive advantage for the companies. For good software, you need great engineers – and most companies aren’t set up to do that. The technological challenges can be solved but it is the smart people writing smart code that will provide the competitive advantage to the cloud infrastructure companies.

Vertical clouds: We are likely to see more and more cloud offerings that are optimized for the vertical functionality e.g. run your Ruby apps on the cloud, analytics on the cloud, storage on the cloud etc. The IT should focus on becoming a service provider against merely a cost center. Chuck Hollis, CTO of Global Marketing, EMC Corporation believes that if IT does not embrace the cloud technology stack, they will most likely become an organization that manages the consolidation of all the cloud services. James Lindenbaum, co-founder and CEO of Heroku, emphasized that the developers should focus on core - what they are really good at and not worry about how the code will scale on the cloud. The bad code is bad code regardless of where it runs.

Hybrid cloud: The debate between private and public cloud continued. The proponents of the public cloud such as Greg Papadopoulos, CTO of Sun Microsystems, argued that most public clouds are run more securely than most private enterprise clouds. I completely agree. One of the ideas that was pitched is to have SEC force the public companies to put their data on the cloud. If, for compliance reasons, the data needs to be retrieved the government has a better shot at retrieving this data from a public cloud against a private and proprietary system that could potentially be sabotaged. The proponents of the private cloud such as Michael Crandell, CEO and founder of RightScale, cited security as a barrier and suggested approaches such as silo clouds that are dedicated for a given customer that do not share data with other customers.

I believe that hybrid deployments are here to stay. Successful cloud and SaaS vendors will be ones who can create seamless experience for the customers and end users from top to the bottom of the stack such that the customers still retain their current on-premise investment, keep their data that they don't want on the cloud, and significantly leverage cloud for all their other needs.

It was a lot of information packed into one day event. However on the lighter side Om's conversation with Marc Benioff included Marc poking fun at Oracle and Microsoft. Marc is witty and he has great sense of humor. Check out his conversation: