人生何处不架构：Tieto、SONY架构实践

本文转自：mp.weixin.qq.com

9月初的某一天，一位朋友的几个问题一下子把正吭哧吭哧敲键盘而处于自High状态的我拉入了一段冥思之旅。是啊，什么是架构师？架构师一天到晚到底在做什么工作？ IT领域中有架构师，其他行业有没有？

这是一个甚为庞大而又严肃的问题。而且，可以预料的是，不同人的答案，甚至同一人不同时期的答案都会千差万别。不过，没有标准答案有关系吗？没有。所谓“一花一世界，一叶一菩提”，或许我在本文中分享的个人经历和一些思考的结果能给大家带来不同的启发。当然，最好希望大家看完此篇文章后，能认可并认同本文的标题，即“人生何处不架构”。

什么是架构师，架构师到底在做什么工作

什么是架构师？这个问题的答案其实就是“一千个人眼里有一千个哈姆雷特”。我个人对这句话的理解就是：架构师是一个公司的职位，不同公司中架构师的职责（也就是架构师的工作）不尽相同。当然，我的理解来源于自己的经历，大家不妨一看。

我是在2012年9月第一次以架构师的身份加入欧洲最大的IT服务公司Tieto来工作的。当时Tieto正处于从Symbian平台全面转向 Android平台的关键时刻，很多同事对Android的认识还不是很全面，虽有大量零散Android开发经验，但还没有系统成型的知识和经验积累。那么我在Tieto作为架构师，具体的职责和工作内容是怎样的呢？

引用

首先，不论对团队，还是对公司而言，提升团队成员在Android方面的技能肯定是最最重要的工作。于是，我根据自己对Android的理解和经验，将团队成员按特长和相关技能熟练程度，划分到各个模块，构建领域小组。这种划分需要充分考虑到团队规模，各知识模块的难度和重要性，还有公司自身在某些技术领域的积累，甚至公司为各个站点（比如北京site，成都site，波兰site）设置的中长期发展规划。所以，最开始我们只划分了 Framework模块，USB和MTP模块，App模块等。后来，随着我们引入Linux内核和多媒体几位专家，BSP模块和多媒体模块随即建立起来。最后，当我们发现公司在Wi-Fi，蓝牙等领域有非常深厚的技术积累时，我们又设置了Local Connectivity模块，主攻WiFi。
除了技能提升这样一个长期工作外，我还要带领团队顺利完成公司的项目。这是Tieto北京第一次以一个团队的形式参与的一个多站点联合实施的 Android系统升级项目。项目的主PM（Project Manager）是波兰人，项目的大部分模块由Tieto捷克站负责，Tieto北京站负责Framework，USB和MTP，部分APP以及测试工作。在项目中，我的主要工作是和Main PM以及北京的PM一起制定工作计划，校验阶段性工作成功，并根据当前结果合理安排下一阶段的工作任务。在团队内部，我们负责的各个模块也采用了敏捷开发的工作方式。另外，定时汇报，提前预警，关键区域加派人手也是我们经常采用的工作方法。另外，为了加强其他站点对北京团队技术实力的认可，我们还会设置不同的攻坚小组（Task Force），积极主动去完成一些难度大，富有挑战性的工作。

通过这些项目，我对架构师的职责有了一些深刻的认识：

引用

对于这种有明确工期的项目制工作而言，架构师一定要了解常说的Big Picture，即项目甚至项目成员的整体情况。要搞清楚哪里是薄弱环节，哪里是关键环节。完成今天的任务后，下一步工作是什么。后续任务中有没有风险，有没有坑。什么时候，是否需要，以及需要什么样的外部support。
另外，对架构师（或者对项目所有成员）而言，有问题绝对不能藏着掖着，一定要尽快尽早提前暴露。
最后，架构师要和PM、测试组密切配合。大家都在同一战壕，所以思想要统一，目标要一致，节奏要配合。

除了项目外，我们在学习方面也是有一整套计划和目标的。前面说了，我的一项非常重要的职责是提升团队成员的技战术实力。项目可以做完，学习却不能停滞，而且还必须紧抓最新的技术趋势。所以，这个项目做完后，我们紧接着就在BSP、多媒体和Wi-Fi等模块痛下苦功，积极钻研。到我离职的时候，团队成员在这几个方面还算颇有成绩。一共在《程序员》杂志上投稿6篇，出版专著一本，并在2013年中国软件技术大会上重磅亮相了我们的Android多窗口技术解决方案。

从Tieto出来后，我加入了SONY移动，职位是资深架构师。作为一个世界知名的老牌企业，SONY在多年的发展过程中，培育了一套具有独特特色并高度成熟的工作流程。其架构师的工作及职责更是值得一提，以为一款手机升级Android操作系统的项目为例：

引用

每个项目都会设置一个Project Arch，简称PA。PA的职责非常重要，可以看做是整个项目在技术方面的头羊。PA和项目经理（也包括其他成员）会一起制定和把控项目进度。在技术的疑难杂症上，PA会出面召集相关人员进行会诊。并且PA需要在重大技术问题或者分歧上给出关键意见，甚至有时候需要作出最终决策。据我自己的观察和体会，PA的候选人并不是片面强调他是否为某个或多个技术领域的专家，而是需要候选人有丰富的项目经验，较强的沟通能力，团队精神和敬业精神。并且要求PA 有很高的风险意识。所以PA需要经常性得查漏补缺，需要根据测试定期发布的测试报告来判断软件质量是否下降，是否有潜在而未发现的问题或风险。
除了PA外，每个项目还会有1到2个System Arch，简称SA。SA主要偏重Android系统层面的技术部分。比如性能调优，功耗等这些牵一发而动全身的问题。SA经常性的工作还包括手机系统崩溃分析，以及一些奇奇怪怪的疑难杂症。有趣的是，SA和相关的工程师团队在SONY有一个特别的名字，叫MiB（Man in Black，黑衣人）Team，其意思是MiB组同事们的工作内容好像不是那么明显，但是却为手机系统的稳定、流畅做出了很有价值的贡献。
接下来，在Android每个子模块都有一位SubSystem Arch，简称SSA。SSA基本上是各模块的技术领军人物了，他在该领域具有绝对的话语权。包括代码review，技术方案的选择，该领域相关问题的解决都由SSA来负责处理。SONY的SSA高手云集，其中有一个非常年轻的负责Kernel的同事最后被苹果中国录用。这是他个人的骄傲，也是我们这么多同事的骄傲。
最后是测试部分，测试组会有一个Verfication Arch，简称VA。VA主要负责测试部分的重难点技术问题。比如设计测试case，自动化测试工具开发、测试流程优化等。比如我们在性能优化方面做了不少工作，但是如何评价优化的效果呢？这就需要VA和我们配合，设计一套合理的测试case。

由此可见，虽然各架构师的职位一样，但是在SONY的项目中，架构师的具体分工也是有很大的不同。

还是“架构师”吗？

当我回答完上面的问题后，这位朋友接着问“你现在还是以架构师的身份在民生银行总行科技部工作吗？”从我所擅长的Android智能设备领域来看，民生银行目前还没有在这个岗位上设置架构师这个职位。但大家可以看看我在这干得工作，然后和之前我在Tieto和SONY的经历比较下，就会发现有很多类似的地方，目前我负责民生银行智能POS机的技术部分，工作内容包括：

引用

设计和完善民生银行智能POS系统规范。一方面，我们需要引导和约束厂商必须遵守此规范，另外一方面我们也非常希望厂商能发挥自己的主动性和优势，把最新，最有价值的内容带入到我们的规范。从某种意义上来说，我感觉民生银行和Android生态系统中的Google的角色有些类似。
另外一方面，为了吸引开发者到我们POS平台上来开发APP，我们已经开发和提供了一套完善的SDK和文档给开发者。我们的目标是让使用了这套 SDK的APP不用再过于担心系统的碎片化问题。同时，鉴于POS机对安全性的严格要求，我们对APP的审核也有着一套高标准的要求。
最后，在一些POS机的关键应用上，比如银行卡支付应由，我也需要摸透它，并最终能自主开发。

所以，我个人感觉虽然现在没有架构师的职位，但干得工作却和之前没有太大的不同。从技术领域看，只不过从Android手机转向了智能POS。

人生何处不架构

回顾我投身软件行业的8年历程，从不是架构师到成为架构师，再到不是架构师，这一路下来颇多感触。真的只有拿到架构师头衔才能被称作架构师吗？此问题的答案必然是否定的。我本人或者其他所有人，其实在工作中都或多或少扮演了架构师的角色，比如：

引用

我和机工出版社的杨福川总编辑一起策划并组织编撰了《深入理解Android》系列丛书。每本书从策划，到寻找最合适的作者，再到编撰过程中给予作者及时有力的支持，直到著作的最终出版，这其中都有规划，执行，反馈，再规范，再执行直到结束。
当我的水电系的同学们，坐在电力调度中心，参与电网发展规划、系统设计，组织编制和执行电网年运行方式、制订月、日调度计划，等等等这些工作，是不是有架构的概念？

生活中就有更多地方能发现“架构师”的影子了，大到举办国庆阅兵，小到举办一场家宴。远到当今很多父母早早就为孩子的未来发展精心设计蓝图，近到周围很多朋友计划生二胎。做这些事情的人，在我看来，他们都是架构师。为什么？

引用

架构师心中有规划，他了解Big Picture，知道现在在做什么，下一步要做什么。
架构师有执行力，不论是他还是别人制定的规划，架构师都会认真去执行，并及时反馈执行结果。后续规划会随着反馈情况适时调整。
架构师有风险意识，哪里有风险，架构师需要及早判断和观察到，并能采取有力的措施以规避或减少风险。

这么说，好像人人都是架构师，那架构师还有什么意义呢？其实，不是很多人能意识到，在漫长的人生旅途中，自己一直都在扮演一个架构师的角色。回归到做程序员这份职业而言，难道不是架构师就不应该积极主动去了解自己正在参与的软件开发项目的Big Picture吗？难道不是架构师，你就不应该深挖一个bug背后的问题和知识点么？难道不是架构师就不应该为自己设立中长期的学习规范并付诸于实践吗？

当你想明白这些，你就是架构师，你就应该按着架构师的要求来看待自己。而那些你当前正羡慕着的，有着架构师头衔的人，我相信他们只不过比你更早一点想明白这些道理罢了。