🤔 Why did we do this?
The idea of ‘software architecture’ has been around for more than 50 years, which is longer than the internet has been public! Yet, most conversations about software today usually revolve around shiny new programming frameworks, infrastructure, and… you guessed it, AI. While all of this is related to software architecture in some way, there isn’t a lot of focus nowadays on the tools, practices, and discipline itself.
A few months ago, we surveyed architects, technical leaders, and anyone who gets value from understanding complex systems. Our goal was to gather useful insights about the field and where it’s heading. We were impressed with the turnout in responses since this was the first-ever survey we sent! It’s clear there’s an appetite to share opinions and ideas.
We hope the results spur some thoughts about the industry, practices, and ideas to help your team better collaborate around software architecture.
🔑 Key highlights
Read this section if you want the TL;DR, or scroll down and look at the summary charts/images if you prefer not to read.
- 96 people responded to the survey. Most were architects and engineers working full-time at medium (100–499) and large (5,000+) companies. Their company typically had a small team of architects, between 1 and 9.
- Most respondents (96%) used diagramming and collaborative wiki tools (79%) to document their software architecture. People used a wider range of tools as their source of truth, from diagramming tools to collaborative wikis to informal methods. Some even had no single source of truth!
- People updated their architecture at different cadences (weekly, monthly, quarterly), did formal architectural reviews once or less a year, and half of the respondents used architectural decision records (ADRs).
- The most common architectural patterns used were microservices (67%) and event-driven (62%).
- Most respondents were moderately or very confident in using the C4 model. Container/app diagrams (Level 2) were the most used diagram type, followed by Context diagrams (Level 1).
- 60% of respondents believed AI-assisted generation and maintenance of docs would have the biggest impact on the industry in the next 5 years.
Let’s dive into the different sections in more detail.
👥 Who answered?
- There were a total of 96 responses.
- More than half (55%) of the respondents were architects, with solution architects being the most common at 29%. Engineers/developers were the second largest group at 26%.
- The majority of respondents were full-time employees (96%), with 1–5 years (38%) and more than 10 years of experience (41%).
- There was a wide range of company sizes, with 100–499 (25%) and 5,000 or more (24%) being the most common.
- Despite the wide range of company sizes, most had a small team of dedicated architects. The most common team size was 1–9 architects, at 58%.
⚒️ Tooling and practices
This section focused on specific tooling and practices for creating and maintaining software architecture documentation.
- Most respondents (96%) used diagramming tools to document their software architecture, followed by collaborative wikis (79%).
- Surprisingly, 64% mentioned using a modelling tool — A bit unexpected since we sent this survey 🤔.
- Although the least common, it was interesting to see that 40% of people still used physical whiteboards for documentation. Nothing can quite beat a whiteboard's flexibility.
We saw a bigger divergence on where the source of truth lived for a team’s software architecture.
- 37% said they used diagrams and manually maintained them, while 30% said it was on a collaborative wiki tool.
- 16% had no single source of truth, and 7% tracked it with code or informally. Teams are still trying to find the ideal location of their source of truth that balances effort and accessibility.
- There was no pattern for how often people updated their architecture documents. It was a close split between monthly (28%), quarterly (23%), and weekly (23%).
- However, people less frequently did formal architecture reviews with their team, with annually or less often being the most common answer at 41%.
- It was a close, even split when it came to using architecture decision records (ADRs) — 47% said yes, and 53% did not.
The most common architecture patterns used were microservices (67%) and event-driven (62%). It’ll be interesting to see how this evolves in the coming years.
4️⃣ C4 model
This section focused on the adoption of the C4 model and its challenges.
- Most people were moderately (41%) or very confident (39%) in using the C4 model.
- We asked respondents who were not confident or slightly confident to explain in more detail the reason why. Some common responses were: Never heard of it or haven’t had time to work/learn it.
- Container/app diagrams were the most commonly used diagram type in the C4 model at 85%, followed by Context (67%), and Component diagrams (51%).
- Out of supplementary C4 diagrams, most people used system landscape diagrams (26%) or dynamic diagrams / IcePanel Flows (27%) the most.
Lastly, we asked people to explain their challenges with the C4 model.
Some common challenges were:
- Creating an overall view that strikes the right balance of detail and clarity.
- Understanding how to map things to the C4 model abstractions (e.g. what should go at what level, what is a system, what is a component).
- The best way to model event-driven architectures.
- Keeping their model up to date with reality and tracking changes over time.
🔮 The future of software architecture
The final section focused on how software architecture and the role of an architect is evolving.
- AI has impacted every industry, and it was no surprise that people believe AI-assisted generation and maintenance of docs (60%) would have the biggest impact on software documentation in the next 5 years.
- Automated updates from code (48%) and integration of docs with CI/CD pipelines (41%) were also believed to have more impact in the coming years.
People seemed split on how the role of architects would evolve in the future.
- 63% thought architects would be more involved in business and strategy, 62% believed they’d be more involved in coaching and mentoring teams on architecture design, and 50% thought they’d have more responsibility for security and compliance.
We wrapped up the survey with a final question for respondents to share any open thoughts about software architecture. Many people stressed the importance of collaboration, not just across disciplines (eng <> architects), but also within architecture teams. A few people also mentioned the importance of architecture in setting guardrails and ensuring systems continue to evolve in a disciplined manner, especially with the rise of AI.
🧊 That’s a wrap!
Thanks so much to everyone who filled out the survey and checked out the results! We plan to make this an annual report to see how trends and opinions change. If you’ve got any thoughts on the results or ideas for what we should focus on next time, let us know — mail@icepanel.io. We’d love to hear from you!
Stay Chill 🤙