Configure instead of program
Pipelines are built in a graphical interface: line up modules, configure each one, done. New requirements are solved by adapting a pipeline, not by new development.
Many systems, one challenge
Processes have long run across systems. The data in between is usually still moved by hand.
From the quotation through technical design to risk assessment, people from different departments work in different applications. Each of them works well on its own. The effort arises at the transitions: master data is typed in, lists are exported and imported again, responsibilities are reconciled by e-mail. This work shows up in no report, but costs time every day - and a wrongly transferred field is often only noticed in production, in the quotation or in the audit, where the correction is expensive.
The usual way out is point-to-point couplings: a script here, an interface there. They grow with every system, and at some point nobody knows any more which of them does what. A system change breaks them.
tri.Hub puts a layer in between instead. A trigger detects an event, one or more plugins process and transform the data, the result is handed over fail-safe. Which system is source and which is target is decided by the pipeline, not the system: tri.Hub reads from PRO.FILE just as it writes into it, and wherever a third-party system's interface allows both, the same applies there. These steps are assembled in a graphical interface. New data source? Only the trigger is swapped, the existing logic stays.