架构规划：以办公系统四阶段案例求解"系统性维护"

架构的本质问题——系统面对复合领域、业务模式频繁变化时如何持续获得”系统性的维护”——除了[[架构形成模型M0的层次约束链条|参考模型M0]]这条”通过什么影响什么”的路径外，还有另一种求解思路：架构规划。M0模型能说明架构各层之间如何相互约束，却回答不了”如何形成架构意图”这个更前置的问题；架构规划则把系统的发展切分成若干个阶段，让每个阶段对应一个不同的架构重点，从而把”系统性维护”这个笼统的目标，转化成每个阶段具体可锁定的架构意图。书中以一个办公系统为例：第一阶段是单一定制——系统只服务一家客户的具体需求，架构意图可以锁定为”快速实现的市场探针性产品”，此时不必追求可扩展性或复用性，验证市场才是核心；第二阶段是同行业多应用——系统开始被同行业的多个客户使用，架构意图转向提炼行业共性、控制差异化定制的成本；第三阶段是平台化——系统需要支撑跨越具体业务差异的公共能力，架构意图从”满足业务”转向”大到看不见”的基础设施建设；第四阶段是跨平台——系统要能延伸到办公场景之外的其他领域，架构意图转向抽象与迁移能力本身。这四个阶段依次递进，每一阶段的架构决策都建立在明确知道”当前处于哪个阶段、这个阶段该解决什么问题”之上，而不是从一开始就试图设计一个能应对所有未来阶段的”终极架构”。可迁移启发：面对一个不断演化的系统，与其试图一次性设计出万能架构，不如先诚实定位当前所处的发展阶段，锁定这个阶段该解决的具体问题，把架构规划变成一系列阶段性意图的接力，而非一次性的完美蓝图。

结构图：

flowchart LR
  A["阶段一:单一定制<br/>架构意图=快速实现的市场探针性产品"]
  A --> B["阶段二:同行业多应用<br/>架构意图=提炼行业共性/控制定制成本"]
  B --> C["阶段三:平台化<br/>架构意图=大到看不见的基础设施建设"]
  C --> D["阶段四:跨平台<br/>架构意图=抽象与迁移能力本身"]