In Part 1 of the “ISV Guidelines for Hosted Microsoft Dynamics CRM 4.0”, I covered the basics of leveraging Microsoft Dynamics CRM 4.0 (MSCRM4) as a hosted platform for Independent Software Vendors (ISV). In this post, I’ll provide some guidance on the two most popular method of using MSCRM4 for an application. This won’t be a deep technical dive, but general guidance.
Part 2: CRM as an Application or Platform
All applications have some business value and problem to solve (ok, not games and stuff) and this is the main mission for ISV’s and the software they want to build and deliver to customers. But before you can build it, you must first decide the platform in which you will deliver the solution. This should NEVER start at the developer view (e.g. .NET or Java) or even decided on web or client application. You must always start this at the core business problem (e.g. managing public records), define user roles, and define core scenarios. Based on all of this, the list of features and technology platforms will come from there.
OK, back to the CRM specific question….
Out of the box MSCRM4 provides a great (and typical) CRM experience. It has all of the standard structure and workflow that you would expect from a CRM application. Under the covers, MSCRM4 stores all of the data in a SQL Server Database. Hosted MSCRM4 deploys each new CRM instance as a separate database, but they all “roll up” to a single SQL Database which stores the configuration information. This is what allows the “Multi-Tenant” capabilities of CRM. Thus, a hoster can provides CRM services to multiple customers, leverage all of the same front (web servers) and back (SQL servers) end servers, and ensure that customers data are properly isolated. I’ll discuss the provisioning of these servers and databases at a later time. This is done using a feature of MSCRM4 called, “Internet Facing Deployment” (IFD). Another key benefit to having IFD is enabling each client to have their own unique URL such as http://clientname.hosterurl.com/, but this can be remapped via a firewall/proxy (such as Microsoft ISA Server) to point to http://crm.clientname.com/, although it’s a bit tricky. When a client connects to their services, you’ll get a form based web page to provide their credentials. This is a generic UI and it’s the same for ALL Clients. You “could” make this unique for your ISV application, but that won’t work in a shared environment as you’ll need to modify a few .aspx pages and .css files. Making this change impacts everyone on the server. In that case, you’ll need a virtualized deployment. That’s Part 3 of this series.
Again, at it’s most standard deployment, it’s a great CRM platform. But again, it’s generic. This is where an ISV can provide some magic. Now the question is, do you leverage CRM as an Application or a Platform. By “Application”, I mean you can provide value to the CRM Experience by adding some additional Entities (more on that in a second) or workflow. By “Platform”, you can leverage the structure of CRM and all of it’s functionality but abstract the entire User Interface for the application with your own.
First, let me cover some of the key areas of extensibility of MSCRM4.
- Entities – All “objects” such as a User, Organization, etc are called Entities. There are many Entities that come standard with each deployment of a CRM Instance, but you can modify and remove those as well. You can even create your own Entities that are specific to your application. Each Entity has it’s own set of properties as well, which you can also add, modify, and remove.
- Relationships – Now that you have Entities customized, you’ll use “Relationships” to associate them with other Entities. Let’s say you want to use a Standard Entity in MSCRM4 like User and associate it with an Entity of “Houses”. This would be great for a Realtor application that wants to associate a collection of houses (Each house can have attributes defined like pool, rooms, etc.). This can be customized per instance or even defined during the provisioning of a new instance (more on that in another post)
There’s WAY more to MSCRM4 then this, but this should give you a good idea on the flexibility of MSCRM4. So you may ask, why not just do all of this in a database like SQL Server 2008? That’s a great question, and sure you could do this. But now you’ll have to develop that complete database structure, logic, web services (maybe), error handling, and more. Developing all of that from scratch doesn’t buy you much and it removes you from focusing on adding the core business value which will make you a real profit. Instead of throwing your development budget towards what MSCRM4, you could add additional features and scenarios that makes your application even more interesting to customers.
By leveraging MSCRM4 as an Application, an ISV can sell their products directly to customers that deploy CRM on-premise (e.g. they run their own server) or via a Hoster. Since the hoster is selling Hosted MSCRM4 directly to a customer or via a reseller, the ISV’s component can be sold for an additional fee. This opens the door to another issues in price modeling. Since the customer isn’t purchasing their MSCRM4 implementation via the traditional perpetual method, but is instead doing it via a monthly subscription, an ISV must now take that pricing into account. This is something you’ll need to work out with the hoster directly.
Now keep in mind that there will be some customers that will want to purchase your solution to enhance their Hosted MSCRM4 instance, but it may not reside on a hoster that you currently have a relationship with. This could be a problem as the hoster may or may not give full rights of administration and customization to that customers. There isn’t a standard here by the hosting community or by Microsoft. On key customization component within MSCRM4 are “Plugins”. A Plugin is used to provide a very rich customization point for ISV’s, but it’s not supported by many hosters in a shared platform because of the security risk it can pose (including Microsoft CRM Live). Each Plugin can see and interact with ALL CRM traffic coming through the front end CRM servers. Thus, even if a customer isn’t using a given Plugin, it will impact their overall performance and data. This isn’t to say that a hoster won’t deploy it, but it will require a relationship with the hoster and allowing them to test and evaluate it. That said, if an ISV chose to leverage the Plugin model for their MSCRM4 related product, this could be a deal breaker if a customer wants to deploy it in a shared CRM deployment and you don’t have a relationship with the hoster. I’ll discuss how leveraging a Virtualized MSCRM4 platform can help in all of this in a later post.
By leveraging MSCRM4 as a Platform, an ISV is going to leverage the structure and multi-tenant nature of MSCRM4 for the benefit of their application but remove the CRM-ish nature from their customer. A good example of this is “Public Records Tracker” by Eskel Porter which leverages MSCRM4 to manage public record requests for State and Local Government. The MSCRM4 platform is hosted for customers which reduces the deployment investments(hardware and configuration services), provides near instant-on access, and the User Interface has been customized to focus purely on the business problem. Thus the customer is purchasing a subscription to an application to solve a business problem, and not purchasing a CRM solution with an add-on.
When using MSCRM4 as a Platform, there are two core scenarios to provide a User Experience to the end user. First, you can fully customized the standard deployment of MSCRM4 via an XML template. By doing this, you can still provide the basic MSCRM4 web user interface, but add/remove/modify the entire experience. This reduces the development investment of recreating a User Interface (UI). While this does provide a great deal of benefit from a time to market and development expense, you lose out in providing a customized and rich UI for the user. Depending on your customer market, this could be a great tradeoff.
Here are some other areas of MSCRM4 that an ISV should know when customizing their solution:
- Web Services (Site) – Each CRM Instance/Site, will have a unique URL to manage that given site. This enables you to automate and integrate with the data structure (entities and relationships) and all settings for that specific instance. We’ll talk more about this in a future section focused on provisioning.
- http://<servername[:port]>/mscrmservices/2007/crmservice.asmx?WSDL&uniquename=organizationName
- Web Services (Admin) – There is a specific management URL to connect to the web services exposed by MSCRM4 to manage that platform. You can do almost anything, but you can’t provision/deprovision instances from it (bummer).
- http://<servername>:<port>/MSCRMServices/2007/AD/CrmDiscoveryService.asmx?WSDL
- ISV.Config – This is an XML file that allows an ISV predefine the entities, relationships, workflows, and UI extensions. This makes the provisioning process a bit easier and can be automated by passing this information via a web service call.
- Site Map – This is an XML file that allows you to fully control the navigation and structure of the site. You can export this directly from within the MSCRM4 web application. This is defined PER SITE. This gives you lots of control, but does provides some headache if you plan on making adjustments to a collection of instances.
- MSCRM4 SDK – There is an SDK that is available for MSCRM4. It’s not required to customize MSCRM4, unless you plan on doing some heavy lifting customization by using Microsoft Visual Studio. This is what’s needed to create “Plug-Ins” as we discussed already
Information on all of this can be found on Microsoft’s Developer Network (MSDN): http://msdn.microsoft.com/en-us/library/bb928212.aspx
Second, you can develop your application leveraging a very different development platform (E.g. ASP.NET, Java, Microsoft Azure) and “connect” to a given customers instance via a Web Service. A powerful feature of MSCRM4 is the ability to fully interact with the data and logic via a Web Service. By doing this, you can have full control of the application UI and thus removing all needs to the existing MSCRM4 UI. The ISV can make all calls in the background. You do this within the same hoster (e.g. CRM On Target is a great hoster for this) so your application AND CRM instances are within the same environment although perhaps not hosted on the same servers (More on that in another post). The downside to this is that you must code EVERY piece of UI. This can make for a better user experience for the customers by using Web 2.0 type of tools like JQuery, AJAX, JSON, and more while building it using ASP.NET/MVC. Again, great for the end user, but it will drive up your development costs and time to market.
In summary, there are a number of ways an ISV can add value on top of MSCRM4. And at it’s core, MSCRM4 will provide greater flexibility and business logic out of the box for an ISV. The ISV must now decide if it will sell their product as enhancement to MSCRM4 or fully abstract MSCRM4 from users and use it as a platform for their application.
Note: If there are specific areas you’d like me to cover in future posts, please post a comment below or contact me here.
Follow Me on Twitter