RSMUS.comI’ve had a change of thinking regarding CRM on premise versus online. You can find detailed information on the technical differences between CRM on premise and CRM online. Don’t get me wrong, the differences are notable and important, particularly if you are responsible for advising customers or you are responsible for implementing CRM. In many respects, though, the difference between CRM online and CRM on premise is “not so much”. Particularly, if you consider that most on premise implementations we do these days are IFD deployments, which I consider a “private cloud”. For those of you that are not familiar with IFD, this stands for Internet Facing Deployment and among other things, this allows external access of your CRM without the need to VPN. IFD is required (essentially) to use the out of the box mobile capabilities and many 3rd parties require IFD, particularly, if they are not still using the 4.0 endpoints.
If you agree with the “premise” that the differences are “not so much”, then this brings to the forefront things such as cost, corporate culture/standards, IT philosophy, existing infrastructure, existing IT capabilities and even something as nebulous as comfort level with one versus the other. I think these are the things that should drive the ultimate decision, rather than things like, “you have to use FetchXML SSRS reports with CRM online” or “you can’t write custom workflow assemblies”. These should be secondary considerations.
I’m going to give you some detailed background on how I’ve come to this new way of thinking (there is a negligible difference, conceptually and technically between CRM on premise and online). For some of you, you’re already there so you may just say duh (or doi, which I coined in 1974) and move on. For me, I used to think it was a philosophical thing and that I had to be on one side of the fence or the other, but now, I don’t care so much. I meet prospects and clients every week that have very strong feelings one way or the other. I’ve met companies where the pendulum has swung one way or the other and I’m here to suggest that we all need to get over this being a philosophical difference and get back to analyzing the specific situation. I’ve said a similar thing or two about having a balanced approach with regard to “build versus buy” (or just get Dynamics CRM and you get the best of both).
The other day, I had some colleagues out of our Northeast office call me to help them on some complex FetchXML based SSRS reporting. Our client is an onpremise client and so I was very confused as to why they decided to use FetchXML rather than a SQL based report. I’ve done FetchXML SRS reporting, but only because I had to (client was online). The NE consultants gave me their reasons (one of which is because they didn’t know SQL very well) but I still didn’t get it and never dreamed that I would ever make a similar decision for an on premise client. Given what they were trying to do (for example, they probably could have used a union statement), I highly recommended that they go to sql based report. Not much re-write, if any, was going to be required and after all, SQL could do what they needed. After thinking about this some more, I think going the FetchXML route actually has merit for on premise customers. After all, you can build a pretty complex advanced find and then simply copy the FetchXML. In addition, there are also some great reference tools out there for FetchXML and I think there are also some misconceptions about what it cannot do. For example, I did not think you could do aggregates with FetchXML, but it turns out you can. In addition, if I’m developing reports as FetchXML, then the client has the flexibility of moving from one to the other (on premise to online or online to onpremise) without needing to re-write their reports. I still have issues with the fact that it is proprietary and FetchXML is not ubiquitous like SQL, plus I know SQL waaaaaaay better.
In addition to the FetchXML example, think about something like the Outlook integration. For me, I cannot tell a difference between CRM online and CRM on premise. when using CRM for Outlook. What about the Sharepoint “documents” integration? Well here, there are some additional considerations, but it’s the same user experience when you’re in CRM. If I have my Sharepoint site on premise, but I’m using CRM online, then users would need a way to get to Sharepoint internally (VPN or making your Sharepoint site outward facing, SP external connector, which is fairly expensive especially if you just need it for this). However, if a customer is online, then they are probably a good candidate for Sharepoint online (for just $4/month/user), which can have the list component installed on it as described here. So, once again, from a user perspective, there is no difference between online and on premise.
What’s the online versus on premise situation for 3rd parties, legacy integrations, xrm or the portals?
- Just about all 3rd parties I’ve worked with have online and on premise support.
- Legacy integrations can be done with tools such as Scribe, SSIS and custom code, just to name a few. The code and mappings work exactly the same because you are working with the same APIs, though there is a slight difference in how authentication is performed when instantiation the respective services.
- With the R8 release, we will get the ability to write workflow assemblies online. I’m not sure if something special will be needed, but this is really the last big development piece that online needed to provide.
- The Adx free or paid versions of the portals all work with online and in fact, most of the documentation is geared toward online deployments and they all have instructions for deploying the portals to Azure.
I think the final thing I’m really starting to not only get, but regularly implement, is this concept of hybrid approaches where some of your “stuff” is in the cloud and some of it is on premise and all the stuff needs to talk to each other. I think some of the pure online vendors make it difficult or challenging to implement this concept (because it’s not easy for them?), whether it’s legacy integration, reporting, or data warehouses, there are still major pieces that make sense to want or need on premise. NetSuite for example has an ODBC product you can buy to do on premise reporting or data warehousing, but it’s pretty expensive. I think Microsoft has not only embraced this concept, but in a lot of ways introduced it, albeit there are obvious reasons for MS to do so. Look at the SSRS Fetch XML datasource for online, pretty cool. The main thing here is that I think you should be able to have your “stuff” wherever you want it. My job, as a consultant, is to help companies understand the considerations when choosing one versus the other for each thing any system they are considering implementing or taking to the cloud. I’m sure there are some people out there that think you should take everything to the cloud. Perhaps I’ll write an article arguing the other side of that (for a change). The other main thing I need to know and teach are the technical hoops I need to jump through when integrating on premise and cloud systems and to me, the barriers here get less and less all the time. Perhaps the “considerations for CRM” and the “technical hoops” will be in part 2 of this article.
So above, I’ve spoken about some common integration points between Dynamics CRM and other systems (e.g. Outlook, 3rd parties, Sharepoint), whether those systems exist in the cloud or on premise. From an end user perspective, the experience with regard to these integrations and whether you are using Dynamics CRM online versus on premise is very similar if not the same, and this, is the way it should be.
Let me know what you think.
