The local public transport company is not a typically traditional public transport company if you look under the hood. They have a well evolved technical maturity and a clearly conscious IT and development department. This was not least noticeable when they discovered the recurring challenges they had when it came to their deployment pipeline. With several developer teams that worked at the same time and in slightly different ways it became clear that they needed to review their setup. An important part was to ensure that the company itself had full ownership of the technical solutions but without preventing the Devops methodology for the development team. Far from all companies would even identify these problems - not even pure development companies. The need for a robust, but flexible, solution was clear and that was when they turned to the team from adesso Sweden. A team that had already been working on projects with them before.
From Devops problems to developer satisfaction with Platform Engineering
How we improved the local Public Tranport company's development landscape
Methodology
Full independence is extremely effective during start-up of projects and means that a lot can be developed in a relatively short time, but the longer and the larger the project grows, the more challenges you face. This meant that the pace of development steadily dropped the further into the growing projects they came. The solution to the dilemma was therefore based on what is often called Platform Engineering, where the whole - the needs of the project and the development team, were weighed together. In order to maintain the speed of development even as a project or product grows, you need to create abstractions at the right level for the development team. You need a clear network structure and Governance Model. This approach focuses on delivering software as a product, which ensures that developer team can work efficiently and in a controlled environment, with just the right amount of freedom.
Platform Engineering is basically about providing the underlying tools, processes and platforms to enable developer teams to effectively distribute, run and monitor their applications. Instead of the fact that each developer team needs to keep their own distribution pipelines or monitoring tools in order to work efficiently, the Platform Engineering method delivers these functions as a form of standard services with basically infinte abstraction layers that enable both simple sets and detailed configuration depending on the development team's competence - and needs. Thus, it's extremely flexible - but absolutely controlled.
We identified several anti-Patterns in their existing devops setup, which included:
• Separated, individual developer teams that often worked isolated, which led to some duplication.
• Lack of shared tools, which causes inconsistency in expansion and monitoring.
• Fragmented communication between operations and developer team, which leads to inaccuracies and above all - inefficiency.
In order to maintain the speed of development even as a project or product grows, you need to create abstractions at the right level for the development team. You need a clear network structure and Governance Model.
Solution
To find suitable solutions to the challenges, the platform architects from adesso Sweden took several important steps:
“We introduced shared tools, Unified Tooling, which all developer teams could benefit from, which ensured stability over distributions and reduced duplication. Similarly, we introduced shared platforms; Instead of each team more or less having its own infrastructure set, we introduced standardized platforms that met the requirements of several teams. ”, Says Johannes, platform architect at adesso Sweden.
This not only made resources more efficient, but also reduced potential sources of error at the same time as the vital point - the company's complete ownership of the technical solution - could be guaranteed.
In addition to these technical changes, it was also made to improve communication between Operations and the developer teams, and also between the teams themselves. This would mean that there was a mutual understanding of goals and limitations, which leads to more adapted goals and significantly smoother implementations.