企业级BI架构师需要具备的素质

浏览: 5080

首先,我所理解的BI架构师不是局限于聚焦于前台Report & Analytics分析平台的精深的专家,而是更普适的至少跨越三个领域:数据库,ETL,Report & Analytics的整体解决方案的架构师。此处需重点指出,本人对聚焦于前台R&A的专家只有敬仰,他们同样是架构师并且也存在世界级应用的架构师,只是不在我本次回答的范畴内。

其次,架构师也是分等级的,我姑且分为入门级,专业级,大师级和殿堂级。

入门级:亲自做过小规模项目,规模大约3-4个人,6个月左右。

专业级:作为Lead做过不少中等规模的项目,规模在15个人以上,12个月以上(有的时候做两期)。辅佐专家级架构师做过大规模项目。

大师级:作为Lead作为大规模项目,规模在30个人以上,24个月(一般来说至少两期)以上。作为专家组成员辅佐殿堂级专家完成世界级超大规模项目。

殿堂级:统领世界级知名企业超大规模项目,规模在100人以上,周期在24个月以上。且有的殿堂级专家著书立说,又或出过各种专利....

(这里我没考虑数据volume, 使用User数量等相关信息,因为这种东西很多时候和行业有关,有的行业就是天然有很多数据,比如互联网比如电信,不想把其他行业的漏掉。这里的项目人数要求绝对不是衡量架构师水准的硬性指标,只是一个参照而已)

当然,项目之复杂,岂能通过如上三言两语描述的清,只是给看官们一个借鉴的样子。

再次,就技能掌握的水平分类,又分为初级,中级,高级和大牛级。

初级:学过,简单任务可实操

中级:用过,项目中实际实操,自己能解决大多数疑难杂症

高级:经常指导中级的人用,自己专门负责解决疑难问题,出模板pattern之类的

大牛级:重点考虑repeatable的产品化应用设计

铺垫做完,再讲讲我对架构师的理解:

通常,架构师的技术范围是T字形的,也就是在某一个或者某几个领域很精深,其他领域相对一般,很难找到所有技术范围都是大师级的选手,而很多时候不一定需要所有领域都是大师级的才能够成为架构师。所有的架构师都是Leader,因为你需要善用别人的长处来辅助你做架构的设计,架构设计很多很多时候都是集体智慧的结晶,如果有人抬杠说他的项目由他自己一个人搞定,要么这个人是各方面都卓越的大神(大神这词快被用滥了),而更多的时候或者说绝大多数的时候实在是因为项目的难度和复杂性不够。

此外,架构师非常重要的特质是,需要站在全局的考虑问题,而不是把眼光放在局部,因此需要架构师对各个领域的知识均有涉猎,建立我们称之为Insight的洞察能力,架构师很多很多时候都要对各种解决方案做取舍,没有整体架构的洞察力,就非常容易做出错误的决定。

另外,很有趣的是,只有你在某一个领域特别精深的,你才能在其他领域达到下一个级别,也就是说不存在T字形纵向一般,但横向很宽,并且能够交付合格出品物的架构师。这种架构师,通常嘴上功夫一流但没有实际的交付能力,不是我等技术人员所倡导的发展方向。T字形,纵向越深,往往触类旁通,在其他领域可能实操能力或许一般但也都有独到的见解。

 

好吧,从入门级别开始,至少你得懂DB,ETL,Report其中一种产品,能达到高级的水准;其他领域至少应该是中级。此外还需要懂得一些Unix的知识,怎么也应该是初级水准,如果能会一门编程语言,Java也好,Python也罢,都会是很好的补充。同时所参与的行业,需要达到中级的水准。而其余领域的知识,比如元数据管理,数据挖掘,主数据管理,数据质量等等如有涉猎当然更好。而这一级别的架构师通常的主要使命是完成当下项目的交付,一般来说不需要太强的系统工程(System Engineering)和项目管理经验,依赖个人能力为主,大部分架构师都是从这个层面成长起来的,这个阶段重点培养的是解决问题的能力。

 

等到了专业级别的架构师,除如上”硬“技能需要持续提高以外,需要站在项目以及系统工程的层面来思考问题,这时候仅仅”硬“知识就显得不够了,通常来说都需要管理10-15人的团队,这时依靠单打独斗的个人英雄模式就很难行得通了,再牛的架构师也会发现自己无论如何一个人无法搞定所有事情,会更依赖团队,同时又有大量的时间用于和PM,和需求方,对团队内部的沟通。需要考虑更多时间,成本等问题。因此,需要掌握更多项目管理,系统工程方面的知识,并且提高沟通的技巧,学会解放自己并把任务交给团队成员,这个时候的架构师需要大量的Review,制定规范等工作,并开始有些Trade off类的技术方向等决策性工作要做。

 

我不是大师级的架构师,只是作为普通一兵有幸辅佐过大师级架构师的工作,因此我很难给出准确的描述。只是尽可能描述我所接触过的牛人的特质:

1. 使命必达,这个看起来和技能的关系不大了,但这个优秀架构师必备的品质和素质,对于项目的交付有责无旁贷。有的时候PM换的像走马灯,而总架构师岿然不动。

2. 洞察以及丰富的经验。这里我举几个例子,来表示经验的重要性。比如全球性的项目,能很早的洞察到货币的需求,其中包括对计划/实际的不同汇率的需求;也包括交易发生时需要记录的货币的种类,还包括个别发展中国家本地货币通货膨胀引起的不可信赖,林林总总。再比如,意大利,奥地利,瑞士对私人信息保护的法律上的严格要求;再比如上市公司在财务年报季报发出前半个月的blackout,如果提前释放销售信息可以从股市获利的金融风险等等,这些是我这种没见过天儿的选手根本事先么有想到的需求,而在澄清需求过程中,如果没有相关知识的储备,可以说完全无法和资深的BA做沟通。所谓需求进,架构出,在这个阶段的架构师需要对公司业务,对行业,对数据有非常丰富的经验,而具体需要上手的操作的技术反而要求不高了。我们称之为大爷的架构师在我们对OS/390的程序一筹莫展的时候,也能伸出援手去coding,当新款MPP数据库设计出现问题时,也能提出非常精准的建议和研究方向。因此,其实“硬”技术一直都很重要,只是到了这个阶段就会被弱化了,但放弃对技术的学习也会逐渐失去了洞察力。这个阶段的架构师需要更多的是对行业以及全方位需求的洞察,对数据整体的把控,对企业发展方向以及数据战略的Alignment,需要更强的领袖风范,需要更强的说服和谈判能力,需要从整个企业的视角去审视架构,需要有平台级的设计观念,而不是局限于某个项目。

 

殿堂级:这个我更没有资格评论了,也没有共同工作过。我所能理解的还是,他们看的更远,我们着眼于当下以,他们着眼于未来。

 

林林总总,说起来高大上,但即使是殿堂级架构师也是普通的人类一步步走上去的。Bigdata时代对技术有了更多的要求,持续学习能力也是架构师必备的素质。我也看到过快60岁的老头儿还对新技术怀有热烈的学习动力。


以上,无非是个人片面的看法,只是一个参照而已。

Appendix: 技术列表, 视个人情况而定,没人能都学全。

1. DB

1) Data Modeling: 3NF, Dimensional Modeling,Data Vault, Anchor(后两种没有太大必要学,尤其最后一种)

2) DB Repository: 

     i. 商用传统:Oracle, DB2, MS SQL Server,  Sybase, Informix

     ii. 商用数据仓库专用:Oracle ExatraData, SAP HANA, Netezza, Teradata, SybaseIQ, GreenPlum, Vertica, 

     iii. 开源:PostgreSQL, MySQL

     iv. NOSQL:MongoDB, Neo4j, Cassandra, HIVE, HBASE, ...

     大部分我也只是知道名字而已。

3) Data Modelling Tool: ERWIN, PowerDesigner, Oracle SQL Developer Data Modeler, IBM Infosphere Data Architect

4) ETL: Datastage, Informatica, Ab Initio, Kettle, SSIS

5)多维数据库:Essbase, TM1, Cognos Powerplay, MS AS, 

6) Report: Cognos, BO, Hyperion Performance Suite, OBIEE, MSTR, Qlikview, Tableau, ...

7) Metadata

8) Data Mining: SAS, SPSS, R, Excel, Matlab...

9)MDM

10) Data Quality

11) Data Governance

林林总总,还有各种bigdata的平台,我连名字都不知道。


职业生涯是有很多偶然性的,如果离实际工作很远,我不是很建议去学习,因为很难深入且容易遗忘,去学习离你近的东西。

吾生而有涯而知也无涯。学海无边,回头是岸。





广告区:

本人2016-1-17开始推出的数据仓库建模指南系列课程,链接如下

http://www.hellobi.com/course/54


上线10天,410名观众

目前上线11天,451名观众

Clipboard Image.png

推荐 14
本文由 BAO胖子 创作,采用 知识共享署名-相同方式共享 3.0 中国大陆许可协议 进行许可。
转载、引用前需联系作者,并署名作者且注明文章出处。
本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责。本站是一个个人学习交流的平台,并不用于任何商业目的,如果有任何问题,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

22 个评论

学习,收藏啊,目前我算初级入门级别
问下@BAO胖子 BI顾问对业务的了解程度是如何分级的 ?
架构师这种职位在中国还是比较少的
这个我也不会分级,只是和别人曾经探讨过,基本上都是这种套路。
1. 学过
2. 用过
3. 多项目用过,主动引导客户能力, 主要和下面资深业务专员沟通
4. 沟通层面到director Level
5. 和C Level的喝茶聊天,谈笑风生那种
也不是了,其实每个项目都是有架构师这种role的存在的,只是很多没有正式的title。这东西没那么玄幻,换个名词显得low一点:Technical Leader
很久没看到这么有料的文章啊。
期待楼主继续更新,收藏加关注中。
学习之路任重而道远啊!能达到真正通透的少之又少,大多数能够达到某一个较高层次的最后也因为很多原因不得不丢下而去追求更现实更直接的东西了,所以最后能坚持下来的......一定要竖个大拇指!

能沉下心来做一件事不容易,能沉下心来做好一件事情更不容易!
所以需要团队啊,一个人不可能搞定所有事
收藏了!好文!
营养非常丰富,收获不少。
很好的文章,先收藏一下
大师级:作为Lead作为大规模项目,规模在30个人以上,24个月(一般来说至少两期)以上。作为专家组成员辅佐殿堂级专家完成世界级超大规模项目。
按照规模,我在这里,哈哈,不过我不是做架构师呃,做包工头的 -,-
不要纠结在人月上...我当时写这块的时候也考虑了一下,有的项目很小但非常成功,也是大师作品
我做过1年,峰值接近50人的项目,但项目其实很糟糕。所以...
之前的项目是SCM BI,团队30+,ETL+BIEE+JAVA+TEST,再加一个助理妹子 :P
日本项目更夸张,一弄就上百人,几百人,但做的和狗屎一样,也没啥意义,所以不看人月。但我也实在想不出其他的量化的指标,本来想看数据规模,但电信电商这种天生就数据量大,有些天生就小,也不能说小的就失败。

华为R&A项目还是很不错的,需求分析做的很赞
哎,反正我做的是很苦逼。。
都是坑,如果坑里恰好有很搭的人,就是幸福的。
不好整阿
又看了一遍,对于我这种半路出家,一直在甲方混的IT运维人员的来讲,真是望尘莫及呀,只有不懈的学习啦!
甲方有甲方视角和立场,业务更熟知,业务人员关系更密切,源系统更熟知,有的时候就是需要上游系统的一次变革,然后才有机会实操一次端到端的架构工作,一般大企业折腾一下也要至少两年的时间

要回复文章请先登录注册