Lately, I’ve been thinking about highest and best use as it would apply to hosted services.  I don’t think it’s any surprise or news to anyone that dedicated hosting may, over time, begin to shrink as grids and VPS become more popular and robust.  With this in mind, the highest and best use for a company who has a dedicated offering would be to begin the movement of its dedicated hosts away from the physical server in the rack to a virtualized instance that runs across a grid that is shared by others.  This allows the dedicated host to maximize the square footage of their datacenter, the power, and other resources, while still presenting that semblance of “dedicated” to the end customer.  But, can we squeeze more density into that highest and best use?  For many companies, the marketing spin around grid is a SaaS platform where you don’t really have to create a multi-tenant application; you can simply create a virtualized instance per tenant.  Traditionally, you would have been buying a physical piece of equipment per customer, but now you can go with the grid and spread your customers across shared hardware.  In my opinion, this is half the equation.  The other half is to build a platform that sits atop a grid that provides on-demand SaaS capabilities, i.e. an ISV can publish their application into a shared virtualized instance.  This maximizes the savings gained from moving away from a physical server per server role, but also maximizes that instance as being shared among multiple customers.  Over time, hosts could decide to move their resources away from their traditional offerings into working on these new, next generation SaaS platforms.

What do you think?  

Dassault Systemes, a French firm that creates 3D and product lifecycle management software and services, has entered into the nascent SaaS 3D modeling space with their launch of 3DVIA, a platform Dassault suggests will transform the world into a place where someone can leverage the power of 3D to create, share, and experience life in 3D online.  The downside to this announcement is that there really isn’t anything there yet aside from being able to upload pre-created models, i.e. the Apple iPhone; however, the potential is there for them to transform this into something quite interesting and equitable. 

Once they launch an application that allows you to easily build 3D models, you’ll most likely start to see subscription packages for more advanced, professional features.  I imagine that as they prove out their online strategy and scale out their internal systems to deal with usage load, we’ll see them bring their industrial applications into the SaaS model. 

Add onto the above news with their announcement of a partnership with the advertising group Publicis to work jointly on 3D online marketing together.  This new venture is going by the name of 3dswym (3DSee What You Mean).  Combine that with the Microsoft partnership to bring 3D modeling capabilities to Virtual Earth and you can see the beginnings of a little ad-driven ecosystem where enough of Virtual Earth has been filled out that you can now walk through virtual landscapes of, say, Seattle where business owners can sell space on their walls or elsewhere all driven contextually off of the information Microsoft (or others) have collected about the visitor.  And finally, the announcement of 3DLive available for Vista with some of the benefits being real-time 3D collaboration and 3D search and navigation.  Will we see some of 3DS in Surface someday in the future?

Some interesting things I could see coming out of 3DVIA and the various partnerships are: 

• Social Networks using more 3D models for avatars and other things.
• Richer online 3D worlds
• Distributed product-cycle collaboration.
• Easier monetization of ad-space within virtual worlds, such as Second Life or open source ones like Croquet or Uni-Verse. 
• A partnership with Microsoft to provide in-game advertising over Xbox Live.
• XNA plug-in that allows you to pull in models built on the 3DVIA platform as MS hopefully embraces the hobbyist game-builder. 
• 3D Flickr

 At what point will we begin to see other CAD / PLM companies bring to market or make announcements about forthcoming SaaS applications?  These announcements from Dassault certainly position them as a player in the space.

Most of us can agree that billing is probably one of the most important elements of any company offering a product -- I know it's the one that makes me the most nervous when I'm looking at providers who will handle billing for me in a SaaS model. The worst scenario any SaaS ISV can get into is to go with a billing solution that they either lose trust in or the company they've chosen begins to layer on extra costs that weren't outlined in the initial quote or promises at the initial sale are reneged upon once you're through the door.

This is probably why many companies in the past have either purchased an on-premise solution or have built their own. In the hosting world, many companies have brewed up their own solution to handle the type of billing models hosters have had to deal with, i.e. things like subscription and usage-based billing.

It would be nice to see some of the major vendors with solid, known names move into the on-demand billing space. I think this is also why I thought about the model Microsoft is using with their SaaS push, in particular MS CRM 4.0 ("Titan"). A company can start off with by going with Microsoft or with a partner who builds additional services on top of CRM, and then migrate into either a dedicated solution or an on-premise solution if they either grow large enough to warrant on-premise or lose faith/trust in the company managing their CRM platform. This creates a great continuum and I know it goes against the SaaS model of moving things to the web, but for some services, many companies will be nervous if they can't switch between SaaS and on-premises, especially when trust has been eroded.

On-demand companies that build a SaaS offering should consider how a customer would move their billing solution to on-premises or to a dedicated platform where they're not lumped in with a shared set of customers. A company that can successfully build a solution that can start hosted, then migrate to self-hosted will be further ahead, in my opinion, than those companies who strictly offer on-demand billing.

All I know is if I trust you with my revenue stream, then I need to have a method of moving the ability to bill for that revenue in-house if something happens that destroys my faith without forcing me into an expensive migration to another on-demand billing solution.

It is critical to understand, I think, that some core differences between a consumer mash-up like those that apply statistical information over, say, Google Maps and a B2B scenario might be: 1) business applications will commonly employ some type of authentication system to gain access to the data within the application and 2) customers could have the ability to alter data within either application.

Within the B2B mash-up model I can see applications participating in both a unidirectional manner, where application A pulls data from application B, and a bidirectional manner, where application A pulls data from application B and application B pulls data from application A -- think of a pair of applications that need to stay in sync with some or all of their data, i.e. a hosted billing solution such as the one offered by Aria Systems and a hosted Sugar CRM solution like the one offered by RPS Technology.

Now, in both scenarios how should we manage identity? When application A pulls data from application B on the behalf of the user in application A how does application B ensure that the end-user has authorized application A to pull that data at that moment in time? I'm thinking about how we protect against fraud or misbehaving applications that might be holding onto credentials and performing actions without the explicit authorization of the end-user.

This is a situation where a SaaS Hosting provider could come to market with an identity solution that could sign the authorization credentials via some type of proxy service that sits in front of the application and issues tickets for that current session. Both applications would trust that ticket of the 3rd party (the SHP) and allow the interaction between the two applications. Once the ticket expires, then application A and application B break the trust and become silos again. The proxy service would also have the benefit of allowing the end-user to utilize a single logon for both applications; it could abstract the credentials and do handle the authentication and hand-off to the application.

I think we will begin to see more and more B2B mash-ups. It will most likely start as narrow contracts between the companies offering the services, but will hopefully expand into a more generalized manner where any ISV can build their application to pull data from another application using some type of trust system. I could see ISVs publishing their API(s) into a service catalogue in which other ISVs can find the API and begin mashing up data points within their applications, creating ad-hoc suites of applications that share segments of data between each other.

In SaaS Hosting, the ISV is off-loading a majority, if not all, of their infrastructure needs to the hosting partner. In some cases, they may also utilize on-behalf-of services such as billing, support, provisioning, and other unique services the hosting provider has experience with that the SaaS ISV does not. Each of these things has some type of cost associated with it to the hosting company, therefore this cost should be passed onto the ISV with some margin on top so we make a little money off of our SaaS Hosting Platform.

For larger ISVs that are moving into the SaaS space, the pricing is usually done via some type of up-front professional services contract to get the system online and then reoccurring revenue once the application is up and being sold. But, my concern is how do you address the other ISVs out there who may not have the capital for a professional services contract or no existing revenue stream to draw off of to fund their SaaS initiative? Should these ISVs be ignored and told to go it alone? The risk I see here as a hoster is that I may be missing out on that "next-big-idea" that I can get a slice of if I were to host that ISV's application and incubate them for a period of time.

This is where an argument could be made for a standardized, shared infrastructure that small to medium sized SaaS applications can live within while they grow. The hosting company would determine a flat, monthly rate based upon the amount of resources used during the start-up phase of the application and charge that to the ISV. Once the ISV has reached a certain point, they would shift into a revenue sharing price structure where the host receives x percent per hosted seat.

Another question I have is, should hosts give away some of their services initially to bring on some of the smaller ISVs? If this is done, what type of profiling process should be done to determine if the ISV might be a possible win? There'll be some risk in here, but there could also be a home run if the hosting company is smart enough to recognize a solid idea and work with the ISV to bring that idea to market.

Thoughts?

As the announcement points out, it's not about what the sample app does, but how it is done. The application adheres to architectural principles for SaaS the Solutions Architecture team has been publishing on their site over the past year.

Now, how does this apply to the hosting community? It's simple really. An architect can utilize this template to build out complimentary solutions within a SaaS Hosting Platform (SHP). A couple would be:

-Activation (or Provisioning): All hosting companies have some type of method for activating, de-activating, suspending, and re-enabling customer services. How can you wrap your activation code around this application? Is there additional work that needs to be done to the sample application before it can be placed within an SHP?

-Billing: How can a hosting company transform their internal billing infrastructure to bill for this application on-behalf-of the SaaS ISV?

There are others, but I'm going to save them for some of my next posts. I see a strong argument for hosting companies to begin building standardized platforms that adhere to SaaS Hosting guidelines.

The next step would be for a hosting company to take apart the source-code and examine what type of SHP API services they can build into their SHP offering that can be utilized by the sample application -- metering comes to mind. It'd be interesting to see LeCayla grab the code and implement their metering API inside it to show-off what they can do.

I, for one, plan on taking a closer look at this application as a use-case for my SaaS Hosting Platform at Affinity. The first step is to read through the code and see how scalable the application is from a hosting perspective.

You can find information on the application here.