This website uses cookies

Read our Privacy policy and Terms of use for more information.

🌟 Editor's Note

Hello again. It’s been a busy summer over here, with conferences, vacations, and the World Cup happening in Vancouver. We’re now back into the swing of things, in need of a vacation from the vacation, but energized to finish off the rest of the year.

Over the last few months, we’ve been thinking deeply about what the future architecture looks like. It’s easy to get caught up in the details of building a product while forgetting to zoom out and see where things are heading. We’re all strong proponents of putting things down on paper, whether through words or visuals.

The culmination of this work and thinking is a long-form essay we’ll be publishing soon, centred around the concept of a loop (we’re calling it the IcePanel Loop). The idea is simple and human-focused, but it acknowledges the new reality architects are operating in with AI/LLMs. We’re excited to share it with you soon, but we included an excerpt below.

Last month, we attended DDD in Antwerp. Without a doubt, one of the best conferences we’ve been a part of. We had plenty of good conversations with architects, and what’s top of mind. Unsurprisingly, plenty of automations through diagrams-as-code with agentic workflows.

Enjoy your summer and remember to stay chill 🍦

The IcePanel Loop

The Shift

Software systems are more complex than ever, and AI is adding fuel to the fire. The role of architects is changing. Diagrams and code that took hours to produce are now generated in seconds. The dream of automated architecture diagrams from code feels close to reality. However, faster output doesn’t mean better architecture. Quantity and quality don’t always go hand in hand. In fact, AI can sometimes create more complexity and uncertainty for teams, especially at scale.

The current approach to software architecture isn’t equipped to deal with today’s complexity. It’s outdated, siloed, and slow to adapt to new requirements. The current tools for software architecture suck. They lack depth, clarity, and opportunity for collaboration when designing systems. Rarely do these tools feel fun and enjoyable to use.

Architecture isn’t something that only architects should care about. It’s soon going to be a baseline expectation for anyone involved in product building. Architecture needs to evolve as fast as the businesses it supports.

The bottleneck is no longer writing code, and honestly, it never has been.

Architects and product builders in general face many challenges when designing software. Coming up with ideas is easy. But without a clear hypothesis for the value proposition and an understanding of current constraints, ideas can’t be validated. They’re just assumptions about the architecture. If the architecture doesn’t reflect the reality of the system, it becomes hard to turn assumptions into tested decisions.

Product builders face challenges like:

  1. Understanding existing systems and business context.

Statements like ‘It just works’ or ‘TODO: add a diagram ’ won’t cut it. Architecture isn’t designed in a void. It’s designed in a world of interconnected systems, each with inputs, outputs, and feedback loops. That’s what Donella Meadows called “Thinking in Systems”. Customers are systems. AI agents acting on behalf of users are systems. The more context we have, from business to technical, the better we design systems that actually work together.

  1. Aligning teams

Designing architecture is one thing. Getting stakeholders behind the architectural decisions is another thing. Aligning teams can be challenging if the problem isn’t communicated clearly up front. Alignment comes from discussing ideas, trade-offs, and reaching consensus. Just as important is making sure teams work from a stable foundation of knowledge and a language for talking about their systems. How many times have you seen people refer to systems as different things?

  1. Making the right decisions

Architectural decisions can be expensive and sometimes irreversible. Product builders should deeply understand the problems they’re trying to solve in order to make the right decisions. Without a deep understanding of the root cause, even well-intentioned decisions can waste months of a company’s time. Jeff Bezos distinguished between two types of decisions at Amazon:

Type 1: Irreversible with long-term consequences like choosing a cloud provider, enterprise resource planning (ERP), or a database solution.

Type 2: Reversible with short-term consequences like building prototypes or a minimum viable product (MVP).

  1. Building the right thing

Sounds cliché, but it’s true. Many teams end up building the wrong thing. This could be misguided product direction, not aligning on decisions, or building on inconsistent architecture. Now with AI, building is no longer the bottleneck. Knowing what problems to solve and how to solve them is.

  1. Pivoting when needed

In a perfect world where all requirements are available upfront and customer needs never change, we wouldn't need to change or revise our architecture. As much as we want this to be true, that’s not the case. Even more so today. Learning how and when to pivot is both a challenge and a critical skill for product builders.

Architecture is foundational to all software we use. But the way we’ve been doing it isn’t working. Treating diagrams as set-and-forget won’t work in modern architectures. Diagrams are just one view of the model, a visual representation that helps humans reason about complex systems. But the model itself is what matters. AI doesn’t need a diagram to understand your architecture. It needs the model. Legacy codebases are inevitably maintained. The models that represent them should be too.

Stay tuned for the full release later this month 👀

🤓 Dear Architects, Episode 5: Federated Architecture

Mahdi is tech lead at Fashion Cloud and has been a long-time supporter of IcePanel. In this episode, Mahdi talks about building an architecture culture from the bottoms-up, without formal architects on the team. A very hands-on chat about the challenges working at a scale-up, establishing the right governance model, and choosing the right tool to scale their architecture practice.

🤓 Reads + finds

  • Architectural Change Cases: a Practical Tool for Evolutionary Architectures. A simple framework that helps teams think ahead about how their architecture might need to evolve, beyond ADRs. Read.

  • The Architects Guide to the AI Era: An honest conversation between Luca Mezzalira and Teena Idnani about how AI is shaking things up for software architects. The fundamentals are more important than ever. Watch.

  • Scaling ArchUnit with Nebula ArchRules: Netflix built a system called Nebula ArchRules that lets them share and enforce architecture rules across thousands of Java repos. Read.

  • Simon Brown’s C4 model book is out! Pick up a copy from the creator of the C4 model here.

😎 Fun in Antwerp!

Last month, our team travelled to Antwerp for DDD. The jetlag hit us pretty hard, but we had fun time connecting with architects and giving away our special edition merch.

Looking spry despite the jetlag

Chilling with some IcePanel customers and DDD attendees

Thanks to the organizers from Aardling and everyone that took some time to learn more about what we’re building. We’ll see you again soon at DDD in Amsterdam next year 🇳🇱!

Stay chill,

The IcePanel team 🧊

Reply

Avatar

or to participate

Keep Reading