多数公司的技术体系都是团队作战，需要分工协作，无论正式还是非正式甚至是临时的领导者角色，或者只是团队中的普通一员，都需要具备与团队一同达成目标的能力，借用冯唐的书名，要有跟团队一起“成事”儿的能耐。行业里有名的亚马逊领导力准则，可作参考。
作为架构师或者架构团队，更需要具备综合的软技能，与技术团队合作，推动架构演进，支持业务发展。
2012年我去当当做架构师，后来负责架构部，到2016年离开，4年之中做了一些事，积累了一些成果。在架构领域的总结思考，关于什么是架构什么是架构师架构师应该具备哪些能力的话题，在中国系统架构师大会上分享过，总结后发在公众号上，名为《架构师的自我修养》。今天跟大家分享的是成长过程，换一个说法叫什么呢？“那些年，我在当当做架构的日子”！
那些年都做过什么呢？挑重要的列出来：
2012年——招商平台重构
2013年——多数跨系统项目、订单重构规划
2014年——架构规划、技术栈转型
2015年——应用框架、开源组件
2016年——基础平台
2012年6月我加入的时候，当当没有完整的系统架构信息。有多少个系统？技术团队三四百人都在做什么？各个系统是什么关系？出了问题怎么判断定位？都不清楚，只有一张很简单的架构图。刚去的时候我也一头雾水，形象的比喻就像是一朵云，在外面看是一大坨，不知道里面什么样子。幸运的是在9月份我参加了招商平台重构。这个项目希望重构第三方商家入驻卖货的系统——招商平台，与当当自营商品销售的整个流程打通结合起来。
这张图分成三个阶段来看。左边是自营电商系统阶段，比如当当最早就是卖书，后来扩充了很多品类，百货、服装、3C、孕婴童等等，还都是自营。接下来是平台并行阶段，京东也是这样演化的，不像淘宝天生就是个平台。尝试新业务模式一般是这样操作的——主营业务有一套成熟的系统，因为不知道新业务能不能做成，最好的做法是外挂一套系统。并行阶段系统前台用户端是一致的，后台所有的系统都是分开的，是两套体系。希望达到的最终目标是一个平台，右边这个图的样子，只有一套系统，像淘宝那样，自营是最大的商家，减少重复的轮子。
但这个目标没达成，我们梳理了整个流程，发现如果做成真正的平台，步子太大、伤筋动骨、成本高、难以短期见效。最终方案是把商品、库存、价格、订单等系统尽可能的结合起来，让外挂系统更轻。这个项目对我帮助非常大，完整的梳理了一遍招商平台，真正的了解了电商系统和业务流程。毕竟只作为消费者很难想象几百人搭建的电商系统的实际架构。
其实并不存在订单重构这个项目，订单系统当时是.NET+SQLServer，迟早要重构。CTO和负责的总监发起了一个架构规划任务，如果订单系统要重构应该怎么规划，我们就去搞清楚订单系统的情况，有了一些思路，主要是通过解耦带来灵活性。正好2013年我们做了很多跨系统的项目，其中有一些与订单相关，比如说一品多促销、手机专享价、预售、预约送货、礼品包装、虚拟捆绑、就近巡仓、合约机等等，做的过程之中把对订单的想法落实了下去，使订单系统功能更强大。
右边的入驻外部平台是什么？现在当当在天猫上有旗舰店，当年在1号店也开过店，跟苏宁也谈过合作甚至都开发完了最终没上线。大家都是平台优势互补合作共赢，这种业务模式大同小异，就是作为商家入驻外部电商平台，需要同步商品信息到平台，从平台同步回来订单信息，再把物流配送信息同步过去。
架构设计需要考虑未来的可扩展性，把外部平台作为渠道，可以开多个店铺，要有相应的标识区分，这样核心功能确定了，入驻新的平台或者开新店只需要增加配置项即可实现，需要额外做的工作只是对接接口和做数据转换。作为核心系统，订单系统要具备业务扩展性，不能只靠外挂解决问题，而且要从更本质的业务模型上进行抽象，用一种扩展设计模式支持多种新的业务模式，提供可行方案令业务设想成为可能，而不是设置各种条条框框。
2014年初我开始负责架构部，开始扩充架构师团队，提升架构部整体能力。架构部要做架构总体规划，分为两部分，业务系统架构和技术架构。业务系统架构规划是一张蓝色的图，名副其实的蓝图，体现系统间的层次和关系，能让老板一眼看明白，不是技术层面的应用架构图。说一个“关键点”，几乎每一个框里都有4个功能模块，这正常吗？当然不正常，就是为了美观大方，所以主要是展示一个体系，一个思维模式，便于快速理解，并不是用来做系统设计。
技术架构图里比较特殊的是三种技术栈并存，原来的有php，主要是前台，有.NET，主要是后台，在12年才开始有JAVA。互联网电商行业主流的技术架构是什么样？技术组件平台化，用现在流行的说法叫技术中台，包括MQ、缓存、数据库、作业调度、搜索引擎、大数据体系、各种中间件。整体技术架构也用一张图展现，比较偏概念，之后根据不同的领域进行了调研和选型。画出这两张图，意味着在业务和技术两方面具备了行业视野。
经过了前面的规划和选型，我们发起了一个项目叫DDFrame，要研发一个应用框架，集成各种组件，统一技术栈、形成完整的体系，由张亮主导。其中的SOA组件选用Dubbo，然而Dubbo当时暂停更新，社区也不活跃，我们用着发现了一些问题，沈理提出我们可以自己改bug，该升级的版本升级，所以我们做了个DubboX，在功能上支持REST调用，适配当当多技术栈并存情况。因为Dubbo本来是开源的，我们反哺社区，把DubboX也开源了，解决Dubbo不更新的问题，行业里很多公司用过。做了DubboX之后我们发现做开源并不难，或者说已经有足够的能力做开源，所以就接着做了Elastic-Job，因为用阿里开源的TBSchedule也是不太爽，不如自己做一个分布式任务调度框架。不像DubboX在现成的项目上改，Elastic-Job是自己从头做，而且不涉及到数据库操作，那时候Docker也没发展起来，相对挑战难度不大。在这种情况下做了Elastic-Job之后，证明自己做一个全新的开源项目也OK，所以后来也有信心做分布式的数据库中间件Sharding-JDBC，现在张亮把这个项目做成了Apache项目ShardingSphere。当当架构部推出的开源项目在行业里产生了一定的影响力，体现了当当的技术水平，提升了技术品牌。怎么体现呢？我们招聘的时候，不会被反问你们当当的技术栈是什么样的了。
到了2016年，我们开始做基础的平台。为什么做基础平台？这就说到技术体系的运转机制了。技术团队的工作，从需求提出到功能上线，再升级迭代、持续运营、到最终下线，要可控可量化可追溯，需要一整套系统，包括项目管理、自动化部署、监控告警、问题跟踪。项目管理，结合敏捷开发方法论，贯穿了需求管理、架构评审、任务看板、工时统计。自动化部署则要支持多环境的管理、发布前自动备份和恢复，以及灰度发布。上线之后，对生产环境应用进行监控，有问题需要及时报警。不管是告警还是线上问题需要跟踪处理，超时自动升级，处理完毕就要关闭。通过基础平台，我们对整个软件产品生命周期进行数据化管理，用系统化的方式支持技术团队的工作，对技术团队的整体能力提升有很大帮助。别看技术公司做产品做项目的时候提起数字化信息化产品化工程化SAAS化智能化头头是道，自己的内部管理很多还停留在基本靠人的水平，这也算是行业里一个值得玩味的小小悖论。
架构师进入新的团队，要成长，要成事儿，时间线如上所述，如果换一个视角来看这个过程，有四个要素：学习、适应、合作、驱动。这四个要素也是层层递进的关系。
第一，学习，了解业务现状，了解行业，要有行业视野，知道行业历史和发展方向；
第二，适应，融入团队，团队氛围什么样？有哪些工作流程？组织是一个什么架构？管理风格什么样？怎么做决策？
第三，合作，跟团队形成合力，产出成果，不断的沉淀一些东西出来，积累信任。
第四，驱动，需要多分享、做一些铺垫和引导，提高影响力，获得认同，形成共识，一起达成目标。
我去当当是做电商系统架构，之前没做过，作为消费者，只有一些很浅薄的认识。怎么办？主流的电商网站都打开对比看区别是什么，有点像产品经理做竞品分析。做架构更要深入理解业务，不只是看功能、流程的差别，要去理解内部机制和外部市场的异同。当时多数电商网站都差不太多，暖色系主题，刺激消费欲望，只有当当是绿的，还有不走本地化路线的亚马逊。后来当当也改成了红色主题，还把“网”去掉了。为了体验和感受电商，我在各大电商都下了不少单，最多的肯定是当当，买了不少书，有些至今未开封。
还有一个途径是看行业的书或者视频，当时电商的书很少，不像现在一搜一大堆，基本上能找到的书我都看了，还好也不多，不用挑。《电商风云》是纪录片，吴晓波策划，中央2套拍的，一共7集，挺好看。新进入一个行业，要从各个维度去找权威的人、权威的书或者权威的媒体，最好是成体系的。看书不能只看书的内容，得知道作者是谁，有什么背景，要用系统化的思维去吸收理解。左边的图是一个文件目录列表，是参加各种技术大会收集到的PPT材料。我们在当当文件服务器上建了个共享文件夹，大家都往上传。这些资料能开阔视野，如果关注一个专题，比如风控，可以直接搜，看看都有谁讲过，是哪个公司的。有些大会的视频回放会放到网上，看过PPT觉得好，还可以找找有没有视频，因为说的更详细。当然要是认识其他公司的相关负责人，直接去交流效果更好。
一般正规的公司都有内部通讯录，能够看到组织架构，扫一眼就能有一个感性的认识。再进一步可以看这些部门都是干什么的由谁负责？自己在哪个部门，上级的上级是谁，有哪些平行部门？甚至可以看到同事职级，做到心中有数。
多参与、多观察、多发声。右边这列是我参与的一些项目，里面是相关文档，参与项目多了对整个系统和相关团队会有更全面的认识。刚加入还是个新人的时候，一定要多了解，不懂就问。好记性不如烂笔头，中间这个图是我在当当4年多用过的笔记本。有些同学习惯用电脑管理日程、记笔记，都电子化，也没问题。还要及时总结，比如我在2013年跟架构师赵振林，画了一个当当的系统架构总图，把100多个系统都串了起来，填补了这方面的空白。
这张图是一个总结，当时我在当当已经一年5个月了。有了这张图，当当的系统不再是一朵云，再把所有系统的负责人拉出个列表，我就是对于系统架构和团队最了解的人。2013年到2014年，我认识当当所有的技术经理，几乎认识所有的技术核心骨干，即便跟一些同事打交道不多，至少也是点头之交，知道他是做什么的。
合作本身比较软性，分几方面讲。首先得有热心肠，多帮忙，不求名利，重在掺和，如果没关系的事都不搭理，形不成合力，就算热脸贴冷屁股，也要表明态度。搞技术大家比较追求完美，实际上资源和时间有限，或者大家理念不同，就得妥协，妥协的进步也是进步，就算没有进步，促进了相互了解也有价值。得摆正心态，不以专家自居。谁也不是全能选手，不必因为自己是架构师就必须永远正确，要平等交流，对于很多系统的细节，直接负责人一定是最了解的。在非正式场合，大家可以一起吐槽，一起吹水，关系会更融洽。大家一起工作，最终是要出成果，用成果积累信任，有了信任才能更好合作，出更多成果。
这张图是什么？是我参与项目之后，留下的遗憾或者发现的问题，在后续的项目合作中，可以提出来，大家有针对性的一起解决，这样也更有成果。
架构师作为公司里的一个角色，有自己的职责，成果体现了价值。该做的事情要勇于承担，争取资源和主导权。有时边界的确不清楚，但如果觉得一件事该做，就要有所考虑。多分享，不一定非得是自己的心得体会，也可以是参加了外面的技术大会，或者学了一个课程，都可以公开分享。一方面混个脸熟，另一方面让更多的人了解自己认同的东西，可称为布道。可以作为讲师参加新员工培训，给新员工介绍公司的架构和自己的理念、原则，第一印象很重要！为他人的成就喝彩，为整体的进步鼓掌。不一定非得自己做才值得夸耀，大家都是同事，是一体的，大家好才是真的好。想推动一些事情，得去影响关键节点，一般来讲，就是组织结构里的关键负责人。理解他遇到的问题是什么？他的想法是什么？这个事情有几种方案？最好提前有所交流，能达成一些共识，真正做决策的时候就容易得多。有了成果要走出去参加行业分享，是骡子是马拉出来遛遛，既能展现公司水平，还能树立个人品牌，提升在公司内部的影响力。
架构师技术领导力的成长过程，不管是做事能力还是认知方面，都遵循了点线面体的规律，曾鸣、梁宁、罗振宇都提到过这个概念，右军老师也专门写过公众号文章。这是正常的成长过程，如果倒着来的话会很痛苦。如果降维用关注圈、影响圈、控制圈平面层次来看，成长就是三个圈越来越大的过程。
2016年11月我离开了当当，回头看有不少遗憾。总结很重要，清楚做了哪些事情，没做好哪些事情，才能不断成长进步。之前在《十年磨剑·大巧不工》的文章里提到过，在此引用。
第一，对决策层在架构方面的关注度影响有限。
架构部的价值在哪里？经常有人问，到底什么样的公司应该有架构师，什么样的团队该有架构师，只有系统到一定规模和复杂程度才需要架构师的角色在全局上做一些事情。
当当已经很大了，需要在架构层面有所投入。然而在决策层，对于架构一直关注度不太高。很多东西需要我们向上管理去推动影响，老板不会去判断是不是架构不合适，这个需要老板在技术层面有一个认识。
不像业务功能层面，竞品做了一个小程序，咱也做一个，人家用三天，你为什么用五天，这不是一个维度的问题。
第二，从架构角度来讲，对于搜索、移动端和数据平台的影响不足。因为相对比较独立的，电商业务里这几部分跟主流程关系不大，所以基本上自己玩得比较嗨，但实际上很多事情需要协同，才能发挥更大作用。
第三，我走的时候，还没有完成主流技术架构在当当落地，也没有去充分彻底让当当的系统平台化。
第四，没有带动更多同事参与开源项目。
非常感谢把我招聘进当当的HR小姐姐们和架构部总监老翁、CTO Justin，让我在当当开始技术转型需要在架构层面有所作为的时候加入，作为架构师与当当同事们一起走过了4年。感谢各位领导的理解和认可，感谢大家的帮助，特别感谢架构部的同学们，我们做了许多有价值的事。所谓天时地利人和，就是在合适的时间加入合适的公司遇到合适的团队，这样的机遇非常难得。在当当我认识了许多朋友，一路走来经历了许多变化，一同成长，我也完成了从传统IT领域到互联网的转型。再回首，唯有感恩，祝当当越来越好！
希望这篇文章能够对大家的成长有一点点帮助，我们无论是前浪还是后浪，都要在时代大潮里披荆斩棘乘风破浪！
原创 史海峰 技术琐话
https://mp.weixin.qq.com/s/z_yEORPlpJkEy3E1-IoxxA
京公网安备 11010802035086号