An intermediate analysis of the IIA management: problems and model review

[demilatof]

If you are in a hurry, this post analyzes the problem; you can skip to the next post to read my proposal.

Introduction

After months, almost a year, that we are stalled on several questions without any new release, I think it's necessary to go a step back to investigate the reasons of this immobility. There is no doubt that a centralized management of the IIAs would have been better, easier and faster. Unluckily now we are on the master-master model, so it would be a waste of time to discuss about the benefits of a centralized management.

Currently we have a lot of changes to introduce that are still suspended, even if some of them should be apparently trivial:

• academic years without holes inside
• modification
• termination
• termination as a whole
• delete
• changes in IIA IDs mapping
• hash code
• version upgrade
• approval of changes after the first mutual approval
• data returned by the approval API

And I'm sure I'm forgetting something. I think the main reason is that every change increases the complexity of the controls not only ad system level but at IROs' level to compare and constantly ensure that the two copies are always aligned, so that they can be mutually approved. If an IIA is simple, made up of only a mobility, we might not see any problem; but as soon as the number of cooperation conditions increases, we fall in trouble.

Let's see a scenario.

The negotiation before the two partners expose their IIAs via EWP

Since an IIA available in EWP must be ready for approval, two partners have to agree on the content outside EWP before sharing it:

1. A writes only its incoming cooperation conditions (CCs), because to write it outgoing cooperation conditions it needs to know B's CCs
2. A communicates its part of the IIA to B
3. B writes its incoming CC and transforms A's incoming CCs in its outgoing CCs
4. B communicates its part of the IIA to A
5. A now knows B's incoming CCs, that it can transform in its outgoing CCs

Note: I used green for "Student Mobility for Studies" CC, light purple for "Student Mobility for Traineeships" CC.

This is the optimal scenario, when A and B don't need further exchanges of communication. (If there wasn't EWP, most probably their activity would end here.)

Now both of them have a full copy of the IIA to expose on EWP

Tasks to be performed via EWP

Once they have their own copy of the IIA, they have to compare them to check that they are really the same. And here the problems start, because there is no order in CCs; therefore, what A has to do is (for B it is the same):

• A's IRO has to identify what B's IIA corresponds to it's IIA (it they are partners for more than one IIA)
• Then, A's IRO has to check over its CCs outgoing and B's CCs incoming to find the match, because they have no identifier or order; it can be easy if there is only a type of CC (e.g. student traineeship), but it can be complex if there are three or more CCs of the same type (e.g. student study)
• A's IRO has to do the same, swapping incoming and outgoing: he/she has to check that B's has written, in its copy, the exact outgoing CCs as the A partner has written its incoming CCs

Only after these tasks, A can approve B's IIA; B has to do the same, checking that A's outgoing CCs are well written according B's will expressed by means of the B's incoming CC.

Whenever there is a change, each partner has to perform again all these steps to check (zero trust) that when B makes a change in its incoming CC it doesn't introduce a change even in its outgoing CC, because if A doesn't realize the second change (in B's outgoing CC), approving the IIA, A also approve the change in B's outgoing CC; and this means that A has approved a change in its incoming CC, because the outgoing CC of one partner is the incoming CC of the other partner.

It doesn't matter if A's copy doesn't have the same value in its incoming CC, we have a break point that can drive to discussions.

I think this is the main reason we have difficulties to introduce new functionalities, because every new functionality increases the need of controls by IROs.

And this problem arises because we have introduced EWP where the IROs task should have been completed, that is at the end of the above section "The negotiation before the two partners expose their IIAs via EWP".

With the current master-master model, we want that the two partners keep two different physical copies of the same IIA and we want they constantly ensure that the two copies are identical. And we impose these duties even for those parts of the IIA (outgoing CCs) where there should be no difference in a perfect world, because they can be decided only by one partner and fully accepted by the other one (after a bit of negotiation outside EWP).

In my opinion, we have to rethink the EWP model if we want to speed up the IIA management, and we have to do in the best way to save all the mutually approved IIAs.

In the next post, I'll try to explain my proposal.

[demilatof]

First of all, this is my view as a developer who has analyzed how an IIA is realized; I still have to share my idea with my IROs.

My proposal comes from the question: "why I have to constantly check that my partner has correctly filled in its outgoing CCs copying my incoming CCs?" As I explained in the previous post, it's a useless task, a waste of time and a great overload of work for IROs and developers.

In my opinion, we need only to expose our incoming CCs, that describe the availabilities of our HEI for the incoming students (after a bit of negotiation with our partner outside EWP). If the partner accepts that set of rules, it can organize its outgoing mobilities as it would like, given that it respects our set of rules for incoming CCs. And we have to do the same, with our partner's incoming CCs (after we have approved them we can organize our outgoing mobilities without informing it of the details).

It's really easier, we don't need anymore that there is a cross correspondence between CCs. If we like the rules inside the partner's HEI, we approve them. If our partner declares to accept 4 places for EQF=6, 7 we can organize our outgoing mobilities as we think it's better for our organization, and for example, select only 4 students with EQF 6 (and not 7). And we can even suspend the selection for outgoing students in case of necessity (pandemic, war and so on) without the need to communicate our new outgoing CCs to the partner and asking it for a new approval. We have no more the necessity to expose our outgoing CCs to the partner and ask its IROs to check and approve them (with all the problems I described in the above post).

An IIA is still mutually approved when I approve my partner's incoming CCs, and it approves my incoming CCs. This is enough to have a full IIA, where the outgoing part is an internal matter that has the only duty to respect the partner's incoming CCs.

Please notice: I have approved my partner's incoming CCs. If later I try to send more students than that I approved to send (its incoming CCs), my partner can deny to accept them when there are nominations, just replying me "you have approved my incoming CC rules, now you're infringing them

What we still need:

• The hash code (with XSLT to uniform it)
• The mutual approval

What we don't need to do anymore in the EWP framework:

• Associate our incoming CCs to the partner's outgoing CCs
• Associate our outgoing CCs to the partner's incoming CCs
• Check before an approval that our outgoing CCs are exactly the same of the partner's incoming CCs
• Check before an approval that our incoming CCs are exactly the same of the partner's outgoing CCs
• Specifying the sending-hei-id and the receiving-hei-id inside each CCs, because we have only incoming CCs (receiving-hei-id); the receiver is the HEI-ID of the first partner of the IIA element; the sender is the second partner of the IIA element.

Extra benefits:

• Single approval: if our partner modifies its incoming CCs, once we approve its own updated IIA we have a new valid mutual approval with our old IIA, because we have not to change our outgoing CCs according to its new incoming CCs; and therefore we don't need to ask it for a new approval. And vice versa
• Termination: if we agree to terminate a CCs before its natural ending, we have only to approve partner's new CCs, without modifying our outgoing CCs and ask for an approval (we need a new approval only if we decide to anticipate, in our turn, the termination at our institution).
• Negotiation: thanks to an easier model we can introduce some of the facilities previously discarded to use EWP to negotiate an IIA.

As concern the last point, negotiation, we can:

• Add the CC ID without the need of mapping
• Add the status of the IIA ("draft", "ready for approval", "retired"; all of them available if the IIAs are not yet mutually approved)

Have we to throw away all what we have done until now? Not at all, we could even don't need a new version if we decide to accept to keep some elements that now are mandatory, but with the new approach would become useless (sending-hei-id and receveiving-hei-id). Thanks to the XSLT we can compute the new hash code only on the incoming CCs (the one that have receiving-hei-id=hei-id of the first partner of the IIA) and we can ignore the other CCs, that we can keep or discard progressively. Doing so, the approval will take into account only the incoming CCs.

If we wish, we can summarize this principle as "My home, my rules"

[georgschermann]

one issue which arises, when the outgoing part is omitted is, that the approved IIA is not complete anymore, and the approval is not linked to both sides of the IIA. you have 10 out 10 in students, you want 5 in 5 out both sides change to 5 in, one approves, the mutually approved IIA is 10-5 until the other side approves

[demilatof]

one issue which arises, when the outgoing part is omitted is, that the approved IIA is not complete anymore, and the approval is not linked to both sides of the IIA. you have 10 out 10 in students, you want 5 in 5 out both sides change to 5 in, one approves, the mutually approved IIA is 10-5 until the other side approves

Why do you think this is a problem? To be valid, the first time an IIA must be approved by both sides; the following changes should not be too different from the first approval I received, that I claimed to be able to honour. What I should be interested in, is to be sure that if I need a change in my organization, it is approved by the partner; that is, if I cannot receive 10 students anymore, but only 5, my partner accepts this change. If this is my need/request, I'll wait for giving an approval until I will receive the approval from my partner. Once I have received the approval, I give my approval too.

Of course, I can be a really unfair and not giving the approval on my turn, but I could loose a partner for the future. And I don't make a disaster in his/her organization anyway, because I was the one with the need to lower the number of places, not him/her. The change proposal comes always from a part, originally.

If we really need that an approval is given on the same couple of incoming CCs, we can introduce the hash codes in the IIA, in the second partner section (my IIA is bound to your particular IIA). Doing so, when we approve a partner's IIA, we approve a particular IIA that is tied to a given IIA of ours.

But if we are afraid of this situation, we should need to introduce the hash code in the partner section already now, with the current model.

[JoepDemey]

I totally agree with this proposal to split IIA's and make each hei owner of his incoming part, as in fact I already proposed this in the chat of an infrastructure forum, but it got lost in the amount of text in those chats.

I would also like to point out that the way OLA's are handling change proposals and the reactions (accept/decline) are better in my opinion than how it's done with the IIA's. In an OLA, you don't need to make a snapshot whenever you want to make a change and keep that snapshot to go back to in case the new chnages are not accepted, because both the accepted version and the proposed changes are all in the one version of the OLA. I would love to see this in the IIA too: split the cooperation conditions into accepted CC's and proposed CC's, with a response to either accept the change proposal or decline it.