Decentralised institutions

[StefanJahnke]

I am wondering if the current implementation allows not only for multiple universities to host their manifestos on one common server, as is the plan in Sweden but also if there is a possibility to have different manifestos per institution.
As described in the Desk Research, we currently see a trend for decentralisation of the IROs. We expect that different faculties might want to implement different APIs and are most likely also in need of different APIs as they use different IT systems from faculty to faculty.

[wrygiel]

Yes, every institution can have a manifest of its own. Manifests' model is very customizable.

[wrygiel]

Actually, in Poland all HEIs have separate computer systems. And each of them will be serving APIs of their own, and probably in slightly different versions.

[wrygiel]

Oh, wait. I have just read it again and just understood what you meant:

We expect that different faculties might want to implement different APIs and are most likely also in need of different APIs as they use different IT systems from faculty to faculty.

So, the answer is "not really". The HEI itself would need to cope with such inconsistencies. That is, the HEI would need to implement an additional proxy and forward the requests to both implementations of their mobility systems.

[georgschermann]

among our customers we have some consortia and loosely coupled HEIs, but all of them have a shared IT infrastructure, so they would most probable be able to use a proxy to distribute the requests or even to handle them directly.
for different API implementations / missing APIs the error responses should work well, eg: 501 Not Implemented, but could lead to confusion if one request is answered by one faculty correctly and the next one yields an error by a different faculty, but on the same endpoint

[wrygiel]

for different API implementations / missing APIs the error responses should work well, eg: 501 Not Implemented, but could lead to confusion if one request is answered by one faculty correctly and the next one yields an error by a different faculty, but on the same endpoint

In this case, perhaps it would be safer to publish an API only after all faculties have implemented it?

E.g. In case when some faculties implement API X in version 1.2.3, and other faculties implement the same API X in version 1.3.0, the institution's manifest would mention the 1.2.3 version only. If some faculties didn't implement API X at all, then the manifest wouldn't mention this API.

Alternatively, we could attempt to add support for such unit-level diversity in our APIs (or manifests). I'm not sure yet, but I'm afraid that would make the implementation complicated for the clients.

[georgschermann]

I also think the most feasable solution would be to stay with one manifest per HEI and let them decide how they handle the requests and what APIs they expose

[wrygiel]

I believe we can close this issue then. @StefanJahnke, are you satisfied with these answers?

[StefanJahnke]

I am happy to adhere with the initially proposed solution. I think it's important that we understand that this decision will have an impact on the usability on the Network though.

During the Desk Research, a trend towards decentralised Erasmus+ management has been identified. This implies different IT systems in most cases.

The current architecture would work in thus far that a faculty that would want to join the EWP Network would have to set up a central discovery manifesto, implement their respective APIs and be responsible for implementing an interface for possible other faculties to join.

Possible challenges that could imply are:

• Individuals that want to implement APIs on faculty level might not necessarily have the political competence to publish a centralised discovery manifesto
• The implementation of a centralised discovery manifesto and the management of the interface might be difficult to coordinate in case of decentralised Erasmus+ coordination. The university would have to set up a centralised management 'board' or give certain competences back to a centralised body (which might not exist)
• Lack of implementation of a proper interface at the university by the first faculty involved in the EWP Network might create difficulties for other faculties to join the Network

These are of course all assumptions but I wanted to lay out some of the possible consequences that a technical decision early on the the EWP architecture can have on the political level at an institution.

[wrygiel]

Side note: the proper word is "manifest", not "manifesto". As described here:

manifest - (...) (computing) A file containing metadata describing other files.

[wrygiel]

These are of course all assumptions but I wanted to lay out some of the possible consequences that a technical decision early on the the EWP architecture can have on the political level at an institution.

Understood! This thread will stay here and you can blame us for this if need be :) We currently judge the advantages of our current approach outweigh the disadvantages you have mentioned.

[StefanJahnke]

I am just here to give advise. You are the experts on the technical issues, so I trust that you taking the right decision.

By the way, thanks for the remark manifest - manifesto and apologies for the the mistake.