Quest for the Cloud

I really like being a Product Manager. Sure, it can sometimes be a (very) thankless job, but I like seeing what happens when the software development team for my product meets with the IT department of our own company (who are effectively representing my future customers). I got both teams in a design room last week to go over architecture for a product that I am working on.  The results were sobering, but eye opening.

A member of our IT staff graciously donated a couple of hours of his time to see the architecture and security considerations we are building into our Enterprise 2.0-ish on-premise product that works in tandem with Cloud-based services. The fact that a network connection needs to ferry data through the corporate firewall to and from the Cloud meant all sorts of proxies, DMZs, load balancers, and redundant clusters turned our rather simple network diagram a veritable rats’ nest of complexity once we understood how security conscious our organization is.

Watching this incredible exchange between the development team and the actual customer (or in this case, their proxy) is exciting. As the finer details get elaborated on through discussion, the development team is changing their plans on the fly to address our customers’ needs. Future discussions will refine this to the point where we can move on to a larger group of enterprise customers to make sure we have a truly flexible solution that meets the market.  The product is not only taking shape, but the shape is being determined by customers saying, “Here’s exactly why I would never trust you” and development saying, “Here’s what we can do about that”.  Wicked cool.

Wireless is a Cloud Service

Satisfying “corporate IT” is the Holy Grail of any solution that needs to talk through the firewall. In my previous life as a software engineer in the wireless industry, I was a Dev Lead tasked with creating a “RIM Killer”.  This was back when a Blackberry was a monochrome pager and a Blackberry Enterprise Server (BES) wasn’t standard issue in every mid-size company (circa 1999). It was an ambitious goal - we created our own hardware device with a wireless radios spanning three types of networks (GSM/GPRS, CDMA, and ReFLEX).   We developed our own device software and our company already had 70% share of the paging infrastructure market (most think Motorola was the leader here, but they had less than 20% share). That left the actual on-device applications and the enterprise server software that would wirelessly ferry all that Exchange goodness to our new creation.

Creating the application software with push e-mail was easy (which helped us become the first company to officially be the first to get into a lawsuit with RIM over push email notifications well before the “famous” RIM push lawsuit). On the enterprise integration for Exchange and IMAP mail servers, we had a few technologies in-house as well as some partnering options that would ensure a quick and painless path. For this piece, we weren’t even the only ones. There was Good Technology, Visto (now merged with the former), InfoWave, a plethora of unknowns.

Same Problem, Different Decade

With so many things going for us, what was our biggest problem?

Getting our product into the server room.

Oddly, most people don’t see a BES server as an on-premise component of a Cloud solution, but that is exactly what a wireless network is entails.  The thing is, wireless email (ala Blackberry or iPhone with push) is essentially a “Cloud Service” (the gateway) with an on-premise component (the BES, or Exchange ActiveSync), combined with a consumption device. Fast forward 10 years and swap the device for a browser and you have roughly the same thing.   Analyzed in this light, it is clear why any on-premise product that deals with a Cloud-based solution is (and should be) subject to the same level of scrutiny as if it was a Cloud application anyway.

So, just how did RIM get into the server room? Part of it is the hordes of users who used the “Cloud-only” version of Blackberry and were beating IT’s door down because they wanted the user-focused features BES offered such as full wireless synchronization of more than just email and Exchange integration requiring a desktop always on running RIM’s redirector software. However the real reason RIM succeeded was they put ultimate power into the hands of IT - for the first time, IT could audit all of those emails that were flying outside the firewall, they could remotely set policies on all devices from a central console, and they could remotely wipe a Blackberry if it ever got lost. They made wireless email “SAFE for IT” - and they did a good enough job that the door to the server room promptly closed right behind them, leaving competitors like Good and Visto to slug it out for a distant second place (there really was never a third). 

Catering to IT for Fun and For Profit

The reign of RIM has lasted so long not because of their devices (you either love them or hate them), but because RIM catered (and still does) to IT.   It is truly remarkable that given all of the money and effort Microsoft has put into Windows Mobile and Exchange, that proper remote wipe capabilities were only implemented in ActiveSync within the last few years.  Proper remote wiping of an iPhone was only achieved in 2009 - almost a full 10 years after RIM. The iPhone is an extremely compelling solution for users and IT has been screaming for OS 3.0’s enterprise features (such as ActiveSync, remote wipe, GPS location of lost devices) because people are going to use the tools they want to use whether IT likes it or not.  If I was a product manager for the mobile side at Microsoft, I’d feel I was an “also ran”, and not because of anything I did.

While the BES model doesn’t satisfy everyone, it is amazingly secure - it satisfies world governments’ strict security requirements, held its own against the “no Blackberries in the White House” concern that President Obama faced, and is even used for top secret “Black Ops” missions around the world (one guess as to what I did in the wireless industry after the economy recovered…)

I know how RIM pioneered this model over a decade ago and why they were successful - they understood that they would be held to a higher standard than traditional solutions because of the unknowns of their “Cloud” service.  Ten years later, I still don’t see many vendors who understand this. There is so much emphasis on the latest features, the quickest development cycles, and the sexiest design that most of today’s Cloud Computing vendors are missing the biggest place to differentiate - make the Cloud “SAFE for IT” - anybody can replicate a FaceBook experience, but could they replicate the trust and perceived value of a Blackberry Enterprise Server?

Under the IT Microscope

It is interesting to witness how much more scrutiny customers want to apply to a product once you associate the word “Cloud” with it. This has been talked about in the media quite a bit - today’s Cloud Computing solutions are typically as secure if not more secure than traditional software because of this increased scrutiny. Where an ISV for on-premise software would previously delegate some of the security responsibility to the underlying OS (such as requiring that the system stay up to date on patches, etc), a Cloud vendor can’t get away with that. They are totally responsible for everything from their own application, to the OS it runs on, and even the network connectivity to and from the data center they are hosted at.

So back to my product: yes, it is very important for the product to be compelling, useful, and even somewhat sexy. But without catering to corporate IT’s needs around security, authentication, auditing, and policy management, a product that interacts with the Cloud will be a great demo of what is possible. It may even have limited success in the server room like Apple’s XServe products, but it will never be the next BES, the next Exchange, or the next SharePoint.  No product manager ever wants an “also ran” product.

The problems expressed by our friend in IT weren’t new - this is Deja Vu all over again.  The major difference this time around is that Cloud Computing is not really a nascent technology anymore - there are far more players in this market right now than RIM ever faced in its entire history.

However, even if the problems are the same, the urgency and importance of solving these problems are orders of magnitude bigger - there are too many early adopters who are barging into the enterprise with their Facebook and Twitter accounts.   The products that will win the market will be those that manage that delicate balance between empowering users and making the Cloud safe for IT.  The rest will be “also rans”.