笔者一直以来做的都是一些纯技术方面的分享,慢慢树立起一个名副其实的埋头啃技术的程序员形象(虽然没觉得有什么不好),其实自己在管理这条路上也走了不少年头了,也考了PMP之类的管理证书,但对管理的思考和沉淀从来没有静心总结归纳出一套体系云云,现在说好听点是仅限于融在了个人经验里。不期而至恰逢一次中生代群里的闲聊,说到了架构评审这块,右军私下说要不你就写写呗。一拍即合,笔者不怕班门弄斧,苦苦搜刮了半个月拼凑了这么些文字,欢迎业界同行拍砖。
关于架构可以谈的东西太多,本文聚焦在组织架构维度,基本也算是笔者在当前公司里的最佳实践(别抬杠,对您很可能不是最佳),另外部分内容参考了《架构即未来》一书。
大家知道有三种基本的组织架构类型:职能型、矩阵型、敏捷型。而笔者的公司是敏捷型组织,对于其他两种组织类型的架构团队的实践会有一些不同,本文不会做任何横向对比,请自行找寻异同点。
开篇说一下架构团队的定位,亦或者说职责范围。
注意:下图的职能很多可以做归并,只当参考。非本文的论点。
笔者关于架构团队的职责定位明确为以下几个方面。
扩展性预期
确保系统的架构和设计可以随着业务的发展而扩展,需要在"业务需要"发生之前就想好,远在业务部门的预测超过平台的容量之前,就已经对如何扩展系统深思熟虑了。 软件的整个生命周期中,开发交付其实只是一小部分,后期的需求变更、维护升级、重构优化才是主旋律。那么多考虑软件的扩展性和未来预期是很有必要的,作为架构师至少看得到半年后的规模扩展吧?
标准规范
负责各项标准、规范、流程的设定和推行。这是架构团队的一个重要职能,也是最容易被忽视的。技术手段并不是所有的问题的最佳解决方案,很多场景通过推行标准规范就可以达到不错的预期效果。
比如编码规范,可以通过投入大量人力来开发IDE/代码库的插件进行代码规范的自动检查,再需要不断的测试来验证这个插件的可靠性。通过编程考试或者平时的review来强化这一规范的落地,再加上编程规范的不断宣导可以达到至少八成的效果,何乐而不为,最后那两成效果就放到公司真到一定的级别了考虑技术实吧。再比如架构组研发了统一的基础日志组件,可以规范日志格式、掩码敏感信息、自动截取/压缩超长日志报文等功能,这种组件就应该作为标准全员推广。
拆解抽象
在参与业务迭代的过程中,能够抽丝剥茧(拆解),发现需求、编码、测试、发布等环节中的痛点、共性点或未来瓶颈点等进行抽象、实现并最终推广全员。在代码层面也适用,拆解交织繁杂的代码逻辑,抽象出基础公共模块。都是架构团队的基本技能。
举例来说,架构师经常会参加各种各样的评审,对那些常见的review comments,五花八门的自造轮子,一旦发现就要有这种敏感度需要制定标准规范或者研发统一的组件了。
技术宽度
架构师需要足够的技术宽度,从软件到硬件,从语言到操作系统,从编码到测试,从运维到安全,从拥抱开源到自造轮子都要有所涉猎。有个比喻,说架构师需要具备某种上帝视角,来俯视软件产品的诞生、成长、重构整个生命过程。而且架构师要有空杯心态,若学习的技术越多,就觉得自己的水平越高,那基本不会是一个合格的架构师;实际应该是越学习觉得自己不懂的越多。
另外,特别要有面对疑难杂症的自信和能力,为业务团队提供强力的技术输出。因为疑难杂症的最后一关就只有架构团队。
协调领导
架构团队绝对不是偏安一角写写基础组件,既然要制定标准,推行规范,那就必须与其他团队进行协作,需要征得他们的合作态度,才能顺畅的推行,这个靠架构团队在技术和业务上的影响力来驱动协调基本可以办到。但在某些情况下,需要一些强制的手段,比如设计文档的强制评审,那就必须赋权给架构团队一定的权力,或者在一些矩阵型组织里架构师就是拥有技术的绝对权威,这个就是领导力。
深入业务
技术的存在就是为业务服务的,脱离业务的架构都是耍流氓,99%的情况下这句话都没毛病。有些技术人有严重的重技术轻业务思想,这种人除非真的是钻研技术的一把好手,可能不善言谈不善沟通(笔者本人是可以接受的),但是架构团队里这种人不能多。后文我们会详细讨论下架构团队和业务团队的协作问题。
创新突破
架构团队在IT内部必须是第一生产力,不管是单兵作战还是团战能力。除了过硬的基本功外,不断的学习和寻求技术上的突破,是贯穿架构团队始终的一个Object。前人已经累计了很多经典优秀的平台、框架或思想作为传承,我们可以继承但绝不能守旧。
在学术研究中,“创新”一词用来表示团队有增加值的产出。而有些创新调研项目很多时候并不会有实际的产出,甚至更糟糕些,会产生许多沉没成本,但这都不是阻碍创新的借口。创新是架构团队延续生命力的最佳营养品和必要条件。可以想象没有创新突破,架构团队完全可以就地解散。
架构团队的处世之道
《架构即未来》《架构真经》两本经典架构书里都对架构的原则展开了很多,但都是偏向技术层面的。这里我要另辟蹊径,说的不只是架构本身的原则,还有架构团队如何玩得转的原则,跟上文架构团队的定位是戚戚相关的:
来自维基百科:
Thundering herd problem惊群问题是计算机科学中,当许多进程等待一个事件,事件发生后所有这些进程被唤醒,而只有一个进程能获得CPU执行权,其他进程又得被阻塞,这造成了严重的系统上下文切换代价。C10K/C10M问题都与这个相关。
还有两个类似的术语一并介绍下:
“Slashdot effect点杠效应”这个词指的是当著名新闻网站Slashdot在一篇有趣的文章里报道了一个网站后许多人纷至沓来把它几乎挤爆的现象。后来被列入其他著名网站后所发生的类似现象也用这个词来称呼了。这个词和Flash crowd这个更一般性、更合适的词对应。
“Flash crowd突发访问拥堵”这个词是1973年Larry Niven在他的短篇科幻小说Flash Crowd中生造出来的。小说预言了廉价的瞬移技术会使得一大群人都会传送到有趣的新闻故事发生的地方从而导致拥堵。20年后,这个词在互联网上被广泛用于指当网站有了能吸引许多人的东西之后其服务器系统资源使用量成指数增长。在此之前,Alfred Bester在他的小说The Stars My Destination中也预计到了这种效应。
架构团队 versus 业务团队
单独拎出来这两个团队的相处之道并不是说这两个团队有什么不得了的冲突(相较于开发vs测试,开发vs运维,测试vs运维),只是只要有协作就会出现问题,但是这个冲突并不难解决。其实上文也断断续续提到一些原则,但终极方案无外乎两个词:尊重和信任。
架构要得到尊重就要在技术上保持先进性,且必须对业务有一定的深入度;业务要得到尊重那就除了要在业务上有深刻理解,在与技术的结合上也必须有自己的思考。而事关信任,双方只要在自己发布的产品上倾注足够的专注度,展示了自己的态度,最后又保证了质量和口碑,就会逐步建立起信任关系。
架构评审委员会ARC
定义
七拼八凑好不容易整理了一个个人还算满意的定义:架构评审委员会Architect Review Committee作为IT的一个治理监管机构,有权力确保IT运转在整个架构生态内保持一致,提高IT的产品质量,并最终与公司的目标、战略达成一致。
《架构即未来》一书中架构评审委员会的缩写是AR B(oard),笔者选择了ARC纯粹是为了好记好发音。其实ARB才是业界主流说法...
那为什么要有ARC?是否必要呢?那是必然的。上图中归纳的5大块:技术、流程、标准、质量和创新都在ARC的辖内,且ARC有绝对的话语权提供决策结果,另外ARC也是捏合架构团队(落地)、PMO(项目管理办公室)和业务团队的关键机构。
不能再搞笑的是笔者竟然先看到了微软2012年的一篇题为<Should We Kill The Architecture Review Board?>的文章...WTF...
传送门: https://blogs.msdn.microsoft.com/nickmalik/2012/04/17/should-we-kill-the-architecture-review-board/
我简单给大家归纳一下文中表达的意思:按照COBIT标准IT的治理体系应该有三个委员会:架构Arch委员会、策略Strategy委员会和指导Steering委员会 ,而架构委员会只对项目工程有话语权,指导委员会却对IT投资、预算和交付等有话语权,一句话就是管钱袋子的定规则,架构委员会干不过指导委员会。既然架构委员会说了不算那就不要了,成立一个CIO牵头的说了算的IT治理委员会,来完成满足COBIT标准的事情。标题说的那么吓人说Kill掉,其实也就是因为微软里的ARB说了不算,对于决策权这个在笔者的定义里已经标明了。
咱们中小型公司没有也不需要微软那么大的标准体系,当然不关心那么多道道,三者合一就叫ARC来行使所有IT治理框架需要的所有职能。
创业公司如果有如下困扰,并开始越来越明显的影响到IT正常的运作,那么贵公司应该考虑成立ARC:
职能范围
工作原则
终于写完了,基本都是大段大段的文字,配图都不好配,确实不如贴代码来的舒爽,可能大家会看的比较累。我就再总结一下,其实主要就说了一下架构团队应该如何以及如何更好的自处或他处,IT管理者如何使用好架构团队这把尖刀的事情。论点太多没有再花时间找到他们的内在联系做个归集,还请各位看客多担待,搁笔。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。