Business Intelligence (BI) is essential to understand and improve the production of software-defined products, yet its application is still immature.
By building trust, involving engineers in defining metrics, and starting with small end-to-end use cases, companies can turn BI into a powerful driver of decision-making and continuous improvement.
Challenges
Software production is an engineering discipline — and great engineering is not only about what we build, but also how we build it. The way software is designed, developed, delivered, deployed, and maintained has a direct impact on customer value, organizational performance, and team well-being.
Many organizations already apply Business Intelligence (BI) to finance, marketing, manufacturing, operations, etc. However, its use in software production is still less mature — especially in industries like automotive. These companies may have hundreds of software engineers working together for long development cycles, often with other organizations, on complex software, tightly connected to hardware (software-defined products). which must be maintained for years.
Despite this complexity, many decisions are still made without proper data support.
End-to-end visibility
As software becomes increasingly complex, maintaining visibility across teams and processes becomes increasingly challenging. Decision-makers, development teams and individual contributors struggle to see the full picture. They often cannot confirm whether their decisions are consistently applied either. This is due, among other factors, to:
- The digital and intricate nature of software.
- The increasing difficulty of tracking processes as the organization becomes larger and more distributed.
As a result, decision-making at technical, product, and business levels relies on lengthy meetings, anecdotes, or manually created reports. These reports, often based on countless tickets, are time-consuming to produce, rarely analyzed, and quickly outdated, leading to inefficiencies.
The cultural challenge
The future of the production of software-defined products will be built by organizations that understand their software production systems as well as their environments, and develop the ability to continuously improve them. BI is the way to gain this understanding.
Why Software Engineers offer resistance to apply data analytics in this field?
Often, it is not the data itself they distrust, but the way it is applied.
In too many occasions, access to metrics is limited, unclear, or defined by others without involving the engineers or the target audience. Instead of analyzing the performance of systems, environments and processes, data is used to evaluate individual or team performance — creating fear rather than improvement. This fosters a culture of blame rather than a culture of learning.
Too many engineers do not trust data analytics applied to their work. Or, in better words, software developers do not trust the organization applying data analytics to their work. Too often, access to metrics is limited and unclear They are defined by others, not by them.
Metrics and data are used to analyze people’s performance instead of the production system, environment and processes performance. Instead of helping, data analytics can make problems worse. It can create a culture of blame instead of one of continuous improvement.
BI is therefore not just a technical challenge — it is a cultural one.
To succeed, organizations must make analytics trustworthy, transparent, and relevant for each role. When engineers trust their peers, their processes, and the data, they see analytics as a way to learn and grow. For BI to work, metrics must be clear, easy to access, and co-defined with those who use them.
BI as part of the solution
When done right, BI is not just accepted — it is embraced. The solution is to build a BI strategy with transparency at its core. Teams and contributors should:
- trust the data,
- participate in defining metrics,
- understand how to use them, and
- receive support to integrate them into daily decision-making.
BI strategy
Many companies have started their data journey for software production. However, they often make common mistakes:
- building a “platform” too early, before addressing concrete use cases, or
- skipping descriptive analytics and jumping directly into diagnosing problems, which makes it hard to get actionable insights later.
A solid approach balances strong infrastructure with early, practical analytics, making BI part of everyday workflows.
Start small, but go end-to-end (a “walking skeleton” approach):
- choose a single value stream,
- measure its end-to-end performance and activity,
- co-create dashboards with the teams who will use them.
Build trust by explaining how metrics are defined and being clear about limitations. Involve engineers and technical leads in shaping reports. Connect analytics directly to workflows. Transparency, peer review, and open dialogue — proven practices in open source — should be an integral part of BI.
Support teams in using data first for decision-making, then for continuous improvement. Show the value of data through real improvement cases. Once the approach works for a few teams, scale it gradually, turning the data hub into a platform as demand grows.
Finally, remember that data analytics is a journey with five stages — data hub, descriptive, diagnostic, predictive and prescriptive. Skipping steps will be very expensive.
In future articles, I will explore these challenges further and present a more detailed BI strategy for software-defined product development.
This article has been polished using AI. The first illustration is made by ChatGPT and the second by Grok
toscalix 