If you are reading the Celedon Partners blog, you are most likely familiar with Dynamics CRM. You may be an existing Dynamics CRM customer or a developer working with the platform in some fashion. For those who are new to Dynamics CRM, here is a quick introduction.
Fresh from the pages of Wikipedia, Dynamics CRM:
“Microsoft Dynamics CRM is a customer relationship management software package developed by Microsoft. Out of the box, the product focuses mainly on Sales, Marketing, and Service (help desk) sectors, but Microsoft has been marketing Dynamics CRM as an XRM platform and has been encouraging partners to use its proprietary (.NET based) framework to customize it.”
So with Dynamics CRM, you have a powerful, fully functioning Sales and Marketing solution for small, mid, and enterprise customers right out of the gates. Users can manage Accounts, Contacts, Opportunities, and Leads, track customer communication, and manage Marketing Campaigns all within the same solution. With the new data about customers and contacts, users can view helpful dashboards and run periodic reports to keep on top of their business.
For developers, Dynamics CRM has been a fully managed code solution, built on the .NET framework since it’s first release. The latest release supports the version 4.5+ of the .NET Framework. Dynamics CRM is, at its core, a database solution with Microsoft SQL Server running under the hood. The current release of CRM 2015 supports Microsoft SQL Server 2012 and its related services, such as Reporting Services or Analysis Services.
Dynamics CRM is available either hosted by Microsoft via Dynamics CRM online, hosted on premise by the customer, or hosted in a hybrid approach – all depending on the customer needs. Users can access the system via the browser, mobile devices, or through Microsoft’s Outlook integration, all meeting the needs and preferences of the end users.
So that’s all well and good, but what is xRM? The previous intro sounds great for an off-the-shelf product if I am in the Sales and Marketing department of my organization. But xRM allows cther members of your organization can leverage the Dynamics CRM platform for Line of Business Applications as well. I like to use this description found in the whitepaper Microsoft Dynamics CRM as a Business Application Platform:
“Take the ‘C’ out of ‘CRM’ and you’re left with Microsoft Dynamics Relationship Management—and that’s the right way to think about this product. Microsoft Dynamics CRM is not just about sales and marketing. It’s a platform for developing line of business applications—applications that manage and track information and processes around real world objects.”
Translation: xRM means “Anything” Relationship Management. Dynamics CRM was originally designed to be a development platform, and to demonstrate what the platform could do, the early team built out a fully functional CRM application. This is the Dynamics CRM system that Microsoft eventually pushed to market.
So xRM has been at the heart of Dynamics CRM since its inception. Dynamics CRM provides the powerful and extensible business framework for solution configuration and customization. Typically, configuration means the system can be updated without relying on developer tools or skillsets while customization usually requires some development level time and skills. Configuration and Customization can be outlined as follows:
- Metadata – configure and extend the underlying data model
- Entities – An entity is a container for data, each containing a set of attributes
- Attributes – An attribute is a container for a piece of data in an entity
- Relationship – A relationship defines an association between two entities
- Entity Forms and Business Rules – forms designer for entity specific data entry
- Security – add application users and apply authorization rules through the built-in security management tools
- Workflows – workflow designer for hooking into the entity event model
- Business Process flows – designer for guided business processes
- Reports – built-in report designer for SSRS hosted reports
No option listed above requires development time, skill, or tools
- Web Resources – extend forms and dialogs via custom HTML pages
- Plugins – hook into the platform execution pipeline
- Workflows – extend workflow capabilities with custom workflow assemblies
- Custom Reports – download and customize SSRS reports
- Services – access to schema and solution data via REST or WCF web services
- Custom Portals – provide custom user interface for CRM data and services
Each option above requires some level of development effort and skill to implement
Leveraging these Dynamics CRM platform capabilities, customers can:
- Treat CRM as a flexible, adaptable platform for any LOB applications
- Rely on one business application platform to support many applications
- Share resources and familiar platform features for cross application users
Though Dynamics CRM has been in the field for over a decade, the argument still continues over custom development vs. extending an off the shelf platform. This is a continuing debate for both business and technical folks and is not exclusive to Dynamics CRM. The discussion has a lot of different angles with many valid points on all sides, such as limitations to functionality (“Why doesn’t it give me CMS capabilities!?”) or platform dependencies (“Why can’t I deploy it to Oracle!?”). Sometimes it’s simply a matter of approach. Developers, accustomed to building from scratch, often do not like giving up control, while business management doesn’t like licensing fees and relying on external vendors. Recent releases of Dynamics CRM starting with CRM 2011 through 2015 have included many new capabilities that chip away at the arguments and make a great case for Dynamics CRM. Some of the pros and cons that we have seen over the years:
- Powerful rapid development platform – quickly model and demonstrate
- Increased developer productivity, less time investment for both short and long term
- Supported by Microsoft, a full SDK, and active developer and user communities
- Many supported add-on solutions by vendors
- Consolidated IT infrastructure and improved IT staff efficiency through a known, supported platform
- Learning curve for developers, another platform to master
- Licensing cost, typically for smaller organizations
- Developer shifting their approach to development
- Lack of some functionality, either through configuration or platform limitations
- Some limits to extensibility
The bottom line comes down to where a team wants to spend their resources in application development. Do they want to spend a large portion on plumbing or on functionality that users will really get to see? With the rollout of services-based architecture over the last 10 years, new solutions are being released every day that reuse not just data but functionality. For example, there is the long list of online applications relying on third party authentication, such as Microsoft Live Id, Google, Facebook, etc. This is a known model that works pretty well, offering a familiar experience to their end users. Using a platform such as Dynamics CRM as an xRM platform follows the same mindset, but on an even larger scale.
Using Dynamics CRM does not mean that you are starting with Sales, Finance or Marketing. The idea of xRM development can be applied to any Line of Business Application. For example, what if I were building a Patient Health Records system for a hospital or medical office? If I were going to build this from scratch, I would need to build out the following:
- Users – data model and business rules around users accessing the system. This includes authenticating users and authorizing their access, once granted.
- Patients – data model and business rules around how patients are managed within the system. This includes capturing all relevant patient data, how they are activated and deactivated in the system, and who can see and manage the patients.
- Patient related data – data model and business rules around tracking all relevant patient data that will be supported by the system. This could include medical notes, drug orders, allergies, lab data, prescription history, previous hospital stays, etc.
- Patient access – assuming that the patients will access their own data but will not be users of the system, we would need to build out some method for the patient to access their data. This can occur via a portal or some reporting tool.
- Communications – all communication between system users and the patients when something occurs around their patient records, such as the records have been requested or will require updates or changes.
- Reports – periodic reports will most likely be mandatory for HIPAA and FDA compliance (and probably a few other acronyms, too!)
This is just a short list since as we know, a real Health Record system is much more complicated. But building even this functionality from scratch can take an enormous amount of time. Authentication and Authorization in any system are critical for data security, and even more so when we are talking about patient medical information. We could easily spend a large portion of our time on just making sure users can login to the system and they see what they are allowed to see. And everything we build from scratch will have to be tested and maintained in addition to the actual business functionality.
What if we used took the xRM model with Dynamics CRM? In the patient medical record example, we could quickly build out the following using Dynamics CRM:
- Users – this is an existing entity within Dynamics CRM. Done!
- Authentication – by default, on premise CRM relies on Active Directory. If this is an online implementation, we would rely on the CRM Online methods for user authentication. Other methods of authentication are available, as well, but these seem to be the most common. The bottom line here is we do not have to build our authentication system.
- Authorization –Dynamics CRM offers a powerful authorization model through the built-in Security Roles and Business Units. We can configure access from an organization level down to a field level for an entity.
- Patients – leverage the existing Contact entity that already contains a large amount of profile information. We can add custom fields that relate to the patient based on the business requirements.
- Patient data – we could create custom entities within Dynamics CRM that meet all of the needs of the system. For example, we can create entities that track a patient’s laboratory data: tracking the lab type, date taken from office, results, etc.
- Notifications – we could design custom workflows that email the patients in certain scenarios about their medical records using Dynamics CRM built-in Activities and Workflow designer
- Reports – we could design some baseline reports using the built-in Report designer offered by Dynamics CRM. If the report is simple enough, we could simply provide a custom view to the user that they can then save to Excel or Word, an out of the box capability of Dynamics CRM.
- Data entry and user interface – With each custom entity and updated system entity, we are building the relations to the patient, the users, the record, etc. We also configure the data entry forms for each. Once our custom entities are in place, we then apply our security roles, either restricting or granting access to the correct users, teams, and scope, as required
This is a pretty quick rundown of some of the things we can do within xRM and Dynamics CRM. And the example provided is MUCH more complex than I covered in the short list above. The point I would make about the list above is that all that I mentioned could be accomplished in Dynamics CRM with configuration alone. A business analyst who knows the details of the proposed solution, but is not a developer, can still step in and build out business entities and relationships, the security roles, and the data entry forms before the development team ever needs to get involved. That is an enormously powerful benefit of the platform and will allow development teams to focus on the tasks that require their skills and allow the business analyst to present a very functional model to all of the project stakeholders.
While this effort is under way, the development team can begin working on the parts of the system that require developer skills and tools. The area from the patient medical record example is the patient-facing portal. Once the entity model is in place, the development team can start building out a custom web portal that relies on the Dynamics CRM service model as its business and data layer. All data can be retrieved from the Dynamics CRM system just as if the development team built out custom web services for the patient data and presented it to the patient in any method they see fit.
We could dive even deeper into this example if we liked. What about integration with third party systems, such as bedside monitors or ADT systems already in place within a hospital system? What about periodic follow ups with patients based on their medical history and their list of recent appointments? Dynamics CRM can be extended to accommodate many more complicated scenarios, but that will be another post!
While Dynamics CRM offers a powerful set of Sales and Marketing tools to any organization, it also offers a very powerful, rapid development platform for any number of different scenarios. It provides a solid platform that can provide savings in development time, ongoing maintenance costs, and sharing of infrastructure. Celedon has seen the benefits of the platform in our many years of development across different versions of the platform. We are also seeing the success of the platform as its adoption grows within different business areas, such as state and federal government or across financial institutions. Microsoft has made a large investment in the platform over the last few releases that heavily favor developers and making the platform extensible, so you can also be sure that Dynamics CRM will be around for quite a while!