...
| Criteria | Without eduTEAMS | With eduTEAMS | |
|---|---|---|---|
Account Provisioning | Accounts have to be created for each member of the research community, which requires collecting name, addresses, etc. beforehand. Keeping the user data up-to-date will required to periodically ask the users or their organisations for any changes, which is a unreliable and cumbersome process that will likely result in stale and inaccurate data within a few months. | Creating accounts on eduTEAMS Member Registration service can be as easy as having a list of email addresses with which participants are invited. Thanks to federated login via eduGAIN, accounts (incl. name, organisation and more) can automatically be created upon first login. Up-to-data user data from the user's home organisation is available on every consecutive login at a service, which easily allows service to always the the most up-to-data data. | |
| Identity Management | Keeping identities/accounts up-to-date has to be done by research community on its own, depending on architecture even multiple times on every application that is used collaboratively. | Identity management is done by users home organization or - in case the user uses the eduTEAMS Identity Hub - the the user himself. It's in the user's home organisation self-interest to keep data as up-to-date as possible and the same is true for the users or that organisation. They also have a high interest to keep their identity data up-to-date because they for example want their name spelled properly on diplomas or staff insurance documents. | |
Credential Management | Credentials (passwords) have to be created, properly protected, securely distributed and reset by a research community on their own. | Credential management is entirely done by user's home organisation (i.e. university), which has a high self-interest to do a good job there because the same user account used to access eduGAIN services like eduTEAMS is also used by the users to access organisation-internal services like student enrollment or sensitive internal staff web services. | |
| Implementation Time | Designing an robust and scalable architecture to facilitate online collaboration within a research community takes quite some time and experience. Often research communities are good at their field of research but less knowledgeable when it comes to design, develop and operate IT architectures. Therefore, doing this on their own, a research community might need quite a lot of time that it typically does not have in case the research project lasts only for few years and researches would like to start working together right from day one of the project start. | With eduTEAMS a research community can rely on a solution that was designed by experts in their area who have several years of experience and who have helped build the underlying infrastructures (e.g. eduGAIN) and software (SaToSa, Discovery Service). Relying on this knowledge and the already available infrastructure that was custom-tailored for the needs of research communities saves a considerable amount of time. | |
| Scalability | Adding more applications to be used in research community in the worst case requires managing yet another set of identities or it will require this application to be connected to the central user directory of the research community, which might be easy to do but will require users to enter their password yet on another web service. Also, collaborating with users from other research communities and maybe accessing their web applications is not easy to configure. | Adding an additional web application to a set of applications used by a research community is relatively easy and scales well. Collaborating with users from another research community (e.g. to grant them access or get granted access on a shared application) is relatively trivial as each service can define its access control independently and in a very flexible but powerful way if one of the popular SAML implementations is used. | |
| Costs | Deploying an own solution to enhance collaboration in a research community might seem very easy, just set up a wiki or some other open source tool and start collaborating. Starting small and simple is fine for only a hand full of people and very few services. The more people and services that have to collaborate, the more know how and work is needed to operate the services properly. This is costly and finding qualified staff to do this is difficult. It then might be tempting to outsource operation to an external company or use a free service (e.g. Google Apps). Both options have disadvantages when it comes to vendor lock-in and data privacy issues. Also, commercial services often custom-tailor their services for businesses that work differently than a research community and the larger the company the less they might be interested to add changes for their offering to make it more attractive for research communities. | eduTEAMS envisages a freemium model where the eduTEAMS Basic version is free for all research communities to try and use and the eduTEAMS Advanced version will then cost a bit, which is also to ensure its sustainability and further development in the long term. eduTEAMS is operated by GÉANT, a non-for-profit organisations which is owned and controlled by the European National Research and Education Networks (NRENs) that themselves are owned and/or controlled by the universities and research institutes in their respective countries or the governements. Therefore, offering services to education and research is GÉANT's main purpose.
|
...
| Criteria | Without eduTEAMS | With eduTEAMS |
|---|---|---|
| Ease of Use |
|
|
| Security | Credential (i.e. password) has to be entered on every service, which increases the risk of entering the password on a compromised service | Credential is provided on one login page only, the one of the user's home organization or (in case of the eduTEAMS Identity Hub) on a social network provider (i.e. Facebook or Google) |
...