One of the main roadblocks I see for several .NET companies and developers is to get into Dynamics CRM mind-set. For somebody who has been doing .NET development for several years
only doing .net way not looking to fit inside the box, extend around Dynamics CRM in the core using techniques which have been successful with extending CRM rather than fitting .net approaches ,
getting into Dynamics CRM implementations can be a total nightmare.
I will like to cite few examples I have seen over the years talking to various teams I have been part of on Microsoft stack of implementation. At times even a mixed implementation between Microsoft products and others.
More often than not I have not faced issues trying to make the simple facts clear to the technical audience about how Dynamics CRM implementations can be implemented, managed.
Over the years, I have to say it has only become easier to make people understand the need of a particular approach with Dynamics CRM. But the hardest part of the discussions have been to convince at times people from
.net background about the particular implementation. So, here are few of the major things I noticed:
· Implementing a design pattern in CRM platform for instance like MVC: Since the product has its own design architecture, anything which needs to be done needs to fit into the CRM architecture.
· Performance concerns on Dynamics CRM product: Just because Dynamics CRM performance tuning is unique and you need to have product knowledge does not mean that CRM cannot be tuned. Just like another product,
it can be drastically improved in performance. However, to improve performance doesn’t mean that in CRM you can go and change system stored procedures at database layer for instance.
Why: simple, because it’s part of product package and to maintain warranty you cannot think to tune it that way!
· Although CRM on premise provides a website, it doesn’t mean we can go ahead and design web pages. We need to start think from Entity level and then design the forms.
· CRM Security model is too complex: Dynamics CRM is made for business and provides lot of security features. It does not mean that we need to implement each security feature in the implementation.
Use only what you want and reduce the complexity of your CRM security implementation.
· CRM as a rule engine: I find the product to be a great fit for doing rule engines based implementation because of the ability to extend, reuse and customize even the business logic using plugins, workflows
and even from client side of things.
· CRM for Data processing: I find the product a great fit for data processing because ultimately it is meant to store customer data and it is fit for processing that data. Just while designing, you need to be
careful of how CRM can effectively process your data.
· Be careful on what you are Auditing: The auditing can be only good for relevant fields and entities, otherwise just a performance and storage nightmare, so care needs to be given to see what needs to be
audited and what not. It parts integral part of Out of box CRM framework.
· Custom UI within CRM: CRM gives full freedom to design custom UI but since it just gives feature to extend, development of custom resources needs time. So, it needs to be scoped accordingly.
It doesn’t anywhere mean CRM limits the form design.
· Comparison of a scripting language (HTML/PHP) with CRM: It is like comparing a framework which CRM considering only the presentation layer without considering all the other layers that CRM platform provides.
The above list is just the major things that I have witnessed during my discussions with .net experts. All the points are my way to explain few of the CRM specific approaches in a very generic manner.
Hope it helps and always happy to hear the feedback in comments, make corrections if the information is not clear enough.
Happy CRMing!
MSDYNAMICSBLOG BY DEEPESH 