技术架构的优化有一个重要目标就是为业务赋能，技术架构支持业务实现更多的能力，可以高效的支撑业务的扩展，服务于用户，最终间接的提升产品的价值。要作技术架构的优化，首先理解业务，业务理解不足，技术架构与业务的融合成本就会提升，甚至会因为架构优化的工作无法保证优化前后的业务一致性，而无法上线。对于业务的深度理解是架构优化是一个前置的，必要的工作。
在业务理解的目标，对于技术架构优化的过程可以产生以下几个帮助，最终实现对于业务的规范化的接入。
- 能力抽像：梳理业务流程的过程，是对于业务的不同的线条的梳理，对于不同的场景中，那些能力可以复用，复用的能力，那些是可以定制扩展的，那些是关键流程，这些都可以与具体的业务场景关联。
- 场景分割：用户使用业务过程，典型的形为是，输入 -> 逻辑处理 -> 输出，对于业务来讲是展现及交互，对于技术架构来说是场景（状态）的切换和事件的处理，场景如何分割，需要覆盖完整的流程，也要包含分支的流程。
- 基点确定：架构优化的过程，不论是重构还是架构的升级，都需要保证现有业务的一致性，不能活干完了，业务流程有缺失。业务的细节理解程度，决定了对于架构的依赖的细节，也决定了在新的架构之上，业务如何适配。现实的工作中的确存在业务流程变化的需求，这个需要看一下是具体的业务行为，还是架构行为，如涉及到架构的调整，同样也要看架构调整支撑的其它业务的影响。
总而言之，如果业务流程不清楚，技术架构的优化工作是很难开展的。业务流程是业务为达到特定的价值目标而由不同的功能模块分别共同完成的一系列活动。业务的活动之间不仅有严格的先后顺序限定，而且活动的时机、方式、责任能力等也都必须有明确的定义和边界，以使活动在不同功能模块之间进行调用及跳转成为可能。
活动与活动之间在时间和空间上有较大的区别。大部分可见的活动主要是客户价值的满足相关的活动。而大部分的不可见的活动主要是为业务支持的架构相关的活动。业务流程就是过程节点及执行方式有序组成的工作过程。
业务流程是有层次性的，这种层次体现在由上至下、由整体到部分、由抽象到具体的逻辑关系，这些关系都与技术架构相关。当产品中有多个业务时，业务之间相互支持，但又相互影响，业务之间即是依赖关系，也有协同关系，这些关系同样也会影响技术架构的设计。技术架构并不限定于一个产品的架构优化，一个模块需要有架构，一个业务也需要及架构，一个产品同样更需要有架构。
在实际的工作中只是关注负责的方向，了解相关的业务，只能说把工作做好，但是全局性就会缺失，多层面的需求就会无感知，技术方案的全面性就会不足。对于业务流程不同于架构的流程，架构的流程偏重于什么场景，提供什么样的能力，触发什么样的动作；而业务的流程更关注于，基于业务本身，在用户的什么样的选择下，完现什么样的能力，直到满足用户所需。
业务流程会有不同的分支，不同的线条，可交互可响应是最低的底线。而架构中的流程应该是基于不同的业务状态，设计实现可提供支持业务的相关能力，并且按层提供能力，并不是说一个架构，业务中的所有的事都要管，而是基于架构的设计目标，对业务进行抽像，解决的是某一层，某一段的，可抽像的，可统一管理的能力，否则的话，架构优化到最后就变成了业务优化，面向架构的研发又变成了面向业务的研发，固然业务重要，但技术架构赋能的思维一定要有。
同时业务流程也是分等级及频次的，基于核心的流程，用户可以完成业务提供的服务，辅助的流程，辅助的流程是在特定的场景生效，这样才可以作到有效的反馈和辑辑处理。架构的流程也是同样的，核心能力的构建是基础，辅助的流程构建也同样需要，这些只是影响优先完成的顺序，决定资源的投入，但最终是需要补齐，实现业务全流程支撑的覆盖。
