This blog deals with potential errors in projects focusing on the connection of two systems – i.e. the creation of interfaces. Starting with the question as to why individual systems need to be connected to each other in the first place: isolated systems only have a limited effect in enhancing administrative processes, as the cross-linking of data – within the boundaries of the law – is increasing constantly. Cross-organizational data exchange and services for the utilization of additional functions are frequent requests or requirements upon an originally isolated system.
Examples from the ECM and eGov environment are the connection to specialized processes or the interface to an ERP system.
However, the road to a functioning integrated interface is often cumbersome and anything but a walk in the park. The following passage deals with this topic and the five most serious mistakes that, from my point of view, can be made in interface projects, which, in a worst case scenario, could sabotage the project.
1. Inaccurate specification
At the beginning of the project the requirements seem clear: two systems are to communicate and exchange data with each other, each system working independently. One often forgets the importance of specifying all interface scenarios at the beginning of the project or before the implementation takes place: which use cases apply to the end users, how should the system react to system errors, etc.
2. Test environment not accessible to both parties
In many cases, access to the test system via a browser (the example shows web service call-up) is not possible for reasons of security. This can become a major stumbling block for timely implementation.
3. Focus limited to technical issues
When faced with the task of introducing an interface between two systems, there is a risk of focusing too much on the technical part while neglecting the sense and purpose of the interface and the user view. Hence, it is possible to successfully implement an interface from a technical perspective, even though successively failing due to lack of user acceptance. In such cases one should fall back on tried and tested implementations, such as SAP-Integration.
4. Individual system experts exist, but there is nobody with a complete overview
At the beginning of the project, those responsible as a rule know nothing about the respective adjacent application. In this situation, one person from the project team should be responsible for acquiring the necessary know-how concerning all systems used, including the interface technology, in order to ensure that someone in the project team has a complete overview. Ideally, this human interface within the interface project is the project leader.
5. No regular interface maintenance
As soon as an interface is up and running, everybody is happy and nobody ever looks back at it. The consequence could be that if the interface fails after years of usage, there is nobody around who knows how it works. Should this be the case, error diagnosis and subsequent repairs can become time consuming and expensive. In the Chamber of Commerce, for instance, there is an interface from the ECM-system to the heating management of all lecture rooms. By this means the lecture rooms can be heated immediately before the start of a lecture so that the participants don’t have to freeze even when outside temperatures are low. If one loses the overview of that system it could lead to cold feet for the participants.
The implementation of an interface should be meticulously planned, whereby focus should be placed both on the organizational challenges and the technical solution. If possible the integration should be made using a tried and tested standardized solution.
What are your experiences in introducing interfaces? Do the problems mentioned in the above sound familiar? Do you have any tips or best practises you would like to share?
No related posts.