业务架构师职责

灰太狼 2022-10-06 10:59 437阅读 0赞

## 什么是业务架构师 ##

通常来说业务想清楚了需要什么能力，就会提需求给产品开始设计整个产品能力，产品同时也会找到对应的技术owner 协助进行，如提供技术角度的支持与意见。 这里的技术owner就可以理解为我们的业务架构师。 从项目立项到项目交付，贯穿整个项目生命周期。不仅要规划好整体项目能力，而且要熟悉其他依赖的业务模块逻辑，可以给出串联整个项目的架构方案。  
并不是所有的项目都是几百人日的，通常一个产品初期会有大量的投入，后期会进行迭代，每次迭代都需要技术owner进行业务拆解，这里的技术owner做的事情和产品初期的时候职责其实也是类似的，所以架构师并不是说只有在大型项目才有，而是每个产品都有自己的技术owner也就是业务架构师。  
一句话总结就是：带项目走向成功的那个人

## 业务架构师的工作 ##

### 确认业务诉求 ###

业务诉求出来的时候通常只有一个雏形，比如说业务的kpi是拉升用户购买率，针对购买率业务会从数据的角度获取到哪些是可以提升的，然后给出自己的规划，确认好营销玩法。  
产品收到需求后会进行细化，会找业务架构沟通，此时架构就要开始介入了，要掌握项目背景，和业务诉求这两个核心信息，做个项目要清楚明白的知道为什么要做和要做成什么样子。 如果中间的诉求偏离了核心诉求，应该及时沟通制止。 多个业务唠嗑唠嗑，你会发现很多隐藏点的，毕竟他们和技术的思维逻辑是不同的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JlbGlldmVyMTIz_size_16_color_FFFFFF_t_70_pic_center]

### 识别核心模块 ###

一个项目肯定是有核心模块和支撑模块的，架构师要识别出核心模块，对这些模块重点投入。比如要做一个新的商品类型销售，那么B端商品发布和C端商详下单就是我们的核心。通常我们可以从供给端和消费端进行拆分。供给端就是我们的信息提供方，通常是B端的数据，如商品发布，isv商品等等，这些是数据的输入方。 消费端就是用户交易购买链路了，交易通常都是核心。

### 识别领域边界 ###

核心链路整理好后，需要规划好各个模块职责，虽说有的各个模块的职责是很明确的，但是很多时候会存在中立的模块，这些信息放A模块也可，放B模块也可，此时得对AB模块有非常深的了解，并且得从项目的角度规划整体方向出发选择最合适的模块。要做好充分的对比，通常这块是硬骨头，同AB模块沟通的时候他们肯定会有各种犀利的问题的。  
还有一种可能就是你觉得放AB中的一个模块，但是AB都不同意，从他们的职责和规划上来说拒绝了这个方案，此时就得再重新看看自己架构设计的方案是否合理了，是否对其他模块真的有足够了解了，这里通常可以和各个模块的owner先进行线下沟通，寻求他们的意见。

### 串联各个模块 ###

在这微服务时代，会根据不同的职责进行系统拆分，这样会导致我们完成一个项目的时候需要多个部门协同配合，每个模块都会在各自职能内进行需求拆解，他们所了解的是整个项目的一块，此时需要有人将所有涉及到的业务模块给串联起来，从整体的视角出发设计架构方向，规范基础方案，同时同各个模块进行沟通，保证有人是最清楚整个项目方案的。业务架构师作为技术模块对接人，需要规划好各个模块的职责，同时需要同业务和产品方进行沟通。  
串联好各个模块后会有一个比较完成的架构方案输出了，架构方案上划分了各个模块的职责，定义了各个模块的链路，如商品发布的系统链路，商详展示的链路，用户下单的链路等。 从这些链路上可以指导各个模块的技术进行系分工作。

### 识别项目风险 ###

串联好各个模块后，对整体链路就非常熟悉了，此时得分析下核心的风险点，比如某个模块在一些场景下可能会有xxx问题，还有两个系统间还会存在数据不一致的问题。 通常我们可以从数据一致性风险，资损风险，高并发流量风险等角度出发识别项目中存在的风险。  
风险识别出来后要同TL，PM，业务及时沟通，有些风险可以从操作上规避，有些则需要业务上认可这些风险，如果出现这些要如何进行操作等等。

### 深入模块 ###

深入各个核心模块的系分和测分评审，在开工前就识别出系分设计的问题，毕竟架构师可是最了解项目的人，可以从多种角度给各个模块的人员提供技术指导。  
最了解项目的人肯定也是知道哪些是重点，哪些场景需要重点测试，测分的时候需要提供更广维度的指导。

### 前瞻性 ###

业务的诉求总是多变的，在设计的时候就可以与业务多沟通，了解业务的发展，结合整体项目的情况作出进一步的规划设计，比如说业务目前只会给A行业用到，所以都只关系A行业的特性。但是实际运行后很快B行业也需要使用了，此时在设计的时候考虑好拓展，沉淀出基础核心能力，B行业也可以非常快速简单的就用上了。  
核心点还是需要多思考，多沟通。

--------------------

## 总结 ##

从确认业务诉求到识别风险，此时架构师已经对各个系统的职责都进行了规划设计，后续各个模块按照方案进行系分设计就好，这里会同PM约定好每个模块的系分和测分时间，以及提测发布，业务可用日期。 当然架构师职责肯定不止步于此，从项目开始到交付都需要深入参与，所以通常架构师不会投入很多编码时间，大部分时间在项目沟通上。

可能有的人会觉得这样做就和PM没什么区别了，自己实际编码的时间这么少，时间都花在了项目管理上了。如果这样想的话，我们换个角度来思考下。

*  架构师需要非常了解整个项目的设计与细节，虽然不参与编码工作，但是方案设计来自于你
 *  架构师的存在除了串联整个项目还有就是要保障项目的成果，如果项目失败了再好的投入与再强的编码都是浮云，能拿结果的架构师才是公司需要的
 *  架构师投入了大量的时间在架构设计和会议上，也抽不了更多的时间进行编码了，项目的各个阶段都会有一大堆的会议等着参加，如果给自己安排任务非常有可能成为瓶颈
 *  架构师不仅要掌握技术还要了解业务，不懂业务的架构发展通常非常有限，没有业务输入怎么做好规划，业务与技术是要结合在一起的，技术设计再牛也要满足业务诉求才有用
 *  要思考下写代码难还是规划设计难

以上就是最近在项目开发上的一点总结思考，欢迎沟通讨论！！！

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2JlbGlldmVyMTIz_size_16_color_FFFFFF_t_70_pic_center]: /images/20221005/f49a31e9f61745ec97fa349b6f7f0d11.png