[drupal-devel] CRM, Civicgroups, OG, Profile- Playing together

[Kieran Lal]

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- 
architecture.

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  
bus architecture.

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.

Cheers,
Kieran



> 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
>
>
>