闲话如何成为一个架构师

停了很久,继续上路。计划写一个系列,先预告:《如何成为架构师》,《如何做一名好开发》,《如何做系分》,《如何转型技术管理》。

正文


拿破仑说

不想当将军的士兵不是好士兵。

类比到IT行业

不想当架构师的程序员不是好程序员。

虽然此种类比不一定恰当。也许你就想简简单单、安安静静写写代码,这种想法没错。国外,就有很多老程序员,与世无争的写代码,把代码写漂亮,没有那么功利非要给自己挂一个架构师的头衔。相比较而言,国内就要现实太多。工作N多年后,如果还是在一线码农,多数时候也会被鄙视,也许还会被BOSS扣上此人发展潜力不行。还有N多人,换工作的时候,非架构师职位不来。 年前和团队人开会,有个同事的给他的定位是渐渐可以做更多架构规划相关的工作。他说,对于如何做架构还有很多迷茫。有些人也许不会选着这条路;有些人正在这条路上,但是很迷茫:我该如何成为一个架构师呢? 视野


记得有个架构师讲过

“视野决定格局”

自己还是比较认同这句话,架构师首先要重构的是自己的视野。视野不是装逼。视野可以作为一个看问题、积累专业领域知识的内在驱动力。 仅仅说视野,未免太虚,如何把视野坐实是很重要。由内在(思维、心态、方法)驱动外在(专业知识)是需要扎扎实实去积淀。 常常听到这样的观点

“做架构师,一定要有全局的视野或关注”

如何理解全局?负责几百个应用就是全局?负责单个系统就不是全局? 个人对全局有如下理解:

  • 单点、模块、链路 由点到面去积累知识,从全局和细节两条路逼近学习;不仅仅关注自我,还超越自我。要做一个架构师,不仅仅需要知道自己能做什么,还需要知道别人能做什么,还需要自己不能做什么。所以要做好,需要超越自我,积累更为全局的知识,首先是你的上游需要理解,进一步是上游的上游需要了解。
  • 过去、现在、未来 从过去看为什么来;从现在看缺什么;从未来来看走向哪里。架构师需要看的更远,比如半年,一年,三年。预知未来的能力。
  • 抽象归纳 从全局、多样性信息中去抽象归纳。案例推演越多,越能找到本质,更能经得住推敲。分离关注点,识别关键内容。

视野会决定你获取信息的宽度和广度。

假比架构师负责的系统是一个圈,架构师的的视野,不仅仅是站在圈内看圈内,还要站在圈内看圈外。进一步,还可以站在圈外看圈内。进一步,你还可以飞起来,鸟瞰。 架构方法论


对于架构相关的工作不是无方法可循,相反对于企业级架构是有一整套方法论。 1、企业级建模方法ArchiMate

没有听过的可以自行搜索查看。

业务架构、应用架构、技术架构、信息架构是常见的划分视角。技术为业务服务,技术驱动业务。 不同层次/定位的架构师的关注点会有不同:

业务架构对接业务愿景,业务架构师不一定需要完全懂技术,或者有很强的技术能力。 如果是强业务型平台,这类平台一般会直接面对业务场景,业务分析、建模能力需要更强;共享型平台,这类平台一般在各个业务平台的下层,提供统一的业务支撑和高可用的服务支撑,此类架构师,既需要领域建模,有需要很强的技术能力,一般没有技术功底的PD也很难规划、掌控此类平台;技术型平台,诸如基础技术平台、中间件等架构师,需要对技术的深入度,对于技术栈的深度和广度需要很高的要求,此类架构师对于业务的理解可能不会太强,而且此类架构师可能不喜欢关注业务。

应用架构对标业务架构,应用架构支撑业务架构。两者关系是相互促进循环。应用架构师考虑如何基于当前的技术架构,对业务架构提出的业务模型进行系统支撑。

技术架构是企业的基础技术栈。消息中间件,服务框架等等都可以纳入这一体系。技术架构不是一味的堆砌高大上的概念。业务发展/愿景,应用架构遇到的问题会驱动技术架构完善;技术架构的扩展能力确保能快速支撑业务爆发增长(比如亿级访问量),或者业务复杂度(比如服务框架或者分布式事务框架)。

信息架构最难,此部分最容易忽略,最容易被取舍。如果要建立完全的信息架构也比较困难,第一个困难就是建设成本太高,第二就是可能当前解决还想不清楚,比如业务领域的变化性很大,在模糊阶段建立信息标准存在悖论。一般前期需要业务先行,所以信息架构,信息标准会缺失;待系统发展到一定规模后,各个系统信息交互存在困难时,再来重构的成本也会很高。 2、业务建模模式 业务功能域拆分,自顶向下的分解功能域。抽象建模是每个层次都需要的能力,不同的业务复杂度级别采取的方案可能不同。 比较简单的业务,建设初期可能就是单系统。可以采用模块化拆分(包结构也算一种模块化,多工程也是一种模块化);可以使用GoF设计模式,进行复杂功能的拆分,提供可读性、可维护性;可以使用OOP面向对象变成进行业务建模等等。 稍微复杂一点的业务,可以使用DDD进行领域分析建模。对于业务领域进行业务实体,领域服务等合理的拆分,确定业务领域的职责范围。 更复杂的业务综合体,可以使用基于SOA的架构进行更大范围的业务功能域的拆分,此部分的拆分模式其实可以理解为更大范围的DDD拆分,然后使用技术(SOA)的方式,让各个业务域进行协作。本质上,建模的方式没有太大的区别,把相同的业务服务划分到特定职责的业务域。 3、架构与组织 一般架构师不需要关注这个点,但是架构和组织是配套对齐。只有得到组织的强有力支撑,架构实施才能得到有力实施。相对大型的业务实体会划分为多个一级业务域,这些域会对应架构师,同时也会配比一定的研发团队;一级业务域可能划分为多个二级架构域,二级架构域也会有对应的架构师,组织一般也是配套。 有的架构师是纯架构师,不带团队,这种架构师需要有加强的架构沟通能力,和各个TL协调资源和架构目标。有的架构师兼容TL,这类架构师得到的支撑力度会更顺畅。 对于大型的架构团队,基本上会有架构委员会。一级业务域形成公司级别的架构委员会,对于一级域的重要职责负责;二级业务域也可以形成架构师团队,便于二级业务域内职责确定和协作。 一个好的架构师需要理解自己,同时理解周边。一级业务域架构师,需要清楚自己负责的一级业务域,同时也需要很熟悉周边的一级业务域。架构越大的域,信息量越大,很考验架构师的信息接收、抽象、建模能力。 4、架构规划闭环 架构规划、架构实施、架构评估是一个架构闭环。

架构是动态的,在平衡、取舍、演进的架构迭代中不断演进。 没有完美的架构,如果你觉得当前的架构是完美的架构,那么你的业务可能是“死业务”。充满生命力的业务会带来业务变化,业务愿景/目标也会有调整。业务愿景可以直接带来架构目标(比如要支撑国际化);缺失的平台能力也带来架构目标(比如平台故障频出)。 对于架构目标的内容进行合理的人员、优先级、里程碑排布,然后付诸于实施。架构实施的过程一般都是充满挑战,实施过程中会有对架构目标的修正,会有和你负责的上下游进行游说、PK,会有基于当前的困难做的取舍。 达到里程碑点后对于架构目标和实施情况进行评估,反馈,进行架构治理相关工作。 架构师的价值


个人把程序员进阶分为如下几个阶段

  • 任务明确型阶段 多见于初入门的程序员,需要在别人指导下完成编码工作。部分仅仅完成开发工作,不追求甚解的人可能停留在这个阶段。
  • 业务明确型阶段 对于一个系统/业务的熟悉后,你已经可以完全掌控这个系统的职责。这个时候给你一个应该你做的需求,你会很容易进行系统的功能分解,设计,然后把这个需求完成。这个时候你知道自己该做什么,不该做什么。
  • 业务模糊型阶段 这个阶段,你会遇到很多需求,这些需求可以在你这里做,也可以不在你这里做。会面对很多模糊领域的问题,解决模糊领域的能力,考验架构师的能力,在信息中抽丝剥茧,归纳抽象能力。这个时候,你不仅仅知道自己不该做什么,还能知道这个不该做的应该放到哪里去做,比如应该放到哪个系统里。
  • 创造进阶阶段 这个阶段更复杂,带有更多创造性,视野可能不仅仅局限在现状里,比如现状划分了5个功能域。但是这个阶段的架构师,也许可以创造出第6个功能域。一种方式是通过业务域重组;一种方式是对未来的识别。

架构师的挑战和价值在于处理模糊领域的问题,让模糊的变得不模糊,清晰可触摸。 架构师的软能力


架构师很爱写PPT,架构师写PPT也很爱被一线的工程师诟病,说不干实事。

但是,架构师很需要沟通表达能力,如何把架构目标清晰的进行表达,对架构职责进行表述,和相关关系人进行沟通,这些都很重要,关乎架构目标是否能达成。

同时,架构师对于信息的处理能力很重要,对信息的理解能力会决定架构师走的多远,能多快、多准的找出架构关键点。

架构师也需要协调能力,比如架构师之间的沟通协调,架构师和实施团队的沟通协调。

架构师该不该写代码


一个好的架构师应该是从实战中的真知,从实战和细节中走来;但是,成长为一个架构师后,关注太多细节,会消耗较多的经历,会影响从更宏观看问题。技术型架构师这方面一般会好点。 架构师的工作,也是从编码,架构规划等工作中的取舍。如果需要关注到很细,架构师需要深入下去;如果不需要深入太细,可以从更宏观来看问题,比如从功能层面。


原文发布于微信公众号 - 芋道源码(YunaiV)

原文发表时间:2018-09-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云社区体验反馈

关于腾讯云+社区的体验

云社区我不常逛,但对各种垂直领域的社区很感兴趣,经朋友推荐,便来此处简单的体验了一回,做了以下书面输出。

317140
来自专栏灯塔大数据

纯干货!如何做一个成功的大数据项目

? 1 失败大数据项目的特征 根据在美国做了15年的大数据项目、产品研发和管理,以及其它一些相关的数据分析的工作经验,了解到的其它的做的比较成功的和失败的项目...

29730
来自专栏孟永辉

B站、秒拍被责令整改,短视频的世界里并非只有流量

有关以B站、秒拍为代表短视频平台被有关部门监管的消息引发热议,热议背后有关短视频未来如何发展的话题引发人们的反思。短视频的快速发展在为用户提供源源不断内容的同时...

6510
来自专栏大数据文摘

为什么Gartner公布的2016新兴技术的技术成熟度曲线都跟“数据”有关

16840
来自专栏华章科技

成功实施BI项目的四大要素

其实所谓“要素”不一定是项目执行过程中的关键点,这其中也包含了执行人的要素,毕竟所有项目的实施都是以人为发起点,然后以事件作为驱动,所以项目中最难把控的就是人的...

16220
来自专栏云计算D1net

关于云技术混合架构的三个认识误区

我以一位负责以云服务为基础实现多种业务解决方案交付工作的CIO的身份表达自己对混合架构的观点。在过去五个月中,我有幸参与到十几次高层对话当中,交流对象包括多位来...

29460
来自专栏DT数据侠

如何精准转化潜力客户?答案都在IBM的数据营销案例中

“数据驱动营销”这个词并不陌生,业界有很多运用数据驱动营销的例子。数据驱动营销最核心的理念和价值就是在对客户数据和营销执行数据分析结果的基础上做出下一步的市场营...

15500
来自专栏人工智能的秘密

知识图谱技术已发展得相对成熟,未来的探索方向在哪

前段时间被沙特阿拉伯授予公民身份的人形机器人“索菲亚”,再一次颠覆了人们对人工智能技术的认知。“索菲亚”多次与人类交锋并公开发表言论的过程中,我们感受到了基本的...

61460
来自专栏新智元

智能音箱2017大爆发,6大数据看懂亚马逊与谷歌之争

【新智元导读】 2017年下半年,智能音箱势必会掀起一场新的风暴。随着谷歌和苹果的重力出击,在国外,各家的争夺日趋白热化。亚马逊凭借先发优势,目前市场份额已经占...

409120
来自专栏新智元

聊天机器人这个2000亿美元的市场,你加不加入?

【新智元导读】国际首席战略官组织SVSG合伙人认为,7个月后就能看到聊天机器人掀起的变革,而Bot在5年内将颠覆人机交互方式,并且取代搜索成为互联网入口,因为世...

35860

扫码关注云+社区

领取腾讯云代金券