直到离开前东家这么久，也依然想为 DataHub 找寻一个准确的定义，直到着笔写下这些文字前，我都很难去描述这个系统。以至于在构建 DataHub 的过程中，参加的每场会议，所做的每次技术决策，在近 3 年时光中，会时不时在我的脑海里泛起与重演，挥之不去。
故事要从新的研发团队负责人到来开始说起。
彼时正处于团队合并融合阶段，新到来的研发团队负责人提出 SaaS Native 的理念，推进技术升级改造工作，从组织权限的系统升级到低代码平台 Studio 的立项开发，意预改变现有构建 SaaS 软件系统的方式。
而关于 DataHub 的故事，我们要从一个方块说起。
一个方块
关于 DataHub 的故事开始于一张架构图。
有过架构图绘制经历的朋友可能知道，对于一个业务线的全局架构图，多数情况下绘图者喜欢用方块表示一个系统。而有经验的工程师不会特别关注一张架构图中聚集了多少方块，而是会将更多的注意力放在方块之间的连接线，如果连线上有箭头那么更需要加倍留意。毕竟在一张架构图中存在的方块即便再多，如果它们之间没有连线，则意味着彼此间没有交互。在任何一个系统中没有交互的模块几乎是不存在的，所以我们可以通过连线去推测一个模块在更大的系统中所处位置、链路，以及可能承载的业务领域。线条之上的箭头通常预示着数据流向，强调着相连模块彼此之间的关系。
在这张绘制于白板之上且略显潦草的的架构图中，写着 DataHub 的那个方块伫立在图中央，同时布满了线条，这些线条向上承载一片区域，向下承接一片区域，每片区域中都填满了规矩的方块，而每个方块都随着双向箭头的线条连接着写有 DataHub 的那个方块。透过两片区域内方块上的文字，昭示着每一个都代表着零售系统中的核心领域。
正因为其独特的位置和众多的连接，以及连接对象所代表的含义，看到的第一眼就知道构建这个名为 DataHub 的系统不会是多么轻松而容易的事情。
DataHub 是什么
初次见到 DataHub 就是一个伫立在架构图中的方块，除此以外关于 DataHub 的其他信息就没有了，至少对于当时接到任务的我来讲。
而我的任务却是去实现它。
所以，DataHub 是什么则是我对它的第一个疑问，也是后来他人问我最多的问题，同样也是一直困扰我的问题。
让我们先回到当时的时间节点，我所经手的第一手消息仅有一张架构图片，而没有其他信息辅助。对于个人来讲，需求第一次接到的时候，理应去追问更多的会议细节，补充需求背景。但不知为何我却并没有这么做。
所以，这个写有 DataHub 的方块就是唯一的着手点。截至目前我知道了它的名字，知道了它在大的系统架构中所处的位置，知道了它与其他系统间的关系。但这却并不能很好地解释它是什么。
为何这样讲呢？因为此时的我尚不清楚 DataHub 是用来解决什么问题的。
于软件工程师而言，主要工作是参与设计开发一个系统软件来解决一个或一类问题。如果待解决的问题涉及的领域比较大，工程师们通常会拆解问题，直至一个合适的粒度，最终可能将一个或一类问题交给一个系统软件来解决，之后再通过组合这些系统软件，来解决最开始那个大问题。而根据系统软件所解决的问题，便可以对其进行定义。有了明确的定义，那么一个系统软件就有了指向性，有了指向性就可以着手进行方案架构设计。再然后便是按部就班地开发、测试、投产，以及后续基于所解决问题域的扩充，进而对系统软件的功能进行迭代升级。
所以，问题通常是软件诞生的前提。不清楚系统软件所解决的问题，就无法准确地定义它是什么。无法定义它是什么，也就无法开展设计与开发工作。
这也就是为什么，我总是称软件工程师就是解决问题的人。
但这次似乎有那么些不一样......不一样的地方在于，问题从哪里来呢？
在企业软件开发过程中，通常情况下，需求的背后就是问题，而需求来自于业务开展期间、或产品运营期间所遇到的阻碍，经由产品经理将阻碍和问题转化成需求并传达给技术团队，之后技术团队再进行设计开发。这是多数产研团队所执行的工作模式，自然也是我所供职的研发团队长期的工作模式。
而这一次我要试着自己发现问题。
在ChatGPT尚未技惊四座的年代，遇到问题还是会习惯性地向搜索引擎寻求帮助，但即便是今天去搜索引擎中检索 "DataHub"，得到的依然是 LinkedIn 出品的大数据生态中的元数据管理开源软件。在经过简单的了解后便会发现，这款 DataHub 显然不是那张架构图中的方块所对应的答案，甚至可能在指导性上都无法提供有价值的参考。
故事讲到这里，对于那些经验丰富的架构师，可能已经意识到 "DataHub" 只是一个代号。这个名称是对系统职能的模糊描述。遗憾的是，当时的我没能提前意识到这个问题，这也为后续的工作带来了一定程度的麻烦。这点暂不展开，让我们先回到主线上来。
所以问题是什么？
所以问题是什么
究竟这个方块要解决什么问题？
似乎只能先回到那副架构图中去寻找答案，不知道读者是否还记得 DataHub 在架构图中的位置，它的作用似乎与连接和承上启下相关。
为什么一个零售 SaaS 平台需要这么一个部件来承上启下呢？
虽然当时整个团队的系统早已经历一轮 SaaS 改造，一方面其 SaaS 能力还比较基础，另一方面用户多为集团内部各业务条线。坦诚地讲团队整体对于 B端 SaaS 系统建设经验并不算丰富与熟稔。
所以，当时只好去其他已高度商业化的 SaaS 产品的宣传介绍，以及简要的系统架构中去探索，希望能从中寻觅一丝灵感。
幸运的是，就在探索和寻觅的过程中，"阿里奇门" 作为一个提示传了过来。
这里先简单介绍一下 "阿里奇门" 究竟是个怎样的软件系统。我们可以将其认为是一个提供了标准化接口定义的网关，适用于不同企业间进行系统集成对接。
上面的解释可能有些抽象，我们结合场景进一步介绍。假设有个企业拥有自建的仓储系统，需要对接物流系统来做货品收发的数字化，常规方案便是直接对接物流公司的系统。假设从公司战略层面对物流公司进行了变更，至少在软件工程师的角度，系统层面上就需要做变更来适配新物流公司的系统。假设需要对接多家物流公司，我们很难奢望这些企业的系统全部遵循一个统一标准，所以研发通常需要依次适配，再转换成本公司系统内统一的物流模型。
上面的例子是站在物流企业作为相对强势一方的视角，需要我们去主动对接。实际上可能还有另一种场景，就是基于双方展开的深度商业合作，那么具体到仓储系统和物流系统谁来承担主要适配工作，到研发层面则可能会是一个斡旋的过程。
基于上述两个场景，如果引入 "阿里奇门" 作为中介，在平台上已形成 "标准化的统一" 接口。且部分物流企业已经完成对接的前提下，那么对于仓储系统的研发只需要对接 "阿里奇门" 便相当于实现了多家物流企业系统的集成工作。对于新接入系统，彼此分别与 "阿里奇门" 对接，一方面少了很多琐碎的对接和权责，同时也可享有前期接入系统的资源与后续红利，也很符合当下 "降本增效" 的议题。
"阿里奇门" 的作用在这里就好比，软件开发领域所谓的 "一处定义，多个实现，按需加载" ，即系统的灵活复用能力。
不得不说，"阿里奇门" 又是一个很典型的阿里系统，要想发挥其价值需要一套生态玩法，这也是为何在其他 SaaS 商业化产品中很少见到同类产品。一方面很多 SaaS 厂商研发类似功能产品的目的，也是为了便于自身替换其他厂商产品，打开自身市场。所以通常会将产品变成系统能力提供给 SaaS 产品的用户。另一方面或许才是核心原因，国内软件市场供应链体系的缺失，以一站式解决方案为主导，缺乏集成需求。所以导致这类产品的价值极低。这个问题也是后续我在建设 DataHub 过程中，不断需要和他人解释和探讨的问题......
先抛开这些问题暂且不展开，至少在当下透过 "阿里奇门" 这个抓手，可以确定 DataHub 尚待解决的问题以及存在于架构图中的意义：解决多系统集成对接问题。
摸着石头过河
既然，这里已经为 DataHub 这个系统确定为 "解决多系统集成对接问题" 。那么便可以开始基于这个出发点，着手进行系统架构设计，另一方面，则可以围绕这个待解决问题逐步规划丰富系统能力。
面对架构设计方面的工作，其实在梳理 "阿里奇门" 的时候便逐步开始了，通过试用与阅读文档，对其系统能力进行梳理与抽象。逐渐地将参考设计目光放到了各大开源网关上面，在提炼这些网关的架构骨架的基础上，考虑后续各能力点的扩展性的同时，我为 DataHub 画的第一版架构图看起来就似一条朴素的链式调用。
对于第二部分工作内容同样重要，也就是需要确定为系统增添哪些核心能力。核心能力的确定，一方面是为了系统后续建设提供规划，另一方面也是为系统设立边界。
为什么这个工作很重要？因为一个边界不清晰的系统，很容易夹杂进不必要的功能，不仅会影响后续的技术决策，严重情况下会加速架构与代码的腐蚀速度。相反，一个边界清晰的系统，还会为后续多团队合作过程，涉及功能权属与工作职责划分提供有力帮衬，减少不必要的复杂性和非系统性因素。
坦诚地讲，对于系统边界的问题，我一直没能很好地妥善处理。这部分会先不展开讲述，我们先回到主线上，把系统的核心能力确认下来。
核心能力要如何梳理，还是需要回到系统所解决的问题上。在系统集成层面，首先就是分属两家企业的系统，除网络外，基于技术栈的不同其远程方法调用的协议可能不同，比如我当时所处的团队是采用集团内部的框架，有其独有的协议，而外部企业可能是基于更通用的 HTTP 协议或其他框架所提供协议。
其次，不同企业因为其所处行业，以及经营规模、方式，业务形态的差异，同一个系统的同一个功能，其模型，反映到接口维度，也就是方法参数上，也会存在诸多差异。
无论是通讯协议也好，还是模型差异也好。其实，只要确定了转换规则，即便是初级工程师也会很快完成开发工作，如果有系统能再进一步减少开发工作的前提下来承接，岂不是起到了事半功倍的效果？这也进一步阐释了 DataHub 所解决问题的切实性。
基于以上两点，最终我为 DataHub 确定的核心能力便是 "转换"，在转换的基础上再叠加通讯能力。转换涉及通讯协议的转换，以及模型参数的转换。
不过，后来我才意识到 "转换" 这个能力描述在传播上太过于抽象，也为系统带来了些许麻烦，在系统边界未能清晰定义的前提下，一个高度抽象的能力会导致系统边界被进一步放大。
就在相关设计工作逐步进行的过程中，有幸得到了集团开放平台网关部分的代码，也获得了与其团队咨询交流的机会，但非常遗憾的是，当时的我并未能有效利用这一资源。不过，好在不久后关于 DataHub 的第一次汇报得到了部分肯定的答复。
不过，关于 DataHub 的系统方案是否可行，当时的我是没有足够底气的，即便经过了架构团队的评审，核心逻辑与流程也经历过代码层面的验证。
回过头来看当时底气不足的原因，可能有三个方面：一方面是深知这个系统已经朝着基础设施类软件系统的方向演进了，而个人完全没有基础设施类系统软件的建设经验，同时又对这类系统软件的建设难度有着不切实的认知，导致提高了对系统建设难度的预估。另一方面，第一次面对个人的设计方案，多数部分需要交由他人实现完成，这不同于以往，设计后自己实现的方式，如果在开发过程中发现设计有纰漏可以加班去调整改造，但却不好意思让他人为你的错误买单，同时如果调整过多的话，对于团队士气也会是个影响。
而最后一方面，可能才是最根本的原因，那便是一系列悬而未决的疑问。DataHub 仅仅就是 "阿里奇门" 么？DataHub 仅仅就是负责系统集成对接么？它在架构图中的位置显然似乎并不仅仅如此......
但当时没有更多的时间去思考与寻找，很多事项的时间节奏又很紧凑，所以只能紧锣密鼓地摸着石头过河了。
湍流
由于是第一次将设计方案的大部分代码交由他人开发，我几乎犯了能犯的所有错误。
首先，虽然系统的核心架构已经敲定，但限于时间关系，以及个人对项目节奏规划的混乱。其实系统诸多实现细节尚未仔细打磨，很多内容仅仅是方向性的描述，而这些细节不得不转嫁到实际开发中去逐渐落地完善。
其次，由于没有在一开始建立严谨的开发规范，以及向开发人员讲解架构规范。同时，没能在开发工作开始前给出系统核心逻辑的代码骨架。所以，起初的开发工作在结果上与我预期有些偏差。这就导致部分开发工作存在反复修改调整，影响了一些进度。同时开发进程中部分问题逐渐显现也需要不断推敲调整，间接地又影响了一些进度。这些进度的影响并非交付层面上的，而是整个产品的节奏步调。
最后，算是十分愚蠢的错误，没能在建立良好的沟通基础上，贸然对同事的代码做了较大的调整。后来也是与其多次交流，坦诚本人自身的问题与压力，方才换来了对方的谅解。
就当每个任务节点列队而立，时间却催促着向前呼啸极驰，另一个问题出现了...... DataHub 不能成为网关。
在对 DataHub 的思路愈发清晰的情况下，为什么它不能成为网关？总的来说，有两方面原因。其中一个主要原因便是如果将 DataHub 做成网关，势必要承载业务的所有流量，那么对其负载、性能与可用性的要求以及团队需要承担的责任都不会小，对于一个业务系统研发为主的团队，且能够投入其中的人手又极其有限的情况下，其挑战与难度则被进一步放大。
再加上当时团队所处的环境和一些特殊因素，我们都不能将其做成网关。那么要如何解掉流量这个难题呢？当时的我没有摆脱一直所经手系统的窠臼，一时间没有想到一个必然需要承载流量的系统，如何不 "成为" 流量的管道。现在回看这个问题其实是比较容易想到 "解法" 的。可即便我想到了解法，凭借自己的力量在当时也无法真的解决这个问题，因为有些问题其实本质就不在技术上，这也是在一些互联网或软件公司中架构师所需要经常性权衡与处理的问题。
另一方面则有些像是立场问题，如果外部企业通过接入 DataHub 来集成并使用我们的零售 SaaS 能力，那么与集团的开放平台有什么区别，为什么不通过集团的开放平台对外提供能力，哪些能力是集团的开放平台所不具备的？
这便牵扯出在集团内能力整合的背景因素下是否存在重复建设的问题。
就对外开放这点，集团的开放平台无疑在能力与经验等各方因素上都完胜 DataHub。不过正因为如此，这个问题倒相对好解，因为请求流量在 DataHub 内部是双向的，所以可以通过 DataHub 来集成外部系统，这是集团开放平台所不具备的。这个问题最终可以通过 "一个负责对外开放，一个负责与外集成" 的权责来化解。但是，对于 DataHub 来说开放能力也是要做的，只不过后续的能力要兼顾集团的开放平台，至少要有合理的解释可以说得通。
在大型企业内做软件系统开发，很多问题的复杂仅仅是因为要解决的问题并不纯粹，夹杂了很多企业内部、团队外部因素。而这些因素如非经历过，恐怕多少有些难以理解和想象，而各个企业所面对的又迥然不同。
解决了企业内部问题之后，让我们回到关于流量的话题，一个网关究竟要如何 "解掉" 流量？
其实，当时的我并没有解决这个问题，思维也陷入局限。估计当时我的直属领导也意识到这个问题，同时解决这个问题又很迫切，也请了架构组的架构师来协助处理。后来在架构组的帮助下，为 DataHub 的架构做了简单的调整，如此一来不仅 "解掉" 了流量的难题，同时也体现了多团队共建，这点在那个特殊时期尤为重要。
因为需要支持多端，如收银台POS、消费者侧的App与小程序，以及运营人员侧的Web管理端。除了Web管理端以外，其他端均有网关处理各端与后台服务间的调用，且都有其特殊的技术特点。所以，架构调整后的解决方案便是由 DataHub 提供 SDK，各端网关团队负责嵌入 SDK 实现后端服务的调用，而各端网关差异性的内容依然由各团队负责，而 DataHub 或者准确的说是由我负责的那个部分，则用于接口与服务的注册，以及具体服务的下发、切换以及访问控制等，这样看来倒有点像是微服务架构中的服务治理，这一部分加上各端网关组合在一起便构成了 DataHub，这是对其架构的主要调整与第一次重定义。
这种形式看起来像是现在流行于很多基础设施类系统中的数据面与控制面。也是因为集团基础架构对于 K8S 的封装，对于业务系统的研发其实整个容器平台相当于一个彻底的黑箱，好处是对于上层应用的部署发布只需要简单的操作即可，坏处则是直接屏蔽向下一窥应用调度部署的细节。这些也是后续我开始了解 K8S 开始才逐步意识到的局限。但是当下基于这些背景，我用了四个字来概括，至少是描述了我所负责的那部分 DataHub 的职责------旁路协管。
深水区
上面提到改进后的架构是各端网关以集成 SDK 的方式实现对接口服务的调用。与此同时，麻烦的地方也来了。一旦需要调整 SDK 与 DataHub 之间的通讯内容时，便会涉及到各端网关同步升级，否则就需要考虑待添加通讯内容的兼容性，同时还需要记录各端网关现在所使用 SDK 版本等一系列问题。
这些问题在一开始对于系统设计与开发影响并不明显，如果不是有相关基础设施类系统的研发经验，且对系统缺乏全面性思考的话，可能不那么容易发现。我也是在 DataHub 实际投入使用阶段才开始意识到这个问题，这里庆幸于一开始 SDK 与 DataHub 之间的通讯协议采用通用的 HTTP 协议，数据传输通过 JSON 格式，兼容性的问题显得没那么棘手。当然，这里并不是一开始设计上考虑到这些问题，而是对待需求方向不明确、开发阶段变化相对频繁的同类系统，在设计实现上的个人偏好。概括起来就是 "糙快猛"，更准确的说法是 "简单，易行，可交付" 。
对于产品或业务在探索阶段，系统设计不应该过度假设，不应将设计集中在不明确的地方，而是在这些地方留有余地，去使用最简单易行的手段完成开发迭代，这样当产品出现调整，业务出现变更时，系统掉头的技术阻力才不至于过大。
当然，在整个开发阶段，幸运总是显得匮乏，问题与困难常伴日常。
对于有一定经验的朋友应该多少会意识到一些问题，那就是通过上面的架构调整，其实 DataHub 的角色变更使得其复杂度朝向另一个方向前进了。它看起来更像是一个注册及配置中心了。不过对于 DataHub 来讲，这个新的角色职责所面临的问题，在当时的环境下，因为尚未投入正式环境的使用，一定时间内也不会有流量压力，短期内更不会需要多服务的实时切换。所以重要而不紧急。
下面要讲的，才是重要紧急，又真正棘手的问题。
毕竟 DataHub 属于 SaaS Native 体系中的一员，需要 Studio 与其协同并利用 DataHub 的能力，来实现 SaaS 系统的多样性表达。既然 Studio 使用 DataHub 的能力，那么似乎如何与系统能力提供方进行结合的思考理应由使用方来完成，那个时候我也陷入了这种思维惯性，导致对此事并不上心。
这就导致 Studio 与 DataHub 在协同上只是做了些表面工作。所以在开发者体验上既蹩脚又割裂，会为很多预想打上折扣。而同时因为自身并未去引导透过 Studio 使用 DataHub 的理念与方式，也为 DataHub 自身后续的产品迭代与研发节奏埋下了隐患，导致一直处于被动。
现在回想这段历程，自承接 DataHub 工作以来，我似乎一直没能完成身份的转变。处于一种需要我扮演的角色和我期望扮演的角色间角力的过程，这种拧巴的状态为系统的本就不平坦的生命周期，增设了许多障碍。这也算是是我后来执着于找寻架构与架构师的定义的一个诱因。
在往后的时光中，当我再次去思考两个系统工具间的协同时，也方才意识到诸多问题。抛开其他因素不谈，从产品与技术的角度出发。其实两个工具平台在整套体系中，一个属于开发态，另一个则是运行时，其核心之所在恰恰是运行时。所以从架构设计的角度，不论是产品架构还是技术架构，应该是由运行时指导开发态，更准确的是主导开发态，而不是使用及依赖关系来确定主导权。这也是上面我认为自己陷入思维惯性的原因。
除了 Studio 与 DataHub 这令人困惑的协同方式之外。其实更让人不解的是，在 DataHub 上注册的接口要符合零售业标准，换句话说在 DataHub 上我们要实现对零售系统标准的定义。
明明很好理解的一句话，为什么我会说让人更为不解呢？
这里牵扯两个问题，一个是接口的标准是什么？另一个即什么是标准的接口？接口的标准纯粹是技术问题，可以通过参考行业头部企业的开放接口来拟定我们的接口标准。而标准的接口则有点哲学问题的意味，需要多费些口舌。如果你想打造支撑零售行业的系统软件，理论上只要实现这些接口，便可以在其上开展零售业务。那么这些接口就应是标准接口，而这些接口便可以演化为行业标准。
这么一说似乎更容易理解了不是？上面提及的不解其内在更多的是对于问题的 "解" 和 "求解"。当我在试着去编写标准接口的示例时，发现这显然是一个很复杂的工作。
其复杂性主要体现在两个方面，这两方面也与接口定义息息相关，一个是模型的定义，另一个是接口包含动作的含义。因零售行业售卖物品包罗万象，如果采用一个大而全的模型，会使得接口的理解变得复杂，那么很难称其为标准。而为了使模型易于理解同时准确表达，那么同样一个接口面对不同品类需要呈现的内容可能是不同的。同时面对不同的业务流程，其接口含义与数量也可能是不同的。而品类与流程区别恰恰对应了售业的细分行业与领域。所以，虽然是两个方面的复杂性，但经过笛卡尔积的叠加后复杂性也承指数上涨。
同时暴露了一个问题，虽然我所在的产研团队具有多年零售系统的建设经历，但其实对零售系统建设的沉淀并未有与之匹配的底蕴，未能突破经验从而形成体系。也就是如果要梳理出能称之为标准的事物，可能需要对产品以及系统进行全盘的梳理，再归纳整理出可用于形成标准而展开探讨的功能与模型。
那么，在这个背景下去要求研发人员在 DataHub 上注册的接口必须是标准接口这件事，短期内显然不太现实。
与解决这两个棘手的问题来讲，有时候可能想那么多也并不是办法，总之先跑起来吧。说句看似调侃的话，对于系统设计来说，不让飞机飞到空中，工程师们都不知道该如何换引擎。
搁浅
随着一个新项目的立项与推进，DataHub 正式投入使用，与 Studio 一道接受未知的检验。一些同事也踏入了这片名为 SaaS Native 的试验田，成为了这两个平台工具的使用者。工作似乎开始进入陌生而又熟悉的模式。
很多基础架构的研发会自嘲每天的工作就是客服。在 DataHub 正式投入使用之后，这点我们也深刻的体会到了。一方面不断完善系统文档，站在开发者使用角度增加 Q&A 条目。另一方面在系统上增加 TroubleShoot 的能力供使用者自行排查。每天处理问题，解答疑问。时而组织会议宣讲，时而在团队内吐槽调侃。基架就是客服的时间，却是在整个 DataHub 建设过程中难得快乐而又短暂的时光。
在此期间，我时常被问到 DataHub 是什么的问题。我渐渐地发现竟然三言两语解释不清，在我似乎以为逐渐理解它的时候。我也时常听到对于这两套工具的使用所带来价值的不解，面对这个问题显然我也一样困惑，甚至作为其中一个工具的负责者，我的困惑可能还要更深层一些。
但即便如此，在我思想的某个角落里一直回荡着一个耳语，这个方向是没有错的，是一种解法。
早些时候的软件行业很喜欢拿建筑行业来做类比，就连架构师这个词都是舶来品。但是即便身处一个庞大建筑的施工过程中，即便你只是一名普通的基层工人，每日的工作只是搬砖卸货，身处整个施工队伍中的一个细小局部，你依然可以看到建筑一天天成型的变化，逐渐长成蓝图描绘的样貌。但，软件系统的开发却不尽相同，有时候一名普通的工程师可能永远也看不到系统全局的轮廓，时间久了，亦会对自己这一隅模块、功能的意义愈发怀疑、倦怠。
一个 技术/产品 团队的负责人需要为其他工程师描绘那个一时间看不到的未来，而架构师有责任为其他工程师指明通向那个未来的路径。但信念的有效且真实的传达是复杂而困难的，尤其对长时间在黑暗中摸索的人，何况是一个群体。
因集团战略布局，需要重点攻坚一个新业务，整个研发团队的负责人也随上级调岗到对应业务条线。有关 DataHub 的进展也暂时搁置了一段时间，并且原本抽调支援 DataHub 研发的同事也陆续回归原业务团队，而我的主要工作也回归了原有系统的开发工作，DataHub 也自然进入仅需最低人月的运行维护时期。随着整个部门的人事变动逐渐平稳后， DataHub 也准备移交架构组负责维护与后续建设。
与此过程中，我也选择了离开这个自打入职便共事的团队，而后在集团大数据团队短暂的停留数月，最终告别供职 1000 天的老东家。而 DataHub 究竟是什么这个疑问则像是达摩克利斯之剑一样，一直悬在我的头脑中，影响着我的职业路径，我也执拗于将那个耳语变成清晰的陈述。
未完待续