03.28.07

I recently had the opportunity to chat with Geoff Crawshaw of OpenAir, about the approach they have taken to managing their software as a service offering. GXS is an OpenAir customer (we use it to manage our professional service teams projects and time tracking), and we recently had an internal session to look at how we use OpenAir, and what is distinctive about it as a service — things that would be difficult to match through the purchase of traditional enterprise software.

What we came up with was not surprising:

• We were able to ramp quickly, over a three month period in our case — globally. This may not sound fast, but the truth is the service was constrained by our ability to load data and train people; at no point did the software as a service slow down the process
• New features arrive on a regular basis without any “upgrade”, in fact — there are no version numbers (I cannot state how amazing I find this. It doesn’t sound like a big deal, but it is — see below about “feature switching”)
• Costs scale with usage — in this case the number of seats. The service is pretty generous here though, as it is very easy to download data (almost every page has a “download” link that can retrieve the data into a pdf or spreadsheet ), so only people that need to “use” the system need a seat

I say these are not surprising because this is what you generally associate with SaaS. What was more surprising was the following:

• customization: the system can be both customized and personalized. Individuals can change the layout of screens (order of fields, what fields are shown, sorting, etc), and create their own reports
• extensibility: new attributes (data fields), reports, etc can be easily added — all through a web interface
• integration: there are techniques to integrate (both batch and realtime) to internal systems (traditional enterprise software)
• speed: the system screams. While I certainly would not say I would expect a hosted service to be slow, I am genuinely surprised that it is quite a bit faster than even our internal portal

Suffice it to say that most of us, and myself in particular, were intrigued — so I asked for a meeting.

Geoff shared with me some of what I would call the “culture” of development at OpenAir. First off, PageBuild (how long it takes to render the page from OpenAir’s point of view) is the key metric — and they obsess over it. They have detailed analysis about how customers perceive speed (basically, if 80% of the pages render in less than a second, with an average of .3 seconds, customers think its fast), and they work like crazy to hit those targets. Deployed features are monitored for PageBuild,and yanked back (see feature switching, next) if they slow things down. Note that being able to regress is a big advantage of the SaaS model as well. They aggressively use existing technology (particularly minimizing database hits), but it is the attention — rather than technology — that keeps it fast.

But they do have a very novel approach to feature deployment — and it is very specific to the SaaS model. They do not think about releases as a packaging of code, but rather as an event that concludes a development cycle (which run about 6 weeks, 4 for coding and 2 for testing). “Features” are somewhat independent of each other, and are deployed using “switches”. Most features are deployed “switched off”, until support can reach out to customers and determine if a feature should be “switchedon” for a given customer. The amazing thing about this feature switching architecture is that the application layer is shared for all customers (each customer has its own database, but customers share a common “farm” of application servers).

This points out another major difference from traditional models (and also helps explain why version numbers are redundant), all of the customers are on the same codebase. This seems obvious since they share the same production application servers, but this means that there are no “old versions” to support. If you are a software or service vendor, you can appreciate the incredible productivity gained from this — which translates into higher quality (focus on single version is powerful), and muchhigher support productivity.

One final point of discussion was the difference in business model, which I know helps GXS succeed as well. In the Software as a Service model, the bulk of revenue comes from existing customers using the service (this is how GXS has operated for its entire history). This is very, very different from enterprise software, where license revenue is the primary contributor of revenue (maintenance is important, but customers are “invested” once they pay the license fee, and switching costsare historically very high….). The effect of this is to focus SaaS vendors on features that drive value in the opinion of current customers using the system, while traditional enterprise software companies must tilt more toward features that appeal to buyers of software. Geoff makes the point that SaaS companies have the upper hand because their financial rewards are better aligned with continuing customer satisfaction than software vendors — and I agree.