架构思考与实践：从通用到场景的转变
在当今复杂多变的商业环境中，企业架构的设计与优化成为了一个关键议题。本文通过一系列随笔，探讨了业务架构的价值、从通用架构到场景架构的转变、恰如其分的架构设计以及如何避免盲目低效等问题。通过对多个实际案例的分析，笔者揭示了架构设计不仅仅是技术问题，更是对企业现状和未来发展的深度理解与把握。本文适合希望深入了解业务架构及其实践意义的读者阅读。
当我们需要了解一个人时，需要“察其言观其行”，不过也难免“误判”。企业的发展与管理，最重要的还是要了解企业自身，知道在做哪些事情，有哪些能力。如果企业都不知道自身的能力和发展情况，那么管理层就容易“纸上谈兵”、“朝令夕改”，或选择“无为而治”。
因为不了解一线情况，就会提出不合时宜、不够长期的个人主张，下面的人也会“晕头转向”，企业长期也可能“原地踏步”。
业务架构其实是为了“塑造一面镜子”，让企业看清自己。下面是本人之前梳理的一个整体逻辑图。从顶层的商业模式，到中间的业务能力、业务流程，再到具体的系统实现与资源消耗，是一个抽象层面的认知结构。
说白了，我们需要一个能够承上启下的模型，能够让企业外的人或者上层的管理者，在比较抽象的角度理解经营活动；同时让具体的干活的执行者能够知道“我在做什么”、“能够产生怎么价值”，“应该往什么方向演进”。也就是把一件事抽象地讲清楚。这个常用的语言就是业务架构大图中价值流和业务能力的部分。
下面是一个讲清楚实现“招聘员工”这个事情的案例，就是采用了“价值流映射到业务能力”的方法。
这里顺便抛出一下相关定义：
-
价值流的定义：价值流表现为【一系列】端到端的【增值活动】，能够为客户、利益相关者或最终用户【创造整体效益】。
-
价值流阶段的定义：价值流中的【增值活动】被称为价值流阶段，价值流每步入一个新的阶段就会为利益相关者【创造并增加增量价值】。
-
业务能力的定义：业务能力是企业为实现特定【目的】或【成效】而可能【拥有】或【置换】的一种特殊【能力】或【产能】。
道理大家都懂，但是该怎么做呢？复杂系统下我们该如何实践？关于这个问题，说到了很多事情的痛点，我们缺少最佳实践，也就是一些优秀的模版。如果没有这些模版，我们很容易“走歪”，变成“东施效颦”、“照猫画虎”、“画蛇添足”等各种辛苦但又无奈迷茫的局面。
此时，我们应该去看一下业界实践和行业观点，多了解大家的实践。当我们见过好东西，就知道差在哪里了，也可能原本方向就是对的，缺的可能就是“信念”。
下图就是中国电信CRM 2010年的一个流程整理版本，是一个相对抽象的角度，讲清楚了中国电信的客户管理系统要干什么。
再进一步，上面是具体的一个价值流阶段展开，下面是抽象出来的功能架构。
继续进一步，将价值流阶段（纵）和一些功能主题（横）组合在一起的时候，就从一个比较高的层次，描述了企业要做哪些阶段的事，每个阶段需要哪些能力支撑，下面就是一本书中对上面电信系统的描述。
回过头来，我们好像一直在讲如何理解企业要做什么事情，需要具备哪些能力，并没有具体讲如何避免盲目低效。但是，我们从日常的经验知道，掌握企业方向的都是少部分高层，让这部分高层理解企业的现状，是他们决策的起点，上面的理解，实际上是一份“沟通语言”、“顶层类目”、“业务模块”的抽象呈现，是“指令”、“反馈”的中间桥梁，也就是打开的企业黑盒。
在这样的基础上，我们可以进一步去做增量思考，相关能力是否不够完善（能力成熟度），多部门之间的能力是否有重叠（重复建设与成本），新的战略要补充什么能力（能力规划与组织招聘）等。
做事情之前，要把事情想清楚，想清楚之前，首先得能够有渠道和视角看到东西。看不到，看不明白，也就无法思考，更没法做出有效决策，那么只能随波逐流，听天由命。
![]()
转变认知：从通用架构走向场景架构
在知识与信息爆炸的情况下，传统的营销策略已经很难生效，因为大家会主观上过滤各种投放的广告。现在要想进一步促进销售，就需要进入特定场景，融入到不同用户的体验过程中，可以称之为场景营销。
回到架构场景上，在相对成熟的公司中，由于基础的建设相对完善，我们现在很难通过一个相对简单和通用的方法解决一大类类似的问题，进而需要进入特定的场景，一步一步地进行场景分析和架构设计，个人认为可以是进入了“场景架构”的时代。
如果有“场景架构”这样的认知的话，我们会有什么样的期待变化呢？
-
放弃一劳永逸的幻想：在这样的情况下，我们很难在不打开研究对象的时候，在外部进行一个切面研究就获得显著的改善效果。一个切面就能解决的，往往称为基础技术。
-
需要进行归类与分级：在打开特定场景的情况下，意味着场景的发散，需要解决的问题很多，在有限的时间内，我们需要进行场景归类，和类型优先级的排序，针对不同的价值和收益，提供不同的解决策略。
-
更加需要基础架构理论：因为场景的发散，我们会发现很多特殊的情况，或者与原先判断相左的案例，从而产生疑惑。为此，我们在解决场景问题前，需要不断完善横向理论，让理论更具包容性和策略性。在多种策略背后，我们需要对目标更加确认和清醒，让目标真正的可持续和符合实际情况。
-
业务内容为先：理解场景意味着理解业务，这意味着我们需要跨进业务域，明白生产关系，各方诉求，也需要增加访谈的能力，了解业务背景。同时，这样意味着我们需要投入更多的精力，会经历更多的反复。
“场景架构”的地位提升，往往发生在业务发展到比较成熟的阶段，是业务进入深水区时的认知改变。如果业务本身还没有很复杂，基础建设也还有空间，那也还有很多的通用策略去解决问题，但是这一部分往往属于技术架构、数据架构、应用架构等方面，而业务架构，则没有银弹。
![]()
过犹不及：明白什么是恰如其分
软件研发过程中，对架构的投入比例常有不同的看法：
-
不需要架构活动：有人认为，完全不需要独立的架构活动，架构应该回归到日常研发过程中，软件开发者会在迭代中自我思考和解决；
-
架构活动基于首要位置：有人认为，开始就需要进行整体的架构设计，这是后续工作能够不返工的关键。
在《恰如其分的软件架构》一书中提到，不同的场景下，需要的架构活动比例是不一样的，并不是绝对的0和1的事情，如果要进一步去认知比例的多少，应该转向“风险驱动的原则”：软件复杂，风险较大的，业务架构活动的比例就需要提高，反之则可以控制在较低比例，甚至没有。
再进一步看，实际上很多软件设计或多或少都需要结构和方案的设计，会考虑后续的扩展性、可维护性、可读性等方面，这个架构活动的比例是天然存在的。不过，很多的问题是，需不需要独立出来一个“架构(师)”的角色来承担各问题域的兼职角色。如果这样看的话，问题变得更加复杂了，软件工作中架构的“恰如其分”不仅仅是架构活动的比例，更需要考虑这个比例在人员上的分摊情况。
不破不立：忘掉自己画的圈和规则
最近在架构书籍的序中看到一个观点：是说到最后要忘掉自己画的圈，不破不立。这让我很触动，我们身边的架构活动，一直都在试图建立规则，维护规则，甚至想方设法植入到生产中，让物理现实和逻辑空间保持强一致性，然后陷入到日常管理的“权利”快感中。
回顾我们的行动本身：当我们看到复杂的规则之后，尝试去设计和建立新的规则时，是不是想过，我们是将复杂变得简化，还是在复杂上增加复杂。
数学中一个很好的例子就是过拟合。当我们拟合的不错的时候，往往我们还会乐忠于不断调整，进行进一步的拟合，因为这样的增量对我们来说比较轻松，也容易看到结果。当看着拟合的曲线几乎完全覆盖所有的点时，往往会兴奋地欣赏着自己的杰作。
可再来一个新的点时候，我们却会陷入深深的茫然：才发现自己对过去发生的事情过于在意，进一步拟合的快感，虽省去了找新思路的的苦恼，但同时也让我们忽略了我们的职责是保持一定的适应性，是对未来（的点）进行预测。
眼前短期的“漂亮”不是我们的目标
事情不能模糊化
可能大家潜意识里面都触碰到过这样的抉择，是继续思考下去把问题想清楚，还是拿着当前看似可通的逻辑去赶快拿结果。前者会面对思维的反复，充满痛苦；后者却可以快速地进入操作，让身体变累，头脑却变得轻松。
但是，思想的大海，一定是要经历蜿蜿蜒蜒的曲径，才能最终看到。让你兴奋的，也许是大海的波澜壮阔，也许只是你为了看大海，而一直前行走过的漫长道路。
忘记“圈”，其实还是让我们不要做思想上的懒惰者，不要享受“一招半式”唬人的快感，还是要踏踏实实地踏上思考苦旅。
大话西游中，可通过“月光宝盒”回到过去，重新演绎历史，甚至能够进行走向的影响，但是总是只能改变细节，很难改变大结局，因为实物运行的规律是多方作用的结果。如果很难改变，如果只是重复演绎，那么这又有什么意义呢？
使用月光宝盒回到过去
工作中，如果在一个相对成熟的公司，站在领导的层面，可能会有这样的疑问：为什么还是那么些产品，却仍需要那么多人？同样，站在一线的人，也会有这样的疑问：好几年前就有的产品，怎么一直要做，到底是什么原因。
如果我们细细去看，这些工作内容，往往不是同一个团队的持续工作，而是历史的多次重演：
-
交互阵地变了：从PC 到 无线，再到各种智能设备，同样的产品，在不同交互阵地上需要重新建设。
-
自建or共享：每个业务线都可以选择自建，因为共享的产品内容，往往因为人员有限，支持粒度有限，不够高效，所以不同业务可能也需要重复昨天的建设。
-
范围变了：原来大家都是管好自己产品内的逻辑即可，因为大盘的增量本身会带动各个产品的增量，但是当增量有限，大家就需要扩大产品的覆盖范围，就需要从考虑大盘变成考虑各个其它产品场景，走入了各种叠加下产品逻辑设计的长尾工作中。
-
维护人变了：即使什么都没有变化，但是人还是可能离开，那么新进来的人势必需要时间学习，通过各种资料去调查历史的故事，了解各个模块的设计和具体实现。
在一些团队“老人”的眼中，他们能够看到之前的一些故事，能够看到一些差异点，知道”重演“的原因。但是在团队新人的眼中，并不会感知之前的历史，只能看到自己在改写新的历史，但是如果被问到“为什么这个产品好几年了，为什么还在做？”时，可能并无法理解。
我觉得，工作中“重复”的事情之所以那么多，因为我们工作的那层还是过于靠近业务，同时建设成本其实也并不高。只要有团队能够想出差异点，只要这个热度比较高，就很容易走向自建或者各种设计的漩涡中。就好比一个街道上开了个奶茶店，很快就会有一堆奶茶店，只要有赚头，就会有新店。我们很容易回答要做什么，因为做了可能就有机会（能找到各种逻辑），而且往往不用考虑成本（公司兜底）。
这个问题很类似的就是，经典电视剧可能每个几年就会重新拍一下。观众变了，演员变了，拍摄技术变了，即使故事情节也没有变，还是会有消费的群体，以前看过老的版本的人可能也不在目标客户中。
回过头来，如果工作中，我们在反复建设以前的产品，同时老板又会疑问为什么还需要那么多人时，其实还是要回到我们的业务：业务在反复打开"月光宝盒"，期望引入各种变化，能够将原来特定结局，演绎成多个版本，为了他们的不同策略，这些策略可能是为了不同人群，可能是为了不同行业，可能是为了不同交互等。
但是，是否真的”重复“的关键还是在于：他们的策略或者目的是否在反复，还是在不断细化完善。这有着截然不同的感受的，一个是产品的重复建设or返工，一个是产品的逐渐完备 。
很幸运的是，我们的工作时间有限，很难经历一个产品的多次反复，总会有新的人演绎新的故事，是否重复并不重要，有人消费可能就够了。
此外，好比电视剧，虽然各种支持人员可以减少，但是演绎的人员的确要那么多，并不可能一个人演了全部的角色。那么，工作中可能只有减少产品新的各种功能，才可能减少特定的人员。
认知有限：我们不如专业人士擅长
近期参加了儿子幼儿园的家长开放日，期间看到老师教小朋友唱歌，很有感触，这里分享一下。
要学的歌词大致如下：
北风北风呼呼呼
雪花雪花飘飘飘
小手小手搓搓搓
天天锻炼身体好
北风北风呼呼呼
雪花雪花飘飘飘
小脚小脚跺跺跺
天天锻炼身体好
北风北风呼呼呼
雪花雪花飘飘飘
小球小球拍拍拍
天天锻炼身体好
引导的方式如下：
-
抛出一个问题：冬天那么冷，做哪些事情可以暖和？有很多回答：洗热水澡，多穿衣服。
-
继续递进问题：能不能不通过外物保持暖和？也有很多回答：做运动，搓搓手等。
-
然后问：大家可以听听音乐中有哪些活动？开始播放音乐。听完后大家补充回答：可以搓手、跺脚、拍球。 老师将提到的东西，做成卡片，贴在小黑板上。
-
然后问：哪些歌词出现了3次？大家回答：北风北风呼呼呼、雪花雪花飘飘飘、天天锻炼身体好。
-
然后通过播放音乐，大家按照黑版提示唱了几遍。
-
然后分2组，让大家依此进行了表演。
我发现通过这样一轮操作下来，小朋友们很快能够记住歌词内容并唱出来。这对于思维比较简单的小孩来说，的确很不容易。
这让我遐想万千，因为我们作为程序员，工作中很关注逻辑、结构、复用等。但是我们却没有很多好的实践，无论是大家对于一套架构的理解，还是说对于团队系统的认知。
但学歌这个过程，让我觉得大道至简，很多事都是相通的，甚至于说，我们陷入于软件世界中，缺少了最为广泛的生活视角，思考的源动力有限。生活是最好的老师，也是智慧最多的地方。
举例来说，上面的学歌过程，可以抽成很好的学习模版：
-
提出一个关注点问题；
-
将这个问题进一步细化描述，形成一定的目标；
-
将需要了解的内容呈现出来，带着问题去观察了解；
-
大家可以一起探讨，互相补充理解；
-
尝试发现规律：比如什么经常重复，有哪些重要动作；
-
形成自己的串联理解，尝试描述出来；
-
进行实践，大家展示交流。
我不知道，按照我们日常工作中的一些理论或者逻辑，能否实现快速教会小朋友们这样的事情。或许说，我们日常的工作中的事情，本没有什么深层次的逻辑，只是将砖头，从A点搬到B点，有时也会再从B点搬回来。并没有思考如何搬，如何搬的更好；也很难教会拌水泥、扭钢丝这样的工作。事实上，我们可能得承认我们的认知有限。
![]()
结语
最后分享一句最近看到的话：“好的设计的重要目标之一就是让系统一目了然”，可能也是大道至简。
本文分享自微信公众号 - 大淘宝技术（AlibabaMTT）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
