Facebook Privacy Scandal is Just People Whining
I don't get the outrage over Facebook privacy settings.
1. Why do you think it's called Social Media? We're here to share.
2. You can always opt out - if you don't like your privacy settings - just change 'em - I did and I found the settings pretty flexible and to my liking.
3. Information about us is out there on the internet flying around between businesses behind our backs anyway - folks are just picking on facebook because it got so big so fast.
4. Finally, if in doubt, keep sensitive conversations off of facebook - take your chances with email instead
Microsoft Retracts Statement? Confusion reigns in SaaS channels...
Note: apparently, on the heels of yesterday's announcement and my blog post, Microsoft retracted their statement about letting partners bill for their SaaS offerings...
Labels: Microsoft, part, SaaS, software, strategy
SaaS Channel Complications Manifested at Microsoft
Today Microsoft announced that they would shift their billing strategy for SaaS away from customer direct billing, instead allowing partners to bill customers directly. One month ago I argued that SaaS models would require new perspectives on channel investments by established vendors, and that these perspectives would be both far reaching and expensive. Microsoft's announcement is a manifestation of the issues I raised in that post. Diving deeper into this announcement provides more clarity and detail on the issues that post raises.
1. Channel leverage is catching up to the SaaS model. The SaaS model isn't necessarily a way to get closer to the customer. One of the often-touted benefits of SaaS is the fact that this model represents a way to get closer to the customer, a way to minimize "disintermediation," the tendency of a channel partner to gain influence over a customer's buying decisions, even to the point that the decision over the vendor being used in delivery was no longer the customer's, but the channel partner. Vendors often grapples with this issue in a managed services environment. When a vendor uses a managed service provider as a route to market, the managed service provider could often replace one vendor's product with another vendor's product without customer visibility. A SaaS model where partners are "holding the paper" to the SaaS offering and delivering the bill to the customer gets one step closer to that world.
2. Billing control is pricing control. Make no mistake about it, this decision is not just about billing. When a vendor gives up the ability to present the bill to the customer, the vendor no longer has control over the customer's buy price. The vendor's pricing is, in this case, channel facing, not customer facing. The difference between control over the street price and an MSRP is vast. As vendors develop the ability to accomodate channels in order to expand market coverage and enhance customer experience, they will inevitably lose control over the pricing of their SaaS offering, and their business models will begin to look more and more like premise-based solutions.
3. Investment is required to accomodate channel based pricing. While there may not be a quantified dollar amount they're willing to disclose, be sure that the decision to switch from an end user billing model to a model that accomodates channel billing will be expensive to Microsoft. The difference between enabling end-user-based pricing and billing and partner-based pricing and billing is dramatic. Turning systems and processes from one model to another will no doubt be a consuming and expensive process.
Enabling partner facing models on SaaS was no doubt a major decision for Microsoft. The need to make this major adaptation midstream underscores the importance of getting channel requirements right for SaaS investments. Put an exclamation point after my previous post. Vendors who do not gear their investments, particularly channel investments, appropriately to the SaaS market opportunity, will find it very difficult to realize a return on their investments.
Alternative Perspectives on SaaS
Yesterday I attended an IDC Briefing on the state of the software market. Amidst all the predictable and dire warnings about the impact of the economy on the software market, there was the equally cliche and predictable hype about the SaaS (Software as a Service) market. These days, it seems that most everyone is jumping on the SaaS bandwagon. Forrester recently emphasized the emergence of SaaS as a bright spot in the software market in a recent briefing to some folks in Cisco Services' software group.
I did learn a new term yesterday, PaaS (platform as a service), the notion that the emerging SaaS market would foster an emphasis among some vendors on "selling to" vendors like Service Providers who would offer a SaaS platform to customers. I also learned that the market growth and momentum had largely shifted from SMB fueled growth to enterprise fueled growth, a sure sign that adoption of SaaS has gone mainstream.
I continue to be amused at the acronym "XaaS," popular these days to mean "everything as a service." I suppose "x" as a variable for "everything" sounds better than saying EaaS.
In light of all the enthusiasm for SaaS, there are certain aspects Cisco needs to consider when evaluating the SaaS option for its offerings.
1) Strategy based on the emerging SaaS market must take into account the market size and scope.
IDC noted yesterday that SaaS still comprises only 3% of the total software market. They did also report that an increasing number of firms say they intend to either adopt SaaS in some form or consider it as an option over time. However, we heard the same thing about "time sharing," "network computing," "application service providers," and "managed services" in their heyday. While each got some traction, none reached the oft-hype predictions we once heard. It's easy to have rampant growth on such a small base of revenue. Adopting a strategy based on these trends amounts to "betting on the come." Given the history of hype in IT trends around this type of client/server computing model, basing a strategy on this trend probably isn't wise. IDC even hedged significantly toward the end of the meeting, when they advised that companies maintain a client software play and not rely exclusively on SaaS.
2. Developing high-end, customized applications for a SaaS environment is not a wise investment.
It is true that some applications lend themselves to SaaS type environments. Collaborative applications (those applications whose value proposition relies on their connectivity between a company and a third party), make sense in a SaaS environment. Webex, for example, requires a network to connect two parties together. A supply chain application might also require two companies to exchange data in order to create value for both parties.
Applications which do not require such collaboration, which are highly customized, and which rely on connectivity to other customer applications, begin to lose their value proposition when they are developed in a SaaS environment. Applications which monitor a customer's business process performance - especially when that business process contains multiple applications, middleware, and transactions between subsystems - do not lend themselves do installation, customization, and execution from the cloud. Applications which manage tangible assets like buildings or stadiums are best left to the customer premises for maximum performance in these circumstances. Arguable, you could develop even these applications in a SaaS world, but why would you? For less cost and greater performance, a client implementation is superior in cases like these.
3. Cultivating a channel sales and delivery strategy around SaaS requires time and investment.
For software companies, channels are hard enough to cultivate as it is. Creating a channel sales strategy requires training, proper financial incentives, and a relationship/tracking infrastructure. Any software company who does this well sustains channel programs, which usually include a level of investment requisite to staff and execute these functions. Moving beyond sales and into the cultivation of relationships which can assist in application delivery - things like installation, customization, integration and support, requires an even greater level of dedicated focus and investment. Companies like IBM and Microsoft spend into the hundreds of millions of dollars on development programs, including conferences, SDKs', support, certification programs, performance tracking, and much more.
Here's the rub: these investments have to be either retooled or made all over again in order to create these relationships for a SaaS environment. The strategy for involving a channel in a SaaS implementation, as well as how the money flows in such an environment, need to be clearly articulated: they are simply not the same ones that work in a customer premise environment. The tools and skills required for a developer to resell, develop for, deliver, and support applications in a SaaS environment are not the same ones required for a channel partner to deliver value in a customer premise environment. At best, converting existing channel partners to a SaaS model requires significant investment and time. At worst, the same channel partners will not work and new ones will need to be identified, recruited, and retained, making the required time and investment even greater.
No companies I am aware of have done this successfully. Salesforce.com has presumably invested a very substantial sum in developing the kind of online developer sandboxes that will create an incentive for ISV's to write application on their platform. The company reportedly claims the result has been relationships that number into the tens of thousands already. It is too early to know if these relationships will pay off in the form of increased revenues, but it's a safe bet that it will be years before this strategy begins to pay for itself. Webex is moving down the same path, recruiting ISV's to develop on its Webex Connect platform. These efforts are also in their infancy. It is also important to note that both of these examples are for offerings which were established as native web applications, and that neither company support an offline, customer premise strategy.
The prospect of a company moving offline applications into a SaaS environment, or cultivating an online developer channel where no SaaS offering has previously existed, significantly complicates the issues noted above. Companies who seek to do so should pursue a SaaS strategy with their eyes wide open to the investments and time required to cultivate a channel in this model.
4. SaaS minimizes defensible competitive advantage.
SaaS results in low "switching costs." When a company adopts a SaaS application, they eliminate customer premise applications, the hardware infrastructure which supports those applications, and the capital investment required for such an implementation . One of the benefits to SaaS currently being touted to customers is the ease of use of moving between providers, presumably by cancelling their subscription (opex) and transferring their data to another SaaS provider in the same market.
The customer's advantage here is the vendor's exposure. Creating "sticky" relationships becomes much more difficult in a SaaS model. When no customer premise applications and hardware exist, no tether exists to the customer. Further, the emphasis on the channel providing the support and customization for the offering becomes more pronounced, and it becomes easier for channels to establish multiple allegiances with multiple SaaS providers. This phenomenon will effective double the problems relative to switching costs, since channels will have little incentives for loyalty to specific vendors as well.
The same reason that SaaS might be attractive to a customer makes it particular concerning for vendors. Vendors may need to think through the impact on customer and channel loyalty, and how they might overcome such problems, before adapting a SaaS strategy.
Conclusion
Despite the way it may appear, I'm not adamantly opposed to SaaS. There are examples and situations where it is appropriate and will no doubt be the right choice for the customer. As this comparatively limited trend gains momentum, vendors are tempted to accelerate our SaaS strategies. Before pursuing this path, vendors should consider the investments required and the time involved for their strategy to evolve - then compare those considerations to the actual market opportunity involved.
