Over the last couple of weeks I have found myself in conversation with several business partners about the technology used within Sage CRM. Some partners were filling RFIs and some were preparing for technical demos with prospects.
The questions were mostly quite matter of fact, for example;
- Can we use .NET to customize the system?
- How can I be sure my data is secure?
- Can we control user access with Active Directory?
- How can we link back office data to the CRM system?
Although the questions I was asked seemed obviously technical and the points had been raised by IT staff but there were other business concerns behind them. As the conversations developed I found myself asking the business partners a variant of this question "what is the problem that the technology needs to solve for the customer".
The partners identified different issues but the main technical 'problems' that their prospects needed to solve were...
- System Performance
- Ease of Development
- Ease of Maintenance
- Ease of Use
Below are some of my thoughts around these matters with links to further reading.
System Performance
The critical path for Sage CRM is the underlying database. This is both the CRM database and the connection to any external databases. You need to make sure that the databases are tuned. If they are then CRM will run like a rocket.
Ease of Development
Sage CRM is meta data driven software. The two main APIs that can be used for the generation of the interface are either the classic COM ASP or .NET. In ASP pages then you tend to write in JavaScript and in the .NET assemblies you can write in C#. Both APIs can take advantage of the features of Visual Studio and SDKs resources are provided for both. The main advantage of C# is that it creates readonly dlls that offer some protection from 'fiddling' with code. The .NET API communicates with the eWare.dll via COM interop so the features of the two APIs are broadly equivalent.
The important point to make is that both are minimum code APIs because the definitions of the objects (or classes in C#) are held in the database. The meta data does the heavy lifting. Once a page is written, then to add a new field to a screen is only a matter of changing the definitions in the Admin screens and there is not need to return to the code.
Both API use wizards provided as part of the SDK resources to generate new entities and screens that further minimise the code that needs to be written.
Ease of Maintenance
Standard code, that uses standard techniques will work on upgrades. This is because we get the meta data to do the heavy lifting. The HTML is generated from the meta data and CRM will generate the HTML correctly for each new version after an upgrade.
Most screens are meta data driven. You don't need IT to make changes to the system. The maintenance of the system is owned by the business. They know the business rules and this avoids the Chinese whispers that can cause confusion in maintenance.
You don't need extensive programming skills, a fact which is important in a business where IT staff may frequently change or be external contractors.
I would always emphasise the power of workflow, and the click only security model when discussing ease of maintenance with a customer.
I would welcome discussion around the ideas I have discussed as this article was prompted by specific conversations with some business partners and I am sure that we could expand this further.
I look forward to reading your comments below.