[drupal-devel] CRM, Civicgroups, OG, Profile- Playing together
kieran at civicspacelabs.org
Mon May 9 08:17:51 UTC 2005
On May 9, 2005, at 6:48 AM, jasonwhat wrote:
> http://drupal.org/node/21940#comment-38421 In this post I talk
> about some of the various modules out there that let users create
> data about themselves, data on other users, and relationships.
> What seems clear to me is there is development going on in CS and
> Drupal and Civicgroups of several similar user managemnt and
> organanization tools.
> I brought this issue up here http://civicspacelabs.org/home/node/
> 12285 and realize that maybe the CivicCRM is the to omnipotent api
> that will unify all several modules. If I'm correct, the CivicCRM
> won't just have it's own data fields, like the current contact
> module in CS, but will share with modules like profile once they
> are updated to work with it.
Actually you don't want to normalize on CivCRM. Thanks for opening
that giant can of worms ;-)
We need to normalize on a common set of labels for our community
member data. But first let's talk about the types of data. The
three types of data we want to capture are reference data,
relationship data, and activity data. The reference data must be
qualified because as you noted it could be coming from any kind of
social software application. You can think of reference data as
name, number, address, etc. Unfortunately, it could also come from
buddylists, petitions, or volunteer lists. That reference data must
be qualified for the source which the reference data came from.
I have been meaning to identify a common set of labels for community
member data but haven't got around to it. I believe that CivCRM has
done a good job with their data model. But they are focused on the
non-profit sector and as a result it's possible that their model
doesn't include reference data that you might consider critical such
as blog, or xfn. There model is flexible and can handle these
changes. The point is that CivCRM has a public data model and how
they map internally is up to them, but as long as other member data
applications can normalize to an agreed set of labels in the
community we should not have a problem. This is very important
exercise and should happen soon.
Once we have a Drupal blessing, a non-profit blessing, a political
blessing, and a social software blessing of our reference labels we
can do something very important. We can create a set of master
textual descriptions of data types known as conformed dimensions.
With conformed dimensions we can query multiple data sources, or data
marts. Querying across multiple sources is known as drilling across
or a multi-pass query. Overall this is refered to as a data bus-
Most folks in Drupal land assume that they will always have a single
database. But anyone in the political or non-profit field will tell
you that decentralized data sources is a fact of life that you just
have to get used to. A data bus architecture is how you design your
data infrastructure to be able to be accessible.
This might seem like overkill but sometime in the next several weeks
CRM will be merged with Drupal. When that happens leaders of
communities are going to start asking questions about the
relationship between content in the CMS and people represented in the
CRM. Those questions will be unpredictable and we need the
flexibility designed in to be able to answer those questions. Over
time, new applications will be developed that involve social
information, as you have noted is already happening. How we
integrate those applications with Drupal is going to be of incredible
importance to leaders who would benefit greatly by being able to ask
complex questions about their communities. If we do less than a
great job those questions will not be able to be answered.
A good place to start would be to research SugarCRM, CivCRM, and
SalesForce.com's non-profit data models. The goals would be to set
a reference and relationship labeling standard that all application
developer could adhere to. If they did meet that standard then it
would greatly facilitate the integration of data sources into a data
There are literally hundreds of world class engineers who have
tackled these problems internally inside corporations. Just as all
the Unix expertise poured out of companies into Linux there is an
opportunity for all this data integration expertise to pour out into
getting CRM and CMS integration done right. They are just waiting
in the wings watching to see what happens.
I hope you take up this challenge.
> If CivicCRM seems like the place to unify all this then I think
> there needs to be a more visible way to get these module
> maintainers and developers involved now. I do believe there is a
> mailing list for this, but I mean a more visible acceptance from
> developers that the CivicCRM is what they should be looking
> towards, and coding towards as much as that is possible.
> I might be stating the obvious here, but my fear is that modules
> like "contact directory" http://drupal.org/node/15863 will continue
> to be developed duplicating the fothcoming CivicCRM. Or maybe the
> module is great and will ultimately be an important aspect of the
> CRM, but if so it would nice to have that conversation started now,
> rather than later. With all the posts about extending profile, or
> searching profiles, referrals and invites, and organic grouping, it
> would be nice for these developers to join in the CivicCRM
> discussion and development, rather than starting their own.
> I see that CivicCRM was discussed at FOSDEM, but I don't know if a
> more general "user management" discussion has taken place or not.
> I'm not sure if it needs to, but just throwing these thoughts out
> to the wolves.
> To unsubscribe, e-mail: civicspace-dev-unsubscribe at civicspacelabs.org
> For additional commands, e-mail: civicspace-dev-
> help at civicspacelabs.org
More information about the drupal-devel