At the risk of upsetting a few people, I'm going to take a shot at defining what I think a hostable line-of-business application platform might look like. Those of you familiar with the CRM platform will recognize quite a few of the concepts.
First, by hostable I mean an application and platform running as a web-based client, rendered using HTML / CSS and supporting any number of modern web browsers. Note that I didn't say an application running inside of an ActiveX control or over something like Terminal Server. Yes, these are "hosted" applications, but only in a very limited sense of the word.
Line-of-business should be pretty clear. This isn't an email application, it's not an online auction site, nor is it a search engine (all of which are perfectly viable consumer-oriented applications). I'm also not talking about hosted productivity applications like word processors, spreadsheets, or presentation tools. I'm talking about those "big" applications that businesses bet their company on which automate "big" processes such as sales, financials, support, marketing, and commerce.
Clearly there are a few different classes of users of these systems. In particular there are members of the business licensing the software, there are customers of the business, and there are those folks on the periphery such as partners, vendors, and suppliers. I'm assuming that all of these "users" need some level of access to the underlying business process and data encompassed by the software. I'm also assuming that there are very different limitations on how the different users interact with the software (let's call this a role that the user plays with respect to the software). That is, the software experience is tailored to the individual using the software at a given time to perform a given task.
Let's look at an example of where software morphs itself - a sales order "process". First, a customer comes to the business' web site and browses their online catalog. They add a silver toaster to a shopping cart, specify some shipping and billing details, and place their order. Inside the software a sales order document is probably created, but the customer doesn't know this and certainly doesn't care how it's done as long as their toaster arrives in time for breakfast. Now, the system, if constructed to actually help the business, is busy fulfilling this order. To do this it breaks the order into a series of work items (let's assume for just one minute that this business builds toasters just in time) and distributes those work items to actors who can perform the work. Each of the actors (I don't really want to call them users or people because we might have a robot on the manufacturing floor that makes the darkness dial and that robot technically isn't a "person") interacts with the sales order indirectly through a role-specific view, but they're probably still using the same software system.
Anyway, I digress, as usual. You get the point that I'm talking about big software the helps the business do what the business does. Back to the discussion at hand. Each business is different and prides itself on being different. That means that they need software which is also different and tailored to how they best do their business. That is, the software is customized to their needs. I'm also assuming that the company hosting the software for the business (let's call them the provider) wants to make money at this providing business in which case they want to run as many of their customers as possible on as few pieces of hardware and software as possible. The provider wants to capitalize on the economies of scale that are possible with natively multi-tenant software. Ideally, if a provider could purchase a single machine with a single "license" and run all of their customers from it, while simultaneously supporting the customers' varied customization needs, then they would do that. That's what I mean by multi-tenant.
I'm not going to go into all the gory details about how to build such a system, but I will state the requirements here. First, the user experience must be tailored to the user's specific role with respect to the company. Next, the user experience must be standards-based (i.e. it must run in a browser and not use any of the weird extensions that many browsers have). Third, the overall business experience must include a level of customization that lets the business completely tailor the software to meet the business' specific needs. Next, the entire interaction model from purchase to provision to customization to use must also be browser-based (can't have any weird requirements to download some fancy development environment to make this work). Finally, the whole thing needs to be cost-effective from the provider's viewpoint (otherwise they can't offer it to their customers in a cost-effective fashion).
Quick update: one more way to think about the hostable line-of-business platform is that someone can come along and build a completely different application on it. It's a platform and it's application-agnostic.
Watch for part two…
Wow, it's been a long time. I kept trying to come back and write something, but between working on new projects and trying to figure out what I could actually write about, well…
So, anyway, just to catch up. I left the CRM team at the beginning of the year to work in an incubation / greenhouse team within MBS. We were initially focused (well, "focused" might be too strong of a word) on hybrid application models. That is, we were looking at ways to create applications that spanned the firewall either directly or indirectly. One of our motivating factors was to introduce a collaboration element to MBS assets. We tossed around a handful of interesting scenarios, and in true Microsoft style, we went way overboard in developing the initial scenario (a building contractor doing collaborative bidding and design on home remodel projects).
One of the good things that came out of all that scenario work was a prototype for a "data projector" that could take internal line of business data and project it onto a shared, hosted workspace. I can't go into a ton of detail around this yet because the concept itself was useful enough that we're going to pursue it as a product. That means I need to be hush-hush about it until the official product team makes an announcement.
In the meantime I'm looking at the CRM platform through the eyes of an ISV (again) to see what we might be able to do with it in terms of building non-CRM products. Watch this space for more information as we learn things (like the callout implementation from CRM for notes and documents is just plain broken).
PS - Caitlyn is doing great, she sleeps through the night and has since we brought her home. Talk about a blast watching her learn about all the cool things in her new world.