大家好,又见面了,我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。
Jetbrains全系列IDE稳定放心使用
什么是业务架构师
通常来说业务想清楚了需要什么能力,就会提需求给产品开始设计整个产品能力,产品同时也会找到对应的技术owner 协助进行,如提供技术角度的支持与意见。 这里的技术owner就可以理解为我们的业务架构师。 从项目立项到项目交付,贯穿整个项目生命周期。不仅要规划好整体项目能力,而且要熟悉其他依赖的业务模块逻辑,可以给出串联整个项目的架构方案。
并不是所有的项目都是几百人日的,通常一个产品初期会有大量的投入,后期会进行迭代,每次迭代都需要技术owner进行业务拆解,这里的技术owner做的事情和产品初期的时候职责其实也是类似的,所以架构师并不是说只有在大型项目才有,而是每个产品都有自己的技术owner也就是业务架构师。
一句话总结就是:带项目走向成功的那个人
业务架构师的工作
确认业务诉求
业务诉求出来的时候通常只有一个雏形,比如说业务的kpi是拉升用户购买率,针对购买率业务会从数据的角度获取到哪些是可以提升的,然后给出自己的规划,确认好营销玩法。
产品收到需求后会进行细化,会找业务架构沟通,此时架构就要开始介入了,要掌握项目背景,和业务诉求这两个核心信息,做个项目要清楚明白的知道为什么要做和要做成什么样子。 如果中间的诉求偏离了核心诉求,应该及时沟通制止。 多个业务唠嗑唠嗑,你会发现很多隐藏点的,毕竟他们和技术的思维逻辑是不同的。
识别核心模块
一个项目肯定是有核心模块和支撑模块的,架构师要识别出核心模块,对这些模块重点投入。比如要做一个新的商品类型销售,那么B端商品发布和C端商详下单就是我们的核心。通常我们可以从供给端和消费端进行拆分。供给端就是我们的信息提供方,通常是B端的数据,如商品发布,isv商品等等,这些是数据的输入方。 消费端就是用户交易购买链路了,交易通常都是核心。
识别领域边界
核心链路整理好后,需要规划好各个模块职责,虽说有的各个模块的职责是很明确的,但是很多时候会存在中立的模块,这些信息放A模块也可,放B模块也可,此时得对AB模块有非常深的了解,并且得从项目的角度规划整体方向出发选择最合适的模块。要做好充分的对比,通常这块是硬骨头,同AB模块沟通的时候他们肯定会有各种犀利的问题的。
还有一种可能就是你觉得放AB中的一个模块,但是AB都不同意,从他们的职责和规划上来说拒绝了这个方案,此时就得再重新看看自己架构设计的方案是否合理了,是否对其他模块真的有足够了解了,这里通常可以和各个模块的owner先进行线下沟通,寻求他们的意见。
串联各个模块
在这微服务时代,会根据不同的职责进行系统拆分,这样会导致我们完成一个项目的时候需要多个部门协同配合,每个模块都会在各自职能内进行需求拆解,他们所了解的是整个项目的一块,此时需要有人将所有涉及到的业务模块给串联起来,从整体的视角出发设计架构方向,规范基础方案,同时同各个模块进行沟通,保证有人是最清楚整个项目方案的。业务架构师作为技术模块对接人,需要规划好各个模块的职责,同时需要同业务和产品方进行沟通。
串联好各个模块后会有一个比较完成的架构方案输出了,架构方案上划分了各个模块的职责,定义了各个模块的链路,如商品发布的系统链路,商详展示的链路,用户下单的链路等。 从这些链路上可以指导各个模块的技术进行系分工作。
识别项目风险
串联好各个模块后,对整体链路就非常熟悉了,此时得分析下核心的风险点,比如某个模块在一些场景下可能会有xxx问题,还有两个系统间还会存在数据不一致的问题。 通常我们可以从数据一致性风险,资损风险,高并发流量风险等角度出发识别项目中存在的风险。
风险识别出来后要同TL,PM,业务及时沟通,有些风险可以从操作上规避,有些则需要业务上认可这些风险,如果出现这些要如何进行操作等等。
深入模块
深入各个核心模块的系分和测分评审,在开工前就识别出系分设计的问题,毕竟架构师可是最了解项目的人,可以从多种角度给各个模块的人员提供技术指导。
最了解项目的人肯定也是知道哪些是重点,哪些场景需要重点测试,测分的时候需要提供更广维度的指导。
前瞻性
业务的诉求总是多变的,在设计的时候就可以与业务多沟通,了解业务的发展,结合整体项目的情况作出进一步的规划设计,比如说业务目前只会给A行业用到,所以都只关系A行业的特性。但是实际运行后很快B行业也需要使用了,此时在设计的时候考虑好拓展,沉淀出基础核心能力,B行业也可以非常快速简单的就用上了。
核心点还是需要多思考,多沟通。
总结
从确认业务诉求到识别风险,此时架构师已经对各个系统的职责都进行了规划设计,后续各个模块按照方案进行系分设计就好,这里会同PM约定好每个模块的系分和测分时间,以及提测发布,业务可用日期。 当然架构师职责肯定不止步于此,从项目开始到交付都需要深入参与,所以通常架构师不会投入很多编码时间,大部分时间在项目沟通上。
可能有的人会觉得这样做就和PM没什么区别了,自己实际编码的时间这么少,时间都花在了项目管理上了。如果这样想的话,我们换个角度来思考下。
- 架构师需要非常了解整个项目的设计与细节,虽然不参与编码工作,但是方案设计来自于你
- 架构师的存在除了串联整个项目还有就是要保障项目的成果,如果项目失败了再好的投入与再强的编码都是浮云,能拿结果的架构师才是公司需要的
- 架构师投入了大量的时间在架构设计和会议上,也抽不了更多的时间进行编码了,项目的各个阶段都会有一大堆的会议等着参加,如果给自己安排任务非常有可能成为瓶颈
- 架构师不仅要掌握技术还要了解业务,不懂业务的架构发展通常非常有限,没有业务输入怎么做好规划,业务与技术是要结合在一起的,技术设计再牛也要满足业务诉求才有用
- 要思考下写代码难还是规划设计难
以上就是最近在项目开发上的一点总结思考,欢迎沟通讨论!!!
发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/182890.html原文链接:https://javaforall.cn
【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛
【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...