Migrating to a Microservice Architecture

Interview with Martin Bundgaard, Chapter Lead at DFDS HQ in Copenhagen, Denmark

How DFDS is using development data to drive and monitor their migration from a monolithic codebase to a microservice architecture

DFDS, the Danish international shipping and logistics company is the busiest shipping company in Northern Europe. DFDS provides shipping, transport, port terminal services and logistics solutions to over 8,000 freight customers and more than 6 million passengers yearly. DFDS has 6,400 employees across 20 countries.

DFDS’s key goals are to limit the impact of activities on the environment, keep people and goods safe with secure jobs and good working conditions. To achieve their goals, one focus area is digital capabilities. For DFDS this is key to future success. Martin Bundgaard, Chapter Lead at DFDS HQ in Copenhagen, told us about their journey from a monolithic architecture to microservices.

“Are we making a distributed monolith or are we making decoupled microservices? It can be hard to see if just looking at the repositories. I find it clear to get information from CodeScene regarding this by using the change coupling”

Is the architecture aligned with the organization?

DFDS were aware of some problematic parts in their codebase, leading to difficulties when adding new features. Martin explains:

"Often, these files with already problematic code quality slowly increase in size because it is easier to add 20 new lines of code to a 4000-line file than to start a refactoring of the file. With CodeScene we have found it easy to overview if we are moving in the right direction or not."

Acting on these issues is a challenge. DFDS operates large systems that transport thousands of people every day; the company is a critical part of the infrastructure between countries. This means that their systems have to evolve securely without disruptions to their mission of keeping people and goods safe. Progressing by small, incremental and frequent releases is the only choice.

In 2018, with the goal of maintaining a high-performing development team while restructuring, DFDS set out to get teams and microservices organized around their business capabilities. This was a core strategic initiative to have a software architecture that allows for autonomous teams, enabling easy scaling, faster time to market and smooth onboarding of new developers.

“It is not just a gut feeling, but something we actively measure.”

Shifting from a monolith into a microservice landscape is a complex task.

Aligning development teams with capabilities is challenging and needs monitoring to make sure the effort is moving in the right direction. DFDS uses the CodeScene tool to provide this monitoring. More specifically, DFDS uses CodeScene’s architectural analyses to uncover unexpected team coupling, track implicit dependencies, and visualize the coordination needs between development teams. This makes it possible to measure how organizational patterns influence code quality and how they are linked to the software architecture.

CodeScene can help monitor the shift from monolith to microservices.

An example on how CodeScene visualizes implicit dependencies between teams and code.

Monitor new code with automated Pull Request Reviews

CodeScene is also integrated into the development pipelines where it reports valuable metrics automatically. This lets the DFDS development teams utilize CodeScene to ensure high quality in new code via the automated pull request review. Martin observes that:

“It is very hard to change code already running in production compared to changing it before it is merged into master. CodeScene informs our developers about undesired parts of the new code – and the recommendations are mostly met."

When they identify files with low Code Health, DFDS also use CodeScene’s Goals that allow them to make sure the relevant code is improving over time. They also use the Hotspot map to identify problematic areas and candidates for pro-active refactorings. Martin adds:

“From time to time we also use the offboarding analyses, so we have a good idea about what should be handed over and what the impact is of a developer leaving a project."

Our new microservices have a code health score of 9.7 out of 10

This process, with the help of CodeScene’s analytic feedback, allowed DFDS to successfully break down existing monoliths into smaller and more comprehensible components, and build a more maintainable system that is ready to respond to future challenges.

Martin also shared some impressive insights on their code health metrics.

"Our inherited monolith code base of our passenger system has a code health score of ~2-3 depending on what hotspots are active. We only have a few files with these low scores, but it is dragging the overall score down. Our new microservices have a score of 9.7. CodeScene is also helping us being at the high end of the scale."

Martin concludes:

"It is also evident that the immediate feedback given to our developers on quality when creating pull requests is lowering the development cost in the long run."

We want to thank Martin Bundgaard and DFDS for sharing this inspiring story! To read more about DFDS’s journey from monolith to microservices, check out:

About CodeScene

CodeScene offers unique insights into your software and is a quality visualization tool for code. Prioritize technical debt, detect delivery risks, and measure organizational aspects. If you’re interested in learning more about CodeScene, please reach out to

How a master-level Software Reengineering course uses CodeScene. Interview with Dr. Henrique Rocha at University of Antwerp, faculty of Science and AnSyMo

Interview with Dr. Henrique Rocha from the University of Antwerp

How a master-level Software Reengineering course uses CodeScene.

“An existing software can be very complex, understanding the software architecture and infrastructure well enough to contribute with changes can be very challenging.”


AnSyMo, Antwerp Systems and software Modelling, is a research group at the University of Antwerp investigating foundations, techniques, methods and tools for the design, analysis and maintenance of software-intensive systems.

Today, a large part of our world and society is shaped and steered by systems and software. More or less all devices and machines use software to some extent. Add to this all the organizations, businesses and enterprises that you communicate with on a daily basis that could not function without software.

One of the courses led by AnSyMo is the master course Software Reengineering. Find below an interview with Dr. Henrique Rocha about challenges with software reengineering and the goal of the course.

The goal of the course is to become acquainted with a broad selection of principles, techniques and skills used when reengineering existing software systems. For 2 semesters this course has used CodeScene in an assignment to restructure existing software.

What is a common challenge or pain point when restructuring existing software?
From my experience, the hardest part is what some researchers call the “entry barrier for contributors”. An existing software can be very complex, understanding the software architecture and infrastructure well enough to contribute with changes can be very challenging. Most often, new developers trying to contribute to open-source software feel discouraged as they don’t know where to start. From my observations, our students face similar problems when attempting to reengineer a software for the course.
How are your master-class students using CodeScene?

We suggest students to always start with CodeScene as it provides great insights on how to begin the restructuring project.

CodeScene is the recommended software for two topics, visualization and metrics. CodeScene provides several visualization options that allow the students to have a better overview of the analyzed software. The visualizations also help the students identify possible candidates for refactoring, especially the Technical Debt tab. Moreover, the complexity metrics and smells details on artifact-level shows the reasoning for the students on why such artifacts were marked as candidates for refactoring.

About how long does it take new students to get up to speed with CodeScene?
The learning curve for CodeScene seems very easy. We direct them in a lab lecture on how to use most of the Technical Debt tab, and to look at the complexity metrics. Most students tend to explore other features for themselves. But usually, after one lab session, the students seem more than able and comfortable to use CodeScene.
How does CodeScene complement other tools used in your master-class?
The visualizations options provided by CodeScene synergizes well with other tools. Moreover, I was impressed by how CodeScene has so many more features that complement tools for other topics. For instance, we use SonarQube in the lecture “Refactoring Assistants”. SonarQube shows detailed reports for code smells, often too much detail. CodeScene also shows potential refactoring targets and some code smells affecting artifacts. Therefore, good projects use both to justify their refactorings. As another example, other CodeScene features fall into the “Mining Software Repositories” lecture, complementing its analysis.

For readers interested in learning more about AnSyMo and their research on the increasing complexity of software intensive systems, there is more information here.

CodeScene is free for students, find more information about it here.

CodeScene is also active in an international research project with the overall goal of helping software teams strike a balance between increased development speed without sacrificing quality. Read more here or visit the project directly.