What does SaaS mean to MBS?

Let's forget for a moment the weird ad-based revenue models that don't make sense for a software development company. Let's focus instead on how we create value for our existing customers using applications that they've already invested in. Let's focus on how we rely on and extend our core competencies to create products and services that customers will purchase. Let's focus on creating a community experience for our partners such that they see a clear revenue model for themselves.

 

Let's move away from selling a platform to selling an extensible, configurable, and customizable business application suite. Let's put the customer and partner first, after all they generate the revenue for MBS by purchasing or extending our products. Let's make our customers' businesses run better on Microsoft software.

 

There are four software models available to MBS and its customers:

 

• On-premise only deployment where all processing and data storage happens behind the corporate firewall. All software management is performed by the customer. Microsoft revenue comes from licensing installed applications (the customer pays for software).
• Hosted only deployment where all processing and data storage happens outside the corporate firewall. Microsoft revenue comes from providing infrastructure and management services (the customer pays for IT services).
• Hosted behavior / services where some part of the business process is run in a non-customer data center. In this case the application maintains local copies of all transactional data and uses that data on a per-invocation basis. The hosted process holds read-only reference data(tax tables and codes, currency exchange, etc.). In this case the service provided is akin to a DLL-in-the-cloud and has no transactional user interface (it might have an administrative user interface). Microsoft revenue comes from one of two places: per-transaction charges or service licensing fees.
• Hosted modules where some larger component of an application suite is run by a third party. In this model some larger amount of user interaction is with the hosted application module. Ideally the user experience is such that there's no discernable difference between various modules. Microsoft revenue comes from providing infrastructure and management services.

 

Notice that nowhere in the list is ad-based revenue mentioned. The reason is simple: business application users have a goal in mind when they use their productivity software (and yes, LOB applications are productivity applications too). They want a simple, uncluttered, role- and task-oriented experience.

 

It should come as no surprise that MBS has many applications which use one or more of the above models. The user experience varies greatly across the products. The IT experience varies greatly across the product. Far worse for Microsoft is that the partner experience varies in such a way that customization skills are not transferrable across applications.

 

Things we need:

• A consistent deployment and application architecture across all applications. MBS needs to provide a single, shared application architecture or "stack" on which all MBS applications are built. This doesn't mean MBS becomes a division focused on platform, but instead MBS creates the equivalent of MSO and extends it on an as-needed basis (with agreement from all consumers).
• Common shared document and schemas at the process integration level. Shared schemas outside of the applications provide a migration strategy for existing applications (wrap, wrap, wrap) and provide a target for new applications.
• A common metadata discovery model outside of the applications. Software clients, services, and other components should have the ability to discover the environment in which they run. Service locations, message formats, service policy, and service existence should be discoverable so that clients and services can configure themselves accordingly and so that business processes can be abstracted from the implementation details.