It looks like there is a good start on the basic architecture for a Drupal-based CRM. I was in attendance at the CRM BOF in Copenhagen. There were a lot of ideas being tossed around there. I think it would be good to have a clear set of goals and definitions for what we are building.
What is our goal?
When someone says, "Let's build a CRM in Drupal," it could mean several different things. Is the goal to provide a set of modules that can be used to build a CRM? Is our goal to build a basic, but extensible core CRM module that people can simply enable on their site and begin using? Is our goal to build an API that is friendly for developers to use?
Right now, the technical stack of the CRM system looks like a collection of modules that will help someone build a CRM. I could build a simple CRM system in Drupal 6 with all the modules that are out there. It may not be as flexible as what is being proposed in this group, but it is still possible. Continuing with this approach would best serve people who build Drupal sites who need their CMS and CRM bundled together in one site. It would also server people who wish to build install profiles and Drupal distributions that are meant to be used as a CRM. The benefits of this approach are that it is quite flexible and it builds on top of . The cons may be that it is not a simple solution. It would be difficult to have a clean, simple API and the stack of modules used to create a basic CRM could be never ending.
What other options are there? Drupal's CMS functionality is mostly bundled into one place: the node module. Modules are then written to extend the core CMS functionality. It takes care of the most basic tasks of managing content: multiple authors, revisions, workflow (published/unpublished), storing data belonging to each piece of content, etc. The node module is extensible because of a well thought-out API. I propose that it would be possible to build a simple, core CRM module. It would only handle the basic requirements of a CRM. These may be storing information about contacts, segmenting contacts, and contacting contacts (printing mailing labels, sending email). The benefits to this are that it would allow more focus on a single API rather than a collection of modules.
I'm not sure which choice is better, but I'd like some open discussion on what exactly we are going to achieve.
Comments
You're right
You're quite right when you envisage a single core CRM module. I think the strategy is (correct me if I'm way off) something like:
Do feel free to add to this. Perhaps this might evolve into a wiki page or something at some point if there's a need for it.
Goals versus constraints versus targets
I think a goal needs to be a much higher level than this. "Stuff that every CRM absolutely cannot do without" sounds like a formal project constraint, but it's as generalized as a goal: who decides what a CRM cannot do without? I also think that Drupal CRM's goals should have nothing to do with module separation. That's a detail of implementation.
Maybe we need some formal methodology here: unfortunately, I personally don't know of any except by hearsay. If anyone has a tame Prince2-trained project manager to hand then please point him at this discussion :)
The best distinction I think we can make is to have goals as something inspirational, then have formal project constraints on the one hand and achievable targets on the other: constraints keep us on a particular path, and targets help us define milestones that make sense. Chris, I've taken your suggestions - and also some of the things which arose re: discussions of other CRMs at the BOF - and hopefully integrated them into what follows:
Goals:
Constraints:
These could change as we start specifying the work further, but include:
Targets:
These could be anything, really, but I think after the first couple of milestones they really have to be user-oriented e.g:
Targets will really come down to satisfying specific and specified user functionality and how we go about doing that. This bit really needs more spec based on use cases, so any work people can do to get use cases out of clients (or elsewhere) would really help.
This all neatly separates out three sets of ideas: 1. what the project wants to achieve 2. how we go about doing it 3. how we know it's done.
Shall I stick this on a wiki page and anyone can fiddle with it?
Another Major Goal
Modification: The Drupal CRM API must be robust and easy to use.
+1 to that!
+1 to that! The APIs are really important in the long term because we want to not have to do all the work ourselves! I think the project will ultimately stand or fall on how easy it is to integrate with it. Third parties will forgive a fair few gaps in a project if they can build and then distribute their own bridges for those gaps.
I've rewritten the extensibility goal to reflect that. I've also added to the API functions constraint to stress usability, and I've added a new target - and expanded an existing target - to stress that we want to be able to build basic modules through the APIs to really call the APIs "done." See http://groups.drupal.org/node/92294
To borrow your node module
To borrow your node module analogy: the reason we're building this with a collection of modules is the same reason that before you can install Drupal's blog module to have a simple blog, you also need Drupal's system, user, and node module. These provide the base that blog module sits on top of.
Some of that would probably sit above the Party module in the planned stack. Feel free to add that to the wiki page. Though for sending emails there are already good modules, such as simplenews and messaging -- we should make sure we interoperate with those rather than reinvent. Something like mailing labels would just be a nicely themed View the module would provide.
Sorry, +1 to jtsnow's
Sorry, +1 to jtsnow's original point about a simple, core CRM module. I do think, though, that that has to sit on top of a number of generic components, some of which simply don't exist yet in the D7 module space. I think the architecture shows a good road map for this, but the CRM will probably sit roughly where Joachim suggests.
Methods of contacting
Methods of contacting contacts is definitely outside core... sure, provide the API to contact, but actual implementation of a means of contact sits outside core.
again, flexibility
I agree. It should certainly be possible to use core Drupal CRM alongside a Drupal email solution... but someone should also be able to connect it with Mailchimp, Constant Contact, or some other 3rd party app if that is what will work best for them.
On the present approach with multiple modules
The idea of building a lot of small modules that achieve particular tasks seems to utilize the model that has made Drupal such a successful project. The unique thing about Drupal that makes it so extensible is the fact that you can combine so many different functions using the framework that Drupal has laid out. If the CRM project is nothing more than a bunch of modules though, then when someone was to pick between CiviCRM and DropCRM, Civicrm would appear very attractive, because it's already set up. That said, I think there should be some real consideration to branching out the Drop CRM project into 4 major components:
At the end of the day, Drop CRM could have all the functionality of CiviCRM or the like, but as a distribution it leaves it incredibly extensible, allowing those of us who are contributors and consulants to continue evolving the distribution with more add-ons, theme enhancements, etc. If it was just a big CRM module, most contributions would still depend heavily on developers and coders - nothing wrong with that, but its a smaller pool of resources. Further, as features develops, in the future e-commerce and other solutions that create mashups of more lightweight modules could easily be used to extend such a CRM site, or some of the CRM modules could go on to be used for other purposes doing their more basic tasks. If anyone is not familiar with distributions, check out Drupal Commons (Acquia), Atrium (Development Seed), Openpublish, and/or Open Scholar to see exactly what kind of capabilities you can get from mashing up a lot of simple modules with 2-3 created for a specific project.