Socialig/Use Case TF/Group Use Cases/Federated Collaboration Groups

Use Case Title

Federated Collaboration Groups (Might also be called: "Data Elements Identified as Sharable or Not, Across Social Platforms")

Use Case

Note from Ann: seems like this Use Case description is too long. Maybe I'm missing the essence of what distinguishes this case, which I think is the emphasis on "federation". Ideas?

1. Ann, Joe, and Bob each work for a different company.
2. They need to work together on a project, and need online tools and "places" in which to collaborate.
3. Because their companies are competitors, they do not want to use a collaboration tool that is hosted inside one of their companies.
4. They agree to use a tool that includes a variety of collaboration capabilities, which is owned and hosted by an entity unrelated to any of their companies.
5. Setting up the project in the external tool, each participant can populate their own profile and other information by "pulling" from an existing master personal data source (whether inside their company or elsewhere)
6. Working on the project, in the external tool, each participant can share and protect information per their own requirements.
7. The collaboration tool enables "social" interactions such as comments, relationship linking, "likes", and etc
8. At the end of the project, in the external tool, each participant can archive what they want, including discussions and other social interactions to which they have access

Type of Social Interaction

Federated Activity

Narrative

Collaboration across entities is commonplace. Companies may collaborate on a product with key suppliers, or may collaborate with a university team on a research project, or colleagues from multiple companies come together in a team, such as at W3C.

Actors

People who work for or are aligned with different entities (companies, universities, etc), who need to work together, across those boundaries.

Goals of Actors

Each person in this scenario wants to work with the other teammates, sharing as much as possible. At the same time, each needs to protect information that is private to his/her own company, university, or self.

Success Scenario

In the best situation, all participants use a common tool, into which they easily populate their own information (profile, contact, etc) from their own tool(s). Data that is not to be shared, does not flow. The user does not need to know which data is approved for sharing, and which is not -- the systems manage it.

Success Criteria

People can collaborate, comfortably sharing appropriate information, while easily protecting other information. Ease-of-use and appropriate-ness of sharing are important criteria.

Failure Criteria

The current state often fails. It is typical for one of the entities to set up a community/group/environment in a way that the other team members from the other organizations join and use. Problems are:

A) People are asked to participate in a tool owned by another company / university. If they are competitors, this can be a security risk, or is at least makes participants nervous.

B) Under- or over-sharing occurs because remote users are unfamiliar with the platform. (Under-sharing occurs when remote users, new to a tool, don't know how to fill out their profile, or participate in discussions. Over-sharing occurs due to context switching when a user is normally in an internal tool, then forgets they are currently in an external collaboration network - especially if the two environments are using the same technology.)

C) Occasionally remote participants cannot connect due to incompatible technologies or corporate policy restrictions.

Graphic Illustration(s) [optional]

Ann asks: How do I get that image to come to the left?

How to collaborate across entities?

Comments

In Ed Krebs' [scenario], he described the following potential solution. Ann Bassetti isn't sure about the logistics of that suggestion.

Potential Solution: "A better view would be where the working group area is defined in each corporation's internal tool as a shared workspace. Key elements of the user's profile should be accessible from any of the participants. This is another case where there may be the need for a subset of the data elements to be identifiable as sharable or not. This may be especially true if this scenario occurs within a system that the internal profile was extracted from or federated with an internal corporate directory system, such as an HR system (see Business Profile and Relationship Federation within this same wiki page)."