业务架构师通常是指一旦了解业务需要什么能力，就会向产品提出需求以设计产品的整体能力，产品会找到相应的技术owner并与之合作，例如从技术角度提供支持和意见。 这里的技术owner可以理解为我们的业务架构师。 从项目立项到项目交付，整个项目生命周期。 除了规划整个项目的能力外，还需要熟悉其他依赖业务模块的逻辑，从而提供连接整个项目的体系结构方案。
不是所有项目都是几百人的日子。 通常一个产品初期有很多投资，后期进行迭代。 每次迭代都需要技术奥内尔进行业务分解。 这里的技术奥内尔所做的和产品初期的责任其实很相似。 因此，架构师并不是只在大型项目中，而是每个产品都有自己的技术内核或业务架构师。
一句话概括起来，就是把项目导向成功的人
当业务架构师的工作确认业务诉求被诉求时，通常只有一个雏形。 例如，业务关键绩效指标可以提高用户的购买率，从数据的角度获取哪些可以提高购买率业务，展示自己的计划，并确认营销游戏。
产品在收到需求后进行细分，寻找业务体系结构进行交流。 此时体系结构开始介入。 要掌握项目背景和业务诉求这两个核心信息，清楚知道做项目为什么要做，怎么做。 中间诉求偏离核心诉求时，应及时沟通制止。 说了很多闲话，看起来有很多隐情，但毕竟他们和技术的思维逻辑不同。
识别核心模块的项目必须有核心模块和支持模块，架构师必须识别核心模块并重点投资这些模块。 例如，做新商品类型的销售，b端商品发布和c端商家的详细订单是我们的核心。 通常可以从供给侧和消费侧分割。 供给方是我们的信息提供方，通常是b方的数据，例如商品发表、isv商品等，这些是数据的输入方。 消费者方面是用户交易购买链接，交易通常是核心。
组织标识区域边界的核心链接后，必须规划每个模块的作用。 每个模块的作用都很明确，但往往存在中立的模块，这些信息可以放在a模块中，也可以放在b模块中。 在这种情况下，您需要非常深入地了解AB模块，并从项目的角度规划总体方向来选择最佳模块。 为了做充分的比较，通常这是硬骨头，在和AB模块交流的时候，他们一定有各种尖锐的问题。
另一个可能认为放了AB中的一个模块，但AB不同意。 出于他们的职责和计划，我拒绝了这个方案。 此时，您必须再次查看自己的体系结构设计方案是否合理，是否对其他模块有真正充分的了解。 在这里，您通常可以与每个模块的所有者在线沟通，并征求他们的意见。
每个串联的模块在这个微服务时代根据各自的职责划分系统。 因此，在完成一个项目时，需要多个部门合作，各模块在各自的职能内进行需求分解。 他们知道的是整个项目中的一个，此时，需要连接所有相关的业务模块，从整体角度设计结构方向，规范基础方案，同时与各个模块联系，确保有人最了解整个项目方案业务建设修订者作为技术模块的对接负责人，需要对各模块的责任进行修订，同时进行业务与产品方面的沟通。
将各个模块合并后，将输出比较完整的体系结构方案。 体系结构方案划分了每个模块的职责，并定义了每个模块的链接，包括产品发布的系统链接、产品详细展示的链接和用户订购的链接。 通过这些链接，可以指导各模块的技术协作工作。
识别项目风险并合并各模块后，对整体链接很熟悉。 此时，必须分析核心的风险点。 例如，在有某个模块的情况下，可能有xxx的问题。 此外，两个系统之间可能存在数据不匹配。 通常，您可以从数据一致性风险、资本损失风险和高并发流量风险等角度识别项目中存在的风险。
确定风险后，及时与TL、PM、业务沟通。 既有运用上可以避免的风险，也有业务上必须承认这些风险的风险。 这些发生时，如何运用等。
模块深入各个核心模块的评分和评分评审，在开工前识别了评分设计问题。 毕竟架构师是最了解项目的人，可以从多个角度为各个模块的人员提供技术指导。
最了解项目的人一定知道哪个是重点，哪个场景需要重点测试。 在测量得分时，需要提供更广泛的维度指导。
积极向上的业务诉求总是在变化，设计时可以与业务多沟通，了解业务发展，根据整个项目的情况进行进一步的规划设计。 例如，业务目前只用于a行业，所以都只与a行业的特性有关。 但是，实际运行后，也需要立即使用b行业。 此时，在设计时考虑扩展，沉淀了基础核心能力，Web行业也变得非常快且容易使用。
核心还是要多思考，多沟通。
从业务诉求的确认到风险的确定，此时架构师正在对各个系统的作用进行规划设计，后续的各个模块可以按照计划进行细分设计。 在此，就各模块的分类和测量时间以及测试发行、业务的可用日期与PM约定。 当然，架构师的作用并不仅限于此，而且从项目开始到交付都需要深入参与，因此架构师通常不会花费大量的编码时间，大部分时间都花在项目交流上。
有些人可能觉得这样做和广告没什么区别，但自己实际编码的时间这么少，时间都花在项目管理上了。 这样想的话，我们换个角度来考虑吧。
架构师需要仔细了解整个项目的设计和细节。 虽然不参与编码工作，但程序设计来自于你的架构师的存在。 除了合并整个项目，还有保障项目成果。 如果项目失败了，再好的投资和再强的编码都是浮云。 只有产生结果的架构师，公司需要的架构师才花了很多时间在体系结构上投资
设计和会议上，也抽不了更多的时间进行编码了，项目的各个阶段都会有一大堆的会议等着参加，如果给自己安排任务非常有可能成为瓶颈架构师不仅要掌握技术还要了解业务，不懂业务的架构发展通常非常有限，没有业务输入怎么做好规划，业务与技术是要结合在一起的，技术设计再牛也要满足业务诉求才有用要思考下写代码难还是规划设计难以上就是最近在项目开发上的一点总结思考，欢迎沟通讨论！！！