最近半年，业务飞速发展，架构不断进化；在接下来半年内，业务将继续高速发展，我能看清楚三个月内架构进化的目标。但是，我却无法想清楚半年或一年后架构演化的蓝图？这个问题给我带来不少困惑，直到最近，才理清楚了一些道理：不为业务服务的架构演化都是耍流氓，对架构长期目标的不清楚，就来源于对于业务多变性的不可预测。

先讲讲近一年项目的架构演化，年初的时候，业务单一，基础薄弱，算法朴素；在线上事故的教训下，增加了全面的监控，问题检测时间缩短到分钟级；在业务压力的推动下，朴素算法逐步更替成大数据（大内存）的高大上模型；在牵一发而动全身的设计困惑下，“大泥团”的实体渐渐理顺了层次和关系，分清了主和次。业务也从单一大业务，变成了3个骨干业务+5初创业务的复合服务。

虽然架构一直在进化，新旧问题也不断在被解决，但是对于半年或一年后的架构，依旧无法看透，虽然自己曾试着提出几种方案，例如SOA的，微服务化等，但是一一都被自己否决了，否决的原因很简单：我不确定这是业务一年后所适配的架构。最近，为此找来了几本书看看。一本是《架构之美》，还有一本是《恰如其分的架构设计》，还有Martin Fowler的一些文章。有些感触，给大家分享一下。

首先对于架构的理解，找到了些共鸣。

大师Grady Booch将软件架构解释：架构是一种设计，但并非所有设计都是架构。架构代表着发展一个系统的重要决定，而这种重要性是通过引入变化的成本来衡量的。引入变化成本将成为架构决策的重要因素，这与我的想法不谋而合，其实架构的演化是与业务息息相关。

“架构是一个过程，而不是一个结果。”

“对定一个系统，需要多少专门的架构设计工作？ 一个关键问题是，如果一个项目没有太多的设计风险，说明架构在一个好的状态，不需要太多的架构工作；如果一个系统的设计风险很大，每一个业务实现都需要过多的考虑设计风险，那么说明这个项目的架构需要大力投入了。这就是风险驱动的架构设计。”

这些理解都和我的想法不谋而合：架构的需求来源于系统的状态和业务的需求，说一句俗气的化“不为业务服务的架构都是耍流氓”。

架构师和建筑师相同的是都需要负责一些框架，建筑师需要保证建筑的美观，实用和坚固，架构师也需要负责软件架构的简单，实用和可靠。他们之间很大的区别是，架构师随着时间的演化，需要继续对架构进行演化，以支持业务的发展，他比建筑师多一个时间的维度。所以，架构师的角色更像是一个城市的规划师，负责长期的演化工作，应对以后的变化，包括很多未知的可能性。遥想当年的，梁思成提出来的《梁陈方案》如果能够演化下来，北京的古城保护将会是另外一番景象。

好了，搞清楚了架构师的作用之后，如何评定架构师的成绩（OKR或者KPI)？响应时间？并发数量？ 开发效率？ 缺陷数量？　这些都是工程师眼中的工程师目标，这些指标到底和业务增长有多少关系呢？ 有些可能是直接相关的，有些可能是间接相关的，并非是面向业务的演化。如果将业务的KPIs作为架构师的KPIs呢，例如营收，用户数，使用时长，留存数等？初想这个问题，感觉很难关联上，但是仔细想想，关联还是非常大的。架构师在系统演化过程中，最重要的技能就是能够平衡好成本，速度，质量和风险，那么在平衡这些因素的时候，总是需要一个基本原则来指导，这就是通常说的True North，用最简单的指标来决定方向。那么，业务的关键指标将是非常重要的。

为什么只选一个关键指标，因为真正的北方只有一个。有一本书叫做《Lean Analytics》里面介绍了一种观点 OMTM(One Metric That Matter)，每个组织都应该找到它的关键指标，这个指标必须简单直接，寻找这个指标也许不容易，但是一旦确定下来，就可以快速迭代，进行优化，周而复始的为之努力。架构的演化也必须找到这个指标。

最后聊聊架构师是的角色吧，能够亡羊补牢，避免悬崖勒马的就是好架构师。不管黑猫白猫，能搞定关键指标(One Metric)的就是好架构师。