Big-picture thinking in software development: a look at the working world of Carsten Hoffmann

Skip to Content
Current language English
  • Deutsch
  • English Current language
  • Article: Big-picture thinking in software development: a look at the working world of Carsten Hoffmann

    Software architects keep an eye on the big picture and choose the right solutions and structures to achieve an ideal long-term basis for software projects. Today we meet Carsten, who is a developer as well as a software architect.

    Or, as he likes to describe himself, "a member of the DevOps team who creates architectures". A bit of a mouthful, perhaps, but it hits the nail on the head. Although Carsten is first and foremost a software developer in a product team, he is also responsible for the architecture of the software that is developed. Having joined DB Systel six years ago as a software architect, he has been working as a developer with architectural duties in a DevOps team for a good two years now. Carsten is a direct colleague of Danny and also works in the "Platforms for New Mobility" team, where he is helping to develop "Curbside Management", a solution for the unified management of micromobility solutions such as rental scooters for municipalities.  

    What do software architects do? 

     Carsten describes the architecture of a software system as "the things that can no longer be easily changed". Software architects decide which frameworks and solutions are the best match for the project requirements. They identify existing solutions and determine how they interact with each other. And they make the fundamental development decisions that are necessary to ensure that all components work together perfectly and that there are no technological dead ends. A key goal of architectural work is ensuring that the solution developed meets defined quality targets. The architecture also defines the hierarchies of the software components.  

    "We organise ourselves – not because someone says we have to – but because we feel responsible for our software. And we're doing a good job."

    On the one hand, Carsten is a typical software developer. But he also keeps the big picture for the application in mind at all times, asking questions like "If we have 20 services, how do we ensure that they all work together?" He favours a hands-on approach and does not see himself as pure software architect drawing theoretical technology constellations on PowerPoint slides. As he says himself, "The architecture doesn't really make an impact until you get into the implementation." 

    In everyday working life, Carsten's tasks vary depending on the current phase of development. During implementation phases, he is busy coding, testing and planning with the rest of the team. In the case of new requirements in particular, he also makes sure that interfaces are documented and that the system solutions used help to fulfil these requirements. New project requirements usually come either from tenders or from within the team. Since the team works according to agile principles, the phases alternate frequently. 

    As a member of a DevOps team, Carsten is also jointly responsible for the operation of the application. Ideally, every member of the team should know everything about the product in order to remain up to speed in terms of operation and support. "We have an operational responsibility because we run our product ourselves," says Carsten. For example, there is always someone in the team who is an alternating contact person and DevOps supervisor. Any vulnerabilities, for example, must be rectified within 48 hours. This is something that the team needs to take into account when organising itself. 

    In two minds: how Carsten ended up at DB Systel 

    Carsten originally studied chemistry. While he was still a student, however, he realised that he found the subject of chemistry more interesting than the actual profession of chemist. That's why he switched to computer science and completed his master's degree in this subject. Meanwhile, he had already gained some initial experience as a developer. After graduating, Carsten worked in a development team for a media database provider, where he was appointed team leader. He and his team were responsible for software integration in customer projects. In practice, this almost always involved interfaces and system integration of the application into the customer's environment.  

    "I had never thought of Deutsche Bahn as an IT company. But after half an hour of conversation, I had changed my mind."

    Carsten came to DB Systel through a headhunter. DB Systel? He had never even heard of it at the time, he says looking back with a laugh. He remembers initially thinking "Deutsche Bahn is probably not for me." But after a half-hour phone conversation, he had completely changed his mind. The combination of cloud strategy, systematic transformation in the direction of agile working and a positive attitude to people pushed all the right buttons and was too enticing to ignore. 

    To look after the architecture of software solutions in a company, the main thing you need is a good overview of relevant tools and technologies, advises Carsten. In addition to this overview, Carsten relies heavily on the Kubernetes container environment for his role in the DevOps team, using it to address issues about how to secure the code and about the container specifications in the company. The team's many deployments of minor code changes only work with a lot of automation and a high level of test coverage. 

    Total commitment to standards and open source code 

    In addition to his core tasks at the company, Carsten is very active when it comes to the issues that matter to him. This is why he is a member of the "Architecture Guild", a committee that looks after IT standards in the company on behalf of management. It creates architectural standards for cross-team issues and improves the quality of architectural work through methodological initiatives. Extensively integrated throughout the company, the guild is a central point of contact for architectural issues. The Architecture Guild also maintains the DB Systel Techradar, which is technically based on the well-known AOE Techradar.  

    Screenshot DB Systel Github
    Screenshot DB Systel Github
    Screenshot DB Systel on GitHub

    He is also involved with the "Inner Source" team, which works to make internally generated code usable and available to everyone within Deutsche Bahn. This represents a starting point for an internal open source policy. It also helps to establish standards and save everyone else time, money and effort. The DB Group already has its own inner source licence and is developing its own GIT (source code management software) with usable code under this licence. Carsten is also responsible for maintaining an open source project in the DB Systel organisation on GitHub: the Trivy Vulnerability Explorer

    Would you like to help drive the digitalisation of the railway? Find suitable vacancies in our job portal

    This might also interest you