架构与封装

lidenghui

笔者非常喜欢“封装”这个概念，作为一名资深架构工程师，这是我最喜欢的与架构设计工作紧密相关的概念，没有之一。

在之前的文章“架构工程师的大局观”、“架构与分工”、“架构与关系”、“架构与中台”、“架构与平台”中，大局观、分工、关系、中台、平台，都是笔者很喜欢且在架构设计中非常重要的概念。
这篇文章我们就来聊聊“封装”这个概念。封装这个概念，最广泛的应用是在计算机程序领域，它指隐藏对象的属性和实现细节，仅对外公开接口。不考虑特定的应用领域，我们将“封装”这个概念的抽象级别提高，封装本质上就是将任何一组不需要关心的细节进行模块化，仅关心此模块对外接口的一种思考方式。
可以毫不夸张地说，“封装”这种思维方式是架构工程师的神器，因为封装使架构工程师从繁杂的细节中抽离出来，能够从更高的层面来分析和解决问题。下面用几个例子，说明一下封装思维的实际应用。
1、EEA从分布式到集中式
在分布式EEA阶段，整车厂将各ECU的硬件和软件设计开发工作进行封装，把主要精力放在整车电气功能层面的设计需求、功能分配、系统级和整车级的集成测试工作上。在功能域集中式EEA阶段，整车厂将归属于某个功能域中的ECU软硬件设计开发工作进行分类，将功能域内系统级和整车级的控制逻辑和算法从ECU中提取到域控DCU中（拆除封装的过程），这部分软件逐渐由整车厂自己掌控，而功能域内的其它ECU只负责局部控制（例如传感器、执行器的控制），这部分软硬件开发工作还是继续封装起来。在中央集中式EEA阶段，整车级和系统级控制逻辑和算法被提取到一个或几个中央计算平台中，部分系统级控制逻辑（例如实时性要求很高）被提取到区控ZCU中，各个区域内的ECU软硬件开发工作继续进行封装。
从核心技术能力掌控的角度理解，整车厂认为核心的、附加值高的、能够形成竞争差异的技术是必须要逐渐掌控的，因此就不能继续封装。
2、架构工程师的工作内容在之前的文章“架构工程师应该做什么”中，笔者提出对汽车电气系统划分的“组成部分”可以有不同的粒度，这个粒度的大小就取决于如何对汽车电气系统进行封装。
在分布式EEA阶段，架构工程师将ECU作为一个黑盒进行封装，ECU成为电气系统划分的最小粒度。这种封装方式，决定了架构工程师的主要工作内容。例如：功能分配：将整车级电气功能分解到一个或者多个ECU中；硬线接口设计：重点关注ECU供电和休眠唤醒相关的硬线接口；网络接口设计：网络类型以及通讯协议确定、网络信号需求审核；网络工程师、诊断工程师以及集成测试工程师的工作也是需要基于架构工程师的工作，一般整车厂的负责系统集成的科室或者部门，基本也涵盖了以上几部分的工作内容。在功能域集中式EEA阶段，ECU的数量大幅度减少，这导致功能分配、硬件接口设计和网络接口设计工作量也会相应减少，在中央集中式EEA阶段，这些工作将进一步减少。综上所述，封装的功能越多（从ECU到域控DCU再到中央计算平台），则传统意义上的架构工程师的工作量也会越来越少。从这个角度来讲，架构工程师要有危机感，需要考虑在工作方向和工作内容上的转变。在这方面大家有什么想法和问题，可以公众号留言，我们一起讨论和交流。3、技术团队管理一个优秀的技术团队管理者，一定是一个运用“封装”思维的高手。
细节决定成败也许有一定道理，但如果不能根据具体场景的需要封装细节，而陷入细节之中不能自拔，那细节就是魔鬼。
技术工程师和技术团队管理者的本质区别是什么？
带团队的能力？情商？管理能力？笔者认为最本质的区别是“封装”思维的运用能力。假设一个合格的技术工程师需要掌握100个技术细节，一个技术团队管理者管理5个技术工程师，那么一个合格的管理者需要掌握多少个技术细节呢？
答案显然不会是500个技术细节。技术团队管理者的首要任务是对整个团队的工作进行梳理和分类，目的是将所有技术细节分为2大类：
第1类是技术团队管理者必须掌握的技术细节。如果不掌握这些技术细节，则无法对其它技术细节进行封装。第2类是技术团队管理者暂时不需要深入了解，可以直接封装起来的技术细节。封装之后，技术团队管理者仅关注封装后的技术模块的对外接口即可，并且需要持续地设计和优化技术模块之间的接口关系以及工作流程。在以后的文章中，笔者会举一些实际例子进行说明。