企业架构设计关注的三个维度：稳定、持续、代价

企业软件架构设计首先应当面向客户而非软件企业自身——理解决定设计，架构师必须尽可能早、尽可能深入地了解工程目标、应用环境、战略决策和发展方向，否则不可能做出有效设计。在此基础上，架构设计集中体现为三个互不相同的维度：稳定性由架构师的设计能力决定，判断架构好坏的基本法则是”适用”——一个不适用的架构无论规模大小都不可能稳定，进一步推论是”架构必须以工程的主体目标为设计对象”，而现实中很多架构设计只在做边角功夫（为一两处”精彩的局部”叫好），全然不顾架构是否服务于工程的真正目标。持续性由架构师的地位决定——如果团队不能认识到”设计的一致性”以及架构师对这种一致性应有的权威，再好的架构也会解体，再长远的架构也会短期内被废弃：架构的实施本质上是以牺牲团队实施自由为代价的，架构师若没有足够的地位对抗实施者对自由的渴望，通常的失败根源不在架构本身好坏，而在于架构被架空、形同虚设。代价则取决于架构师的经验——若不能准确评估所设计架构的资源消耗，可能在项目初期就埋下设计失误，也可能在实施中困于枝节、疏离关键，白白耗费资源。当这三个维度都没有被重视时，结果就是迟迟无法上线的工程、半拉子工程和不停追加投资的项目——这类问题的根源往往从设计阶段就已经埋下，项目经理事后回天乏术。

结构图：

flowchart TB
  F["企业架构设计先要面向客户<br/>(理解工程目标/应用环境/战略/发展方向)"]
  F --> S["稳定性<br/>由设计能力决定<br/>法则=适用,以工程主体目标为对象"]
  F --> P["持续性<br/>由架构师地位/权威决定<br/>无权威→架构被架空形同虚设"]
  F --> C["代价<br/>由架构师经验决定<br/>误判资源消耗→设计失误或徒耗资源"]
  S --> R["三者缺一→迟迟无法上线/半拉子工程/不停追加投资"]
  P --> R
  C --> R