What Do You Care What Other People Think?

Architecture Strategies for Catching the Long Tail

Fred Chong has completed his work on the overview of the architectural guidance for building Software-as-a-Service (SaaS) applications on Microsoft infrastructure.  If you haven't seen it yet, check it out.

Fred spent several weeks in the field with SaaS providers who have built their applications on Microsoft in order to understand the key issues core principles in building a scalable, multi-tenant on-demand environment.  Many of the companies they worked with are startups managed by the Microsoft Emerging Business Team (EBT), and I had the privilege to connect with some of them.

The EBT is actively reaching out to and working with SaaS providers building on the Microsoft platform in order to improve their market exposure and business relationships.  If you are interested in connecting with the EBT, check out their SaaS page and drop a line to SaaSMS@microsoft.com

SaaS Architecture Guidance

I've had the privilege to work with Fred Chong and Gianpaolo Carraro, a pair of extremely bright guys who work in the Architecture Strategy group.  They have a passion for SaaS and are applying themselves energetically to mapping out the space of SaaS application architectures.  They realized that there is very little guidance or documentation on best practices for SaaS architectures in the community at large - while there is some shared knowledge and a set of conversations, no hard documentation exists in any comprehensive way.

Fred is now on a mission to build definitive guidance on how to grapple with tough issues like multi-tenancy (including defining what that means), security, customization, metadata, and operations readiness.

Fred has posted the outline of the SaaS architecture guidance book that he is developing on his blog, and I'm pasting some of the chapter outlines here as well.  Fred is an expert in Identity Management and Web Services management (he literally wrote the book for WSM at Microsoft), so he knows what he is talking about.

1. Introduction
2. Business Model
3. Application Architecture Overview
4. Scaling 101
5. Data Management
6. Tenant Management
7. Tenant Customization
8. Application and Data Security
9. Programmable Software Services
10. Programmable Software Service Consumption
11. Instrumentation and Monitoring
12. Configuration Management
13. Metering
14. Infrastructure Security
15. Operation Structure

If you're interested in this, drop by Fred's site and take a look - better yet, send him an email and tell him what you think.

Where are the OSS/BSS companies for SaaS?

Most of the companies I've spoken with have had to build their own OSS/BSS systems to run their Software-as-a-Service operation.  Provisioning, metering, and billing are core business functions for service delivery organizations, and while there are custom aspects to them, and hence good reason to build your own, there are probably better reasons to buy them off the shelf… if they were available.

Companies like Portal Software and Convergys have long supplied these systems to the telco industry, yet I've seen no indication that they are moving to engage the SaaS segment; nor have I heard of VC-backed startups targeting this critical infrastructure space.

A related need is that for a robust pricing engine that is capable of handling multiple pricing schemes (i.e. per transaction, per user-month, or per CPU-month).  Again, this is a core business function, and as we saw in the great Telco battle between Verizon and AT&T Wireless, the winner is the one that can combine their difference service assets into the widest variety of packages.  The story behind this (from my perspective) was partly due to integration (Verizon made the investments required to integrate their dozen-plus backend billing systems) and partly due to pricing & packaging - the ability to target a new demographic or customer segment with a custom package that is more attractive than the competition.

One quote I heard in the last few months - and I apologize, I have forgotten who said it - is that in the end, telco margin per customer is probably the same between "friends and family", "small business", and "enterprise" packages… but the success of the business is in crafting the package that feels right to the target customer and incents them to make the purchase.  So Verizon won, because they used their pricing agility to win new customers.

The corollary for SaaS that I'm taking away is that pricing flexibility is going to be key to competitive advantage… which brings me back to "where are the OSS/BSS apps for SaaS?"

Scoble Interview: Enterprise Mash-ups

I got the chance to sit down with Robert Scoble for 20 minutes last Friday.  The thing that has puzzled me recently is whether mash-ups are for real, or just another Web 2.0 buzzword.

So I asked Robert: "Are mash-ups going to make a real difference outside of the digerati - do you think they'll make it into the enterprise?"

His take was: what's to prevent mash-ups from being the main way that departmental apps are built in most enterprises 3-4 years from now?

We've seen composite applications pitched for years, with some very cool companies like Digital Harbor building development environments for constructing them, but in a way mash-ups are an even simpler way to build a composite application - pull together a set of ICCs (still looking for the definitive term for this, as are others, it seems - see Harry Pierson's discussion).

So what would an enterprise mash-up server look like?  How would it have to be packaged in order to be adopted by departmental users?  Would it be hosted like the other new technologies that are breaking into departmental use (salesforce.com, MarketTools, ExactTarget, etc.) or would it need to be a local server?

One of the other issues Robert raised was that of attention, and its necessary evolution to make the computing experience more useful.  Currently, attention is captured and processed only on the server, which makes for some thorny issues about trust (who am I trusting with my attention data? and why?).  To deal with these issues it seems to me that there will need to be a client-side standard for attention, implemented by browsers for inter-ICC communication, as opposed to relying on the server to have good behavior.

Then, in a twist of synchronicity, I got to talk with a very early-stage company building a mash-up server that can run on the client or the server.  It's in stealth so I can't disclose much more yet... but I am becoming convinced that this programming model could be just the thing to build SaaS composites on.

[Updated to add reference to Harry Pierson's entry.]

Contrary Evidence at the SLC

At last week's IDC Software Leadership Council, opinions on Open Source were not the only surprise.  The IT Execs from 4 companies (Manufacturing, Healthcare, Heavy Equipment, and Financial Services) were generally against subscription models for software.  As the conversation progressed, two key statements came out:

1. The CIOs did not want to go with subscriptions because if their business grew beyond expectations, they didn't want to pay the software provider more ("Why should we share the upside"?)
2. The CIOs did want providers to reduce pricing if their business failed to grow to expectations

I think this was a case of two things - first, the natural expression of greed (wanting vendors to share the downside but not the upside) - but more importantly, a need for the industry to provide clearer guidance on standard pricing models.  There was a clear conflation between value-based pricing and usage-based pricing in the mind of the customers.  Additionally, they were concerned that in the long run it would be cheaper to go with perpetual licenses and pay maintenance, dealing with amortization internally, rather than pay a subscription cost which would never go down.

So where do we go from here to advance the understanding of the SaaS industry's offer to CIOs of mainstream companies?  Are the doubters right, and will SaaS fail to penetrate large enterprises because of these issues?

Disruptive Innovation and Darwin

I have great respect for Clayton Christensen, who has done serious work putting real meaning into the term "disruptive innovation".  He's quoted in the latest Newsweek article on Skype, saying:

Still, the novel pay schemes "are hugely interesting," says Harvard Business School professor Clayton Christensen, who cites both Kazaa and Skype as great examples of the "disruptive innovations" he studies. "It's almost never the technology itself that paralyzes the incumbent—it's that the incumbent has a system for making money that's irrelevant to the new guys."

The combination of companies growing up after the bubble burst, dealing with recession and market pressure by using free software and then reducing customers' cost to use through "rightsized" pricing (moving amortization costs of hardware and software from the customer to the vendor, and reducing overall management costs through centralization) has produced some very fit organisms - not unlike biological organisms that have deveoped in impoverished environments, they may be tougher than the incumbents of enterprise software.

Axel Shultze of BlueRoads has said that no one originally set out to get to the current state of SaaS - it was a series of changes to fit the customer environment that led the industry here.  It will be very interesting to see where the intersection of pay-as-you go and ad-funded software business models leads us next.  I think Darwin would be having fun right now watching this industry evolve in real time.

SaaS is the "S" in SPLA

I've found that relatively few people know about the Service Provider License Agreement, which was built for hosters and companies which need monthly, usage-based licensing.  From the program description:

The Services Provider Licensing Program enables services providers to license Microsoft® products on a monthly basis. The program is designed to emulate how service providers do business - providing services on a monthly fee to their end-customers. A sample list of products available to service providers in this program is provided below.

So it's a pay-per-use model that works in arrears - hosters provide a report of the license units used that month and pay after they're done.  SPLA incorporates Software Assurance so there is only one license and one price to pay for usage.  There is a version specifically for ISVs which you should look at if you're currently a SaaS ISV using the Microsoft perpetual license model.

Two good examples of why this is useful:

1. Cashflow management: under the perpetual license you would need to buy the software up front and amortize the cost over a multi-year period.  SaaS is a cashflow-focused business model with little room for capital expenditures that need to be rationalized later (as seen by the standard practice of leasing hardware rather than buying)
2. Seasonal volumes: if usage goes up one month, and down the next, there's no need to buy additional perpetual licenses, guess what the necessary capacity will be, and suffer for guessing too high (if you're in Operations at a SaaS company, you know how challenging this can be - as they say, "it's hard enough to predict the past, let alone the future").  Instead, SPLA users report & pay month to month, so payments go down when usage goes down.

The team that came up with SPLA, led by Pascal Martin, has partnered with Rackspace and other hosters so that SaaS ISVs can transfer their existing operations to an MSP.  They are working hard on the next version of the ISV-focused hosting solution - more news on this in the near future.

A Billion Emails via SaaS on .NET

I've had the chance to some time with ExactTarget in the last week.  They're a SaaS email marketing company based on .NET with a very slick AJAX interface.  Since they're an email-centric company, they use Outlook as their design center - task pane selection and folder trees on the left, interaction page on the right, etc.  This parallels feedback I've heard from customers about email interfaces in the recent past.

The impressive statistic I got from our conversation was that they will send a BILLION emails this quarter - perhaps it's my ignorance of the email marketing space but I thought that was impressive.

While talking with their CTO and VP of Engineering, I learned a few things. 

First, they're doing all of this on end-to-end .NET (Windows Server, SQL Server, etc.) and have achieved massive scale.  Second, they're based on AJAX.NET, an elegant Open Source AJAX framework for ASP.NET (for example, to make a method asynchronous on the client, you just add an attribute: [AjaxMethod]).  Furthermore, they've hand-built a number of generally useful client-side features using AJAX - a WYSIWYG editor like Writely, and due to their server-side architecture, they've been able to integrate useful data cleansing tools via SOAP interfaces.  With the number of comments I get about REST >> SOAP these days, I had to ask about their use of SOAP.  They said they got it for free by using ASP.NET (.asmx pages), and that the automatic harnessing of SOAP rather than raw XML was useful.

The new stuff they're coming out with - and which they demoed at Salesforce's conference recently - is significant - partly because of their use of AJAX for some sophisticated drag & drop workflow features, and partly because of the breadth of scope they can handle with their workflow engine.  I can't give it all away here, but be sure to check them out when they launch the new stuff in December.

The ExactTarget team was happy overall with our technology, but were not happy with our licensing.  Running on Windows and SQL Server perpetual licenses, they are charged in a way that's out of sync with their business, and while standard "failover" servers are not charged for by Microsoft, "unutilized production" servers are.  Fortunately, we do have a better offering for them - I believe that the Service Provider License Agreement (SPLA) will be the solution to most of their issues.

If you're a SaaS ISV and you're using Windows, you should almost certainly be using the SPLA instead of perpetual licenses - it's pay-per-use and is a much closer fit to the SaaS operations & cashflow model.

VCs on SaaS

I've been asked several times recently why I'm focusing so heavily on Software as a Service.  The answer is very simple: the future of the model is inescapable.  I work in the team at Microsoft that is responsible for managing our relationships with Venture Capital firms and helping their startups succeed with us as business partners.  In the last 6 months I have heard in person - whether around a table or attending an event - from partners at Accel, Hummer Winblad, NEA, Norwest Ventures, and many others: "We are only considering software deals that include a strong SaaS component." 

John Hummer actually said it more directly, at the SDForum event on SaaS back in March 2005: "If you are going to pitch me a software deal, it had better be Software as a Service."  Emergence Capital is a $125 million fund established solely to finance SaaS plays.  BAVP made their interest clear way back in 2003.

Add to this the fact that many partners I've spoken with have said that the software side of their portfolios currently include between 1/3 and 1/2 SaaS plays, and the reason to focus on this is obvious: the trend is only accelerating.  IDC forecasts the delivery segment (not "market") to reach $10.7B by 2009. 

It can be argued that this is a new bubble, but unlike Web 2.0 (which sure smells like a bubble right now but perhaps it's an echo boom) it is a software value shift that is fundamental and easy to grasp, whether or not you're a member of the digerati. 

Client Software as a Service

I spent a couple of hours with Dan Udoutch and Venky Venkataram from AppStream yesterday - smart guys with an awesome product.  Dan was at Netscape in the early days and has been all around the Valley since then (including CommerceOne from early on to the famed $350 share price and then Intersperse) and Venky ran engineering at ZoneLabs - enough said.

AppStream has some very cool technology that streams just enough of a Windows or Java application down to the desktop that it can start up and respond to standard user flows - then pulls down more of the application dynamically as the user activates other features in the app.  There's no interruption in the user experience, and the app runs locally on the client, with normal permissions, Start Menu entries, all the normal Windows app behavior you'd expect.  This is cool technology because the user wouldn't even notice it was there.

They combine this with robust management, provisioning, and metering for applications across large user communities.  Since applications are streamed on demand, apps can be versioned automatically across a user base, without any action required from the user.

What this enables is full client-side software as a service - where the definition of SaaS is "freeing the customer from daily operation, maintenance, and upgrades of the application".  When I step back from the SaaS phenomenon what I see is a value shift in which customers want their applications to "just work". 

There are a number of applications for this - one that springs to mind is security policy management of application versions; NAP and NAC both require a local SHA (System Health Monitor) that reports the versions of current apps on the client back to the Health Server, which then allows access to the network or sends the client a list of remediations required; the client then goes to a remediation server for detailed instructions which typically require patching or upgrading specific applications.  AppStream would allow this whole cycle to be bypassed (for managed applications) as the application would automatically stream down the latest version when the user starts it up.

I think this could be transformative as the pendulum of SaaS swings back to blended client & server implementations.