当前位置：首页 > article >正文

架构思考与实践：从通用到场景的转变

article 2025/1/19 8:11:23

在当今复杂多变的商业环境中，企业架构的设计与优化成为了一个关键议题。本文通过一系列随笔，探讨了业务架构的价值、从通用架构到场景架构的转变、恰如其分的架构设计以及如何避免盲目低效等问题。通过对多个实际案例的分析，笔者揭示了架构设计不仅仅是技术问题，更是对企业现状和未来发展的深度理解与把握。本文适合希望深入了解业务架构及其实践意义的读者阅读。

价值理解：（业务）架构的价值

当我们需要了解一个人时，需要“察其言观其行”，不过也难免“误判”。企业的发展与管理，最重要的还是要了解企业自身，知道在做哪些事情，有哪些能力。如果企业都不知道自身的能力和发展情况，那么管理层就容易“纸上谈兵”、“朝令夕改”，或选择“无为而治”。

因为不了解一线情况，就会提出不合时宜、不够长期的个人主张，下面的人也会“晕头转向”，企业长期也可能“原地踏步”。

企业黑盒：盲目，低效

业务架构其实是为了“塑造一面镜子”，让企业看清自己。下面是本人之前梳理的一个整体逻辑图。从顶层的商业模式，到中间的业务能力、业务流程，再到具体的系统实现与资源消耗，是一个抽象层面的认知结构。

业务架构大图

说白了，我们需要一个能够承上启下的模型，能够让企业外的人或者上层的管理者，在比较抽象的角度理解经营活动；同时让具体的干活的执行者能够知道“我在做什么”、“能够产生怎么价值”，“应该往什么方向演进”。也就是把一件事抽象地讲清楚。这个常用的语言就是业务架构大图中价值流和业务能力的部分。

下面是一个讲清楚实现“招聘员工”这个事情的案例，就是采用了“价值流映射到业务能力”的方法。

价值流映射到业务能力案例，来自《TOGAF 口袋指南》

这里顺便抛出一下相关定义：

价值流的定义：价值流表现为【一系列】端到端的【增值活动】，能够为客户、利益相关者或最终用户【创造整体效益】。
价值流阶段的定义：价值流中的【增值活动】被称为价值流阶段，价值流每步入一个新的阶段就会为利益相关者【创造并增加增量价值】。
业务能力的定义：业务能力是企业为实现特定【目的】或【成效】而可能【拥有】或【置换】的一种特殊【能力】或【产能】。

道理大家都懂，但是该怎么做呢？复杂系统下我们该如何实践？关于这个问题，说到了很多事情的痛点，我们缺少最佳实践，也就是一些优秀的模版。如果没有这些模版，我们很容易“走歪”，变成“东施效颦”、“照猫画虎”、“画蛇添足”等各种辛苦但又无奈迷茫的局面。

此时，我们应该去看一下业界实践和行业观点，多了解大家的实践。当我们见过好东西，就知道差在哪里了，也可能原本方向就是对的，缺的可能就是“信念”。

下图就是中国电信CRM 2010年的一个流程整理版本，是一个相对抽象的角度，讲清楚了中国电信的客户管理系统要干什么。

CRM 整理流程框架，来自《中国电信CTG-MBOSS BSS CRM系统业务功能规范》

再进一步，上面是具体的一个价值流阶段展开，下面是抽象出来的功能架构。

CRM 功能架构，来自《中国电信CTG-MBOSS BSS CRM系统业务功能规范》

继续进一步，将价值流阶段（纵）和一些功能主题（横）组合在一起的时候，就从一个比较高的层次，描述了企业要做哪些阶段的事，每个阶段需要哪些能力支撑，下面就是一本书中对上面电信系统的描述。

CRM 功能域划分，来自《业务架构·应用架构·数据架构实战》

回过头来，我们好像一直在讲如何理解企业要做什么事情，需要具备哪些能力，并没有具体讲如何避免盲目低效。但是，我们从日常的经验知道，掌握企业方向的都是少部分高层，让这部分高层理解企业的现状，是他们决策的起点，上面的理解，实际上是一份“沟通语言”、“顶层类目”、“业务模块”的抽象呈现，是“指令”、“反馈”的中间桥梁，也就是打开的企业黑盒。

在这样的基础上，我们可以进一步去做增量思考，相关能力是否不够完善（能力成熟度），多部门之间的能力是否有重叠（重复建设与成本），新的战略要补充什么能力（能力规划与组织招聘）等。

做事情之前，要把事情想清楚，想清楚之前，首先得能够有渠道和视角看到东西。看不到，看不明白，也就无法思考，更没法做出有效决策，那么只能随波逐流，听天由命。

转变认知：从通用架构走向场景架构

在知识与信息爆炸的情况下，传统的营销策略已经很难生效，因为大家会主观上过滤各种投放的广告。现在要想进一步促进销售，就需要进入特定场景，融入到不同用户的体验过程中，可以称之为场景营销。

知识爆炸

回到架构场景上，在相对成熟的公司中，由于基础的建设相对完善，我们现在很难通过一个相对简单和通用的方法解决一大类类似的问题，进而需要进入特定的场景，一步一步地进行场景分析和架构设计，个人认为可以是进入了“场景架构”的时代。

如果有“场景架构”这样的认知的话，我们会有什么样的期待变化呢？

放弃一劳永逸的幻想：在这样的情况下，我们很难在不打开研究对象的时候，在外部进行一个切面研究就获得显著的改善效果。一个切面就能解决的，往往称为基础技术。
需要进行归类与分级：在打开特定场景的情况下，意味着场景的发散，需要解决的问题很多，在有限的时间内，我们需要进行场景归类，和类型优先级的排序，针对不同的价值和收益，提供不同的解决策略。
更加需要基础架构理论：因为场景的发散，我们会发现很多特殊的情况，或者与原先判断相左的案例，从而产生疑惑。为此，我们在解决场景问题前，需要不断完善横向理论，让理论更具包容性和策略性。在多种策略背后，我们需要对目标更加确认和清醒，让目标真正的可持续和符合实际情况。
业务内容为先：理解场景意味着理解业务，这意味着我们需要跨进业务域，明白生产关系，各方诉求，也需要增加访谈的能力，了解业务背景。同时，这样意味着我们需要投入更多的精力，会经历更多的反复。

不再期待架构中有“神灯”

“场景架构”的地位提升，往往发生在业务发展到比较成熟的阶段，是业务进入深水区时的认知改变。如果业务本身还没有很复杂，基础建设也还有空间，那也还有很多的通用策略去解决问题，但是这一部分往往属于技术架构、数据架构、应用架构等方面，而业务架构，则没有银弹。

深水区需要精耕细作

过犹不及：明白什么是恰如其分

软件研发过程中，对架构的投入比例常有不同的看法：

不需要架构活动：有人认为，完全不需要独立的架构活动，架构应该回归到日常研发过程中，软件开发者会在迭代中自我思考和解决；
架构活动基于首要位置：有人认为，开始就需要进行整体的架构设计，这是后续工作能够不返工的关键。

在《恰如其分的软件架构》一书中提到，不同的场景下，需要的架构活动比例是不一样的，并不是绝对的0和1的事情，如果要进一步去认知比例的多少，应该转向“风险驱动的原则”：软件复杂，风险较大的，业务架构活动的比例就需要提高，反之则可以控制在较低比例，甚至没有。

再进一步看，实际上很多软件设计或多或少都需要结构和方案的设计，会考虑后续的扩展性、可维护性、可读性等方面，这个架构活动的比例是天然存在的。不过，很多的问题是，需不需要独立出来一个“架构(师)”的角色来承担各问题域的兼职角色。如果这样看的话，问题变得更加复杂了，软件工作中架构的“恰如其分”不仅仅是架构活动的比例，更需要考虑这个比例在人员上的分摊情况。

生活中恰如其分的设计

不破不立：忘掉自己画的圈和规则

最近在架构书籍的序中看到一个观点：是说到最后要忘掉自己画的圈，不破不立。这让我很触动，我们身边的架构活动，一直都在试图建立规则，维护规则，甚至想方设法植入到生产中，让物理现实和逻辑空间保持强一致性，然后陷入到日常管理的“权利”快感中。

回顾我们的行动本身：当我们看到复杂的规则之后，尝试去设计和建立新的规则时，是不是想过，我们是将复杂变得简化，还是在复杂上增加复杂。

思考不能偷懒

数学中一个很好的例子就是过拟合。当我们拟合的不错的时候，往往我们还会乐忠于不断调整，进行进一步的拟合，因为这样的增量对我们来说比较轻松，也容易看到结果。当看着拟合的曲线几乎完全覆盖所有的点时，往往会兴奋地欣赏着自己的杰作。

可再来一个新的点时候，我们却会陷入深深的茫然：才发现自己对过去发生的事情过于在意，进一步拟合的快感，虽省去了找新思路的的苦恼，但同时也让我们忽略了我们的职责是保持一定的适应性，是对未来（的点）进行预测。

眼前短期的“漂亮”不是我们的目标

如何忘记自己给自己的画的圈？如何不固守自己的一亩三分地？如何跳出自己煮出来的“温水”？我想更好的办法，还是要牵引，不停地奔向远方，去看大海，看到更多的世界和想法。

当我们遇到一些问题的时候，我们往往可以找到一些基本的策略，可以不假思索地去执行与推进，因为以前就是这么做的，这样也很好做，前人可能把阻力磨平了，你只需要在上面做新的调整。

但是，时间与阶段发生了变化，我们面对的问题和环境也不一样，还是用前人的思想讲述当今的故事，往往是思想上的偷懒，逻辑经不起深度推敲。

事情不能模糊化

可能大家潜意识里面都触碰到过这样的抉择，是继续思考下去把问题想清楚，还是拿着当前看似可通的逻辑去赶快拿结果。前者会面对思维的反复，充满痛苦；后者却可以快速地进入操作，让身体变累，头脑却变得轻松。

但是，思想的大海，一定是要经历蜿蜿蜒蜒的曲径，才能最终看到。让你兴奋的，也许是大海的波澜壮阔，也许只是你为了看大海，而一直前行走过的漫长道路。

忘记“圈”，其实还是让我们不要做思想上的懒惰者，不要享受“一招半式”唬人的快感，还是要踏踏实实地踏上思考苦旅。

理解重复：重复的故事，不同的演绎

大话西游中，可通过“月光宝盒”回到过去，重新演绎历史，甚至能够进行走向的影响，但是总是只能改变细节，很难改变大结局，因为实物运行的规律是多方作用的结果。如果很难改变，如果只是重复演绎，那么这又有什么意义呢？

使用月光宝盒回到过去

工作中，如果在一个相对成熟的公司，站在领导的层面，可能会有这样的疑问：为什么还是那么些产品，却仍需要那么多人？同样，站在一线的人，也会有这样的疑问：好几年前就有的产品，怎么一直要做，到底是什么原因。

如果我们细细去看，这些工作内容，往往不是同一个团队的持续工作，而是历史的多次重演：

交互阵地变了：从PC 到无线，再到各种智能设备，同样的产品，在不同交互阵地上需要重新建设。
自建or共享：每个业务线都可以选择自建，因为共享的产品内容，往往因为人员有限，支持粒度有限，不够高效，所以不同业务可能也需要重复昨天的建设。
范围变了：原来大家都是管好自己产品内的逻辑即可，因为大盘的增量本身会带动各个产品的增量，但是当增量有限，大家就需要扩大产品的覆盖范围，就需要从考虑大盘变成考虑各个其它产品场景，走入了各种叠加下产品逻辑设计的长尾工作中。
维护人变了：即使什么都没有变化，但是人还是可能离开，那么新进来的人势必需要时间学习，通过各种资料去调查历史的故事，了解各个模块的设计和具体实现。

在一些团队“老人”的眼中，他们能够看到之前的一些故事，能够看到一些差异点，知道”重演“的原因。但是在团队新人的眼中，并不会感知之前的历史，只能看到自己在改写新的历史，但是如果被问到“为什么这个产品好几年了，为什么还在做？”时，可能并无法理解。

思考：循环中是否大部分是新的东西

我觉得，工作中“重复”的事情之所以那么多，因为我们工作的那层还是过于靠近业务，同时建设成本其实也并不高。只要有团队能够想出差异点，只要这个热度比较高，就很容易走向自建或者各种设计的漩涡中。就好比一个街道上开了个奶茶店，很快就会有一堆奶茶店，只要有赚头，就会有新店。我们很容易回答要做什么，因为做了可能就有机会（能找到各种逻辑），而且往往不用考虑成本（公司兜底）。