企业IT架构团队组建方案 .pdfVIP

企业IT架构团队组建方案

1

关于架构可以谈的东西太多，本文聚焦在组织架构维度，基本也算是笔者在当前公司里的

最佳实践（别抬杠，对您很可能不是最佳），另外部分内容参考了《架构即未来》一书。

大家知道有三种基本的组织架构类型：职能型、矩阵型、敏捷型。而笔者的公司是敏捷型

组织，对于其他两种组织类型的架构团队的实践会有一些不同，本文不会做任何横向对比，请

自行找寻异同点。

架构团队的职责定位

架构团队在IT组织里到底处于什么位置，应该行使哪些职能。

架构团队的处世之道

架构团队不能超然，需要与各团队深度合作。那么哪些基本原则需要遵守？

架构评审委员会ARC

这是一个很强大，一个不慎也可能走偏被唾弃的权力组织。

架构团队的职责定位

2

开篇说一下架构团队的定位，亦或者说职责范围。

注意：下图的职能很多可以做归并，只当参考。非本文的论点。

笔者关于架构团队的职责定位明确为以下几个方面。

扩展性预期

确保系统的架构和设计可以随着业务的发展而扩展，需要在业务需要发生之前就想好，

远在业务部门的预测超过平台的容量之前，就已经对如何扩展系统深思熟虑了。软件的整

3

个生命周期中，开发交付其实只是一小部分，后期的需求变更、维护升级、重构优化才是主

旋律。那么多考虑软件的扩展性和未来预期是很有必要的，作为架构师至少看得到半年后的

规模扩展吧？

标准规范

负责各项标准、规范、流程的设定和推行。这是架构团队的一个重要职能，也是最容易

被忽视的。技术手段并不是所有的问题的最佳解决方案，很多场景通过推行标准规范就可以

达到不错的预期效果。

比如编码规范，可以通过投入大量人力来开发IDE/代码库的插件进行代码规范的自动检

查，再需要不断的测试来验证这个插件的可靠性。通过编程考试或者平时的review来强化

这一规范的落地，再加上编程规范的不断宣导可以达到至少八成的效果，何乐而不为，最后

那两成效果就放到公司真到一定的级别了考虑技术实吧。再比如架构组研发了统一的基础日

志组件，可以规范日志格式、掩码敏感信息、自动截取/压缩超长日志报文等功能，这种组

件就应该作为标准全员推广。

拆解抽象

在参与业务迭代的过程中，能够抽丝剥茧(拆解)，发现需求、编码、测试、发布等环节

中的痛点、共性点或未来瓶颈点等进行抽象、实现并最终推广全员。在代码层面也适用，拆

解交织繁杂的代码逻辑，抽象出基础公共模块。都是架构团队的基本技能。

举例来说，架构师经常会参加各种各样的评审，对那些常见的reviewcomments，五

花八门的自造轮子，一旦发现就要有这种敏感度需要制定标准规范或者研发统一的组件了。

4

技术宽度

架构师需要足够的技术宽度，从软件到硬件，从语言到操作系统，从编码到测试，从运

维到安全，从拥抱开源到自造轮子都要有所涉猎。有个比喻，说架构师需要具备某种上帝视

角，来俯视软件产品的诞生、成长、重构整个生命过程。而且架构师要有空杯心态，若学习

的技术越多，就觉得自己的水平越高，那基本不会是一个合格的架构师；实际应该是越学习

觉得自己不懂的越多。

另外，特别要有面对疑难杂症的自信和能力，为业务团队提供强力的技术输出。因为疑

难杂症的最后一关就只有架构团队。

协调领导

架构团队绝对不是偏安一角写写基础组件，既然要制定标准，推行规范，那就必须与其

他团队进行协作，需要征得他们的合作态度，才能顺畅的推行，这个靠架构团队在技术和业

务上的影响力来驱动协调基本可以办到。但在某些情况下，需要一些强制的手段，比如设计

文档的强制评审，那就必须赋权给架构团队一定的权力，或者在一些矩阵型组织里架构师就

是拥有技术的绝对权威，这个就是领导力。

深入业务