Panel: Taking Architecture Out of the Echo Chamber - InfoQ

Andrew Harmel-Law and a panel of expert architects discuss the shifting practice of architecture in 2025. They explain strategies for communicating technical debt to stakeholders, the benefits of decentralized decision-making through ADRs, and the career paths of modern leaders. The panel shares insights on bridging the gap between mobile and backend teams to ensure a holistic system.

Key Takeaways

• Decentralized decision-making through ADRs enables faster, more autonomous team operations while maintaining architectural coherence
• Effective stakeholder communication requires translating technical concerns into business impact using visualization and cost-based risk analysis
• Architecture career paths are becoming more multidisciplinary, moving away from linear progression toward integrated roles
• Mobile-backend integration challenges stem from legacy siloing and require cross-functional collaboration from the start
• Architectural compromise often results from poor capability decisions rather than true trade-offs

Panelists

• Andrew Harmel-Law: Tech Principal @Thoughtworks
• Cat Morris: Product Manager @Syntasso
• Diana Montalion: Founder @Mentrix Group, author of "Learning Systems Thinking"
• Shana Dacres-Lawrence: Senior Principal Architect @6point6
• Vanessa Formicola: Principal Architect and Head of TASC @Prima
• Elena Stojmilova: Technical Lead @Open GI
• Peter Hunter: Head of R&D, Tech Architect @OpenGI

The Evolution of Architectural Practice

Andrew Harmel-Law opened the panel by framing the central tension: "Architecture is probably more important now than it's ever been, but how we do architecture is coming into conflict with all of the other important things." This conflict drives the need to move architecture out of its traditional echo chamber.

Diana Montalion emphasized that modern architecture requires impact beyond code: "If I'm making decisions in the context of code, there's a relatively small context of decision and impact around me. Now, if I want to have impact on the system as a whole, I have to be able to make a recommendation that is going to get me the money and the time and the things that I need."

Decentralized Decision-Making with ADRs

The panel discussed how Architecture Decision Records (ADRs) enable decentralized decision-making while maintaining system coherence. Peter Hunter explained their implementation: "We set up our teams to be flow-aligned. We were measuring ourselves on the DORA metrics. We're deploying to production multiple times a day. We agreed that the decision records would have effectively a seven-day warranty period."

This approach addressed concerns about decision ownership and responsibility. Elena Stojmilova clarified: "We don't have like a level to which the teams can make decisions. Teams can make any decision, but you have the architectural principles and they are creating the overall architecture vision where we wanted to go."

The seven-day feedback window proved crucial for behavioral change. Hunter noted: "It's about behavior change, and it is a big behavior change. It doesn't happen for free. You can't just put principles in, ADRs in, and AAF and hope that it all works."

Communicating Architectural Concerns Effectively

Panelists shared strategies for bridging the communication gap between technical architects and business stakeholders.

Diana Montalion advocated for knowledge management principles: "Designing knowledge flow and understanding the principles of knowledge management, those are so handy to integrate into our own work. Once I create an artifact that gives me insight and understanding, I create versions of that artifact that speak to the audience in their language, and I keep those things interlinked."

Cat Morris emphasized the power of cost-based arguments: "If you can put a cost to it, like a number against it, like if something goes wrong it will cost us this much, the likelihood is 20%, therefore the cost of the risk is x, then you're much more likely to get buy-in and agreement."

Shana Dacres-Lawrence highlighted the importance of framing concerns around business objectives: "If you articulate it in a way that highlights their core concerns or their core objectives, we want a secure solution, but if you do this, it's not secure, which then will mean that your data is leaked, your data is lost. Then that really drives home why you need to put in certain measures in place."

Career Paths in Modern Architecture

The panel challenged traditional notions of architectural career progression.

Vanessa Formicola argued against strict role separation: "I have the very unpopular opinion that you shouldn't split the managerial roles and the architectural and the developer role. I'm a firm believer that either people should be able to flip around the various roles or find this perfect slice of shared responsibilities at the right level."

Diana Montalion described architecture as multidisciplinary: "Systems leadership is multidisciplinary in a world that wants you to climb one ladder and then that's your ladder and you cannot get off your ladder. An architect role from my experience is you get off the ladder and you are going to do what a circumstance needs you to do."

Cat Morris illustrated the diversity of architectural roles: "There's so many different hats you can wear in so many directions. I was a developer for two years and was pants at it. There's still a path into architecture in some flavor for people who should not be allowed to touch a keyboard."

Bridging Mobile and Backend Architecture Gaps

Addressing the siloing between mobile and backend teams, panelists shared practical approaches.

Vanessa Formicola recommended cross-functional collaboration from the start: "I never allowed mobile engineers to be alone designing while backend engineers were in a different room. By designing the people who are in the room, you design the conversations that they will have to the limit of what's your existing problem."

Diana Montalion traced the problem to legacy decisions: "Every organization would have a web app. Wait, we need it to be responsive. Then they'd build either a mobile version or they do a responsive theme. Then we need an app. They'd hire a completely different team because they didn't overlap."

Cat Morris emphasized product management alignment: "You have your iOS product manager and your Android product manager, your web product manager, your backend product manager, and that's when I start flipping tables, because you're never going to get a consistent user experience."

Handling Architectural Compromise and Innovation

When multidisciplinary conversations produce compromise rather than innovation, the panel offered guidance.

Diana Montalion introduced the concept of the "car boat": "One team wants a car and they get the budget and another team wants a boat and they get the budget. The engineers are asked to build a car boat, which everybody hates because nobody wanted a car boat."

This occurs when organizations cannot make capability decisions. Montalion emphasized: "They have to be able to do that to not get a car boat."

Cat Morris recommended reading "Never Split the Difference": "Compromise is a fallacy. Most of the time there is a goal that you can both achieve and get what you want at the end of it. It's not the case of either/or, or both of you have to give up something."

Learning from Architectural Decisions

The panel addressed how to distinguish between necessary trade-offs and genuine architectural mistakes.

Peter Hunter advised against dwelling on past decisions: "You're always going to reflect on decisions and there's going to be some positive decisions and there's going to be some negative decisions. Then you're going to have to make another decision, as to whether you spend any time on it."

Elena Stojmilova emphasized making smaller decisions: "It will really help to try to make smaller decisions, as small as possible, and write them, and create an idea for them, ask for feedback, and that will lead you to not rethink in detail a lot."

Diana Montalion reframed the question: "When you made that decision, you made it based on the time and context you were in, things have changed. You're going to look back and say that decision did not lead where I wanted it to go, always and forever. That's actually part of architecture, that's inherently part of architecture, the learning, the growth mind as context."

Key Principles for Modern Architecture Practice

• Trust but verify: Empower teams while maintaining architectural oversight
• Small, documented decisions: Enable faster feedback and more flexible adaptation
• Cross-functional collaboration: Break down silos between mobile, backend, and other disciplines
• Business-aligned communication: Translate technical concerns into business impact
• Multidisciplinary career paths: Move beyond linear progression models
• Capability-driven decisions: Avoid compromise by making clear system priorities

The panel concluded that architecture in 2025 requires a fundamental shift from technical gatekeeping to enabling multidisciplinary collaboration, with decentralized decision-making and clear communication as the foundation for successful system evolution.