【万泉河】PLC行业也可以有架构师

说实话， 这个题目酝酿很久了，然而因为很难写，所以一直拖，拖到2021年底了， 下定决心一定在年底之前把这个话题了结掉，或者说把这个种子先种下去。

为什么难写，因为我自己对架构师的理解都不够，没做过IT行业的架构师，也没见过几个正式的架构师，现在对PLC行业的架构师的认知，就只能猜了。

PLC行业，大部分方面是可以对标IT行业的。 而且会有一些工程师，是从IT行业转行过来的， 同时也总有许多工程师， 做了几年PLC行业之后，不满意PLC行业工作辛苦，出差多，待遇低，咬咬牙参加些IT培训，然后成功上岸，离开PLC行业，去专心搞IT去了。

我在今年里， 分别组织探讨过PLC行业的代码开源， CODEREVIEW等等，结果暂且不论，但根源都是在于与IT行业的对标， IT行业存在的理念和方法，都可以在PLC行业找到对应的存在。

所以，当我们把IT行业的通用做法了解一圈之后，当PLC行业发展到一定的程度，系统足够强大，做出来的应用设计足够复杂之后，自然而然应该想到， 在IT行业中存在的架构师，似乎也应该在PLC行业对标出现了。

架构师的功能与概念是什么？

其实从名词的字面含义即便一个外行都可以很容易理解，负责把持大原则大方向的架构。

然而具体要做的工作是什么？不清楚。

那么，让我们参考一下IT行业架构师的技能要求：

架构师必备技能（目标）

1、技术实力：每个好架构师都是NB的程序员

1)、解决解决方案：产品团队要做一个产品，架构师要帮助团队把技术可行性，技术方案权衡取舍一一剖析清楚；

2)、架构设计和技术实现步骤

3)、编写核心模块：

4)、部署上线和完善流程：

2、业务理解和抽象能力：驾驭概念的技能是最高潜力

3、设计能力：前瞻性的设计眼光，站在技术的山顶向前眺望

1）、掌握最新技术：

2）、分析整合能力

3）、前瞻性地设计

4、技术深度：透过问题看本质，解决问题和绕开问题

5、技术广度：要成为百科全书式的智者

6、沟通能力：善于沟通的技术领袖

7、系统性的思考：权衡利弊，只有合适没有喜欢

引用自：https://www.sohu.com/a/371210866_99908665

这里只引用了大纲，具体细节内容看原文。

这里大部分只讲了抽象概念性的要求，大部分可以借用到PLC行业架构师工作内容。

而对于具体的技术需求，随便另外找了一篇网文，这里只是JAVA架构师：

总之， 一眼看下来， 是一大批几十个上百个专用技术名词。

具体名词就不一一列举了， 总之，放在PLC行业，一概用不到。

所以对PLC行业架构师的技术能力需求列表，看来还需要对标枚举一大堆名词才行。

这个需求列表， 就不是当下的我有能力做出来的了。整个行业目前都还没有架构师，我自己当然也没做到架构师，自然就没有能力也没有资格来下定义了。

所以，不管是现在还是将来， 都不会有一篇名字叫做《【万泉河】PLC架构师技能标准》的标准出世。

所以一直以来，有许多同行见到我提PLC标准化编程就反对，怕我占据了制订标准的先机而割了他们韭菜，直到我主动把我推广的技术定名为PLC编程烟台方法之后才有所缓解。

现在我猜测， 这些人反对的应该是这个PLC架构师标准。

不过， 我纵然没有能力定义PLC架构师的标准条目， 然而我现在就知道哪一些要求是不该被落入到标准之中的。

比如有人看到名词很多，说那我们PLC行业加上传动，名词概念也很多啊！也全都罗列上呗！

各种PLC厂商品牌， 变频器， 伺服控制器品牌， 触摸屏，上位机软件品牌， 数据库， 通讯网络， 传感器、仪表，有多少列多少，咱也能列上个几百个。

我说，这肯定不行。

任何一个公司， 有机会采用的供应商品牌都是有限的。 公司会说了， 我这儿缺一个得力的架构师呢， 你给我来个所谓架构师，懂的技术，仅仅比我原本的工程师多懂了一些其它品牌的产品应用，这对我公司业务没有任何好处啊！我不要这样的架构师。

这里面涉及了一个著名的公案。

我和某网站的某版主发生的公开的分歧。

我表达过， 一个工程师， 如果工作经历，从事的PLC产品品牌越多， 说明其加入的公司（盈利水平）越烂，个人技术水平也不会有机会得到大的提升。

简单说，就是天天忙活学习熟悉新产品去了， 凑副着把项目干完交工就烧高香了， 哪有机会对某一个品牌技术静下心去专心研究----------这是我一位朋友跟我说过的原话。 我俩认识多年，有一次突然发现他还会某个小众PLC品牌的应用，他告诉我以前的工作经历，在某个小工程公司工作过一两年， 啥破烂项目都接， 遇到过这些产品，都是被逼着学会的。

而倒过来，业界公认的西门子技术大咖，大都在西门子技术中心， 或者专职专注做西门子业务的集成商内部，他们十几二十年心无旁骛专注于某一项技术，研究越来越深，越来越专，水平自然可以越来越高。

这在我看来是一种不言自明的常识，然而在一次发帖后得罪人了。 有某版主对此言论大加批判，而且还截图发帖，作为证据多次批判。

其实，我也挺需要对这个截图的帖子截图呢！可惜没心情去翻了。

上面这段话，欢迎再次截屏批判。  

有一个谚语，如果你闭着眼往狗群里扔一块砖头，叫的最响的那个一定是被击中的。

我猜，这位就是一不小心被击中的。

我们一直认为， 一项技能的含金量，一定与获取这个技能付出的汗水多少有关。 如果一个技能，轻轻松松花两三天就可获得，那注定没有多少含金量。

对于PLC来说， 它本来就是个低代码应用平台，如果简单应用为目的，门槛值必然不会太高。 各厂商在开发时都以简单易用容易上手作为目的，而且还会附加各种手把手教程甚至视频都有，一个稍微有一些行业经验的工程师，安装软件玩弄几天，基本就可以开工干活了。 这是他们的目标，而代价就是你从中获取的个人价值提升并不会太多。

那么， 一个成熟的PLC工程师，如果不满足于当下的职位技能， 想要提高，想要突破自己，做技术团队的带头人， 要做到架构师的资质，应该怎么做，应该学什么？

说实话，我目前还真不知道。 对我个人来说，也是个努力在争取发展的方向。

我在描述PLC编程烟台方法实施后的团队分工时制作过一个图片：

我把其中最顶端的定义为主任工程师，我觉得这部分的工作应该比较接近于架构师了，但还不够，在其顶部之上，还有许多需要提升的空间。

所以， PLC编程烟台方法的本质， 不是教会学员去如何做PLC行业架构师，而是带领有志于成为架构师的同行，我们一起去摸索探索成长为架构师的途径。

未来， 如果再有人问起学习烟台方法有什么前提资质需求的时候，我会给出两点：

1，  目前的团队技术带头人，有计划成为架构师的工程师。

2，  目前虽然不是技术带头人，或者压根没有团队，但个人有树立职业规划目标将来成长为PLC行业中的架构师。

将来，技术发展成熟，行业中已经自发成长起来一大批合格的架构师以及准架构师的时候，整个行业已经可以达成共识，可以为整个行业制定标准的时候，大家再一起商议，制订架构师的标准。 站前台的主持的会是你们。