努力成为架构师的你,却连架构师的分类都不清楚

简介: 努力成为架构师的你,却连架构师的分类都不清楚


正文


进阶成为架构师是大多数开发者的梦想,但是你真的知道什么是架构师吗,如果你连架构师是什么都不知道,估计你离进阶架构师还有很远的路要走。


其实架构师也有分类,这里我们看看有哪几种,分别需要具备怎样的技能。同时也能让我们找准我们自己的定位。朝着适合的架构师方向进行努力。让我们事半功倍。


我们通常根据工作内容,一般可以划分为四大类:


1.企业架构师EA(Enterprise Architect)


职责:


企业架构师(EA)的职责是决定整个公司的技术路线和技术发展方向。这种架构师往往是某些公司的高层管理出来实现自己的想法,创办自己的企业时,或者某些高端的职业经理人,才会有针对性的规划公司的技术路线与日后的发展方向。


企业架构师不一定是整个公司技术最好的人,但是他必定是整个公司最有大局观的人。因为他的一举一动决定了整个公司的命脉。一般的开发者想要到达这一步,需要经过长久的磨砺,而并非一朝一夕就能成为合格的企业架构师。


举例:


假如你要建房子,我不关注你的房子到底要建成什么样子,但是我会帮你进行选址,同时我会规定好整栋房子的具体用途,比如说商业用途,住宅,公寓楼等等。可以换算成现在互联网大健康,大金融等方向。


建议:


一般的EA并不是广大开发者进阶架构师的首选,如果从开发者的岗位想进阶架构师,建议不要一开始就尝试走上这条路。


2.基础结构架构师IA(Infrastructure Architect)


职责:


基础结构架构师(IA)的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件,这些都是一个技术型公司传承下来的最宝贵的财富之一。


这个级别的架构师并不关注具体的业务,他们更关注的是抽象的设计方案。


举例:


我只负责建个一栋毛坯房,至于你们装修成什么样子,那个不是我应该关注的事情,你们要在一层楼开个茶餐厅,二层楼开个商场,这些我都不关心,我只关注我整栋楼结构的稳固,保证我整栋楼的基础结构的稳定,公共设施是否可以复用。同时我这套房子的结构是支持你做任何方向的改变。他是用来支持我们企业架构师(Enterprise Architect)的构思与规划的。


建议:


开发者能在这条路上走得很远的不多,因为现在市面上能够走上这条路的架构师通常还需要拥有特定的技术架构,来保证整个项目的落地。


一般中小型公司不会在架构师这个角色上安排两个职位来保证业务与基础组件的同步进行,同时对于基础组件并不需要优化得非常细致。导致很大一部分架构师都只是刚刚走上这条道路,就被特定的技术架构给限制了。


通常在市面上被称为软件架构师。不过只要能够到达IA这个级别,并且到达较为高深的程度,基本不用为以后是否失业而发愁,因为现在行业中缺口最大的就是高级IA。同时待遇相对其他架构师角色也较为丰厚。


3.特定技术架构TSA(Technology-Specific Architect)


职责:


特定技术架构师TSA,他们主要从事类似安全架构、存储架构等专项技术的规划和设计工作。


举例:


我们的房子已经搭建完成了,但是我们整栋楼的消防安全没有人可以做,那么我们就需要寻找出最节省成本的方案。这个时候恰好有一个人,以前做过类似的事情,可以解决掉我整个消防安全的问题。那么,他就是我们的TSA。


建议:


这一类架构师一般需要对某个特定的专项技术要求理解很深,对于技术的深度要求非常高。


一般情况下,他们在自己的技术能力范围之内,业务广度仅次于基础结构架构师,领域专业度也仅次于解决方案架构师。算是非常吃香的一种架构师。有很大一部分开发者都会朝着这个方向所努力。


4.解决方案架构师SA (Solution Architect)


职责:


解决方案架构师(SA)的工作则专于解决方案的规划和设计,“解决方案”这个词在中国已经到了严重泛滥的程度。所谓解决方案,就是把产品、技术或理论,不断地进行组合,来创造出满足用户需求的选择。


他们一般都是从应用程序的维度,负责某个解决方案的技术架构,主要偏业务系统,关注理解业务,梳理模型,设计模式,接口,数据交互等方面。


一般市面上的公司在自己没有研发能力或者预算不够的情况下,就会去寻求“解决方案”的存在。


这种架构师,通常我们还可以将之称为:业务领域专家、行业专家、资深顾问、业务架构师。


举例:


我的房子实际上已经设计好了,但是我的设计者只能或者说只会将他设计成商业用途,或者只会设计成住宅用途,这个就叫做解决方案。


建议:


这个架构师可能是开发者目标最明确也是难度最小的架构师,因为我们不需要将目光放在其他我们不需要的领域,只会将目光放在我需要的技术实现上。


比如我可能做了8-10年的互联网金融项目,那么我对于金融项目的每一个组件,每一个细节点都有了很好的把控。甚至说我能拿出成型的技术方案,不需要花费过多的人力物力。

 

在我们实际工作中,由于我们的公司规模问题,或者运营成本问题,可能一个人需要身兼数职。我们也经常会见到另一种比较简单的分类方式,他将架构师分为两种


1.软件架构师


软件架构师基本上是TSA+IA,这也是开发者最容易突破,最可能走上的一条道路,比如JAVA架构师、DotNet架构师等等。


因为现在大部分开发者更换工作的频率会相对频繁,甚至可能在不同的行业,不同的领域来回进行工作的变动,但是基础组件跟专项技术是不会变更的。


所以对于开发者来说,软件架构师更容易进阶。同时,软件架构师更加适应工作环境的变更。


工作职责:


在一个软件项目开发过程中,软件架构师负责将客户的需求转换为规范的开发计划及文本,并制定这个项目的总体架构,指导整个开发团队完成这个计划。主导系统全局分析设计和实施、负责软件构架和关键技术决策的人员。


2.系统架构师


系统架构师实际上是SA+TSA,实际上对于开发者来说,系统架构师更难突破,他更倾向于面对相对应的业务场景,给出基于自身技术体系的一套成熟型的解决方案。


在细分领域上来说,系统架构师可能更加专业。但是一旦离开原本的行业,适应度一般不如软件架构师。


系统架构师通常要求通晓软、硬件两方面的知识,所以它的知识体系也相对庞杂。


工作职责:


系统架构师是从系统的维度,负责整体系统的架构设计,对常见应用场景能马上给出最恰当的解决方案,同时要对所属的开发团队有足够的磨合度,能够评估自己的团队实现特定的功能需求需要的代价。


系统架构师负责设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单等。


现在,亲爱的读者们,你们知道你们的努力方向了吗?可以在公众号后面留言问题 ,我每篇文章都会抽取一条留言问题进行回答。不限于技术方向哦!算是给到读者的一些小福利。


备注:有小部分架构师定义内容来源互联网,已经找不到原作者了,特此说明。


相关文章
|
1月前
|
机器学习/深度学习 人工智能 架构师
【架构师】AI时代架构师必备技能
【架构师】AI时代架构师必备技能
|
2月前
|
存储 消息中间件 算法
深度思考:架构师必须掌握的五大类架构设计风格
数据流风格注重数据在组件间的流动,适合处理大量数据。调用返回风格则强调函数或方法的调用与返回,过程清晰明了。独立构件风格让每个构件独立运作,通过接口交互,提升灵活性和可重用性。虚拟机风格则模拟完整系统,实现资源的高效利用。
深度思考:架构师必须掌握的五大类架构设计风格
|
2月前
|
敏捷开发 缓存 架构师
Apache 架构师总结的 30 条架构原则
Apache 架构师总结的 30 条架构原则
23 0
|
2月前
|
设计模式 架构师 前端开发
架构师进阶篇-什么是架构师
架构师进阶篇-什么是架构师
58 0
|
4月前
|
人工智能 运维 架构师
数美科技首席架构师陈建:基于云上弹性的高可用实时风控架构实践
2023年10月31日-11月2日,2023云栖大会在中国杭州·云栖小镇举行,北京数美时代科技有限公司首席架构师陈建在【CloudOps云上运维专场】发表了题为《基于云上弹性的高可用实时风控架构实践》的主题演讲,从在线实时风控架构及高可用解决方案等方向做了分享。
|
5月前
|
Dubbo 应用服务中间件 Docker
阿里P8架构师谈微服务架构:Dubbo+Docker+SpringBoot+Cloud
什么是微服务架构呢?简单说就是将一个完整的应用(单体应用) 按照一定的拆分规则(后文讲述)拆分成多个不同的服务,每个服务都能独立地进行开发、部署、扩展。服务于服务之间通过注入RESTful api或其他方式调用。
|
5月前
|
Dubbo Java 应用服务中间件
阿里巴巴资深架构师深度解析微服务架构设计之SpringCloud+Dubbo
软件架构是一个包含各种组织的系统组织,这些组件包括Web服务器,应用服务器,数据库,存储,通讯层),它们彼此或和环境存在关系。系统架构的目标是解决利益相关者的关注点。
|
5月前
|
缓存 负载均衡 架构师
阿里资深架构师钟华曰:中台战略思想与架构实战;含内部实施手册
最近在读一本书,叫做《企业IT架构转型之道:阿里巴巴中台战略思想与架构实战》,在写此文时本书还没有看完,因为担心如果把书全部看完后再来写这篇文章,很多精彩的内容可能已经忘记了,所以中途先写一篇来分享给大家。
|
5月前
|
消息中间件 存储 缓存
阿里P8架构师带你“一窥”大型网站架构的主要技术挑战和解决方案
传统的企业应用系统主要面对的技术挑战是处理复杂凌乱、千变万化的所谓业务逻辑,而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理;前者的挑战来自功能性需求,后者的挑战来自非功能性需求;功能性需求也许还有“人月神话”聊以自慰,通过增加人手解决问题,而非功能需求大多是实实在在的技术难题,无论有多少工程师,做不到就是做不到。