iBridge 4.0

iBridge as a solution has been in constant development since the late 1990s. The name of the solution has been changed on a couple of occasions as the focus of use has changed - from ERP-driven document production with eDoc, to processing and converting files and electronic documents with Xmap, and over to a more general "bridge" between systems and companies with iBridge.

However, we have always had the same underlying idea: iBridge should be a tool that can be used by consultants and developers at iSYS - in our own projects - but also by super users and technical personnel at our customers. The development of the solution will therefore naturally be both customer- and project-driven - in the sense that it will be expanded to solve real problems, rather than building in "nice-to-have" functionality that in practice will never be used.

The underlying technical platform has also changed, but here too in line with actual needs - both for our own operation of the solution and for the requirements and needs reported by our customers. In practice, this has meant that iBridge has run entirely on Microsoft Windows throughout its lifetime. This does not mean that iBridge has been static - it has constantly evolved along with the platform - from being a 32-bit service on physical servers, to today - where it is largely a matter of one or more 64-bit services on virtual machines.

But, of course, the development doesn't stop there, as the focus these days is largely on cloud solutions and container applications. In principle, it is perfectly possible to run today's iBridge in such environments. But, in practice, we still choose to break with the continuous development path we've had for the past 25 years, take a few steps back and rethink - focusing on simplicity and flexibility, while upgrading and streamlining the technical platform.

The really big gains with container applications are achieved when they are implemented so that each "container" can be easily upgraded without disrupting operations, and also holds as little static information as possible over time - and only works with clearly defined and delimited tasks. 

Another important factor, and again one that is easier to exploit when using container applications, is manual and automatic scaling of a solution in line with demand. iBridge has long had support for running both multiple tasks in parallel, and also having several separate instances that have been able to communicate and work together. However, one thing has held us back: Dependency on shared resources - in practice, a shared database and shared files.

We are not abandoning the storage of data in databases, as this is of course an important part of a system like iBridge, but we are planning for the individual modules to be able to function autonomously - without directly sharing resources with the others, unless there is an explicit need for this. A simple example is that we should be able to import an electronic document in one format and then convert it to another format - without intermediate storage. If, during such a process, there is a need to store the data in a database as well, we do this, but as a separate activity - not as an integrated part of the entire process.

In practice, this means that iBridge as a product goes from being a relatively monolithic service to a "cloud" of microservices that talk to each other - either via a queuing system or via defined APIs. These services can be co-located, and we also provide a common system on top - so-called "orchestration" - so that we can create workflows as in today's iBridge. We're looking at Spring Cloud Data Flow as one possible solution to tie it all together. However, the architecture with microservices also makes it much easier for both ourselves and external integrators to use parts of the solution directly - e.g. by calling modules from external systems to process files or produce documents.

The loose connection between the individual services, and far less sharing of resources, also means that the system as a whole can be scaled during periods when there is a need for this - e.g. processing orders on days like Black Friday.

All in all, we look forward to offering old and new customers a system aimed at the future, but which will also be recognizable to existing users!