The Erasmus Without Paper (EWP) initiative promises Higher Education Institutions (HEIs) to exchange information in the context of student mobility swiftly and securely. To do this, it uses digital technology to pave the way to manage mobilities more efficiently. But what does this mean? And how does it work? Let's look under the hood of the EWP Network at one of the core components, the so-called Application Programming Interfaces, shortly referred to as APIs.
How do APIs work?
APIs are mechanisms that enable two software components to communicate with each other. Compare it with how you order in a restaurant. To order food from the kitchen, you rely on the restaurant staff. They provide the menu (with the available food and beverages), you use them to request your order from the chef and they deliver your order at the table. Behind the scenes “data” is exchanged between you and the chef.
This is similar to how APIs collect and provide data between two systems. You request data from the EWP network, or use the API to send data in the form of an interinstitutional agreement (IIA) or learning agreement (LA) to another HEI / user that is connected to the network. In this case, all systems can communicate with each other via the EWP network. Developers implementing your mobility software need to connect their system to the system of your partners using APIs.
For this to work, it is crucial to share the information in a “common data structure”. This is because it allows sharing data that all systems can recognise and translate it back to their own data structure. Imagine a mobility that starts on the first of May 2023. One system may use the dd/mm/yyyy format for dates while the partner is using mm/dd/yyyy. The difference in format entails a difference of 5 months for the start of this mobility: 01/05/2023 vs 05/01/2023. How is this done? APIs use a set of definitions and protocols to make sure they “speak the same language” and share information in the same format.
API specifications
The EWP Consortium provides the API specifications, which describe what data should be exchanged and what actions are required from the partner to be able to work with a specific data set (for example, the API specifications are different for the IIAs and LAs API). It is up to the organization managing the local software (this can be a third-party provider or your university's IT department) to develop the business processes on what should happen with the data retrieved via the EWP network. This is part of what is called ‘the local implementation'. To make sure the processes are tailored to the needs of its end users, development teams providing the mobility software should cooperate closely with the International Relations Office (at a central or faculty level).
To optimize the exchange of data, some important decisions are made at network level. For example, in case of the learning agreement (LA) it was decided that the student and the sending HEI should first approve an LA before the receiving HEI can either approve the LA or reject it with comments. These decisions impact which data is exchanged and what actions are required from the partner for that specific process (IIAs, or LAs).
API: governance
The impact of such decisions taken at the level of EWP cannot be underestimated. That is why there is a chain of actors involved in the design of APIs. First, there is the development team of the University of Warsaw who are responsible for the API specification. They rely on DG Education and Culture for the main programme document templates (determining what information is required). Secondly, there is the Business Process Owner forum who are specialists when it comes to mobility processes. A third important actor is the Infrastructure Forum where developers discuss several design options. Many discussions are also happening online via the GitHub forum for developers. In all these discussions the European Commission takes part as well.
Changes to existing APIs that are already implemented by many HEIs and software providers, are to be avoided as much as possible. For each change in the API everyone using these APIs need to modify their implementation, resulting in a lot of work and potentially new errors. Changes are only considered to add new essential functionalities and improve the mobility process. An example of an idea that is currently under discussion, has to do with the possibility to change an existing IIA (which is not possible now). To make that possible, developers are examining the best technical solutions to modify approved agreements. In the near future, such functionality will be rolled out, both at the level of the network and at the level of the local implementation.
Now how can you participate in these discussions? First of all you can join the Business User Groups and share your suggestions via this channel. Secondly you can suggest a change or improvement via the ESCI Service Desk. And finally, you can also get in touch with your development team who can bring up issues via GitHub or at the Infrastructure Forum.
Join the business user groups and follow us on LinkedIn and Twitter for regular updates.