But let’s first take a look at why such a resource might be needed more than ever. I think that massive Dynamics CRM deployments – in number of users - are still quite rare especially if you compare it with SharePoint. This is however quite normal given that both products are covering completely different functional domains and where SharePoint might be used by everyone in a company, Dynamics CRM users are typically still found in customer facing departments (service management and sales & marketing) . This might be one of the reasons why there hasn’t been any need to compile such an extensive list of boundaries and limits for Dynamics CRM. But in an era where winning the customers heart and mind is getting harder and harder – it becomes imperative that companies transform from ‘product-focused’ to ‘customer-focused’ which will put CRM more at the center of your enterprise architecture and which might also trigger larger deployments of CRM both in terms of number of users, transactions and records.
But in the enterprise market we are currently already encountering at what you might describe as “High Volume” systems. A “High Volume” system might have one or more of the following characteristics:
- High volume data: more than 1 mio records in the base tables (Contacts,Accounts, …) or more than 5000 activities/day or more than 1 mio/year
- High volume transactions
- High volume users/security: more than 300 concurrent users or more than 1000 teams and business units
I also got feedback from another CRM architect stating that there are no real hard limits in Dynamics CRM for on-premise deployments but only scalability guidelines that you should follow. But still when you are doing a large CRM deployment chances are that you might call in Microsoft consultancy to assist you or audit your design they will point you to some specific boundaries and limits that you should adhere to. These guidelines and boundaries and are defined in the Microsoft Product Line Architecture for Dynamics CRM which unfortunately is not publicly available (See Introducing the Microsoft Product Line Architecture if you are unfamiliar with PLA) and although these are indeed no hard limits –if you don’t comply you will be asked to provide mitigating or corrective actions.
To get started you should definitely take a look at the Microsoft Dynamics CRM 2015 and Microsoft Dynamics CRM 2016 Performance and scalability documentation. This download contains the Dynamics CRM Scalable Customizations white paper which describes how SQL Server platform-level issues can occur that create slow Microsoft Dynamics CRM application performance or error messages returned to the end-user. It also provides information about how to optimize a custom implementation and enable better performance that results in better end-user experience. It also contains the Scalable security modeling with Microsoft Dynamics CRM 2015 white paper which describes how security modeling features in Microsoft Dynamics CRM 2015 and Microsoft Dynamics CRM 2016 related to authorization work at scale, the associated implications, and guidance on common and recommended usage patterns for modeling Microsoft Dynamics CRM 2015 and Microsoft Dynamics CRM 2016 security at scale, incorporating teams as appropriate. Both white papers are updated versions of the papers which were initially written for CRM 2011 and CRM 2013 because in essence the core architecture as described in Microsoft Dynamics CRM Reference Architecture has not changed significantly in the later versions.
Given the focus of Microsoft on Dynamics CRM Online you might also be faced with a large deployment of Dynamics CRM Online and you have to keep in mind that Dynamics CRM Online does contain some hard limits. I will cover these in a next blog post. But the Microsoft Dynamics CRM Online patterns & principles for solution builders white paper download provides already some solid guidance specifically about building solutions using Microsoft Dynamics CRM Online. Also keep in mind that Dynamics CRM Online deeply integrates into Office 365 (Yammer, SharePoint Online, Exchange Online and Office 365 Groups) and you might also need to the integrate some Microsoft Azure components so you should also have a solid grasp of these components as well as a solution architect.
Last but not least - it is a sad truth that in most deployments bad performance is not due to the number of users, transactions or records stored in Dynamics CRM but mainly caused by bad code – so also take a look at Best practices for developing with Microsoft Dynamics CRM.
References:
- Software requirements for Microsoft Dynamics CRM 2015
- Microsoft Dynamics CRM Server 2015 hardware requirements
- Introducing the Microsoft Product Line Architecture
- Microsoft Dynamics CRM Reference Architecture
- Microsoft Dynamics CRM 2015 and Microsoft Dynamics CRM 2016 Performance and scalability documentation
No comments:
Post a Comment