Account Member and Profile Model: Cloud Services need to have the ability to have members associated to an account in which they can use the service being provided for an account, but do not own the account itself nor have any financial responsibilities for paying for the service being provided. This model also enables profiles for each member of the account. This model depends on the Party and Account Model.
Note 1: I've enabled the ability to create a profile at the account member level rather then the account level or the party level because people may have different profiles for each team the may be working with. Some more private then others. Example: I could be a member to 3 different Accounts. One is my employer, another is a very public group I'm volunteering work for, and a private account in which I also own as well as being a member. Each one of these profiles may be different depending on the focus and exposure. I hope that clarifies where I'm coming from.
Note 2: There could be multiple types of profile documents that could be created for a member. One could contain more PII information that is used by the service and needs to be tightly secured and managed. Another profile could be a gaming profile in which is more public and has no PII information. Physically speaking you could end up storing these two types of profiles separately due to security issues. But I've placed them together because logically they are the same concept.
Note 3: Attributes can be defined once and then applied to one or more profile documents to save from having to duplicate and manage multiple attributes that are logically the same concept.
Please see (Baseline Conceptual Models Commentary) for further details on what conceptual models are to be used for.
No comments:
Post a Comment