A platform for building business applications: Live or On-premise

We already offer an extensible platform for building business applications on-premise. I intentionally didn’t say “CRM” business applications because one can build any types of business applications, CRM or not, on our platform. If you look at different pieces of our extensibility model (customization tools, powerful web services, deep code extensibility on the server including custom plug-ins and workflow extensions, UI Customizations, Form programmability, etc) we are providing major components that one would need to build a wide range of applications. Now that has been the on-premise story until now with the addition of partner hosted story that was started recently.

With the announcement of CrmLive, I am sure there are new questions in developers and partners minds such as: How do I build a business around CrmLive? What are the key differences of CrmLive programming model compared to on-premise? How do I build an application on CrmLive? Where do I host my application? Will I be able to build applications that are as rich as what I can build on the on-premise version? Etc, etc,

We need more than one post to discuss these questions but I’d like to start with a few basic topics. The first thing is to look into is what a multi-tenant and live software-as-a-service (SAAS) platform really look like and mean and what are its key architectural differences with CRM V3.0 on-premise version. Here is a good high-level and general description of the architecture of a SaaS application to get you started on the bigger picture perspective.

The next topic would to be think of an application not only as a piece of software that you install on CRM Server and expose on CRM Forms (or your own custom forms) but also as a service that you could host somewhere in the cloud (over the internet) and provide the same seamless user experience to the user. It doesn’t really matter where the core calculations and functions of your application is hosted and running, as long as we can ensure the user experience is well integrated with the rest of the CRM experience. Lets say you have built a productivity tool/application that maps out and draws all the related objects of a customer account instance (shows all the activities, cases, appointments, etc related to an account, in a single aggregated graphical view). Your tool takes an account id and returns all the related entities to the presentation layer which then draws the graphical map for the user. On CRM on-premise you would install your application on CRM server and integrate it with CRM application UI using ISV.config. The same application can also be hosted on a different server other than CRM Server somewhere in the cloud and exposed in the CRM Application via the same ISV.config mapping. So assuming security, development and maintenance cost and performance of both approaches are similar (they are not, these are big topics on their own), the location of your application becomes less relevant. It can even be running on the users (client) machine as AJAX style JScript code.

 

Lets talk about the security, performance and other hosting options as well of type of the code that you can run, in the next posts.............