Last week I attended the Microsoft Convergence conference in Atlanta, GA where I got a deeper dive into a technology that I’m spending a lot of time with right now. You could say that Microsoft Dynamics CRM and I are seriously dating and she’s keeping things in my medicine cabinet.
While sitting in a tips-and-tricks session, I started jotting down a list of things that I should focus on to REALLY understand how to use Dynamics CRM to build a solution. Microsoft is pitching Dynamics CRM as a multi-purpose platform (labeled xRM) for those looking to build relational database-driven apps that can leverage an the Dynamics CRM UI model, security framework, data structure, etc.
I realized that my list of platform “to do” things would be virtually identical for ANY technology platform that I was picking up and trying to use efficiently. Whether BizTalk Server, Force.com, Windows Communication Foundation, Google App Engine, or Amazon AWS Simple Notification Services, a brilliant developer can still get into trouble by not understanding a few core dimensions of the platform. Just because you’re a .NET rock star it doesn’t mean you could pick up WCF or BizTalk and just start building solutions.
So, if I were plopping down in front of a new platform and wanted to learn to use it correctly, I’d focus on (in order of importance) …
- Which things are configuration vs. code? To me, this seems like the one that could bite you the most (depending on the platform, of course). I’d hate to waste a few days coding up a capability that I later discovered was built in, and available with a checkbox. When do I have to jump into code, and when can I just flip some switches? For something like Force.com, there are just tons of configuration settings. If I don’t understand the key configurations and their impact across the platform, I will likely make the solution harder to maintain and less elegant. WCF has an almost embarrassing number of configurations that I could accidentally skip and end up wasting time writing a redundant service behavior.
- What are the core capabilities within the platform? You really need to know what this platform is good at. What are the critical subsystems and built in functions? This relates to the previous one, but does it have a security framework, logging, data access? What should I use/write outside services for, and what is baked right in? Functionally, what is it great at? I’d hate to misuse it because I didn’t grasp the core use cases.
- How do I interface with external sources? Hugely important. I like to know how to share data/logic/services from my platform with another, and how to leverage data/logic/services from another platform into mine.
- When do I plug-in vs. embed? I like to know when it is smartest to embed a particular piece of logic within a component instead of linking to an external component. For instance, in BizTalk, when would I write code in a map or orchestration versus call out to an external assembly? That may seem obvious to a BizTalk guru, but not so much to a .NET guru who picks up BizTalk for the first time. For Dynamics CRM, should I embed JavaScript on a form or reference an external JS file?
- What changes affect the object at an API level? This may relate to more UI-heavy platforms. If I add validation or authorization requirements to a data entity on a screen, do those validation and security restrictions also come into play when accessing the object via the API? Basically, I’m looking for which manipulations of an object are on a more superficial level versus all encompassing.
- How do you package up artifacts for source control or deployment? You can learn a lot about a platform by seeing how to package up a solution. Is it a hodge podge of configuration files or a neat little installable package? What are all the things that go into a deployment package? This may give me an appreciation for how to build the solution on the platform.
- What is shared between components of the framework? I like to know what artifacts are leveraged across all pieces of the platform. Are security roles visible everywhere? What if I build a code contract or schema and want to use it in multiple subsystems? Can I write a helper function and use that all over the place?
- What is supported vs. unsupported code/activities/tweaks? Most platforms that I’ve come across allow you to do all sorts of things that make your life harder later. So I like to know which things break my support contract (e.g. screwing with underlying database indexes), are just flat out disallowed (e.g. Google App Engine and saving files to the VM disk), or just not a good idea. In Dynamics CRM, this could include the types of javascript that you can include on the page. There are things you CAN do, but things that won’t survive an upgrade.
- Where to go for help? I like to hack around as much as the next guy, but I don’t have time to bang my head against the wall for hours on end just to figure out a simple thing. So one of the first things I look for is the support forums, best blogs, product whitepapers, etc.
Did I miss anything, or are my priorities (ranking) off?
Richard Seroter's Architecture Musings 
I like the list and I think you’ve covered the bases. I think the ranking will alter based on your goals. Are you learning for the heck of it, or do you have a particular problem to solve? When you’re learning a platform for resume purposes your ranking is fine, but when selecting a platform to solve a problem I’d mix it up a little. I’d bump #2 (core capabilities) up into first place because I want to create an initial shortlist of platforms that can solve my problem. If one platform solves my problem great, if not then #3 (interface capabilities) get’s bumped to second place because now I have to integrate 2 or more platforms. Now I have my shortlist I might look at #1 (code or config) to order them as it’s always a good differentiator. I can then further refine and order my shortlist by considering the other aspects on your list. They effect implementation more than attacking the problem but can help swing a decision. In a perfect world we get to learn all platforms. In the real world we have to justify our training 😦
Good points Ian. If I just need to go inch-deep and mile-wide, I’d focus primarily on core capabilities.
I think #6 is huge and is frequently overlooked. I’ve encountered plenty of systems (even from major vendors) that basically had NO deployment capability other than “do it over in the next environment”, “build your own deployment tools”, or “jump through these hopelessly complicated and error-prone hoops”. You want to find this out early.