-%20Survey%20Insights.webp)
Software architecture challenges in 2026 are not primarily caused by technology, but by gaps in prioritisation, measurement, and accountability. Many engineering organisations struggle to define success, evaluate architectural investment, and align decisions with business outcomes, which leads to increasing complexity and higher long-term costs.
To understand how widespread these software architecture challenges are, we surveyed 100+ engineering leaders at QCon London 2026. The results show that most teams are only partially aligned, rely on inconsistent metrics, and remain constrained by legacy systems.
In this report, you will find the full breakdown of their responses, the tensions the data exposes, and what the most accountable engineering organisations are doing differently.
Balancing software architecture and cost is difficult because both innovation and efficiency compete for the same limited resources. This forces engineering teams to make continuous trade-offs between delivery speed, scalability, and long-term system health.
The data shows that infrastructure cost is rarely the primary constraint. Instead, teams are more often slowed down by scaling complexity and the persistent impact of legacy systems.
Every investment in platform modernisation reduces capacity for product delivery. Every sprint allocated to architectural improvements is a sprint not contributing directly to roadmap commitments. The tension is real, but it is often intensified by how teams approach it. Many engineering teams rely on reactive and informal prioritisation rather than structured evaluation, which makes trade-offs harder to manage over time.
These patterns are clearly reflected in our exclusive survey of engineering leaders at QCon London 2026, providing a data-backed view of how teams experience this challenge in practice.
When asked about their biggest challenge in balancing software architecture and cost, responses were distributed across four key pressure points. This distribution is important because it shows that there is no single root cause. Instead, teams face multiple competing constraints at the same time.
These results highlight that the main challenges are not isolated technical issues. They are linked to prioritisation pressure, trade-offs, and increasing system complexity.
The largest group, at 34%, highlights the difficulty of prioritising architectural work against business ROI. This goes beyond managing technical debt. It involves deciding:
Without a clear way to evaluate these trade-offs, decisions are often influenced by immediate business pressure rather than long-term impact.
At 29%, many teams report difficulty balancing system stability with the speed of feature deployment. This reflects the ongoing pressure to deliver new functionality while maintaining reliable systems.
In practice:
Without a clear approach to sequencing architectural work alongside delivery, teams often delay structural improvements until issues arise.
Practices popularised by Google’s Site Reliability Engineering (SRE) model emphasise balancing reliability, scalability, and delivery speed as systems grow.
A further 26% of respondents identify managing design complexity as a key challenge. This reflects how systems become harder to maintain and evolve as they grow.
Design complexity increases:
This type of complexity is often not immediately visible. It accumulates gradually and becomes a significant cost driver over time.
Only 11% of respondents identify cloud or infrastructure cost as their main challenge. This suggests that for many organisations, cloud cost optimisation is not the primary constraint in software architecture decisions.
However, this does not mean cost is no longer important. Instead, it indicates that cost is often embedded in other challenges:
These costs do not appear directly in infrastructure spend, but they have a significant impact on overall efficiency.
In a separate question, 22% of respondents identified cloud architecture cost optimisation as an area with strong potential to improve cost-effectiveness. This shows that while infrastructure cost is not the main challenge, it remains an important optimisation lever.
The data suggests a shift in how cost should be understood in modern software architecture.
Teams that focus only on visible metrics such as cloud spend are measuring part of the problem, but not the full picture. The most significant costs are often structural and accumulate over time through:
These costs are harder to quantify, which is why they are often overlooked.
Key takeaway
Balancing software architecture vs cost is difficult because it involves continuous trade-offs between innovation, delivery, and long-term system health.
The data shows that:
To improve cost efficiency, organisations need to look beyond cloud spend and focus on how architectural decisions impact scalability, maintainability, and business value over time.
Most organisations evaluate software architecture investment informally rather than using structured, data-driven methods. This leads to inconsistent prioritisation and weaker links between technical decisions and business outcomes.
Based on our exclusive survey of engineering leaders at QCon London 2026, there is a clear gap between how architecture should be evaluated and how it is handled in practice.
The data shows that only a minority of organisations use formal methods:
Key insight: 75% of organisations are making critical architecture decisions without a structured financial or strategic framework.
The most common approach, used by 32% of teams, is prioritising based on delivery capacity. While practical, this leads to:
Similarly, 29% relying on informal estimation creates inconsistency:
At the extreme, 14% operating reactively means decisions are driven by incidents or urgency rather than planning.
High-performing organisations treat architecture investment as a business decision, not just a technical one.
This typically involves:
One widely used approach is Architecture Decision Records, which capture:
This creates consistency, improves knowledge sharing, and reduces repeated mistakes.
More mature organisations are moving towards continuous evaluation of architecture by:
This allows teams to maintain architectural integrity as systems scale, rather than reacting after issues appear.
The gap is not caused by a lack of tools. It is caused by organisational factors:
Key takeaway:
Most organisations have the capability to evaluate architecture investment more effectively. What is missing is the structure and consistency to apply it.
Understanding what blocks scaling software architecture is a critical concern for engineering leaders. Scaling challenges do not appear suddenly. They build over time as systems, teams, and processes grow beyond their original design.
As demand increases, systems that once worked efficiently become constraints. Processes that supported smaller teams turn into bottlenecks at scale. Early architectural decisions become harder and more expensive to change, especially as more dependencies are introduced.
Our exclusive survey data highlights clear patterns in what limits system scalability today. The results show that scaling is not driven by a single issue, but by a combination of technical and organisational factors.
Yes. 43% of respondents identified monolithic or legacy systems as the main factor limiting their ability to scale. This is the largest single barrier reported.
Despite years of investment in modernisation, legacy architecture remains a dominant constraint. Many organisations continue to build on top of existing systems rather than replacing them.
There are clear reasons for this:
As a result, legacy systems are extended rather than replaced. Over time, this leads to:
What starts as a short-term compromise becomes a long-term limitation on scalability and delivery speed.
While legacy systems are the primary blocker, other factors also play a significant role:
These findings show that scaling software architecture challenges extend beyond technology.
The data shows that it is both. Treating scaling as purely technical often leads to ineffective solutions.
Legacy systems are not just a technical issue. They are closely tied to:
Similarly:
This reinforces a key point. System scalability depends as much on organisational structure as on system design.
Modernisation is difficult because it requires long-term commitment and coordination.
Common challenges include:
Without clear ownership and visibility, modernisation efforts are often delayed or deprioritised. This allows legacy constraints to persist.
In practice, organisations that address these challenges early tend to scale more efficiently. In several of our case studies, we have seen how improving architectural alignment and reducing complexity leads to faster delivery and lower long-term costs.
The biggest blockers to scaling software systems are not limited to technology.
To scale effectively, organisations must address both system complexity and organisational capability.
Scaling is all about ensuring that systems, teams, and priorities
Software architecture is only partially aligned with business strategy in most organisations. Our survey shows that the link between architectural priorities and business outcomes is often assumed rather than clearly defined or measured.
This gap exists because alignment means different things across teams. In engineering, it often refers to system consistency and technical standards. In business, it refers to whether investments support growth, efficiency, or revenue. The disconnect between these perspectives is a key source of inefficiency.
Partial alignment is the dominant pattern. According to the data:
Partial alignment means some architectural initiatives are tied to business goals, while others are not. This creates uneven prioritisation:
Over time, this leads to:
Partial alignment also creates ongoing friction. Engineering teams invest in improvements that leadership may not fully value, while business decisions are made without understanding architectural impact. Because the misalignment is not absolute, it often goes unaddressed.
In high-performing organisations, alignment is intentional. It is supported by:
However, most organisations lack these structures. This is reflected in the data, where 21% of respondents say that executive sponsorship and clearer organisational strategy would most improve their ability to balance innovation and accountability.
Without this support:
This leaves engineering teams making decisions without full visibility of business direction.
When software architecture is not aligned with business strategy:
Research consistently shows that organisations which connect architectural decisions to business context perform better across delivery, reliability, and efficiency metrics.
Only 18% of organisations have strong alignment between software architecture and business strategy. The remaining 82% operate with partial or no alignment, which limits their ability to scale efficiently and deliver consistent value.
Improving alignment requires:
Without this, even well-designed systems struggle to deliver long-term business impact.
Measuring success in software architecture is difficult because its impact is long-term and hard to link directly to business outcomes. Without clear metrics, teams struggle to justify investment and prioritise effectively.
Our survey data highlights this gap. When 34% of teams struggle to prioritise architecture against business ROI, it suggests that many organisations lack clear, outcome-driven measurement.
Teams typically rely on four main approaches, each reflecting a different view of what success means.
This means that 1 in 5 organisations cannot reliably measure whether their architecture is delivering value.
Software architecture impacts multiple areas, including scalability, performance, and maintainability. These outcomes are often long-term and difficult to isolate.
As a result:
This creates a gap between technical performance and business value.
When success is not clearly defined or measured:
This reinforces the challenges already identified in the data, particularly around prioritisation and complexity.
Several established frameworks can improve measurement:
These approaches help teams move from subjective evaluation to consistent, data-driven measurement.
Established frameworks such as the DORA metrics, originally developed by Google, provide a reliable way to measure delivery performance and connect engineering practices to business outcomes.
Measuring success in software architecture is not optional. It is essential for prioritisation, investment, and long-term scalability.
The data shows that:
To improve results, teams need to adopt clear, outcome-driven metrics that connect architecture to measurable business value.
The greatest opportunity to improve software architecture cost optimisation is not reducing infrastructure spend. It is improving how architectural decisions connect to business outcomes.
Frameworks such as the AWS Well-Architected Framework provide guidance on balancing cost, performance, and reliability.
Our exclusive survey of engineering leaders shows that engineering leaders see cost-efficiency as a strategic issue, not just a financial one. The biggest gains come from better alignment, stronger capabilities, and more consistent architectural practices.
Yes. 34% of respondents identified better alignment between business strategy and the architectural roadmap as the biggest opportunity to improve cost-effectiveness.
This ranks above:
This is a critical insight. While cloud cost is visible and measurable, misalignment creates hidden costs across the entire system.
When architecture is not aligned with business goals:
Misalignment creates costs that are difficult to track but significant over time.
The most common impacts include:
Earlier data showed that 34% of teams struggle to prioritise architecture against business ROI, which reinforces how widespread this issue is.
26% of respondents identified upskilling in modern architectural practices as a key opportunity.
This reflects a clear pattern:
Upskilling improves:
As a result, it reduces both development and operational costs.
Only 22% of respondents identified cloud and infrastructure cost as the main opportunity.
This suggests that:
Cloud cost optimisation remains important, but it is not the primary driver of cost-efficiency in software architecture.
18% of respondents highlighted improving architectural governance and design processes as the biggest opportunity.
This does not mean adding more process. It means:
Without effective governance:
The most expensive architectural problems are often invisible.
They include:
These issues compound over time and affect:
The biggest opportunity in software architecture cost optimisation is not reducing spend. It is improving how decisions are made and how architecture supports business goals.
The data shows:
Organisations that focus on alignment, skills, and consistency achieve better outcomes than those that focus only on reducing costs.
The data in this report reveals a consistent pattern. Engineering teams are operating under pressure, making architectural investment decisions without clear structure, struggling to scale beyond legacy constraints, and measuring success in ways that do not always reflect business value.
This final section focuses on what engineering leaders say would actually help. The findings challenge a common assumption. Software architecture challenges are not primarily technical. They are driven by organisational, strategic, and cultural factors.
The most common response, selected by 43% of respondents, is improved cross-team collaboration and alignment on design standards.
This highlights a critical issue in scaling software architecture. Collaboration is not simply about communication. It is about ensuring that architectural decisions are made with full visibility across teams, systems, and business functions.
Effective collaboration requires:
When collaboration is weak, systems become fragmented and harder to scale. The data shows this is not a tooling problem. It is an organisational gap.
26% of respondents say that clearer frameworks for architectural prioritisation and ROI evaluation would have the biggest impact.
This connects directly to earlier findings. When teams lack structured ways to evaluate trade-offs, prioritisation becomes inconsistent. Decisions are influenced by delivery pressure, stakeholder opinions, or short-term goals.
Clear prioritisation frameworks help to:
Without these frameworks, software architecture cost optimisation becomes difficult to achieve.
21% of respondents identify executive sponsorship and clearer organisational strategy as their main need.
Executive support goes beyond approval. It requires active involvement in:
Without consistent sponsorship, architectural initiatives are often deprioritised in favour of short-term delivery.
Only 10% of respondents identify budget control and financial oversight as their primary need.
This reinforces a key insight from the survey. Cost is not the main challenge. The issue is how architectural investments are prioritised and governed.
Governance is often seen as a barrier to speed. In practice, effective software architecture governance reduces complexity and improves decision-making.
Modern governance is not about control. It is about clarity.
Well-defined governance provides:
When governance is clear:
The data suggests that most organisations do not have too much governance. They have too little of the right kind.
Effective governance should:
This approach supports scalable, cost-efficient software architecture without slowing down delivery.
The most important insight from this section is clear. Engineering leaders do not need more tools or more technology.
They need:
These are organisational capabilities, not technical ones.
Improving them is essential to solving software architecture challenges at scale and balancing innovation with cost effectively.
The survey findings point to a clear pattern. Software architecture challenges are not driven by technology alone, but by gaps in prioritisation, measurement, and strategic alignment.
Legacy systems continue to limit scalability. Architectural investment is often informal. Success metrics are inconsistent. And many teams lack the visibility and support needed to connect technical decisions to business outcomes.
This is based on exclusive data from QCon London 2026, reflecting the reality faced by experienced engineering leaders. If these challenges exist at this level, they are likely more severe in organisations with lower architectural maturity.
The key question is no longer what the problems are. It is what high-performing teams are doing differently.
The data highlights three behaviours that distinguish organisations where software architecture investment delivers measurable value.
High-performing teams make the connection between architecture and business results explicit.
Only 18% of respondents report full alignment between architecture and business strategy. These organisations achieve this through:
They do not assume alignment. They build it into how decisions are made.
Teams that succeed apply consistent evaluation to architectural decisions.
Around 25% of respondents use formal ROI calculations linked to business KPIs. This enables:
When evaluation criteria are clear, architecture becomes more predictable and defensible.
High-performing teams focus on measuring what matters.
Around 34% of respondents use outcome-based metrics to assess architectural success. These include:
The difference is not the volume of metrics, but how deliberately they are used. Measurement is tied directly to decision-making.
These behaviours reinforce each other:
Together, they create a system where architecture supports scalability, cost efficiency, and business value.
The main challenge identified in this report is not technical. It is an accountability gap between architectural ambition and the structures needed to support it.
Closing this gap does not require large-scale transformation. It requires consistent, practical changes.
Architecture should be part of business planning, not treated as a downstream activity.
This includes:
Organisations need a shared approach to evaluating architectural trade-offs.
This does not need to be complex. It needs to be applied consistently:
Consistency is more valuable than complexity.
Teams should define what success looks like before making architectural changes.
This means:
Common approaches include:
The specific metrics matter less than the discipline of measuring consistently.
The gap between average and high-performing architecture teams is not primarily technical. It is organisational.
The data shows that:
Improving software architecture in 2026 requires:
Organisations that apply these principles over time are better positioned to scale efficiently and control cost while continuing to innovate.
If you want to understand how your organisation compares, contact Imaginary Cloud to assess your architecture maturity and identify high-impact improvements.
We help engineering leaders align architecture with business goals, improve prioritisation, and build scalable, cost-efficient systems.
The biggest challenges are prioritising architectural investment against business ROI, balancing system stability with delivery speed, and managing design complexity. Only 11% of teams identify infrastructure cost as the main issue, which shows that most challenges are driven by trade-offs and decision-making rather than technology alone.
Balancing software architecture and cost is difficult because innovation and efficiency compete for the same resources. Teams must continuously decide between delivering new features, maintaining system stability, and investing in long-term scalability, often without clear evaluation criteria.
The main blockers to scaling are legacy systems, organisational complexity, and unclear prioritisation. According to the data, 43% of teams are constrained by legacy architecture, while others struggle with skills, alignment, and resource limitations.
Most organisations measure success using a mix of outcome-based metrics, productivity indicators, and quality metrics. However, 20% still rely on subjective measures, making it difficult to consistently evaluate architectural impact or link it to business outcomes.
The biggest opportunity lies in improving alignment between architecture and business goals. 34% of respondents identified alignment as the main lever for cost-efficiency, compared to 22% focusing on cloud cost optimisation, which indicates that strategic improvements have a greater impact than reducing infrastructure spend alone.
Engineering leaders can improve outcomes by strengthening cross-team collaboration, introducing clear prioritisation frameworks, and ensuring consistent executive support. These changes help teams make better decisions, reduce complexity, and align architecture with business value.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
%20(1).webp)
.webp)
.webp)
.webp)
.webp)
.webp)
