办公系统案例：识别与分别无法得到真正的架构

作者用一个通用办公系统（OA）的演化案例，展示了[[知得与识得及识别分别两种方法的不可靠性]]里”识别”和”分别”这两种低层次认知方法能做到什么、又做不到什么。第一步，从系统的几个显而易见的事实出发（这系统总被办公室成员使用、总要提供日常工作所需功能、既映射现实工作又想电子化改造它），很容易识别出邮件/日程/考勤/审批等日常办公功能，以及新闻发布/消息通信/文件管理等电子化管理功能——这构成了架构图v0.0….1、v0.0….2这两个版本，纯粹靠”识别”现实系统里显而易见的需求堆砌而成。第二步，作者回过头把这些功能模块归类成”日常办公”“电子化管理”“特定业务”三个上位概念，形成了版本号明显不同的v0.0.0.1——版本号的变化本身就是一个信号：前两版连”架构的阶段性版本”都算不上，只有第三版才勉强算得上”最初级的架构版本”。这个差异的关键不在于”分类是否合理”，而在于这三个概念从何而来——在你主动提出”日常办公”这个概念之前，客户或办公室成员根本不会向你提出这个词；除非你主动把它独立出来命名，否则即便现实系统确实内在地被这条规律驱动着，也不会有人发现它。也就是说，识别和分别这两种方法只能”得到系统知识而无法归纳之，能分辨出差异而无法梳理之，能构建功能模块而无法推演之”——它们能帮你列出功能条目、能帮你按某个视角把条目分门别类，但归纳出统摄这些条目的核心概念、梳理出概念之间的关系、推演出这些关系为何必然如此，需要更高层次的思维方法，而不是继续在”识别更多事实、换个角度再分一次类”这条路上原地打转。可迁移启发：判断一份”系统架构”是真的架构还是仅仅”陈述了现实系统的事实”，可以检验它里面的核心概念是不是客户/用户会自己主动提出来的东西——如果答案是”是”，那这份文档很可能只是把现实系统的既有说法照抄了一遍（分别的产物）；只有当架构师主动命名、独立提炼出连客户自己都未曾意识到、但确实在驱动系统的核心概念时，才真正跨过了”了解系统”和”架构系统”之间的门槛。

结构图：

flowchart TB
  A["办公系统架构演化"]
  A --> V1["v0.0….1<br/>识别显而易见的功能:邮件/日程/考勤/审批"]
  V1 --> V2["v0.0….2<br/>识别更多特定需求:人力/营销/经营<br/>(仍是识别+分别的产物,客户自己会提出)"]
  V2 --> V3["v0.0.0.1<br/>归纳出上位概念:日常办公/电子化管理/特定业务<br/>(客户不会主动提出,需架构师主动命名独立)"]
  V1 -.->|"识别/分别:能列条目/能分类,但不能归纳/梳理/推演"| N["非真正架构"]
  V3 -.->|"归纳出统摄性概念,推演其必然性"| Y["才勉强算最初级架构版本"]