It’s old news that the Internet has disrupted channel structure across numerous industries. So why go on about the channel now? Because, cloud computing is transforming the Internet as a channel. The evolution from Internet applications that service people (SaaS) to Internet applications that service other applications (cloud computing) transforms the Internet from a direct website channel to an indirect cloud channel and fundamentally alters the economics of the Web. This evolution has already transformed consumer advertising with the rise of syndication and social media, but the impact will not be limited to B2C communication channels. It will deepen and spread through online B2B channels with the rise of cloud computing and platform-as-a-service (PaaS).

In this post, I’ll provide some concrete examples of how the new cloud channel, or more specifically how cloud computing in the form of Web service APIs and PaaS, is driving a fresh wave of channel disruption that leaves new entrepreneurial opportunities in its wake.

Marketing Channels 101 – A Quick Review

Marketing channels accelerate revenue by streamlining the communications and logistics required to connect buyers and sellers. As such, disruptive improvements in channel cost, velocity and structure can transform industries. Basic channel functions can be categorized as follows:

• Promotion – Communicating the availability and value of a product or service
• Purchase – Facilitating and negotiating the actual sale of a product or service
• Distribution – Cost effectively transporting the product or service from seller to buyer
• Sorting & Packaging – Transforming a raw product or service into a more attractive one
• Risk – Shifting risk from buyers and sellers to channel vendors

Most channels provide more than one of these functions, and on the Internet it can be difficult to tell one from the other as content and applications are fluidly mixed and remixed as they cross the Web. In fact, it is the ability of cloud computing and PaaS to facilitate and accelerate this mixing process that is opening the new cloud channel. Instead of a single threaded link from buyer to seller through the browser, the cloud channel allows sellers to promote through, purchase through, distribute through, resort & repackage through, and shift risk through the network from application to application to application before reaching the final browser destination in front of the buyer.

Cloud Channel Disruption – Promotion

Communication, particularly advertising, is the mainstay of the consumer Web, and the impact of cloud computing on this channel can hardly be overstated. The most obvious example is the role of the RSS standard in transforming content distribution from a direct channel ruled by websites and portals to a cloud channel ruled by syndication and sharing. The combination of this standard data exchange format with Web service standards has created the penultimate “promote through” cloud channel as content is passed from blog to news site to friend to tweet and so on. It is the technical underpinnings of cloud computing as machine-to-machine interaction that enables the far reaching content syndication and person-to-person interactions of social media. Web service APIs create the conduit of the cloud channel, while the RSS standard makes the cloud channel indeterminate, organic and viral.

Cloud Channel Disruption – Purchase

Unlike blog posts and tweets, financial market data like real-time stock quotes is content of such high value that it still costs real money. In fact, according to Burton-Taylor the market for financial information and analysis is a $23 billion market. Unfortunately, market data is also incredibly difficult to buy. Mirroring the enterprise software model, market data is mostly purchased offline through third party data providers in the form of bulk, complex data feeds that require lots of on-premise data management software, hardware and professional services to parse, scrub, store and serve it to final applications and invariably force customers to buy and manage more market data than they actually consume.

Delivering market data over the Internet using standard Web service APIs, Xignite transforms the way market data is both bought and sold. Market data powers financial applications like electricity powers kitchen appliances. The Xignite market data cloud channel creates a power grid that connects the generators of market data: stock exchanges, trading networks, major brokers, etc., directly to financial applications using a Web service API as the standard socket. Immediate online access allows prospects to evaluate data fit and quality before they buy. Transparent, usage-based pricing facilitates online purchase. Web service delivery enables real-time sorting and packaging of the data to meet specific customer needs in a fashion unavailable to bulk data feeds, allowing customers to consume and purchase only the data they need. By simplifying and accelerating purchase, data providers like NASDAQ and CME Group can reach a wider global audience, including customers that can’t afford the time, effort and cost of buying a traditional data feed product.

Cloud Channel Disruption – Distribution

Application adoption and customer on-boarding is a primary challenge of every SaaS startup. While shuffling snippets of content around the Internet may satisfy the monetization needs of many a B2C Web business model, B2B SaaS companies need to move product to make money. Without APIs, the distribution channel of a SaaS application is limited to a single URL and adoption is constrained by the manual processes available from UI tools and professional services. For data-integration-intensive SaaS applications, such as BI and ERP, the adoption cost challenge seems almost insurmountable as highlighted IMHO by the failure of LucidEra and elusive profitability of NetSuite.

Frankly, I’d almost given up on these SaaS categories until I recently put the question to Roman Stanek, CEO of GoodData, and he coolly pointed out that the solution was right in front of my face: the cloud is the channel. The GoodData BI PaaS platform, puts APIs ahead of BI and cheats the adoption cost barrier outright by leveraging the cloud channel. While most SaaS BI startups sell direct, relying on low TCO and enterprise sales prowess to motivate customers over high adoption costs, GoodData plans to drive distribution through the cloud channel with a ground-up PaaS architecture, canned integration to major SaaS applications, cloud solution partners and strong support of its developer network. The SaaS BI space is crowded, competitive and unpredictable, but pure-play PaaS is the strongest and most disruptive strategy I’ve seen to date, because it focuses like a laser on eliminating the biggest obstacle to SaaS BI adoption, data integration.

Cloud Channel Disruption – Sorting and Packaging

If you use Twitter, chances are you don’t really use Twitter.com, because seventy-five percent of Twitter traffic flows through its APIs. That means that most people are using Twitter just about everywhere else, like their mobile phones, Facebook, LinkedIn, TweetDeck, and Seesmic just to name a few. Twitter is not a micro-blogging website; Twitter is a micro-blogging PaaS. Individual tweets are just not all that interesting, but when you mash them up with friends, colleagues, interest groups, search, and related Web content, they become a conversation. Had Twitter taken on a portal strategy common to social networks like Facebook, chances are it would have failed miserably. By allowing developers to easily repackage Twitter to meet the divergent needs of a myriad of market segments, Twitter leverages the cloud channel to drive adoption and use, while remaining focused on the core value of it’s service.

Cloud Channel Disruption – Risk

A common objection is that the cloud is just too risky. This despite the fact that only the largest IT organizations can come close to internally matching the dedicated expertise, SLAs and security of established SaaS and cloud companies. However, it is important to remember that the role of the channel is to absorb risk not shirk it, particularly inventory risk. On the cloud channel, inventory is measured in IT workloads, and the more unpredictable the workload, the higher the risk of managing it in-house, and the greater the value in shifting it to the cloud. I especially like this slide that the Windows Azure folks put together to illuminate this concept.

The cloud channel absorbs the risk of fluctuating IT workloads through shared infrastructure just like a wholesaler absorbs the inventory risk of fluctuating demand for physical goods.

As the cloud channel matures, I believe it will become more effective at absorbing risk of all kinds. While there are certainly applications where privacy, security and compliance concerns may permanently preclude moving them to the cloud, the vast majority of applications will succumb as the technology advances. Ten years ago, many businesses would have balked at putting their customer databases on the cloud. Now it is a common practice that Salesforce.com has turned into a billion dollar business.

The most common fallacy of the cloud channel is the illusion that control reduces risk, when in reality it is simply a reaction to fear. But, fear of flying doesn’t make you a pilot, and you probably aren’t safer flying the plane yourself.

I’ll say it again: SaaS is NOT cloud computing. As the industry rushes to embrace cloud computing, too many SaaS experts and vendors are simply updating their marketing messages with cloud buzzwords. This is not enough.

When I started this blog, the biggest challenge faced by SaaS vendors was getting our heads around the new lightweight paradigm for marketing and selling an on-demand Web application versus the heavy-handed direct sales approach of traditional enterprise software.

Today, a new challenge is arising. However, this time the threat comes not from the past, but from the future. Just as SaaS vendors have found their Internet footing, cloud computing is destabilizing the very ground beneath our feet. Depending on your SaaS business, cloud computing could impact everything from application architecture to channel strategy. Or, it may not affect you at all. Either way you should know. What is your cloud computing IQ?

The Cloud is the Computer

John Gage’s prophetic remark “The Network is the Computer” beautifully highlights the difference between SaaS and cloud computing. While SaaS applications provide on-demand services to millions of users across the Internet, cloud applications provide on-demand services to millions of other applications across the Internet. The network really is the computer.

Why should this matter to SaaS experts and vendors? Two reasons. First, because most SaaS applications today exist as silos that only solve a piece of a customer’s puzzle. Second, because cloud computing enables new economies of scale through shared infrastructure that properly designed SaaS applications can leverage to further drive down total cost of service.

SaaS Model Economics 101 states that SaaS competitive advantage comes in two Internet-enabled flavors: network-based differentiation and lower cost from economies of scale. Cloud computing creates new opportunities for SaaS vendors to extend their competitive advantage by opening their applications to the cloud through Web services and further driving down costs by running on shared cloud infrastructure.

SaaS Silos vs. Cloud Platforms

SaaS Do #9 – Open Up to The Cloud encourages SaaS vendors to reach out to complementary applications on the Web through open, standards-based APIs. But opening up to the cloud is not just about easy integration. Comprehensive Web service access will transform your SaaS application into a cloud computing platform. Virtually everyone today knows about Facebook. But, what not everyone in the SaaS community knows is that the fundamental reason Facebook kicked the crap out of Myspace and all the other wannabees vying for social network dominance was the introduction of the Facebook platform that allowed independent developers to create Facebook applications. Platform-as-a-service (Paas) opportunities are not limited to pure play PaaS companies making cloud development and deployment toolkits, PaaS opportunities are open to every SaaS vendor that thinks beyond the browser and is willing to expand its definition of “user” to include not only people, but other applications as well.

Have SaaS, Will Travel

It’s hard to believe, but we already have a “traditional model” for SaaS application architecture based on database multi-tenancy and a vertically integrated delivery infrastructure. This architectural model is the foundation of the SaaS cost advantage. However, it originated in a pre-cloud computing world based on the pre-cloud computing assumption that the SaaS application would run on a static host infrastructure.

To fully realize the cost advantages available on the Internet, the next generation of SaaS applications will not only be multi-tenant, but will be multiple tenants in their own right on shared cloud infrastructure. Monolithlic, vertically integrated SaaS applications will be broken up into loosely coupled, multi-layered Web service components that can be dynamically deployed to multiple cloud platforms in order to meet production requirements. This trend is so visible to the VC community, that the folks at Bessemer promoted it to the #1 spot of their recently revised 10 Laws of Cloud Computing and SaaS.

Blooming Channels

The inadequate grasp of cloud computing in the SaaS community was highlighted for me by some of the reactions of my fellow SaaS evangelists to this recent post of the emerging PaaS channel opportunity. As if the emergence of the PaaS channel somehow devalues the “pure” SaaS channel. This is not the case. There are fewer “pure” SaaS channel partners simply because SaaS vendors are doing a good job of making their applications easy for people to deploy and use. This is a good thing!

The fact that there are fewer “pure” SaaS channel partners does not in any way discount their value. SaaS channel partners have naturally gravitated to very high value services such as business strategy, process design, requirements definition, vendor selection, and training. However, from the SaaS vendor’s perspective these types of channel partners are gatekeepers. They don’t move product. And, anyone who has spent any amount of time in consulting will tell you that while a strategy project may net you $100K in services revenue, a development project can net you $1M. So, I’ll say it again. Cloud channels will follow the money.

This is not to say that we’re going back in time with the PaaS channel reliving the custom development glory days of enterprise software VARs. PaaS channel partners will be leading the charge into a new paradigm of cloud-based application development, sewing SaaS applications and Web services together into flexible mash-up cloud applications and application suites that are dynamically deployed across the Internet. The retooling required of traditional software VARs to deliver these services is no less daunting than the shift required of enterprise software companies to deliver SaaS. (How long did it take SAP and Oracle to get with the program?)

SaaS vendors with high cloud computing IQs recognize the cloud as the new channel. They will transform their applications into cloud computing platforms and will see their PaaS channel opportunities bloom. Whereas today’s “pure” SaaS channel opportunities are largely limited to marketing referrals from trusted advisers and affiliates, tomorrows PaaS channel partners will redistribute SaaS applications over the cloud as components, complements and containers of other applications. They will extend both the market reach and product capabilities of SaaS vendors that embrace PaaS the same way they have already done this for Salesforce, Facebook, Google and Twitter. The network is the channel.

SaaS channel partners have definitely received the short end of the stick compared to their software channel counterparts. With a few notable exceptions like Salesforce.com, Netsuite (and largest, but least recognized as SaaS, Google AdWords) there simply have not been enough customers or enough work to engender a thriving ecosystem of SaaS channel partners, at least not when compared to the sprawling extent of enterprise software channels. I think this is about to change.

Channels Always Follow the Money

There is one universal law that governs all channel management: CHANNEL PARTNERS MUST MAKE MONEY. The biggest channel mistake made by many a SaaS start-up CEO is to fall into the fantasy that SaaS channel partners are there to help your business. They are not. They are there to help themselves. And, how much money they can make boils down to a very simple formula.

SaaS channel money = SaaS channel value-add x SaaS application customers

And right here is the rub. The self-serviceability of many SaaS applications from customer acquisition through deployment significantly reduces the value-add for SaaS channel partners. In fact, if all SaaS vendors embraced SaaS Top Ten Do #3 – Accelerate Organic Growth, then the SaaS channel situation might be even more dire. Moreover, the number of SaaS applications with enough customers to drive SaaS channel development can be counted on your fingers and toes.

Unfinished Business is the Business of Channels

The work required to realize the benefit of your product is the same whether you do it, your customer does it, or a channel partner does it. Channel partners add value by finishing the unfinished work that you and your customer start, but for business reasons can’t complete. They simplify and speed adoption by shouldering tasks that they can do better, cheaper and faster. The greater the gap between your service and your customers’ ultimate needs, the greater the value delivered by the SaaS channel partner and the greater the SaaS channel opportunity.

SaaS Total Cost of Service – Visualizing the SaaS Channel Slice of the Pie

I like to visualize this as the cloud channel partner’s contribution to total cost of service (TCS), because the success of your cloud channel strategy will always hinge on a) your cloud channel partners’ ability to make money and b) your customers ability to realize value that exceeds total cost of service, including the money made by your cloud channel partner.

Developing in the Cloud: The Emerging PaaS Channel Opportunity

The problem with SaaS channels to date is that there simply has not been enough for them to do. I think this is about to change, but I also think it will happen one layer down in the cloud technology stack. If you examine the raison d’etre for the vast array of enterprise software channels it comes down to the fact that enterprise software is delivered in an unfinished state, leaving plenty for enterprise software channel partners to do and lots of it requiring very specialized technical knowledge with which customers simply don’t want to bother.

These attributes are also present in the emerging platform-as-a-service space (PaaS). Whether it is building, deploying and managing a new application on Amazon AWS or simply extending and integrating existing SaaS applications using the ever expanding pool of Web services APIs, the number of opportunities for pure cloud-based development is increasing and is sure to grow to a scale that rivals enterprise software. Unlike SaaS applications that are designed with the business user in mind, PaaS and IaaS offerings are designed for developers. They are by their very nature brimming with potential value, unfinished and highly technical–making them ripe for channels.

Whereas SaaS providers have struggled to develop the interest of potential SaaS channel partners, IaaS, PaaS, and PaaS tool vendors are likely to find their businesses increasingly dependent on cloud channel partners focused on pure-cloud application development and deployment. Moreover, you can expect these cloud channels to spark a proliferation of home-grown development, deployment and monitoring tools that will ignite and accelerate the already hot PaaS tools sector as cloud channel partners product-ize their home-grown systems and take them to market.

So, if you are an enterprise software channel partner and have been scratching your head for the last few years trying to figure out how to jump on the cloud channel bandwagon, then think PaaS channel not SaaS channel. And, get started already or you may miss the boat.

From time to time, I come across what IMHO are really fantastic and enlightening blog posts and SaaS best practice guides that truly stand out above the rest….by authors other than Chaotic Flow . To me the value of these gems is immeasurable, because I generally have to read through a lot of crap to get to them. It’s a big Internet.

In the hope of adding more value than I alone can muster for my loyal Chaotic Flow readers and in the spirit of supporting the authors of these high quality gems by spreading their words to my small corner of the SaaS and cloud computing business community, I’m launching a new SaaS best practices community blog companion to Chaotic Flow dubbed Open Current (cute right?).

Open Current is an open repository of SaaS best practice insights and tools for executives charged with building SaaS and Cloud Computing businesses…moderated by yours truly, so ONLY THE BEST will be make it through the rigorous evaluation process (basically, I have to read it and think it’s earth-shatteringly good…but, please don’t let that deter you….help wanted, submit your favorite SaaS and cloud related posts!)

ANYONE CAN POST to Open Current and I need your help! Please comment on this post, email info[at]open-current.com, or directly submit your favorite SaaS and Cloud Computing blog posts, SaaS best practice guides, and industry research and reports for inclusion.

SaaS Do #8 Enable Mass Customization is a core principle for building SaaS applications. Salesforce.com, for example, has taken it to new heights with offerings such as the Force.com platform. However, do SaaS-based development platforms such as Force.com represent a fundamental shift in application development, or are they simply the SaaS equivalent of Microsoft Visual Basic for Access? How do they stack up against cloud computing platforms like Amazon Web services? This post examines the potential for competitive advantage through mass customization in cloud computing vs. SaaS.

The short answer is this…
Mass customization in cloud computing is more natural, more flexible, and offers more potential for competitive advantage than in the wildest dreams of SaaS, because cloud computing is built on Web services that are a) inherently abstracted, b) independent components and c) accessible at every layer of the technology stack.

Note: In a previous post, I claimed that the salient difference between SaaS and cloud computing is that SaaS has largely been about Internet applications used by people, whereas cloud computing is about Internet application components used by other computers. More succinctly, Websites vs. Web Services. Although everyone seems to have their own definition of all the cloud buzzwords, I’m going to be rather specific and equate them as such: Cloud = Internet, SaaS = Websites for human users, Cloud Computing = Web services for computer users. My intent is not to debate or define the industry terminology, but simply to keep track of what the heck I’m talking about here at Chaotic Flow.

The Role of Meta-data in Mass Customization
Mass customization in SaaS is achieved by converting hard-coded application functions into meta data configuration settings.  For example, multi-tenancy converts hard-coded deployments of multiple customer databases into a single database infrastructure where each customer deployment is identified by a unique customer ID. All the technical miracles that distinguish one customer’s data from another customer’s data are abstracted to this single piece of meta-data to enable data-driven functionality like Customer[1].Name = “Company X” and “Customer[2].Name = Company Y”. Voila!  Mass customization = meta data abstraction of functional capability.

More Natural – The Inherent Abstraction of Web Services
Mass customization is more natural to cloud computing vs. SaaS for one simple reason: meta-data abstraction is inherent to Web services, but it is optional for websites. SaaS applications must be carefully architected to enable mass customization at all, i.e., it is a matter of good SaaS application design discipline to employ a multi-tenant database, configurable security settings, customizable page views, etc. In contrast, every function of a Web service is inherently abstracted to meta-data in the XML inputs and outputs of the API.

The Xignite stock quote Web service can return a wide variety of information
such as the current stock price, an intraday stock chart, and financial news
that varies by the stock symbol (meta-data) supplied to it.

For example, given a particular stock symbol (meta data), the stock quote Web service above can return a wide variety of information about a company such as the current stock price, an intraday stock chart, and financial news. Let’s say Company X above is a manufacturer that uses this Web service to create a website with detailed, current financial information about the company for potential investors. Now let’s say Company Y is a Web publisher that uses this Web service to create a widget that provides in-line stock quotes for companies discussed in its news stories. Here we have two completely different applications built from a single Web service. Imagine trying to architect this degree of mass customization into an end user SaaS application, i.e., a single Web application that can present anything from a detailed company financial profile Web page to a single stock quote widget simply by changing application configuration settings. Sounds like iGoogle to me. Not easy.

More Flexible – Independent Components vs. Monolithic Applications
The stock quote example above also demonstrates the flexibility of enabling mass customization through independent components over that of a monolithic application. Changing a single feature from hard-coded to configurable in a SaaS application can require modification and refactoring at every layer of the software stack from the database structure to the user interface, e.g., adding user-defined custom fields. Moreover, the introduction of  new configuration settings can have a multitude of known and unknown impacts on existing and seemingly unrelated features, e.g., changing an address format from a standard US postal structure to a configurable structure that better supports international clients. The result is that even the simplest modifications to a SaaS application must be carefully considered and become more difficult the more complex the application.

Web services are relatively independent, loosely coupled components. New functions can be added to current Web services, and entirely new Web services introduced with minimal impact on other Web services. For example, I use Google’s chart Web service to generate the charts on the SaaS Model Scorecard. If Google wants to add new chart types to this Web service, it simply creates new values for the “cht” parameter and any other relevant options. However, a SaaS charting application would require changes to the UI to select the new chart type, select the new chart type options, visually edit the new chart type and display examples of the new chart type. Depending on the architecture of the application, this could be a modest change or a monumental change.

Moreover, independence allows customers to assemble solutions from best-of-breed components more easily. The stock quote web service above supplies the data and charts, but the UI can be constructed using the customer’s tool of choice, including any SaaS application that supports Web services. Application integration across functional silos has proven to be a consistent challenge for SaaS companies. Most have turned to open APIs, i.e., Web services to address this challenge. The more a SaaS application opens itself through Web services, the more it acquires the flexibility for mass customization available to native cloud computing solutions. Pushed to the limit, it can become difficult to tell the website from the Web service.

Wildest Dreams – Morphing Applications and Infrastructure, not Just Features
Imagine building a SaaS application that could magically morph from CRM to ERP through configuration settings. The complexity of building such an application is staggering, not to mention the subsequent configuration. Again the Force.com platform comes to mind. Now consider cloud computing. Let’s say I store the respective CRM and ERP application executables on Amazon S3. And, I create a Web service with two calls: gimme CRM and gimme ERP. When I log in, I select ERP or CRM. This Web service automatically downloads the specified application and instantiates it on a farm of Amazon EC2 virtual server instances, where it can be accessed from the URL www.elastic_crm_or_erp.com. This neat trick is possible, because Web services allow mass customization at every layer of the software stack. In this particular case, the configuration reached down below the application layer itself to the O/S and swapped out the entire application. From the user point of view, I just magically see my website change from ERP to CRM.  This approach is really overkill for this simple example, but it makes clear the ability of cloud computing to handle meta data driven, ad-hoc modification at any layer in the technology stack.  It could just as well be accomplished at a much higher level in the stack using two SaaS applications and a single sign-on…uh, Web service.

Mass Customization and Competitive Advantage in Cloud Computing
Although cloud computing offers greater potential for mass customization than SaaS, cloud computing does not really compete with SaaS. Amazon AWS and Force.com are unlikely competitiors, because they segment the market into the high-end and low-end of mass customization respectively, and customers will choose one or the other according to their requirements.

Like SaaS, cloud computing competes against on-premise software, offering many of the same benefits such as lower TCO and mass customization. But unlike SaaS, cloud computing does not compete head-to-head for a final end-user applications. It competes for components at every layer of the technology stack from storage to user interface. As a result, the competition centers around architecture as much as outsourcing. While SaaS adoption is usually driven by functional executives, cloud computing adoption is driven by IT executives. Adopters of cloud computing must rethink how they build applications, employing interchangeable components that may or may not exist within their own firewall. In order to overcome this barrier, cloud computing vendors should leverage mass customization to offer their customers orders of magnitude improvements in functional versatility, deployment flexibility and infrastructure elasticity in addition to lower TCO.

It seems that everyone is jumping on the cloud bandwagon.  Cloud this, cloud that, everything cloud.  Salesforce.com has all but rebranded its entire business as cloud.  Instead of sales force automation, we now have “Sales Cloud 2” (and “Service Cloud” and “Custom Cloud” and “Collaboration Cloud” with nice little TM’s attached, so if you were thinking of using them for yourself, you can forget it!).  I suppose it might be a good thing.  Personally, I was getting pretty tired of Salesforce.com trying to “force” this brand, “force” that brand on me.  I really don’t have a problem with the cloud buzz per se.  I think it is good for the industry, because it creates excitement, momentum and funding for B2B Internet companies.  But, I am concerned that all this unbridled rebranding and repositioning is obscuring the underlying technological and economic shifts which characterize this next stage of Internet evolution.

Cover from the Pink Floyd album Obscured by Clouds.
Not really relevant, but I needed a picture.
Retweet if you’re a Pink Floyd fan!

The Web 1.0 Internet revolution, of which classic software-as-a-service is a part, arose as a result of the universal interface offered by the Web browser.  Suddenly, anyone could access any global computing resource over the Internet as long as they had this one, standard client application.  It didn’t really matter what happened on the back end, because everyone was plugging into the same application on the front end.  I like to think of this as application – user interoperability.  The economic implication of this paradigm shift was that you could now aggregate customers around the globe onto a single Internet application.  Say for example, ordering books or sales force automation.

The shift we are seeing now is driven by increased interoperability on the server side, or rather application – application interoperability.  And, because it is on the back end, it is occurring at every layer of the software stack from the virtual machines of cloud computing to the really simple syndication (RSS) of personal blogs.  Not only have underlying Web service standards like XML, SOAP and JSON gained broad acceptance, but general openness, public APIs, and application development frameworks are becoming the cultural norm for Internet applications.

Let’s be clear on the magnitude of this technology shift.  The current Web 2.0 boom, call it the social Internet revolution, is realistically 95% new product ingenuity and 5% new technology.  A little AJAX, a little RSS, and voila!  Facebook.  Twitter.  The application-application interoperability of the cloud is a fundamental technology shift that has the potential to unleash the same kinds of disruptive economies-of-scale and disintermediation of legacy business models by aggregating computing resources in the same fashion that Web 1.0 did by aggregating users.  But, this time the war won’t be fought at the user level between brick-and-mortar businesses and Web businesses.  It will be fought at the application level between traditional closed, proprietary on-premise software and open, standards-based cloud offerings.

For example, this is the essential value proposition of Xignite.  Xignite supplies on-demand market data via Web services.  As Salesforce.com “Sales Cloud 2” is to Oracle-Siebel, Xignite is to legacy data feed application vendors like Thomson-Reuters and Bloomberg.  But, instead of serving a multitude of users from a single application infrastructure to create economies of scale and reduce TCO, Xignite creates new economies of scale and reduces TCO by servicing a multitude of applications, such as WorlframAlpha, NetSuite, Forbes.com, corporate financial apps at GE and iPhone apps at startups like Palantir.

For me, this giant leap forward in application-application interoperability is the essence of this revolution we call The Cloud.   The rest is window dressing.

After spending the last couple of years consulting around the SaaS and Web 2.0 worlds, I’ve decided to take the startup plunge again and settle down in the clouds. I recently joined Xignite, a cutting edge on-demand cloud services and mashup platform provider that helps companies incorporate accurate, current financial information directly into websites and applications via Web services, i.e., no integration programming required! The company is off-the-charts on the SaaS Success Top Ten Dos and Don’ts as evidenced by everything from the potential market (market data is a multi-billion dollar industry already…based on really old legacy stuff) to the e-commerce Web site to mass customization via the Splice on-demand mashup platform. Plus, the team is great from the sales reps to the board and the culture is pure software-as-a-service.

Xignite has a classic SaaS vs. legacy software value proposition
(on-demand web services vs. data feeds and custom code)

We have an Xignite company blog at xignite.web-services-blog.com, so my loyal readers can rest assured that opinions expressed here at Chaotic Flow will remain as objective as ever, but they may start taking a bit of a bent toward the emergence of cloud services…which differ from application-oriented SaaS in some distinct ways that directly impact the economic and business model dynamics–not the least of which is that they are used by computers instead of human beings.  However, the primary value proposition at Xignite remains classic SaaS vs. Software, or in financial services industry-speak financial web services vs. market data feeds.