软件架构最佳实践、企业架构模式以及系统描述的正式方法都是非常重要且实用的工具，总会有合适的场景让它们发挥作用。但在设计系统时，请从简单始、以简单终，尽可能避免一切会无谓提高复杂度的架构与正式工具。
我的职责是设计和构建大型系统。我参与重写了Uber的分布式支付系统，设计并交付了Skype on Xbox One，开源了Uber的移动架构框架RIBs。所有这些系统都进行了彻底的设计，经过多次迭代和大量讨论。然后，这些设计被记录到设计文档中，在我们开始构建之前分发出去，从而获得更多的反馈。
所有这些系统的规模都很大：有数百名开发人员在构建它们——或者以它们为基础进行构建——并且它们支撑着每天数百万人使用的系统。它们不仅仅是绿地项目。重写的支付系统就是用于替换两个已有的支付系统，有几十个系统、数十个团队在使用它们，但所有这些都没有对业务产生任何影响。重写Uber App是一个由数百名工程师同时参与的项目，他们将现有的功能移植到一个新的架构中。
让我先说些可能会让你觉得吃惊的事。首先，这些设计都没有使用任何标准的软件架构规划工具。我们没有使用UML，没有使用4+1模型，没有使用ADR，也没有使用C4和依赖关系图。我们创建了大量的图表，但是没有遵循任何严格的规则。只是使用了普通的方框和箭头，类似于这个描述信息流的图或这个概括类结构和组件之间关系的图。同一个设计文档中的两个图经常会有不同的布局，并且经常由不同的工程师添加和修改。
其次，负责设计的团队中没有架构师。没有IT架构师或企业架构师。没错，Uber和Skype/微软都没有袖手旁观的软件架构师职位。级别较高的工程师和普通工程师一样，仍然需要定期编写代码。对于所有的项目，我们都有经验丰富的工程师参与。然而，没有人专门负责架构或设计。经验丰富的开发人员确实推动了设计过程。不过，即使是最初级的成员也在设计过程中进行了输入，他们经常会挑战决策，并提供其他可供讨论的替代方案。