01

什么是业务架构

【资料图】

业务架构是基于业务的需求和目标的信息输入，定义系统的各个部分的核心职责和协作方式，持续的追求系统的可维护性，从而提升整个系统的投入回报，这就是业务架构的定义。

这里面有四个关键词核心职责、协作方式、可维护性、投入回报。核心职责和协作方式，指的是我们对系统各个部分的定义；可维护性，是我们在做业务架构过程中持续的追求的一个目标；投入回报，就是我们做业务架构的最终收益。

关注我，从技术到产品，样样精通

02

目标与收益

我们在做业务架构的过程中有三个重要的目标。

1、识别有效的需求。这也是我们在需求分析阶段面临的最大的挑战。我们会面临很多很多的这种伪需求，甚至是伪装成需求的方案，我们都需要识别出来。

2、守护系统的可维护性。这也是我们在方案设计阶段面临的挑战。一方面我们需要保证系统对业务的表达是准确的，另外一方面我们也需要考虑系统的演化是符合业务发展的诉求。

3、准确的传递设计意图。这需要确保我们最终拿到的系统，是业务想要的。

基于这三个目标，我们可以有三方面的收益。

1、降低做无意义需求的可能性。一方面我们可以避免无意义的投入，另外一方面，我们可以把这些机会成本转化成做更有意义的事情。

2、提升系统的迭代，而不是重构的可能性。重构就意味着我们过去做错了，我们过去的付出就打水漂了。如果我们是迭代，就意味着我们是有计划的进行系统的能力的扩展。迭代就意味着是在过去对未来业务的预判的基础上，并且我们的预判相对准确。

3、显著的提高设计决策传递的有效性和效率。在我们系统设计的过程中，我们会参加需求的分析会， PRD 的评审会，各种各样子的沟通会。这些会议上，我们经常会把时间花在名词的解释上，理解的对焦上，甚至有些时候因为理解的不一致而导致我们决策错误。业务架构就能够很好的避免我们对业务概念的理解的不一致，从而降低我们在沟通协作方面所消耗的损耗。

既然都是架构工作，那业务架构和技术架构又有什么不同呢？

业务架构的核心是面向业务人员，衔接业务人员与开发人员之间的关系，确保我们的业务的实现的一致。技术架构更多的是从技术问题出发，面向技术人员，解决技术人员面临的技术挑战。

03

设计原则

在我们做业务架构的过程中，有三个比较重要的原则。

1、有限信息决策原则

我们在做业务分析和系统设计的过程中，必然不会拿到百分之百的信息，不可能像上帝视角那样，做出百分之百正确的决策。我们可能拿到了百分五六十的信息，这时候就需要去做决策。一方面我们需要在有限的信息下及时的去做出决策，另外一方面，我们需要在有限的信息下对业务的未来发展做一些预判，把这些预判植入到我们的系统的扩展点，以应对未来业务的发展。

2、准确性比正确性更重要原则

追求正确性就意味着我们每一个决策都需要得到证明，这样就会使我们的业务决策者和方案决策者陷入了一个做证明题的陷阱，他就不再是去分析系统，做出系统设计的决策，而是需要证明自己的决策是正确的。这样，他的设计意图就发生了变化。所以说，准确性比正确性更重要。

准确性是指我们明确的知道有什么样的讯息，我们有什么样的业务背景，这些信息哪些是确定性的，哪些是不确定性的，我们准确的知道，哪些可以准确的涉及到系统里，并且固化在系统里，哪些是基于我们的业务预判去做的一些扩展的假设。这样，我们在做决策的时候是非常准确的，能够描述出我们系统哪些部分是相对固定稳定的，哪些部分将来是要变的。对于系统设计的具体实现阶段，就有了一个更准确的指导。

3、少即是多原则

我们在判断一个事物的复杂度的时候，其实有两个重要的维度。第一个维度是元素的多少，第二个维度是元素之间关系的多少。这类关系我们不用复杂来描述，是因为多和少是可以量化去判断的。当我们去设计一个系统的时候，系统中的元素个数越少，关系连线的个数越少，系统是越简单的。反之，我们元素的个数越多，元素之间的关系连线越多，我们的复杂度越高。业务架构的原则少即是多，指的就是业务元素的个数，元素之间的关系要尽可能的少，用更少的元素和元素之间的关系来实现我们的业务目标，解决我们的业务问题。

4、复杂度守恒原则

这个是什么概念？是指我们没办法通过业务架构系统设计降低业务本身的复杂度。很多时候我们经常会陷入一个误区，我们通过系统的设计，通过解耦的操作来让系统变简单了，我们就认为我们降低了业务的复杂度。这个理解是不准确的。业务本身的复杂度，它是客观存在的，并且这是必然我们业务需要去承担的复杂度。这个复杂度是映射到系统中，我们是不可能把复杂度抹去的，只是将复杂度进行了重新的整理，分而治之，将大问题划分成小问题，转移在各个系统的组件的各个部分去。所以，复杂度并不是因为我们的设计而降低了，而是复杂度被我们控制住，放在了更有序的环境里面。我们系统没有因为从现实世界到系统的转化过程中间去增加它的复杂度，也是业务架构本身更多的是控制复杂度，不引入新的复杂度，而不是消灭业务本身的复杂度。

04

业务架构评价标准

我们如何来去判断业务架构做的好还是不好？首先需要锚定一个时间周期，是一个项目的迭代周期，是一个季度的周期，或者是一个年度的周期都可以。但我们要持续的在这些项目系统演化的过程中间，持续的去做业务架构的判断，以识别过去做的是否准确合理，判断的是否准确。基于这些时间周期，我们可以去做三个维度方面的判断。

1、判断我们过去的需求识别是否准确，我们有没有将真正的需求做出来，我们有没有将伪需求做进系统里。

2、看我们过去的预判准不准，看我们做了多少重构的项目，还是我们都是按照计划迭代的。如果我们的项目计划总是被打乱，我们的项目总是方案总是持续的被修改，说明我们的业务架构其实做的是不够好的。

3、看执行好不好，看我们的技术实现的方案与我们的业务设计的表达是否一致，开发人员的理解、对业务的理解和他设计的详细的技术方案，是否准确的表达了我们的业务行为。

总的来说，业务架构设计是系统研发过程中，衔接业务人员和研发人员的重要工作，对系统的研发成本，甚至系统的成败有着重要的影响。重视业务架构，企业和团队将获得显著的收益。

推荐书单《程序员的思维修炼》是菜根老谭结合自己的工作经历和对这个岗位发展的认知而专门开辟的一个专栏，旨在分析程序员的职业发展的过程中我们应该锻炼哪些思维意识，如何去合理正确的看待事物，如何形成适合自己发展的思维体系。本专栏既是对过去思考的总结，也是对自己发展所具备的能力的思考，希望这些内容能陪我成长，帮大家解疑答惑。 该专栏首发今日头条，关注我的同名头条号获取更及时的内容推荐。

同时，微信为菜根老谭开通了视频号，配合着一些短视频，讲讲产品研发的那点事，分析产品研发过程中出现的问题以及思考。

更多精彩在公众号对话框输入以下关键词查看更多优质内容！ 研发体系|产品规划|产品经理|项目管理 |思维修炼技能图谱| 商业分析工具|产品知识地图|大数据|数字化转型 中台|思维工具|低代码|企业架构|数据中台