有机软件架构

我已经思考了好几年，为什么大多数长期以软件为核心的公司效率低下。加入那些被迫在技术和业务负债累累的系统中实施解决方案的团队并不罕见。通常情况下，在这种公司里，人们会抱怨他们所谓的“怪物”，The Monolith并尽可能地避免投入更多的时间和精力去喂养它。

通常表现为The Monolith一大段代码，这些代码是用团队不再喜欢的旧技术栈编写的。大多数情况下，解决方案耦合度高，因此团队不敢在上面编写任何新代码。领域划分不明确，导致团队无法理解彼此的界限，并且由于代码所有权模糊，团队之间容易产生摩擦。通常，它没有自动化测试，或者至少测试质量很低，因此添加新功能的速度很慢，需要大量的手动测试，甚至需要团队投入大部分时间。

这就是为什么患有这种疾病的组织The Monolith会投入大量人力、精力和金钱来实施解耦策略，或者说transformation，这将使团队能够提高绩效，因为普遍的理解是，更先进的架构应该释放团队的潜力。

更好的架构确实能显著提升组织的绩效，但如果我们重复同样的失败，它不太可能长期保持高效。如果组织结构的骨干保持不变，改变技术解决方案也无济于事。

这就是为什么改变一个组织如此复杂，需要数年时间。因为我们改变的不仅仅是交付给客户的解决方案的结构，更是为客户和利益相关者设计和交付价值的文化。

我个人并不认为软件架构只是一门构建软件蓝图的学科，无论蓝图是何种格式。十年前，由于团队规模和解决方案规模较小，这种架构还算有效，但如今，随着团队的分散和业务解决方案的全球化，这种架构已不再有效。

以我的经验来看，软件架构是一门根据业务需求灵活地扩展和收缩组织规模，从而构建软件解决方案的学科。它更具元性：你不是在构建蓝图，而是在发展构建解决方案的团队。这就是为什么我喜欢说软件架构的未来是organic……

融入Organic软件架构可以增强以人为本的系统愿景，其原则允许组织扩大或缩小规模，在失败的基础上取得成功，并为团队形成一种培养文化，使他们能够为组织在不久的将来将面临的挑战做好准备。

那么，有机软件架构的原则是什么呢？至少这些是我在做软件项目时的指导原则。

解释所有内容需要花费大量时间，因此我只想分享每个类别的高级清单，如果有任何主题需要进一步讨论和解释，我可以撰写更多相关帖子。

商业

• 计划应该是短期的，由长期目标驱动。
• 指标和目标应该透明，并让所有感兴趣的人都能理解。
• 企业有望根据共同的事实改变目标。
• 企业应该将失败视为一种学习的方式。
• 企业应该为团队提供一个失败的沙箱。

团队

• 团队绩效应由个人成长和协作主导。
• 业务在变，团队也在变。
• 方法论应该由文化主导，而不是其他。
• 团队决定如何在组织内进行全球沟通。
• 团队愿景、期望、目标和界限应该明确。

解决方案

• 共同定义由业务需求驱动的技术愿景、战略和原则。
• 不要编写廉价的代码，而要编写廉价的代码。
• 基础设施在预算方面很便宜，但在认知负荷方面却很昂贵。
• 解决方案由整个团队推动。

这些原则取决于公司的情况，但至少放弃其中一个原则的决定应该是有意识的。

你觉得怎么样？我乐意接受反馈、其他人的经验和想法。