Tuesday, 29 September 2015

Membership and Dynamics CRM - How's It All Going, Then?

A few months back, I blogged about how Spotlight has chosen Microsoft Dynamics CRM 2015 as the platform for delivering our new membership system, and our high-level plan for incorporating Dynamics into our existing infrastructure. Six months on, I thought it'd be worth revisiting to talk about how the project is progressing and the lessons we've learned so far. Particularly since people on Twitter keep asking me if I'm regretting it yet. :)

Now, I wear many hats. I'm a systems architect. I sit on the strategic board at Spotlight. I've been here long enough that I understand most of our business processes in excruciating detail. I'm interested in UX and interaction design. And, sometimes, when nothing else is going on, I write code and build stuff.

With my business hat on, Dynamics CRM is clearly the right solution for us. It works. It supports a business-to-consumer sales model, out of the box, which works really well for us (it surprised me how many of the other CRM systems we looked at assume that every customer is a company and every sale starts with a quote.) Dynamics CRM offers features like case management, service calendars, Outlook integration, multiple price lists and currencies, mobile device support, Active Directory integration - things that would probably never make it to the top of the backlog if we were building our own system. And that's fine - we are not in the CRM business. We build software to help people cast actors and make movies; everything else is overhead.

Strategically, it makes sense. Our initial customization and integration phase will end up being less than six months, after which membership and CRM will be very much a "solved problem" as far as our development team is concerned, freeing us up to focus on other things. Using an off-the-shelf product as the backbone of our membership and business activity gives us lots more options for making improvements in future - certainly more than if we'd built our own system.

So I still believe Dynamics CRM was, and remains, the best solution to our business requirements.

But... (you knew that was coming, didn't you?) as a software developer, it has frustrations, which can be broadly categorized as good, bad and ugly.

The Good...

It's a hugely complex product, and it has a learning curve. There's frequently several ways to achieve something - multiple email integration patterns, several different ways to implement single sign-on for user authentication. Almost anything is possible once you know how. This is frustrating when you don't know how, but once you get the hang of it, it works pretty well.

You can also write custom code in C# that runs directly within Dynamics, which - again - has a hell of a learning curve but is actually a really powerful technique. With a little ingenuity, you can even build C# components that implement your business logic and rules, and then decide later where that logic should be deployed. I like that sort of flexibility.

...the Bad...

Dynamics CRM is the heart of a software ecosystem that's still a long, long way from the software-as-craft ethos which is becoming fairly common elsewhere. Partly, this is a question of tooling and process. Things like revision control, continuous deployment and unit testing become really quite hard when your "project" is a ZIP file full of proprietary XML - no branching, no merging, only the most rudimentary support for rollbacks. As a developer, this is frustrating - but it's important to remember that systems like Dynamics blur the boundary between "developers" and "users" that's prevalent in most development projects. It's a platform. The people who use it every day for the next decade WILL be making changes to it - because the whole reason we're doing it is to empower The BusinessTM to manage their own membership system - and those people aren't software developers.

More worryingly, Dynamics CRM appears to be one of those products where you can make a very good living as an "expert" without actually knowing anything. The amount of misinformation and bad advice surrounding this product is astonishing. I've read blog posts promoting the most dreadful solutions. I've spoken to consultants - and interviewed contractors on quite generous day-rates - who are completely unaware of whole swathes of the core product's capabilities. That makes it really difficult to know who you can trust - and how much time to invest in validating your assumptions before committing to any kind of delivery.

This isn't a problem with Microsoft Dynamics per se - I think it's probably characteristic of any market sector where we see the dreaded "point and click - no development required!" shibboleth - but it's still a lot less fun than working on, say, Nancy or ServiceStack, where the code is open source and most of the community seem to know what they're doing.

...and the Ugly

And then there's the stuff that's just plain stupid. For example, there's an entity in CRM called a Contract. Once a contract has been "invoiced" - which you can do by clicking a single button in the UI - it is immutable. There is literally NOTHING you can do - even with all the Administrator permissions in the world - to change any detail on that contract. Ever. There's various workarounds for this. Microsoft's recommendation is that you need to "clone" the Contract as a draft, cancel the original and replace it with the clone. Our own solution was to write a custom plugin in C# that throws an exception if you ever try to invoice a contract - this works, but it's not pleasant having to work around such an arbitrary restriction.

They say there's only two hard problems in software development - cache invalidation and naming things. Well, Dynamics CRM will remind you of that on a daily basis. Almost everything in CRM needs to have a name otherwise you can't save the record. For people, companies and products, this makes sense... but, really, when you're creating an order to allow somebody to renew their membership, does it need a name? Really? So we're having to build our own code to automatically create these names all over the place, and it's a waste of time.

As for cache invalidation - there's a thing called the "portal toolkit", aka the Developer Extensions for Microsoft Dynamics CRM 2015. You can read all about it here. Pay particular attention to the sentence that says:

The Customer Portal and Partner Relationship Management (PRM) Portal solutions for Microsoft Dynamics CRM 2015 will be available from the Microsoft Dynamics Marketplace soon.

I don't know when "soon" is, but at the moment, if you start using the portal toolkit, you end up with a cache that you can't invalidate - the only supported invalidation mechanism involves deploying an (unreleased) solution to your CRM server, that calls an (undocumented) DLL that you're expected to deploy to your web server. Oh, and if you're running a server farm, you'll need to work out how to configure your load balancer to forward these cache invalidation calls to all your backend servers simultaneously.

So...

Like democracy, it's probably fair to say that Dynamics CRM is the worst option apart from all of the alternatives. It certainly isn't perfect, but it is pretty damn good, and I think the long-term advantages will significantly outweigh the short-term headaches we're having. And if they don't? Well, that's why we have loosely-coupled architecture, isn't it?