One of the big tasks ahead in the Next Generation project is redefining all the ways in which a constituent relates to other constituents. Today we call this Associations and we know that it doesn’t begin to cover all the bases. So just as we have in the past, we need you to help us out with your thoughts on any or all of the following questions:
1. What are the ways that constituents relate to one another, particularly ways that aren't so easy to track in Tessitura today? 2. What are some scenarios that describe ways that your business needs to communicate with different segments of related constituents? (A simple example: “Sometimes I need to send a mailing out with only one piece per household. But if I’m doing the same promotion in an email I need to send it to all the members of the household.”)3. One of the things we struggled with in designing Tessitura the first time was the whole name1/name2 construct. Is there a reason to treat spousal relationships differently than any other type of family/household relationship? 4. What other questions need to be asked about this topic?
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?
To your question Dan, if you want to speculate on what a constituent entity might look like, of course that's fine--it's your forum and ideas are always welcome.
But as I think you surmised we're really interested in usage scenarios, especially those that we may not have thought about. And also in members' thoughts on whether a spousal relationship is somehow different. I have to say that we're loving the feedback that's been coming in!
Our plan is to come back with a draft model at some point. Following our broad brush strategy, that model will probably be very half formed and full of holes. But something that we hope will elicit more comments. Like nearly every other decision we will have to make in our design it will strive to be a balance between "nirvana" and "doable".