Eoin, who now works independently across software architecture, green software, and engineering, has spent decades around large systems. Eoin 目前以独立身份从事软件架构、绿色软件和工程领域的工作，他在大型系统方面拥有数十年的经验。
The failures he keeps seeing are rarely exotic. They begin with something mundane, an environmental detail nobody verified, a technology nobody fully understood, or a second order effect nobody expected until the system was already live.他所见过的故障很少是离奇的。它们往往始于平凡之处：一个无人核实的环节细节、一项无人完全理解的技术，或者一个在系统上线前无人预料到的二阶效应。
That is why, for him, architecture is less about drawing clean systems on paper and more about surfacing the assumptions production will eventually expose.这就是为什么对他而言，架构与其说是在纸上绘制整洁的系统，不如说是揭示生产环境最终会暴露出的那些假设。
When I asked Eoin where failures come from, he resisted the temptation to separate elegant design from messy execution. He argued, the system that matters is the one that ships, and the one that ships is full of assumptions.当我问 Eoin 故障从何而来时，他拒绝将优雅的设计与混乱的执行割裂开来。他认为，真正重要的系统是那些交付出去的系统，而交付出去的系统充满了假设。
Ultimately the problem is always the design or actually, not even the design but what ends up in production…归根结底，问题总是出在设计上，或者更准确地说，不是设计本身，而是最终进入生产环境的东西……
This means that diagram may look reasonable, the architecture review may pass and the slide deck may even sound convincing. Production is where the assumptions become visible. Experience changes what people notice, Eoin put this bluntly:这意味着图表看起来可能很合理，架构评审可能通过了，幻灯片演示听起来也可能很有说服力。生产环境是假设变得显而易见的地方。经验会改变人们注意到的事物，Eoin 直言不讳地说道：
The older and more cynical you get, the more questions you ask.你越老、越愤世嫉俗，你提出的问题就越多。
Seniority, at least in architecture, often means noticing the missing question before the missing answer turns into an incident. The same logic applies to coupled systems. A component can behave well on its own and still create trouble once the rest of the system starts reacting to it.资历，至少在架构领域，通常意味着在缺失的答案演变成事故之前，先注意到缺失的问题。同样的逻辑也适用于耦合系统。一个组件在独立运行时表现良好，但一旦系统其余部分开始对其做出反应，它仍可能引发麻烦。
If one component slows down dramatically, the others (if tightly bound to it) probably slow down dramatically as well. It’s only when it actually happens that everyone realises everything else slows down in lockstep, because they hadn’t realised how coupled together they were.如果一个组件运行速度大幅下降，其他组件（如果与它紧密绑定）很可能也会大幅减速。只有当这种情况真正发生时，大家才会意识到其他所有组件都在同步减速，因为他们之前并没有意识到彼此之间的耦合程度有多深。
That is the kind of failure teams usually understand only after the fact. The system behaves as designed, then fails as a whole because the interactions were never really understood as interactions.这就是团队通常只有在事后才能理解的那种故障。系统表现得如设计预期，但作为一个整体却失败了，因为这些交互从未被真正理解为交互。
That distinction matters most where recovery is expensive. Financial infrastructure, healthcare, industrial control, and similar environments do not get the luxury of treating failure as a learning exercise.这种区别在恢复成本高昂的环境中最为重要。金融基础设施、医疗保健、工业控制及类似环境，没有奢侈到将故障视为学习练习的余地。
We’re much less enthusiastic about moving fast, breaking things and fixing forwards actually because if we do break something in a mission critical system it has a really serious side effect.我们对于“快速行动、打破常规并向前修复”的做法热情要低得多，因为如果我们确实在关键任务系统中破坏了某些东西，它会产生非常严重的副作用。
In those environments, speed only helps when recovery is cheap. If rollback is hard, repair is slow, or the impact is irreversible, then fast delivery stops being a virtue and starts becoming a liability.在这些环境中，速度只有在恢复成本低廉时才有帮助。如果回滚困难、修复缓慢或影响不可逆转，那么快速交付就不再是一种美德，而开始成为一种负担。
That is why architecture is never just about structure, but about consequences. A design that looks efficient in a presentation can become expensive in the real world the moment its assumptions meet a system that cannot absorb mistakes.这就是为什么架构绝不仅仅是关于结构，而是关于后果。一个在演示中看起来高效的设计，一旦其假设遇到一个无法容忍错误的系统，在现实世界中就会变得代价高昂。
Eoin made the same argument in his Devoxx talk by describing a scene almost every engineer will recognise. Eoin 在他的 Devoxx 演讲中也提出了同样的观点，他描述了一个几乎每位工程师都会熟悉的场景。
A stakeholder asks for something scalable, cost effective, secure, and easy to use. The architect comes back with containerised microservices, lower storage costs, forced password changes, and a task oriented interface. The stakeholder says it sounds good, while still not really understanding what was asked or what was decided.利益相关者要求系统具备可扩展性、成本效益、安全性和易用性。架构师给出的方案是容器化微服务、降低存储成本、强制密码更改和任务导向的界面。利益相关者表示听起来不错，但实际上并不真正理解所要求的是什么，也不理解所做出的决定。
That gap between what was asked and what was understood is exactly what architectural scenarios are designed to close.这种“所求”与“所解”之间的差距，正是架构场景旨在弥合的地方。
A scenario takes a vague wish and turns it into something concrete. Not “the system should be scalable” but what happens when 5,000 users connect at the same time and the primary database fails at 7pm during peak load. Not “the app should be secure” but what happens when a decryption key needs to be recovered after an incident. The value of that exercise is not subtle.场景将模糊的愿望转化为具体的事物。不是“系统应该具有可扩展性”，而是当 5000 名用户同时连接且主数据库在晚上 7 点高峰负载时发生故障会怎样。不是“应用程序应该是安全的”，而是当解密密钥在事故后需要恢复时会怎样。这种练习的价值是不言而喻的。
There’s nothing like writing a scenario to reveal what you don’t know about your own system.没有什么比编写场景更能揭示你对自己系统的不了解了。
That is why scenarios matter, Eoin believes. They do not make uncertainty disappear, but they do force it into view.Eoin 认为，这就是场景重要的原因。它们并不能消除不确定性，但它们确实迫使不确定性显现出来。
He described six practical uses for scenarios. Teams use them to:他描述了场景的六种实际用途。团队利用它们来：
The point is not documentation for its own sake though, but to make the system legible before production does the explanation instead.重点不在于为了文档而文档，而在于在生产环境给出解释之前，先让系统变得清晰易懂。
If offline mode has only been demonstrated and never truly tested against the live system, the scenario is where that becomes obvious. If a recovery flow exists mainly in a vendor demo, the scenario turns the demo into a question rather than a conclusion.如果离线模式仅经过演示而从未在真实系统中进行过真正的测试，那么场景就是让这一点变得显而易见的地方。如果恢复流程主要存在于供应商的演示中，那么场景就会将演示变成一个问题，而不是一个结论。
Eoin’s most practical advice was also the least glamorous: Eoin 最实用的建议也是最不引人注目的：
Make architectural decisions intentionally, and write them down.有意识地做出架构决策，并将其记录下来。
This means recording the assumptions built into it, the trade offs it accepts, and the implications that follow.这意味着记录其中内置的假设、所接受的权衡以及随之而来的影响。
ADRs, or architecture decision records, are not a new idea. Eoin said he was already writing them as a graduate in the 1990s, and even then they were not common practice. The fact that the advice is old does not make it less relevant. If anything, the opposite is true.ADR（架构决策记录）并不是一个新概念。Eoin 说他在 20 世纪 90 年代读研究生时就已经在写这些记录了，即使在当时，这也不是常见的做法。这一建议虽然古老，但并不意味着它不再重要。恰恰相反，事实正好相反。
AI tooling is generating code faster than teams can inspect the assumptions that end up inside it. Requirements are still vague. Stakeholders still do not always understand the technical response and decisions are still too often left implicit.AI 工具生成代码的速度快于团队检查其中所包含假设的速度。需求依然模糊。利益相关者并不总是理解技术响应，而决策也太常被留作隐性。
The result is more software with more hidden assumptions inside it.结果就是产生了更多包含隐藏假设的软件。
That is where architecture really begins, in the part of the work that makes those assumptions visible before production has to do it for you.这就是架构真正开始的地方，在那些让假设在生产环境不得不为你揭示之前就使其可见的工作中。
