区分内在动律与整体动向，及"改变现行工作"的臆断风险

[[识别架构意图的三个入手角度与支付系统案例]]提到系统脉络包含内在动律与整体动向两部分，这里进一步指出两者在”可信度”上有本质区别：内在动律通常是无可争辩的事实，整体动向则往往是主观判断或客户战略。用这把尺子重新审视此前办公系统的”三点事实”：只有把第一点（系统总被某些办公室成员使用）和第二点（总提供其日常工作所需功能）合并起来，才能拼出一个真正的一般过程（”办公系统向某些办公室成员提供日常工作所需的功能”）——这才是站得住脚的内在动律。第三点事实（既映射现实工作，也试图改变现行工作）则要拆开看：前半句”映射现实工作”完全正确但也毫无信息量（这本就是软件系统的本质，放之四海皆准）；后半句”试图改变现行工作”却是一个相当危险的臆断——除非客户的电子化战略里确实包含这个诉求，否则架构师无法仅凭前两点事实推断出”要不要改变现行工作”这个判断。危险性在于，”改变现行工作”往里深挖会牵出业务流程再造（BPR）乃至企业资源计划（ERP）这类系统性工程，这直接涉及客户企业有没有能力承接如此大规模的组织变革——而这早已超出了架构师能从”内在动律”里直接推导的范畴，作者提醒”架构不是为客户设定战略，而是服从客户设定的战略”，如果客户的战略本身不清晰，架构师顶多只能依据内在动律做出一些阶段性的、维系系统自身发展所需的主观判断，而不能擅自把”改变现行工作”这类重大战略假设塞进架构意图里。可迁移启发：审视任何一条”既定事实”时，先问它是描述系统内部无可争辩的运作规律（内在动律），还是暗含了对客户战略走向的判断（整体动向）——后一类判断即使听起来顺理成章、即使表述得和前者一样斩钉截铁，实质上都是需要客户明确确认、而非架构师能替客户拍板的臆断，贸然把它当作既定前提去架构系统，代价可能是把一个简单的办公工具项目意外升级成一场企业级流程再造工程。

结构图：

flowchart TB
  A["原始三点事实"]
  A --> E1["点1+点2合并→内在动律<br/>'办公系统向某些办公室成员<br/>提供日常工作所需的功能'<br/>=无可争辩的一般过程"]
  A --> E3["点3:既映射现实工作,也试图改变现行工作"]
  E3 --> E3a["前半句:映射现实工作<br/>正确但无信息量(软件系统的本质)"]
  E3 --> E3b["后半句:改变现行工作<br/>=危险的臆断,除非客户战略明确包含此诉求<br/>否则可能牵出BPR/ERP级别的组织变革"]
  E3b -.->|"架构服从客户战略,不为客户设定战略"| Rule["战略不清晰时,只能依据内在动律做阶段性判断"]