How do you unify five systems without replacing them?
In a company with 1,200 employees across several sites a business trip went through five desktop applications, one per purchasing channel, with approval to be requested inside each one. Instead of replacing them, an API layer was put in front: it receives the calls from the app and talks to the five, which stay where they are.
In an industrial group a business trip went through five desktop programs, one for each purchasing channel, and approval had to be requested inside each of them. That is 1,200 employees across several sites.
Why the five programs are still there
The short road would have been to redo everything in a single system. We did not take it: those five programs worked, and they were tied to suppliers and contracts that we would have had to redo along with them.
The cure was an API layer in front. It receives the app’s calls and routes them to the right program. The five stay where they are, with their suppliers and their contracts.
What the people who use it see
Three things, and none of them is a screen:
- access with biometric control, because a password typed on a phone while travelling is a point where a process stops;
- notifications, instead of opening a program to find out whether there is something to approve;
- a look that changes with the company role: the features and data shown are different for those who request a trip and for those who approve it.
Identity, before any screen
In that project one thing came before everything else: understanding where the identity comes from for whoever opens the app, in a company that kept its access rights on several directories and on a Windows stack.
Until it is clear where the identity of the person opening the app comes from, you cannot decide what that person sees and what they can approve. It is work that shows in no screen, and that decides whether the screens can exist.
The questions to ask a supplier before giving them access to systems and directories are collected on the page about how we work with enterprises.
Where the work is, if not in the app
A job like this is designed as a custom management system for a reason that lies outside the app: in the five systems that stay underneath, in the directories that say who is who, and in the fact that none of this is configured from a panel.