Relationships, anyone?

Cool!  From the Chicago Summit discussion and this thread great design needs begin to emerge!  Of course I would fully expect that Chuck and his design team already have some models in mind.  However, it's completely appropriate to see what the membership thinks.  So, some of these comments are just recapping or restating some of the other comments we've read so far.

I fell that the answers to Chucks original questions show that we don't want to build in any constraints that are not technically required.

Imagine that we move to a different environment where every entity gets its own record.  If its a person, they get a record. A foundation gets a record.  A school gets a record.  Even a group can get a record.

Each of these entity records could be typed so we know what kind of entity it is.  We would need to establish what the minimum base amount of data is that would be required to create one of these records.  For example, we'd have to decide if we can create an entity record for a person with only a first or last name.  If so, we'd have to come up with other identifiers to make this record unique.  

Uniqueness would be a key concept for entity records.  Every entity record would have to be unique with no duplicates allowed.

Transactions could be tied to an entity.  However, we may need to build in the ability to split the value of the transaction according to both predefined and perhaps on the fly rules.  However it's done, we will probably need the ability to assign value and benefits to one or more entity based on relationship rules.

Relationships could become the connectors that tie entities together.  If we follow these ties we could get pictures of entity groups that have different functions.  Again, a rules engine would need to be used to build the views according to organizational standards.  

For example, the term "household" has been mentioned many times in this thread.  What is a household?  What relationships determine which entities can be tied together into a household group?  Are spouses automatically part of a household?  What about married people who live separately?    If there are child records tied through relationship to a parent record should we assume that they are in the same "household"?

Why are we even concerned with what a "household" is?  Is this for marketing and communications purposes?  Are there other ways to do that?

Imagine again that in this model we establish location records that could contain an address of a particular type such as a private residence.  The location or address records could stand on their own and also be tied to an entity in a similar way that entities can be tied to one another.  

When you're communicating with a direct mail piece who are you trying to reach?  Are you trying to reach an individual entity or a group of entities that reside at the same location?  

If you establish the relationships between these records (entities and locations) correctly, you should be able to create a communication that is targeted to one or more specific entities, but only delivers one copy to a specific location.  The salutation could also be manipulated through similar rules.

It looks like I'm rambling now so I'll summarize...

The greatest flexibility may come from keeping data elements grouped together at the most granular level possible.  Then building mechanisims that allow us to link these grains of information togeather.  

Perhaps not technically feasible.  But it could be interesting to follow the concept through some modeling.

Question for Chuck...

Is speculating about the constructs of an entity record relevant? Or should we be focusing exclusively on defining scenarios of usage?

I like many of the thoughts that are coming through, thanks everyone! I think Ken and Dan are proposing some grear thoughts that are very much aligned with what I've been thinking as we've dealt with varied business needs in several organzations.

Let me throw out two extensions to what everyone has said for further comment and thoughts.

1. Relationships - what if these relationshis were flexible, and could join multiple entities to an actual grouping? For instace, several individuals could be related to a particular Family, and that family grouping would have an ID# of it's own and be treated as a 'first class object' in it's own right.

2. What if you could link both an individual entity (person or organization) AND a grouping to transactions or orders or payments, etc?

With the thoughts already expressd y others, this would allow you to identify the individual person or organization AND the capacity in which they are acting (the 'grouping/relationship entity) to any action in the system. It would seem to address all of the issues/needs raised by everyone on this discussion.

The relationships become primary objects, after all, this is a 'Customer Relationship' Management system!

Alan

Cool!  From the Chicago Summit discussion and this thread great design needs begin to emerge!  Of course I would fully expect that Chuck and his design team already have some models in mind.  However, it's completely appropriate to see what the membership thinks.  So, some of these comments are just recapping or restating some of the other comments we've read so far.

I fell that the answers to Chucks original questions show that we don't want to build in any constraints that are not technically required.

Imagine that we move to a different environment where every entity gets its own record.  If its a person, they get a record. A foundation gets a record.  A school gets a record.  Even a group can get a record.

Each of these entity records could be typed so we know what kind of entity it is.  We would need to establish what the minimum base amount of data is that would be required to create one of these records.  For example, we'd have to decide if we can create an entity record for a person with only a first or last name.  If so, we'd have to come up with other identifiers to make this record unique.  

Uniqueness would be a key concept for entity records.  Every entity record would have to be unique with no duplicates allowed.

Transactions could be tied to an entity.  However, we may need to build in the ability to split the value of the transaction according to both predefined and perhaps on the fly rules.  However it's done, we will probably need the ability to assign value and benefits to one or more entity based on relationship rules.

Relationships could become the connectors that tie entities together.  If we follow these ties we could get pictures of entity groups that have different functions.  Again, a rules engine would need to be used to build the views according to organizational standards.  

For example, the term "household" has been mentioned many times in this thread.  What is a household?  What relationships determine which entities can be tied together into a household group?  Are spouses automatically part of a household?  What about married people who live separately?    If there are child records tied through relationship to a parent record should we assume that they are in the same "household"?

Why are we even concerned with what a "household" is?  Is this for marketing and communications purposes?  Are there other ways to do that?

Imagine again that in this model we establish location records that could contain an address of a particular type such as a private residence.  The location or address records could stand on their own and also be tied to an entity in a similar way that entities can be tied to one another.  

When you're communicating with a direct mail piece who are you trying to reach?  Are you trying to reach an individual entity or a group of entities that reside at the same location?  

If you establish the relationships between these records (entities and locations) correctly, you should be able to create a communication that is targeted to one or more specific entities, but only delivers one copy to a specific location.  The salutation could also be manipulated through similar rules.

It looks like I'm rambling now so I'll summarize...

The greatest flexibility may come from keeping data elements grouped together at the most granular level possible.  Then building mechanisims that allow us to link these grains of information togeather.  

Perhaps not technically feasible.  But it could be interesting to follow the concept through some modeling.

Question for Chuck...

Is speculating about the constructs of an entity record relevant? Or should we be focusing exclusively on defining scenarios of usage?

Alan,

Great point!  

I was thinking of a situation where the grouping of relationships could be built on the fly.  However, our rules may demonstrate that some relationship groupings would be commonly used, and could have attributes of their own.  Thus the relationship becomes a record itself so that those attributes could be tracked and maintained.

Exactly!

Alan,

Great point!  

I was thinking of a situation where the grouping of relationships could be built on the fly.  However, our rules may demonstrate that some relationship groupings would be commonly used, and could have attributes of their own.  Thus the relationship becomes a record itself so that those attributes could be tracked and maintained.

Another answer to #3...

We need to also address how people use their personal assistant/secretary. Those people have a number of the same "powers" that spouses/partners have.

Honestly, I'm concerned about the concept of "split" values in general. I was thinking about how people describe themselves. "I'm a donor" and "I'm a subscriber" are pretty typical - the next step is to say "I'm a $1000 donor" -- which BOTH the husband/wife will tell you. Each spouse will take full credit for the entire amount - either on the phone, or in person.

I know that we aren't in a design phase here, but when you "split the value" - will Tessitura reflect that "value" as the husband is $500 and the wife is $500?? I can see a number of pitfalls with this approach that we should be aware of moving forward. The last thing any of us want is to navigate ourselves into a field of landmines as we use our sparkling new CRM system... telling a donor once by mistake that "the system reflects half" (or whatever) of what they think that they gave will not be pretty. Especially if it is one person's money.

Maybe I am missing something, but I don't get this part, or maybe I'm not buying =) Thanks for any enlightenment out there -

Erin

Another answer to #3...

We need to also address how people use their personal assistant/secretary. Those people have a number of the same "powers" that spouses/partners have.

Honestly, I'm concerned about the concept of "split" values in general. I was thinking about how people describe themselves. "I'm a donor" and "I'm a subscriber" are pretty typical - the next step is to say "I'm a $1000 donor" -- which BOTH the husband/wife will tell you. Each spouse will take full credit for the entire amount - either on the phone, or in person.

I know that we aren't in a design phase here, but when you "split the value" - will Tessitura reflect that "value" as the husband is $500 and the wife is $500?? I can see a number of pitfalls with this approach that we should be aware of moving forward. The last thing any of us want is to navigate ourselves into a field of landmines as we use our sparkling new CRM system... telling a donor once by mistake that "the system reflects half" (or whatever) of what they think that they gave will not be pretty. Especially if it is one person's money.

Maybe I am missing something, but I don't get this part, or maybe I'm not buying =) Thanks for any enlightenment out there -

Erin

Excellent points Erin,

I think what some of us were getting at is this...

The system needs to be designed in such a way that rules can be configured to determine if the value is automatically split and if so how.   There may be circumstances where an organization wants to do this.  Then again, there may be times when you don't.

The transactions could be recorded at the lowest level of granularity.  Yet the view of these patrons that is filtered by the spousal relationship and a custom rule that gifts in spousal relationships have shared value would allow you to get what you want.

Put another way...

Because we currently have a joint account model we think of the need to "split" the records to share them.

Instead, think of the records being split from the beginning.  The need then becomes to find ways to join the records and in some cases the values of the transactions when viewing them.

Let's see if we can flush out the individual entity records and relationship records concept with your scenario.

Patron A has an individual entity record.  So does patron B.  A relationship record exists that indicates that Patron A and Patron B are spouses, and a rule exists that indicates that they choose to jointly share the value of their giving.

In this case anytime you query the system for the value of gifts given by Patron A, it would also include Patron B's giving.  So, if Patron A wrote a check for $500 and Patron B wrote a check for $1,000 a query for the giving level of either of them would indicate that they have given $1,500.

However, the fact that Patron A gave $500 and Patron B gave $1,000 would also be captured.

You retain both views.  The fact that they gave individually through separate checks is captured.  The reality that you want to know and report what they gave collectively is realized.