How Space International is using Port to track DORA metrics

The challenge

As it began to scale, Space International wanted to change its approach to software engineering to help its 100+ developers – including backend developers, frontend developers, data ops and data engineers – to work more autonomously and efficiently.

Across numerous teams and departments, the company’s developers were struggling with a lack of centralized information. They had been using a Wiki to store information about services including documentation and ownership – but this required significant manual input which was error prone and frequently not updated. Without real-time access to these insights, on-call engineers struggled to diagnose issues and manage incidents quickly, managers were not able to measure performance accurately, and leaders were not able to make data-driven decisions. This led to delays and inefficiencies across the board.

As the organization was in the midst of a modernization program from a monolith system to microservices, it needed a way to bring all of this information into one place as the number of services began to proliferate.

A second challenge that the organization faced was that it was encumbered with a lot of manual processes such as ticketops which created bottlenecks and increased frustration among developers and DevOps. "We implemented bots in our Microsoft Teams channels so that JIRA tickets can Automatically created or updated," Levan Elerdashvili, solutions architect at Space International explained. “While this streamlined the process of passing information along - it wasn’t solving the problem of streamlining technical tasks or automating the development team’s day-to-day jobs,” he added.

Developers also relied on manual processes for routine tasks such as granting repository access, managing deployments and handling alerts, which all caused delays.

Meanwhile, the engineering leads were lacking a way to keep track of everything that was going on – from engineering metrics to standards compliance – and they were also unable to provide different developers with the information they needed, tailored to them.As a result, Elerdashvili said that the company piloted a number of internal developer portals on the market at the time - including open source, open and rigid commercial offerings.

“We were looking for a smart tool with a lot of possibilities for integrations and a tool that can enable us to create scorecards and self-service actions,” he said. After a comprehensive evaluation process, Space International chose Port due to its extensive integration capabilities, ease of use and flexibility.

“We chose Port because it’s a very smart, intuitive tool. It doesn’t require the same resources as open source alternatives; you need minimal technical expertise to start building integrations,” said Elerdashvili.

The implementation

Establishing a software catalog as a foundation for dashboards and scorecards

To begin with, Elerdashvili wanted to establish a software catalog in Port; bringing together information from the organization’s entire software development lifecycle. This would allow developers to easily find all the relevant information about services, including ownership, documentation, and metrics, in one place.

Port’s extensive integration support allowed Space International to connect with various tools - including SonarQube for code quality metrics and Sentry for application performance monitoring and error tracking. 

The organization is also assessing how it can drive better standards through scorecards. One of the key areas that the team is keen to have visibility on is with engineering metrics. Space is currently deploying multiple times per day, with a lead time for changes of five days-  but it wants more visibility over these metrics.

The organization will be using Port’s built-in Insights capabilities to get this visibility over DORA metrics and other metrics, using historical data and line charts. It will then extract this data to generate scorecards. “The idea is to have scorecards for each team – meaning each team will have their own scorecards that they can view in their own dashboard on a daily basis,” said Elerdashvili.

The dashboards will consist of the microservices that are relevant for the specific team. “For example, one team can have 10 microservices and we’re showing them the relevant information about those 10 microservices by using Port to collate data from the likes of SonarQube, Sentry and Opsgenie and present it through dashboards,” said Elerdashvili.

The onboarding team owns eight services and their dashboard incorporates: a Git repository, Stryker, metrics, APM dashboards, an event catalog, Swagger, diagrams, SonarQube URL – and has metrics specifically for SonarQube coverage, number of code smells and number of duplicates.

By using these scorecards and dashboards, teams will be able to better understand the metrics that matter to them, their KPIs and how they’re progressing against their objectives. They can then identify approaches that can help to adjust any given metric using the portal – such as creating self-service actions, adding elements to the software catalog, or utilizing an automation.

Creating self-service actions and automations to drive autonomy

The second phase of building the portal will be about building self-service actions and automations.

Elerdashvili is sending out a version of Port’s survey to his team to understand which processes are causing the most friction – and then turn these processes into self-service actions or automations. This may include actions for deploying services, creating repositories, requesting access and giving permissions.

Currently, the team uses CI/CD to create a new repository in GitHub – but Elerdashvili believes one of the key issues is for developers to request access to repositories, and therefore this may be a starting point for a new self-service action. “Other ideas include automatically opening JIRA tickets from our alerts platform Opsgenie, or sending notifications in Microsoft Teams,” he said.

Internal developer portal surveys and training 

As well as getting feedback from developers through surveys to understand what to include in the initial internal developer portal, Elerdashvili will be training each set of developers on how to use Port. “We need to provide 100 developers with training to show them what the system can do,” said Elerdashvili.

Since beginning to work with Port, Elerdashvili explained that he has been impressed by the developments made to Port.