制造业领域，我是如何被逼到做顶级架构设计的
什么是顶级？还是澄清下吧；
这里的顶级并非说“最牛&”、最高档次，而指的是在开发一个复杂系统或软件时的最高层次设计的过程。
接下来，我要介绍的是，我是如何被逼到从单业务系统到系统与系统层面的顶级设计。
现状
说说制造业这个行业吧；
只针对软件部分
我是互联网出身，在制造业领域截止目前也只待了大半年，说说自己的感受；
卷，但并没互联网模式的卷；
它的重心，在于创新和降本，在特定方向发力，抢占更多的市场。比如工业化机器人，你得应对市场不同需求场景下提供快速解决方案。软件的价值，更像是工业化产物的附属品，起不了主体的作用，它的核心竞争力在实体，甚至很多软件系统，都是只白给。
场景1: 你根本不懂我
企业不会把太多的精力放在软件上，自然而然，重视度、人员配置就不能跟互联网相比，很多的软件系统，最开始可能只是一个想法，直接给到研发。
在这种以结果导向的模式中，很多信息在传递过程中，就已经失真了，而结果也是可想而知，在软件后端的实施过程中，往返来回的折腾。
场景2: 你懂我，但不完全懂我
在一个团队中，往往会将职能岗位规划成一个个独立的团队，比如专门做仓管系统的团队（WMS）、视觉团队（天眼）、云团队、调度团队（RCS）...
由于业务职能与技术边界性问题，职能团队往往都只会专注在需求中拆解自己职能团队部分的职责，团队与团队之间，存在很多技术壁垒与理解的偏差，客户的一个需求，在这个过程中，可能就演变成无数个系统交付给客户，增加交付的学习成本与复杂度。
最终变成，既没有满足客户需求，系统不断在现场做整改，也没有完成标准化产品交付，非标类变多，标准产品也早就名存实亡，即使是标准，也会在这个过程中变成非标。
这里面有很多隐晦的环节，是无法公开表达的，有美丽、痛苦挣扎、无奈的，感兴趣的伙伴可以私下与我交流～
破局
回归正题。
这里分享几个阶段的历程，在这段经历中，首先介绍下团队的组成；
不全是，组织结构只是为了梳理下文的流程
所有的产品项目，大部分均是开发人员根据市场规划给的需求进行理解开发。
以下会用几个具体的案例来介绍这段历程。
向介绍下背景，由于非标项目种类多，业务需求场景复杂，所有项目团队，在自己的业务线上，很少会关注到彼此之间业务的关联，虽然整体方案是闭环，自身设计上也能实现闭环，但在更高层面的应用架构上，是零散的，当遇到需要多端集成时，往往大家都很被动，没有形成流程规范，很多功能都是临时被动设计。
顺从
case 1
接触的第一个项目，车辆HMI，一个针对车辆使能的控制系统，里面涉及到一些图形处理与算法，其目的就是在车辆进场之前，需要使用HMI为车辆使能施工。由于工期紧张，只有两周的时间，需要开发车载端与手持端（h5、pad），并没有时间去思考它的业务场景与逻辑性。
以下为车载部分功能：
由于没有产品的角色，很多功能的使用场景，更多的是来源市场反馈与开发者本身对业务的理解而进行开发，很多业务之间的衔接性都很差，导致后期投入市场，反响都不是特别理想。
case 2
智能仓储管理平台（WMS），主要的业务是针对仓库里面的货物进行出库、入库、盘点、任务下发操作。核心的功能就是监控仓库的库位状态。整个产品体系分为：pc端、移动端、PDA、大屏监控。
在这时，你就会发现，两个系统，他们都有任务下发的功能，从原理上来说，都是给车下任务，只是车载的任务，下发给的目标是很明确的，而WMS下发的任务，目前来说是模糊的，它只关心仓库货位状态，并不关心具体的任务下发给谁了，谁来执行。
case 3
调度系统，主要负责整场车辆的调度工作，包含车辆使能前参数配置、路径规划、任务调度、任务下发等功能，核心在于控制车辆之间的调度与交管问题。
这时候不难发现，调度系统，也有自己的任务下发，它也不是具体的，但它能清晰的规划自己的任务规划路径，以及为了完成一个任务，需要调度哪几台车。
总结下以上几个场景；
以上几套系统，都用一个共同点，他们都有任务下发，从深层次讲，所有的任务，最终都是为了控制车辆，变换的是过程，结果都是殊途同归，就像溪流最终都会汇入大海一样。
思考
上文只是众多业务场景中的一部分，类似系统之间的壁垒和冗余，只要深挖进去，就会发现，核心目的都是为了控制车辆完成任务。其中有些环节，不管是哪一端的业务系统，都是必经之路，有大有小，小的点，如果不跳出单独的业务体系去看，就很难被发现。
那么，接下来，我们看下独立于各业务系统之外的项目，在做资源整合的过程中，我是如何将几个业务系统串联起来的。
以我的专栏项目 3D数字孪生 为例：
它的数据来源涉及到几套上层业务系统，随着业务深入就会发现，不管是前端直接对接各业务端，还是由服务端开发去对接各个业务系统，都是让人很膈应的一件事。每个端的标准规范不一样，提供的数据不一，牵扯到的人越多，协同也会变难。
举个例子：
WMS系统中的库位点，并没有记录RCS系统中的实际坐标点，因为WMS本身并不关心车辆路径，它只关心库位的状态，而当在2D与3D数字孪生中，我们需要能真实的体现车辆的位置与库位状态，就需要将两端的数据做绑定。
为了让RCS与WMS中的坐标点与库位点绑定，中途提出了一套仓库编辑器，其目的，就是拿到RCS的点位数据，并在点位的基础上，绘制库位、区域、巷道的位置，生成一套与WMS数据一直都规则的数据，同步到WMS中。
但是，这种系统，也只是过程中的临时产物，只是为了服务实施人员与开发人员在涉及到跨端做数据同步的时候，所采取的一种应对方案。
于是，我再一次向领导提了建议：数据汇聚平台的诞生。
核心的目的，就是建立一种广播机制，所有平台数据，都会汇聚在一个地方，业务端只需要去订阅广播，我不关心数据的来源，这样既能实现多端的技术统一规范，也能随时得到自己想要的数据！！
当然，这只是站在前端的角度去提业务需求，但最终也是如愿PR成功，立项开发。
实践
这里跟大家分享一下我的做事方法论，在准备做一件事之前，一定！一定！一定要先构思好自己的框架，可以从简单的思维导图、时序图再到流程图、类图等工具，去帮自己梳理思路，提前规划好可能会面临的问题，以及如何应对。这样在面对各种质疑的时候，才能毫无破绽。
以上记录，可能比较繁琐，更多的是分享一种思路与方法论，中途还做了很多的资源整合优化，感兴趣的小伙伴可以找我交流～ 随时欢迎。
前端组内部还做了很多的技术架构设计，也都是基于业务开发后的思考沉淀的产物。
比如大屏可视化架构搭建，前期的组件库与技术选型，可以理解为物料准备阶段，后期规划做3D、2D可视化大屏编辑器～
好了，喜欢的伙伴可以关注我，后面会规划将这套体系做分享和开源（可能会比较漫长～）