Almost tangential to the main thrust of Warfield’s post, he writes;

“There are two ways the SaaS world tackles [the problem of making enterprise software applications flexible]–for some problems metadata is the answer, and for other problems end user-approachable self-service customization works.  Let me give some examples of each.

Metadata is literally ‘data about data‘.  As such, it is a beautiful thing.  Let’s consider the database.  It is very common for different organizations to want to be able to customize the database to their own purposes.  Let’s say you have a record that keeps information about your customers.  A lot of this information will be common, and could be standardized.  We all want the customer’s name, their address, phone number, and perhaps a few other things.  But then there will also be a lot of things that differ from one organization to the next.  Perhaps one wants to assign a specific sales person to each customer.  Another wants to record that customer’s birthday (obviously this is a much smaller organization than the first!).  And so on.  Without metadata, each database has to be customized and changed.  With metadata, rather than changing each database, you build the idea of custom fields in, and then you can just tell the database what the custom fields will be in each case but the structure needn’t change.  Metadata is not unique to SaaS, but it is an important part of the ‘multitenant’ concept.  It makes it possible for all those tenants to live in the same database, but still get to have all their custom fields.

Metadata can also make it possible to enable that second method for flexibility.  Customizing a database without metadata is going to require someone to get into the database, modify the schema, make sure reports are modified to deal with the new schema, make sure the schema changes don’t break the product, and on and on.  Such work is definitely the province of expensive and highly technical experts.  However, once we have metadata, we can create a simple user interface that lets almost anyone add new fields, and that handles all the rest of it automatically.  Suddenly we have made what had been a difficult and expensive technical task approachable in a self-service way by non-technical customers.  Not only that, but they can make these changes quickly and easily, and they can even iterate on them until they get it just right.”

‘Metadata’, eh? I remember the times I spent, back in the Nineties, travelling a world that seemed in thrall to massively over-complicated taxonomies, cataloguing rules and data structures, evangelising the benefits of a more light-weight approach to the description of resources. The assertion that metadata was ‘data about data’ appeared in just about every presentation, closely followed (when talking to librarians, at least) by ‘it is sort of like cataloguing.’

Enter Grigorovici, and his discussion of an old post by Glenn McDonald. As Dan notes, Glenn doesn’t seem particularly keen on ‘metadata;’

“There is no such thing as ‘metadata’. Everything is relative. Everything is data. Every bit of data is meta to everything else, and thus to nothing. It doesn’t matter whether the map ‘is’ the terrain, it just matters that you know you’re talking about maps when you’re talking about maps. (And it usually doesn’t matter if the computer knows the difference, regardless…)”

So, two views of metadata that are apparently contradictory. Yet I pretty much agree with both of them, actually.

Returning to the Nineties, and the rather ridiculous pinnacle of my Gold status with a plethora of the world’s airlines, the “metadata is ‘data about data’” truism was often closely followed by “one person’s data is another person’s metadata” (or vice versa, of course).

Here, as elsewhere, there can be a depressing tendency to seek polarisation; to make things simple by declaring everything either black or white. Grey is anathema, and to be hunted down for exposure to ridicule almost as biting as that directed at proponents of the pole opposite to your own. The reality is, of course, that grey is frequently the norm. The world is a complex place, and one in which a spectrum of views and ‘truths’ is necessary in helping us to make sense of the confusion that bombards all of our senses throughout every waking moment.

An overly dogmatic attempt to categorise some things as always being metadata and others as always data is pointless. Whilst Glenn forcefully argues that there is therefore no such thing as metadata, I would push back just as forcefully to say that any data can be considered metadata; in the right context.

That detailed and structured description of the new car after which you lust is a perfectly valid set of data. In a different context, and perhaps as a surrogate for the car itself, it can more usefully by characterised as metadata.

A database of flight codes, routes, times and aircraft is rich with data just begging to be used in a plethora of ways, whilst ‘BA283′ is equally comfortable as a piece of metadata describing one airline’s afternoon flight from London to Los Angeles.

The concept of metadata can be an extremely useful one; so long as we avoid becoming too dogmatic in defining its boundaries or fervid in upholding spurious conceptual purity.

Hillmann’s Real Metadata © Jeffrey Beall 2007, and shared on Flickr under Creative Commons License.

The formal release is perhaps deliberately ironic;

“In an industry flooded with buzzwords and numerous companies jumping on the platform bandwagon, Apprenda cuts through the SaaS platform clutter and draws a bold line with SaaSGrid. SaaSGrid is a powerful cloud operating system that abstract SaaS intricacies into the SaaSGrid software layer and provides ISVs with the necessary online tools to manage their SaaS business and application offerings. SaaSGrid drastically slashes time to market for ISVs by automatically weaving a SaaS architecture into their non-SaaS web applications while providing significant long term value via web-based application management capabilities.”

Sinclair’s blog post is more straight-talking;

“For anyone unfamiliar with SaaSGrid, it’s a cloud operating system (literally) that makes writing and commercializing SaaS offerings with Microsoft .NET very easy. It removes quite a few headaches from the architecture and engineering perspective, and provides a tightly woven business services layer for managing operational and customer facing aspects of your business. So, if you’re building a SaaS offering and are planning (or looking for a reason to) to use a .NET based language and stack, look no further!”

Bob Warfield is also amongst those covering the news, over on SmoothSpan. Bob gets right down to it, commenting that;

“Apprenda calls SaaSGrid a ‘Cloud Operating System.’  I don’t know if I would call it that or not, but at the very least it is a SaaS platform that offers a lot of benefits not unlike Force.com from Salesforce, but with some key differences.  First and foremost in my mind, is that there isn’t much of anything proprietary about SaaSGrid.  It’s a framework that makes it easy for .NET developers to move their applications to a SaaS Cloud-based delivery vehicle.  Looking at the services provided by the framework, it isn’t hard to see that Schuller & Co. have had experience building SaaS applications before (in fact quite a few of them), because it solves many of the SaaS-specific problems I’ve seen in my career as well.”

He continues, echoing my own initial impression that the most important piece of this might not be the technical infrastructure at all;

“SaaSGrid covers two bases.  First, it offers plumbing and delivery infrastructure services.  In my mind that’s the “Cloud Operating System” piece.  But, at least as interesting is their Business Engine, that helps simplify a lot of the operational aspects of SaaS.”
(my emphasis)

Talking to Sinclair, it is clear that the rationale behind SaaSGrid comes from experience. He talks about work in the financial sector, higher education and elsewhere, in which the same basic pieces were necessarily duplicated. Each project, each deployment, required his team to almost start from scratch and to concern themselves with a plethora of background operations before they were able to concentrate on the actual task at hand.

As in other industries, the framework – the Platform – that Apprenda have developed is intended to remove some of that background complexity and to enable developers working on a given project to get on and develop the actual applications that need to be written. Sinclair said that SaaSGrid

“provides a new layer of abstraction that takes the burden of creating SaaS specific technology, architecture and business components off of ISVs shoulders”

Back in his blog post, Sinclair describes the proposition for a developer;

“Apprenda does not host applications for software companies. Instead, we enable existing hosters to offer independent cloud instances of SaaSGrid. This means that you can write an app and leverage SaaSGrid, but get to choose which Cloud Provider to publish your application to. You basically write code in Visual Studio in a single-tenant fashion, use our API for certain SaaS related duties, upload your app (UI, web services, database schema) to a SaaSGrid cloud of your choice, click a couple of buttons through a control panel and you’re up and running with a true multi-tenant, ready to accept money SaaS offering!”

A community portal provides documentation, support, and access to the basic building blocks such as an SDK that developers can download in order to develop their own applications.

Online tools that Sinclair walked through with me do a good job of tracking multiple versions of an evolving product, managing customers, etc. The Business Engine that interested Bob Warfield comes into play here, offering a remarkably straightforward process by which application developers can manage availability and pricing of ‘features’ and ‘securables’ within each application they release.

SaaSGrid has been in beta for the past six months, with around 30 companies involved in building network monitoring, CRM, HR and other applications. As might be expected, around 40% of beta customers originated in the US… but the beta programme extended as far as Namibia!

The first of these applications are expected to go live early in 2009, and Sinclair was also open to the idea of Apprenda-branded applications appearing as well in order to showcase SaaSGrid and (presumably) secure other revenue streams for the company.

The SaaSGrid user interface is currently only available in English, although currency information for pricing within applications is fully customisable.

Given Apprenda’s reliance upon Microsoft components such as .Net, Azure might be considered a threat. Sinclair appeared unconcerned, though, arguing that Microsoft’s Cloud offering is more concerned with technology even further down the stack. Azure, he said

“could be a resource to use, rather than competition.”

We shall see!

SaaSGrid, though, represents an interesting step forward for those application developers already comfortable with developing atop the Microsoft stack. Just as Talis has recognised with their Platform in the Semantic Web space, there is clear value in ‘doing the heavy lifting’ and enabling developers to get on with building their applications as quickly and painlessly as possible.

Related articles by Zemanta

• Windows Azure: Microsoft Moves to the Cloud
• User Interface and Cloud Computing – Part 2

Facing the real prospect of significant disruption to the mid-range part of their business from the lower costs of relative newcomers Salesforce, NetSuite and others, it certainly made sense for SAP to ape Salesforce’s success and pursue a strategy that would see the German company able to offer their smaller customers a cheaper hosted solution, rather than continuing to rely exclusively upon the expensive purchase, installation and upkeep of hardware at customer sites.

However, as ZDNet’s Larry Dignan reported back in April, the company was forced to slow the roll-out of their Business ByDesign solution, and Phil Wainewright was quick to spot the opportunity that the company had handed to its competitors;

“By announcing its own SaaS product for the midmarket late last year, SAP put its stamp of approval on the on-demand model. Now that it has said customers will have to wait another year or more before they can buy it (due to scaling problems, no less), the company has created the worst of all worlds: it has validated a market and then vacated it, giving competitors a free run.”

So what went wrong, and are there broader lessons to learn from SAP’s mis-steps? As Vinnie Mirchandani notes, both Salesforce and NetSuite have been characteristically swift in publicly rubbing salt into wounds, and most companies would naturally be keen to avoid handing the competition such an easy target.

In a tightening economic climate, and with Dennis Howlett reporting customer disquiet at rising maintenance costs for SAP’s existing installed product base, the company must surely regret not having a good news story to tell about a product that requires no hardware or upgrade investment on the part of their customers. Zoli Erdos at CloudAve reports that NetSuite has jumped on this opportunity too, claiming a total cost of ownership comparable to 50% of just the annual maintenance component of SAP ownership. It’s worth noting that Dennis responds to Zoli’s post in the comments, describing the premise as;

“pure hubris and you know it.”

Unfortunately, and as SAP are discovering to their cost, moving an existing deployed software solution toward on-demand hosting is not simply a matter of moving the application from one data centre to another. Costs rise rapidly at the provider’s end, too, as they take on previously delegated costs for networking, power, maintenance and more. Software designed for single tenancy installation is either expensive in wasteful under-utilisation of numerous single tenancy servers, or technologically inefficient in the way that it operates across multiple tenancies and virtual machines. In either case, these new – and rising with every ‘successful’ sale – costs must be borne by the provider rather than the customer. Whilst SAP’s incremental costs in shipping each new software package to a customer site are very close to zero, every new SaaS tenancy brings costs that SAP must plan for and bear; space in a data centre, hardware, power, cooling, bandwidth, etc.  All too soon costs begin to spiral out of control, and if the economics are not carefully optimised ‘success’ runs the risk of very quickly becoming self-defeating.

Purely in terms of the corporate balance sheet, the shift from installing software to deploying it can be too painful to endure. Rather than a sizeable up-front license payment supplemented each and every year by an up-front annual maintenance charge and intermittently by hefty upgrade fees, software companies transitioning to provision of SaaS face the prospect of no more than a monthly or quarterly subscription payment. The ‘upgrade’ gravy train makes little sense in a SaaS environment, where customers have been led to expect continual incremental improvement. Even where customers could be persuaded of the value in some notional upgrade, the economics again become self-defeating as the software vendor rapidly finds themselves maintaining a plethora of legacy versions to their software and absorbing the resulting overheads in support, equipment partitioning and the rest.

That secret money machine of the enterprise software business – consultancy around implementation and customisation – is undermined by the Model T Ford plainness of much SaaS too, adding significantly to the woes of CFOs at traditional software companies who are trying to balance the books on a move to the Cloud. SaaS products today tend to target the low end, rather than competing head-to-head with the feature-bloated behemoths at the top of the software foodchain. The nature of SaaS products means that ‘trials’ are a couple of mouse clicks away. Even signing up to take the full product tends to be quick, painless, and priced at a point well within the budgets of middle managers and even individual professionals. Salesforce was one company to make significant headway in this fashion, infiltrating the enterprise via individuals with just enough budgetary authority to close the contract without having to negotiate the complexities of an ‘enterprise sale’ or compete directly with the incumbent system or the biases and politics of the C-suite.

Whilst perfectly capable of matching or exceeding the value of license and maintenance components over the long term, especially when the savings inherent in running a single version of the core software package in a controlled and manageable environment are taken into account, this retrospective trickle of utility rental funds requires a significant realignment of a company’s finances and metrics. All of an organisation’s carefully optimised profit and loss models need to be completely rethought, and tenets at the heart of the corporate DNA stand every chance of directly impeding any serious move toward a utility computing model where individual short-term margins will tend to be far tighter than before.

Although not directly addressing the utility computing market by name, the lessons in Clayton Christensen‘s The Innovator’s Dilemma and Innovator’s Solution are writ large here for all to see. What traditional provider of locally installed software can successfully cannibalise their own business and reimagine themselves fundamentally enough to succeed in the Cloud? SAP are certainly trying, but it’s not clear that they’re even close to succeeding.

The SaaS success stories tend to be SaaS from their foundation. Marc Benniof could not have produced Salesforce whilst at Oracle, and even Larry Ellison had to facilitate NetSuite at arm’s length to his main business.

Can traditional software providers ever make the transition, and are the major obstacles standing in their way technological or financial?