DB Schenker Finland

DB Schenker is one of the world’s largest transportation and logistics service providers, with over 91,000 employees working across 2,000 offices in 130 countries worldwide.

For many years, Proximity has developed, supported and maintained business-critical IBM i applications for DB Schenker across Europe, building a long-standing, close and mutually beneficial working relationship.

So, when DB Schenker Finland was looking for a company to not only support and maintain their domestic IBM i-based transport management system (TMS), Opera, but also to get involved in exciting ‘next generation’ projects, integrations and new IBM i application development, they came to Proximity.

The Challenge: A resource shortage for a legacy system

Developed in-house over many years, DB Schenker Finland’s Opera application is, unsurprisingly, their core domestic system, which covers their transportation operations, from route and load planning to proof of delivery through a PDA based app.

Orders come into Opera via EDI, from customers through their web booking portals, or from interfaces with other cross-border parts of the business.

A significant portion of the shipments are automated, as well as the majority of financial processes.

As with many businesses running IBM i applications, there has been a steady reduction in in-house IBM i development skills within the DB Schenker Finland’s internal IT team due to retirement and developers moving onto new roles.

Although Opera is still operating today – delivering an excellent, consistent and highly reliable service – with the reduction in internal skill sets, the business needed a way to supplement their internal IT team and ensure that Opera remained as relevant to the business as it did when first developed.

This meant not only simply supporting and maintaining the application, but being able to develop new interfaces between Opera and other third party applications.

A new system rollout – soon

There are approximately 26 operations across DB Schenker’s European business, with 17 of those countries using CIEL and the rest – including Finland domestic – using systems individually developed or bought for that country. Eventually, they will all be replaced with a smaller number of new systems.

While DB Schenker as a whole is currently developing new applications to replace CIEL for the European operational clusters to use both for cross-border and domestic logistics, the Finnish Opera system will need to continue operating beyond that initial rollout programme.

Having developed a long-standing relationship with DB Schenker right across the UK and Europe, Proximity was asked to provide maintenance and support services for Opera – and deliver new functionality and build the data bridges for exchanging information between Opera and other applications.

Proximity provides DB Schenker Finland with two IBM i developers to supplement their IT team on a day-to-day operational basis supporting development on both the API modernisation side and the RPG side.

Limited IBM i application architecture documentation

Once appointed, it was essential for the Proximity team to quickly get up-to-speed on the underlying application architecture and how it has been developed over the years.

Unfortunately, there was limited documentation – and the documentation they did have was in Finnish.

Although the need for thorough knowledge transfer was apparent, it was understandably not practical to manually write out reams of documentation translated into English.

As Anthony Whalley, one of our IBM i developers working on the project, says:

“We needed a solution to interrogate the application and produce that documentation on how the database hangs together, how the programs are using the database and the interaction between the programs”.

The solution? X-Analysis from Fresche Solutions.

Not only does X-Analysis help our team (and any new recruits) to on board and understand the underlying architecture of the IBM i applications we’re working on rapidly, it also provides documentation that the whole DB Schenker Finland and Proximity team can reference – even when the people currently working on the system have left.

“X-Analysis is referenced almost daily”, commented Anthony. “As an example, if I’m working on an integration with the driver PDA or on a new interface via AWS, I can use X-Analysis to add stability to the development process. Developers have been able to copy some existing data flows”.

Overcoming language barriers

Our team had to overcome another barrier in the onboarding process – the one of language. Rick Butler, Project Manager, picks up the story:

“Although we held a series of knowledge transfer sessions with the Finland team as part of the onboarding process, it was a challenge to find all the information necessary for us to start to support and develop the Opera application.

“Everything, from comments to program names to descriptions, were in Finnish. Add to the fact that the application itself is so large – with about twenty-five production libraries – just trying to find and remember which library certain parts of the source code were in was a challenge”.

With X-Analysis, on the other hand, all the application architecture is documented in one place and is easily accessible.

“We can look at one element of the application in X-Analysis and quickly understand what other parts of the application, or third-party applications for that matter, could be affected if we make a change in that file” explains Anthony.

“It is easy to know what each program is called and why they’re being called, and to find all the database files related to a single program. You can look at the object descriptions and immediately know what to search for to find the database files you need. We can find the relationship between a header and all the other files associated with that, and can easily find all the extra files and how they’re linked together.

“What’s more, as we’re is looking at both English and Finnish documentation, with X-Analysis, we don’t necessarily have to be able to translate a field name or a file name, we just have to know the key between the two database files, and X-Analysis tells you that information” explained Anthony.

“X-Analysis reads the RPG and works out your business rules and your logic for you. If, for example, it says to call a specific program or to read a specific file, X-Analysis knows that it’s a database file, because of the RPG code. If you then double click on that in the source, it will take you to that database file and show you all its details.

“As X-Analysis is only concerned with fields and code – it’s almost language-agnostic. It only displays whatever language object descriptions are programmed in, but you’re only looking at object names and relationships”.

Organising IBM i source code efficiently and analysing impact

As well as the challenge of overcoming language barriers, it was also apparent early within the project that being able to document, analyse and organise all the source code was going to be vitally important.

Once again, X-Analysis provided the functionality to be able to audit the application quickly and provide the required level of control over the source code, especially when third party developers and even new staff are involved.

Anthony explained more:

“At the start of the project, X-Analysis was used to interrogate the structure of the application, in terms of libraries and source, in order to rationalise the code, document and structure each library, and keep up with the latest versions”.

When the initial architecture was interrogated, it took X-Analysis two-days to fully analyse and document the application.

And, it’s still being used on a day-to-day basis even now:

“X-Analysis has proved invaluable in our daily project tasks”, explained Rick, “for example, when one of our team is making a change to the source code and – because they’re not the one who has been developing the system for the last 20+ years – they can quickly double-check the impact of that change. It leads to a structured, disciplined and robust development process”.

In order to increase that robustness, Proximity also deployed Remain Software’s IBM i change management tool, TD/OMS in the project.

Working in tandem, and closely integrated, TD/OMS source management capabilities ensure that any changes that are made are updated in the X-Analysis’ repository.

In large development teams, implementing TD/OMS can have a significant impact on reducing the likelihood of errors.

“Using TD/OMS for source management really helps to avoid mistakes by reducing the risk of things like developers making changes to the wrong version of the source code and, in doing so, reintroducing bugs that were fixed in other versions”, explains Rick.

“This is something that can all-too-easily happen when large teams of developers are working on an application without a change management system in place, as they may make changes in their own libraries without putting things back in the right place. It is one of the most frustrating issues to have to deal with”.

“Nobody hates a bug more than a bug they’ve seen before” explained Rick.

Deploying TD/OMS has also removed the majority of manual tasks in which mistakes are likely to happen.

“From the very start of any source code change, when a developer is retrieving source TD/OMS draws in any associated programs and files that you will also need to change, even right through to after the changes are done, which removes a lot of the manual work of promoting changes to test and eventually to production”, Anthony explained.

“What’s more, it’s easy to roll back a version rather than looking through a library to try and work out which source version you want to put back in. TD/OMS does all that for you”.

Through TD/OMS making concurrent development is also much easier.

“When we have a whole suite of programs that we’re changing as part of a big project, we can make some small changes or fixes to take one or two of those programs. With TD/OMS, we can do those side by side, get the small fixes into production, and then merge them back together – without having to manually recheck the source” says Rick.

“It allows the development team to be more confident of changes, because it’s done in a systematic way. We’re working on solid ground, to make an analogy, rather than working on a shaky foundation”.

Antti Annala, DB Schenker Finland’s Manager for ITM Land commented:

“TD/OMS brings important structure to the development process especially now we have both in-house and Proximity’s IBM i developers working with the same programs. X-Analysis has been invaluable in the project as it saves a lot of time when both teams have to check the facts”.

IBM i development tools working in harmony

X-Analysis and TD/OMS have both been integral to the continued success of the project.

“In the initial phase, X-Analysis tidied up all the source code. It gave us the ability to be able to list all the objects where the source was different to the actual data, so we could get that fixed quickly. Each of those mismatches is just a disaster waiting to happen: a bug waiting to be introduced” explained Anthony.

“X-Analysis ensured that the source was in the right place and that the right versions of the source for the objects were in the right place. Once the library structure is registered in TD/OMS, it’s hard to make changes to those libraries, so it’s good to get that stable ground.

We’re now supporting and maintaining around 30,000 objects in the X-Analysis libraries on behalf of DB Schenker Finland, which represents the very latest version of the source code”.